Russ, thanks for your review. Michael, thanks for addressing Russ’s comments. I have entered a No Objection ballot.
Alissa > On Oct 3, 2017, at 12:57 PM, Russ Housley <[email protected]> wrote: > > 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 | | | | | > +-------------+--------+----------+--------+----------+-----+-------+ > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
