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

From: Robert Sparks <[email-masked]>
Date: Wed, 11 Mar 2020 11:11:22 -0500

This is a Working Group Last Call for draft-ietf-stir-cert-delegation-02

Please send your comments to the list or the chairs by Wed Apr 1. (This 
LC is three weeks because of the proximity to the IETF 107 week).

RjS

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Mar 2020 17:46:01 +0000

I just re-read the doc.  Looks good.  (I'm not a STIR/telephony person, I'm a PKI person :)

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Mar 2020 17:29:52 -0400

The US FCC released a document earlier this week: https://docs.fcc.gov/public/attachments/DOC-362932A1.pdf <https://docs.fcc.gov/public/attachments/DOC-362932A1.pdf>

This part is relevant to this document (it is arguing that STIR/SHAKEN is ready for mandatory implementation):

    We disagree with those commenters who argue that we should not move
    forward with a STIR/SHAKEN implementation mandate.  First, we
    specifically disagree with the argument that we should delay a
    mandate while industry develops technical solutions to allow the
    STIR/SHAKEN framework to accommodate certain more challenging
    scenarios.  According to some commenters, the standards for
    attestation do not fully account for the situation where an
    enterprise subscriber places outbound calls through a voice service
    provider other than the voice service provider that assigned the
    telephone number.  In such scenarios, commenters claim, it would be
    difficult for an outbound call to receive "full" or "A" attestation
    because the outbound call will not pass through the authentication
    service of the voice service provider that controls the numbering
    resource.  We are optimistic that standards bodies, which remain
    engaged on the impact of STIR/SHAKEN on more challenging use cases
    and business models, will be able to resolve those issues just as
    they have overcome numerous other barriers to caller ID
    authentication so far.  For instance, the Internet Engineering Task
    Force (IETF) has proposed a certificate delegation solution that
    would allow the carrier who controls the numbering resource to
    delegate a credential that could be used to sign calls regardless
    of which  network or administrative domain handles the outbound
    routing for the call.  Further, granting a delay until standards
    bodies address every possible issue would risk creating an
    incentive for some parties to draw out standards-setting processes,
    to the detriment of widespread STIR/SHAKEN implementation.  In any
    event, the TRACED Act requires that voice service providers
    implement the STIR/SHAKEN framework in their IP networks and so
    the point is moot.
    
Russ

> On Mar 11, 2020, at 12:11 PM, Robert Sparks <[email-masked]> wrote:
> 
> Please send your comments to the list or the chairs by Wed Apr 1. (This LC is three weeks because of the proximity to the IETF 107 week).
> 
> RjS
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Mar 2020 16:57:26 -0400

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 20 Mar 2020 00:09:39 +0000

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 <[email-masked]> on behalf of Russ Housley <[email-masked]>
Date: Friday, March 13, 2020 at 1:57 PM
To: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] WGLC: draft-ietf-stir-cert-delegation-02

Section 4, para 1, says:

Section 4, para 4, says:

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

I suggest:

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Mar 2020 00:22:31 +0000

>  I’m not entirely sure where the TLS subcerts draft is

WGLC soon I believe.