Re: [Gen-art] Genart last call review of draft-ietf-anima-voucher-05

[Alissa Cooper <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art