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

[Russ Housley <[e-mail]>]

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 |        |          |                   |             |
   +-------------+--------+----------+--------+----------+-----+-------+