Re: [stir] WGLC: draft-ietf-stir-cert-delegation-02

[Russ Housley <[e-mail]>]

Process question:  This is intended to become a Standards-track RFC, and there are a bunch of ACME Internet-Drafts referenced in Section 8.  Do we want to wait for them to get further in the process, or do we want this document to sit in the RFC Editor queue waiting for them to catch up?


Section 4, para 1, says:

  The parent certificate needs to have its CA boolean set to
   "true", indicating that that it can sign certificates.

This is correct, but the enough context.  I suggest:

  The parent certificate needs to contain a basic constraints
  extension with the cA boolean set to "true", indicating that
  the subject can sign certificates.

Also, later in the same paragraph, it says:

   Every STIR delegate certificate identifies its parent
   certificate with a standard [RFC5280] Authority
   Key Identifier.

Please add "extension" to the end of that sentence.


Section 4, para 4, says:

   Delegate certificates may themselves be issued with the CA boolean
   set to "true" so that they can serve as parent certificates to
   further delegates; effectively, this delegate certificate is a cross-
   certificate, as its issuer is not the same as its subject.

I would like to see similar context added here too,  And, I do not see how this create a cross-certificate, which happens when two CAs each issue a certificate to each other:

   +------+             +------+
   |      |------------>|      |
   | CA 1 |             | CA 2 |
   |      |<------------|      |
   +------+             +------+

I suggest:

   Delegate certificates may also contain a basic constraints
   extension with the cA boolean set to "true", indicating that
   they can sign subordinate certificates for further delegates.


Section 4.1, para 4: s/surely sufficient/sufficient/


Section 5, para 1: I am unsure what is meant by "baseline STIR behavior".  Is this [RFC8226]?


Section 6, para 1: s/AKID object/Authority Key Identifier extension/


Section 7, para 1:  s/PEM encoded/PEM-encoded/


Section 7, para 1: I think there is a better way to talk about AKID/SKID order.  I suggest:

   The list begins with the certificate used to sign the PASSporT,
   followed by its parent, and then any subsequent grandparents,
   great-grandparents, and so on.  The key identifier in the Authority
   Key Identifier extension in the first certificate MUST appear in
   the Subject Key Identifier extension in the second certificate.
   The key identifier pairing MUST match in this way throughout the
   entire chain of certificates.  Note that ACME [RFC8555] requires the
   first element in a pem-certificate-chain to be an end-entity
   certificate; however, STIR relaxes this requirement, because CA
   certificates are permitted to sign PASSporTs, so for STIR, the first
   element in a pem-certificate-chain MAY be a CA certificate.


Section 8, para 1: s/may delegate from it as/may delegate resources from it as/


Section 8, para 1: s/the CA boolean set to "true"/a basic constraints extension with the cA boolean set to "true"/


Section 8, para 2: s/CA's root certificate/CA's trust anchor/


Section 8, para 3: s/CPS/CPS [RFC3647]/