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

["Peterson, Jon" <[e-mail]>]

To the process question, those Info references should be coming along soon – we think the ACME authority token drafts are mature at this point, and acme-star seems to be in Pub Req already.  I’m not entirely sure where the TLS subcerts draft is, but the text about that isn’t too crucial, and if push comes to shove we could drop it.

I will implement the other fixes you recommend below – they all look great. When it comes to the definition of “cross certification”, I’m sure I stole that from some relevant RFC (that the term signifies a CA cert whose issuer is not the same as its subject), but I’m happy to go with your text. The reference in section 5 to “baseline STIR behavior” is to the definition of an authentication service in RFC8224: I’ll clarify that. Your fix to section 7 is also appreciated, as are the many nits.

Thanks,

Jon Peterson
Neustar, Inc.

From: stir <[e-mail]> on behalf of Russ Housley <[e-mail]>
Date: Friday, March 13, 2020 at 1:57 PM
To: IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] WGLC: draft-ietf-stir-cert-delegation-02

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]/