要約

  • RFC 3125は、globally uniqueなpolicy identifierとdefinitive specificationのhashを署名処理へ結び付け、verifierがどの規則を実行するかを特定できるようにした。
  • signatureとpolicy hashの一致は結論ではない。signing period、commitment、certificate、revocation、timestamp、attribute、algorithm constraint、契約上の承認、transaction outcomeは別のtestだった。

signature valueの外側に規則があった

digital signatureは、あるkeyとalgorithmの下でbytesが検証できるかを答える。取引はさらに、certificateが用途に適するか、許された期間に作られたか、approvalかreceiptか、どのrevocation evidenceやtimestampが必要かを問う。

2001年9月のExperimental RFC 3125は、creationとvalidationを定める規則集合をsignature policyと呼んだ。legal/contractual contextは特定policyを要件に合うものとして認め得る。しかしRFCの公開自体が、その承認を作るわけではない。

Policy Issuer、Signer、Verifier、Arbitrator、Trusted Service Providerは別roleだった。issuerはbusiness needに合う規則を定め、signerは参照policyへのcommitmentを表し、verifierはそのpolicyで検証する。arbitratorは後のdisputeで再検証できる。一つのartifactはauthorityを一つにしない。

OIDはrulebookへのpointerだった

参照policyはOIDで識別され、specificationが存在し、一つのdefinitive formがunique binary encodingを持つ必要があった。signerはagreed algorithmによるhashを出し、verifierがcheckした。

OIDはeditionのidentityを選び、hashはexact bytesを固定する。optional ASN.1 structureとDERはmachine-readable formをdeterministicにした。曖昧な名称や翻訳が別版を隠す危険を減らした。

しかしOIDはapproval markではない。hash一致は同じencoded policyを使った証拠であり、issuerの権限、外部procedureの履行、裁判所やpartnerの承認を証明しない。そのためhuman-readable formも必要とされ、制度がpolicyを評価する余地が残された。

validはparameter付きの結論になった

structured policyにはsigning period、common rules、commitment rulesがあった。period外のsignatureは暗号的に正しくてもpolicy creation ruleに反し得る。

common rulesはsigner/verifier duty、certificate trust、timestamp trust、attribute trust、algorithm constraintを定義できた。commitment ruleは特定の約束に条件を割り当てる。approvalとreceiptは同じ証拠を要求しないかもしれない。message semanticsにcommitmentが含まれる場合もあった。

verifierはpolicy versionとcommitmentを選び、それからtrust pathを評価する。同じchainでも用途が違えば結論が変わる。algorithm deadlineを越えれば同じkeyにも別判断が出る。「valid」だけでは重要なparameterが消える。

trust serviceは部分的なreceiptを渡した

CA、RA、repository、TSA、certificate-status responder、attribute authorityが支援できた。policyはtrust point、path constraint、revocation、timestamp、roleを選べる。

certificateはkeyとidentity assertionを結ぶ。status responseはcertificateの状態、timestampはある時刻より前の存在、attributeはroleを支える。それぞれbounded evidenceであり、transaction commitment全体は決めない。

再現可能なvalidationには、policy、使ったresponse、時刻、software version、commitment ruleを残す必要がある。green resultだけでは、後のarbitratorがdecisionを再構成できない。

policy hashはprocedureを監視しなかった

CMSのmandatory signed/unsigned attributeやcertificate referenceはmachineで確認できる。他の条件はkey custody、internal approval、human processに存在し得る。

hashはrulebookを特定するが、そこに書かれた全procedureの実行を示さない。signerのpolicy commitmentはrepresentationであって万能telemetryではない。外部procedureには別logが必要である。

従って「OID Xの下でvalid」は、「署名権限があった」「相手が受諾した」「支払い済み」「履行完了」と同義ではない。それぞれ別のdecision ownerとevidenceを持つ。

algorithmにもhistoryがあった

RFCはprivate key protectionを重視し、algorithm strengthが低下するためmodular implementationを勧めた。policyはalgorithmとkey lengthを制約できる。

将来のreviewには、署名時のpolicy edition、timestamp、algorithm transition ruleが要る。後日のdeprecationだけで過去のevidenceを裁けない。

RFC 3126はlong-term signature format、RFC 3161はtimestampを扱った。RFC 2630、2634、2459、2560は当時のCMS、S/MIME、PKIX、status contextであり、RFC 5280と5652は後の系譜である。いずれもRFC 3125 deploymentを証明しない。

Experimental RFCはusage reportではなかった

conformance requirementはsigner/verifier systemがOIDで識別されたpolicyに従うことを求めた。これはconforming participantへの条件であり、参加者数の観測ではない。

史料から確認できる貢献は、policy identityを追跡可能にしたことだ。OID、definitive form、unique encoding、hash、commitment rule、trust conditionがchainを作る。adoption、interop、legal effectには別資料が必要である。

完全なreceiptはsigned object、signature、certificate、OID、policy bytes、hash、period、commitment、path、revocation、timestamp、attribute、algorithm、verifier outputと、policyを承認した外部agreementを含む。cryptographyは一つの式を閉じた。policyはどの式が意味を持つかを定めた。

出典

  1. https://www.rfc-editor.org/rfc/rfc3125.txt
  2. https://www.rfc-editor.org/info/rfc3125
  3. https://datatracker.ietf.org/doc/rfc3125/
  4. https://www.rfc-editor.org/rfc/rfc3126.txt
  5. https://www.rfc-editor.org/rfc/rfc2630.txt
  6. https://www.rfc-editor.org/rfc/rfc2634.txt
  7. https://www.rfc-editor.org/rfc/rfc2459.txt
  8. https://www.rfc-editor.org/rfc/rfc2560.txt
  9. https://www.rfc-editor.org/rfc/rfc3161.txt
  10. https://www.rfc-editor.org/rfc/rfc2119.txt
  11. https://www.rfc-editor.org/rfc/rfc5280.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt