Reviewer: Russ Housley Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-anima-voucher-05 Reviewer: Russ Housley Review Date: 2017-10-03 IETF LC End Date: 2017-10-112 IESG Telechat date: unknown Summary: Not Ready Major Concerns: Please do not reference RFC 2315. The is a full Internet Standard that should be used instead. Please reference RFC 5652, which goes back to PKCS#7 as follows: PKCS#7 --> RFC 2315 --> RFC 2630 --> RFC 3369 --> RFC 3852 --> RFC 5652 RFC 2315 only support signatures with the RSA algorithm. The signature value is the "result of encrypting the message digest and associated information with the signer's private key." RFC 5652 will support any known digital signature algorithm. Please reference it. In Section 6, the document says: The PKCS#7 structure SHOULD also contain all the certificates leading up to and including the signer's trust anchor certificate known to the recipient. Normally, the signer does not include the trust anchor certificate, so a bit of rationale is needed here. There are clearly situations where the trust anchor will not be known in advance, so that the the reason to include it. In Section 6, the document also says: The PKCS#7 structure MAY also contain revocation objects for any intermediate certificate authorities (CAs) between the voucher-issuer and the trust anchor known to the recipient. This is another place where RFC 5256 offers an improvement over PKCS#7. See Section 10.2.1 in RFC 5652, and see RFC 5940 for the information on OCSP responses. You might want to include CRLs or OCSP responses in a short-lived voucher so that the recipient does not need to fetch any revocation information to process the voucher. Section 6 needs to specify the content type that will be carried in SignedData. I believe that a new object identifier (OID) needs to be assigned. I'm not sure whether you want to assign an OID for JSON object or YANG structure. I can see where either one would work. Section 9 should be expanded to assign the OID for the content type: www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1. Minor Concerns: I think it would be very helpful to include a diagram something like this in Section 6. Perhaps all of the CMS discussion belongs in a separate subsection. I did this to see if everything that is needed was specified, and I learned that the eContentType was not defined. ContentInfo { contentType id-signedData, -- (1.2.840.113549.1.7.2) content SignedData } SignedData { version CMSVersion, -- always set to 3 digestAlgorithms DigestAlgorithmIdentifiers, -- Only one encapContentInfo EncapsulatedContentInfo, certificates CertificateSet, -- Signer cert. path crls CertificateRevocationLists, -- Optional signerInfos SET OF SignerInfo -- Only one } SignerInfo { version CMSVersion, -- always set to 3 sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs SignedAttributes, -- Required signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs UnsignedAttributes -- Optional } EncapsulatedContentInfo { eContentType !!! NOT SPECIFIED YET !!! eContent OCTET STRING -- the ietf-voucher } It would be very helpful to the implementer to say how each CMS field is used. You can copy that vast bulk of the information that you need from RFC 4108. In particular: - See RFC 4180, Section 2.1.1 for ContentInfo. - See RFC 4180, Section 2.1.2 for SignedData. - See RFC 4180, Section 2.1.2.1 for SignerInfo. - See RFC 4180, Section 2.1.2.2 for EncapsulatedContentInfo. Nits: In section 2: s/autonomically/automatically/ s/Registrar See/Registrar: See/ s/entity it is contacted by/entity to make contact/ In Section 6.1: s/in Section 4)./in Section 4./ In Section 8.1: s/no understand of time/no understanding of clock time/ s/clock accuracy then vouchers/clock accuracy, then vouchers/ I think the table in Section 5 could be more readable. I suggest: +-------------------+-------------------+-------------+ | Assertion | Registrar ID | Validity | +--------+----------+--------+----------+-----+-------+ Voucher | | | Trust | CN-ID or | | | Type | Logged | Verified | Anchor | DNS-ID | RTC | Nonce | +-------------+--------+----------+--------+----------+-----+-------+ |Audit | X | | X | | | X | +-------------+--------+----------+--------+----------+-----+-------+ |Nonceless | X | | X | | X | | |Audit | | | | | | | +-------------+--------+----------+--------+----------+-----+-------+ |Owner Audit | X | X | X | | X | X | +-------------+--------+----------+--------+----------+-----+-------+ |Owner ID | | X | X | X | X | | +-------------+--------+----------+--------+----------+-----+-------+ |Bearer | X | | wildcard | optional | |out-of-scope | | | | | +-------------+--------+----------+--------+----------+-----+-------+