Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-cert-delegation-03: (with DISCUSS and COMMENT)

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

Hi Benjamin,

Thanks as usual for the detailed read (and sorry as usual for the looongg RTT) - responses inline below. I hope the new version takes care of (most) of this.
    
    Despite the length of the list of numbered points, this document is
    actually in pretty good shape -- most of them just relate to
    clarifying/correcting how this document interacts with other documents
    rather than issues with the way this mechanism works.
    
    (1) Section 4 calmly asserts that "[i]n the STIR ecosystem, CA certificates
    may be used to sign PASSporTs", but I could not find this documented in
    RFCs 8224, 8225, or 8226.  If it is already documented somewhere, please
    provide a reference; if it is a new property of the architecture being
    asserted by this specification, we should be more clear about it, as
    well as how it is not entirely consistent with cryptographic best
    practice (see COMMENT).
    (It is perhaps unfortunate that RFC 8225 did not talk about (extended)
    key usage values suitable for signing PASSporTs, though it is probably
    not appropriate to start doing so in this document.)

This idea emerged from concerns expressed in the operator community about having to manage intermediate certs independently from the certs used to sign PASSporTs. We floated this as a possibility, but weren't sure how much uptake it would see in deployment - hence we were a little glib about it. We didn't want to rule it out, but nor did we think it required a ton more explication. 

I think on balance, though, after discussing with the WG, we can safely remove it, and explore later if people want it. So it's not in the new version.
    
    (2) We are introducing new entities that act as X.509 CAs with this
    mechanism.  Do we need to mandate that they provide CRLs/OCSP/etc. for
    making revocation information available?  ("This is already covered by
    RFC XXXX" is a fine answer, though it is probably worth a reminder in
    the text.)

I added a little text to Section 8 about the responsibilities for certificate revocation and so on that being a CA entails. Practically speaking, in the SHAKEN ecosystem for the USA, CRLs for all participating CAs are actually managed by a centralized policy administrator, so I don't think it's appropriate for this to be normative, but hopefully it helps.
    
    (3) I think we are missing some exposition about how an SPC TNAuthList
    value is treated as "encompassing" specific telephone numbers/ranges
    controlled by the provider to which that SPC is assigned (more than just
    a mention in passing that the CA has to have access to the industry
    database), such that the CA cert might have the SPC form of TNAuthList
    but the child certificate a different form.  I was also looking for some
    discussion of the related risk of skew if the database changes, but
    perhaps https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8226*section-10__;Kg!!N14HnBHF!vi9Kfx95R2gfLeC2KDeP2MWE1q4cbmh9rR9dyIytKeZKUL3UaBH9qsnrQ-c$ 
    cover that.  (It would be nice to have some data on the relative
    lifetime of database mappings and certificate lifetimes, though.)

I would have thought we said that a CA cert with an SPC TNAuthList can have a child EE cert with TNs in its TNAuthList in the first sentence of 4.1, but reading your comment below, I see that sentence needs to be reworded to make that explicit (which it hopefully is now). Yes, I think the existing reference to RFC8226 10.1 is intended to address database skew.
    
    (4) We seem to have an internal inconsistency about whether alternative
    certification paths are allowed -- Section 6 implies that it is a very
    rigid procedure (and Section 7 requires
    AuthorityKeyIdentifier/SubjectKeyIdentifier matching), but Section 8.2
    suggests the use of cross-signing and AIA for an alternate chain
    construction.

The whole bit about cross-signing there, much like the bit about letting CA certs sign PASSporTs, is something we've heard operators fret over, where they don't want to have to manage some huge keyring if they are getting TNs from 15 different carriers. So if an enterprise, say, inherits TN range A from Carrier1, and TN range B from Carrier2, we'd like to have a way to consolidate those into a single instrument, which is why we're interested in cross signing. That said, the text of 8.2 is pretty exploratory and non-normative in character, it is enumerating some things you could flesh out if you wanted to go down any of those paths; it is not intended to clobber the AKID/SKID matching in Section 7. I added some text to clarify that.
    
    (5) Section 9 contains a false statement that TLS subcerts has ways for
    the issuer of a (TLS) delegated credential to revoke that credential.
    https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-tls-subcerts-09*section-7.3__;Kg!!N14HnBHF!vi9Kfx95R2gfLeC2KDeP2MWE1q4cbmh9rR9dyIytKeZKUL3UaBH977bjeTk$  is
    quite clear that expiration is the only mechanism to invalidate the
    delegated credential, with the risk of stolen/leaked delegated
    credentials limited by their short-lived nature.

Um, right you are... that one is my bad, I'm sure. I imagine that the text there was initially talking about ACME STAR and it just got glommed into subcerts. Fixed.
    
    (6) Section 4.1 seems to waver on where the "encompassing" check is
    performed, leaving open the possibility that it is not performed at all.
    I think we need to be very explicit about what is required, not just
    what might be done or what is desirable.  This might end up needing to
    be passing the buck ("the authority for the deployment in question will
    specify which entity performs this validation"), but at present it seems
    like there's a gap that needs to be filled in some manner.

I think the text is clear that we ideally want it to be performed by the certification authority, and furthermore expect it may also be performed on the authentication or verification services as a belt-and-suspenders check. But we aren't writing the CP for those CAs here, and I can imagine sane CPs that could defer it to verification, say. So passing the buck is intentional here. I guess in our limited experience so far, those CPs are being written by government-sanctioned bodies to conform with regulatory policies; I don't want to write something here that could potential conflict.
    
    (7) Section 8.1 has what I think is a stale statement about ACME,
    relating to suitability of the certificate URL for use as "x5u" -- RFC
    8555 only requres POST-AS-GET access, not the GET access that we imply.
    (See COMMENT for additional related points.)
    
Reading this in light of your comment below, we're not trying to suggest that the PASSporT contain the URL returned by ACME, but instead that the URL contains an "application/pem-certificate/chain" object, and that the object is question is suitable for someone else to host a URL for. Hopefully that is now clarified.
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    Section 3
    
       A user might also roam from their usual service provider to a
       different network or administrative domain, for various reasons.
       Most "legitimate spoofing" examples are of this form: where a user
       wants to be able to use the main call-back number for their business
       as a calling party number, even when the user is away from the
       business.
    
    It seems like we're trying to implicitly define "legitimate spoofing"
    here.  While this is probably effective for most readers, we might
    consider a rewording that does not introduce an otherwise-unused new
    term, for example:
    
    % Most cases where legitimate traffic is hindered by anti-spoofing
    % protections resemble this scenario: a common case is where a user
    % [...]
    

Gen-ART suggested that I just define "legitimate spoofing" in the Terminology section, so, I did that.

    Section 4
    
       certificate that itself contains a TNAuthList object.  The parent
       certificate needs contain a basic constraints extension with the cA
       boolean set to "true", indicating that the subject can sign
    
    nit: "needs to contain"

Fixed, thanks.
    
       certificates.  Every STIR delegate certificate identifies its parent
       certificate with a standard [RFC5280] Authority Key Identifier
       extension.
    
    And RFC 5280 §4.2.1.2 requires that the cA:TRUE certificate sets its
    subject key identifier, so it's safe to use authority key identifier to
    identify the issuer, excellent.
    
    But, do we want to say anything about key usage here?  It seems that RFC
    5280 fairly tightly constrains what needs to be done here, so no new
    normative requirements would be needed, but if we are giving a reminder
    about cA:TRUE, I will ask if that is the only reminder we want to give.
    
Well, we've backed out that sign-PASSporTs-with-intermediate-certs thing. I don't have any particular restrictions in mind, as really the CPs will end up governing a lot of this... is there something else we should be worried about?

       certificate's scope: it must be "encompassed."  For example, a parent
       certificate with a TNAuthList that attested authority for the
       numbering range [phone] through 1999 could issue a
       certificate to one delegate attesting authority for the range
       [phone] through 1599, and to another delegate a certificate
       for the individual number [phone].
    
    I would (weakly) prefer to not use this notation for ranges that
    requires the reader to infer that only the last four digits are
    changing.  Could we use the full eleven-digit codes or reword match the
    actual RFC 8226 structure ("N numbers starting at <blah>")?

In North American usage, there's a big distinction between the last four digits and the rest of the number in terms of the way number are allocated. While that isn't a global practice, it is globally familiar. So I guess I'd weakly prefer to keep it, for that reason - as you point out, nothing in the RFC8226 syntax forces it, but it's intuitive.
    
       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.  In the STIR
       ecosystem, CA certificates may be used to sign PASSporTs; this
       removes the need for creating a redundant end-entity certificate with
       an identical TNAuthList to its parent, though if for operational or
       security reasons certificate holders wish to do so, they may.
    
    (Noting that this text may change due to my discuss point,) I'd suggest
    rewording the last sentence here to talk about how "if a CA certificate
    could only be used to sign certificates, then a redundant end-entity
    certificate with identical TNAuthList to its parent would be needed to
    sign PASSporTs".  That said, though, it's general crypto best practice
    to only use a given key for one type of operation, and "sign
    certificates" and "sign JWTs" qualify as separate operations in this
    sense.  While it is highly unlikely that the JSON/base64 input to be
    signed would collide with the DER of a certificate, it's not entirely
    clear that this "convenience" justification outweights the cryptographic
    best practice.

We backed out the offending text.
    
    Section 4.1
    
       STIR certificates may have a TNAuthList containing one or more SPCs,
       one or more telephone number ranges, or both.  When delegating from a
       STIR certificate, a child certificate may inherit from its parent
       either of the above.  Depending on the sort of numbering resources
    
    Does "either of" exclude "both"?
    ensure that it always happens at least once.
    
Per your discuss, we'll clarify this sentence. We mean either or both. In practice, SPC->TN delegation needs to work.

       is issued, or at the time that a verification service receives an
       inbound call, or potentially both.  It is generally desirable to
       offload as much of this as possible to the certification process, as
       verification occurs during call setup and thus additional network
       dips could lead to perceptible delay, whereas certification happens
       outside of call processing as a largely administrative function.
    
    Is "network dip" a term of art in this field?

I think so, but I can just change it to "transactions with a service." 
    
       numbers specified as the scope of a certificate.  The presence of one
       or more SPCs and one or more sets of telephone number ranges should
       similarly be treated additively, even if the telephone number ranges
       turn out to be redundant to the scope of an SPC.
    
    Any thoughts about s/should similarly be/are similarly/?  This is the
    architecture we have, not some thoughts about the best ways to do
    things (AFAICT).

Fixed.
    
    Section 5
    
       signing certificate.  Authentication services SHOULD NOT use a
       delegate certificate without validating that its scope of authority
       is encompassed by that of its parent certificate, and if that
       certificate has a own parent, the entire certification path SHOULD be
       validated.
    
    Why are these only SHOULD?  (Probably related to my discuss point.)

It is related to your discuss (so it's addressed up there).
    
    Section 7
    
       When a STIR delegate certificate is used to sign a PASSporT, the
       "x5u" element in the PASSporT will contain a URI indicating where a
       certificate list is available.  While baseline JWS also supports an
       "x5c" element specifically for certificate chains, in operational
       practice, certification path are already being delivered in the STIR
       environment via the "x5u" element, so this specification recommends
       continuing to use "x5u".  That list will be a concatenation of PEM-
    
    I have a really hard time supporting this practice based solely on the
    stated justification.  These elements have well-specified meanings; why
    should we diverge from that?  Just because some people are currently
    doing a thing we don't need to recommend that everyone does that thing
    going forward...  (It's fine to say that some people are doing this and
    you may want to accept it, but why go further and actively recommend
    propagating the error?)
    
If existing implementations hadn't basically hard coded "x5u" so that they would just crash if they saw an "x5c", I'd be more permissive in what I'd send here. I know you're correct, and that the IETF should not recommend doing the wrong thing. I just feel like that's a higher burden to acceptance of the standard than one might think.

       encoded certificates of the type "application/pem-certificate-chain"
       defined in [RFC8555].  The certificate path [RFC5280] ordering MUST
       be organized from the trust anchor towards the signer.  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
    
    Maybe it's just me, but I'm having a hard time squaring "organized from
    the trust anchor towards the signer" with "begins with the certificate
    used to sign the PASSporT" -- doesn't "from trust anchor" mean "start
    with trust anchor"?  (Also, while I'm happy to have a rigid
    chain-building algorithm, the requirement for
    AuthorityKeyIdentifier/SubjectKeyIdentifier does kind of make it
    redundant...)

Somebody suggested that we needed a chain building algorithm, at some point; agreed it seems redundant. Fixed that ordering from signer to trust anchor.
    
       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 used for STIR MAY be a CA certificate.
    
    [cross-referencing previous question about direct message signature by
    CA certificates]
    
Again, removed this text.

    Section 8
    
       a certification authority itself; serving as a certification
       authority is a function requiring specialized expertise and
       infrastructure.  [...]
    
    I suppose we could link to
    https://urldefense.com/v3/__https://cabforum.org/information-for-auditors-and-assessors/__;!!N14HnBHF!vi9Kfx95R2gfLeC2KDeP2MWE1q4cbmh9rR9dyIytKeZKUL3UaBH9DjXvNBI$    or
    https://urldefense.com/v3/__https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf__;!!N14HnBHF!vi9Kfx95R2gfLeC2KDeP2MWE1q4cbmh9rR9dyIytKeZKUL3UaBH9C_wGkAY$  
    if we wanted to scare people with exactly how specialized this stuff
    is...

Heh.
    
       the terminating side.  However, some additional object in the
       certificate outside of the TNAuthList could preserve that
       information; this is a potential area for future work.
    
    Should we perhaps say that the only mechanism currently defined is to
    have the longer certification path?

Okay, done.
    
       particular telephone number is encompassed by an SPC.  Alternatively,
       a CA may acquire an Authority Token that affirms that a delegation is
       in the proper scope.  Exactly what operational practices this entails
    
    nit: I know we talk about "Token Authority" in the first paragraph of
    the section and forward-reference §8.1, but "Authority Token" is a
    different thing, so we should probably do the same forward-reference
    dance here.

Okay, done.
    
    Section 8.1
    
    I wonder how much detail we really want to go into here while keeping
    the acme drafts as only informational references...
    
       STIR delegate certificate.  ACME returns an "application/pem-
       certificate-chain" object with suitable for publishing as an HTTPS
       resource for retrieval with the PASSporT "x5u" mechanism as discussed
       in Section 7.  If the CSR presented to the ACME server is for a
    
    This would seem to suggest that people actually use the ACME-provided
    URL as the "x5u" URL.  I don't remember anything in 8555 to suggest that
    the ACME server is under any obligation to maintain this resource
    indefinitely (or to allow GET access, vs the required POST-AS-GET), so
    we should either disavow such a practice or document the relevant
    considerations and preconditions for relying on the external party in
    this way.

Addressed up in your DISCUSS; we'll reword to remove that interpretation.
    
       Service providers that want the capability to rapidly revoke
       delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star]
       mechanism to automate the process of short-term certificate expiry.
    
    We need to reword this.  The STAR mechanism does not provide a
    revocation mechanism; it merely attempts to obviate the need for an
    active revocation mechanism.

Okay - we'll rapidly age them out.
    
    Section 11
    
       placing calls.  As this information is necessarily a superset of the
       calling party number that is openly signaled during call setup, the
       privacy risks associated with this mechanism are not substantially
    
    If I understand correctly, "this information" is the information in the
    parent CA certificate that issued the delegated STIR certificate (as
    opposed to the delegated STIR certificate itself)?  Baseline STIR needs
    a certificate, after all, and the new thing here is not the end-entity
    but the (parent) CA.

No, "this information" meant the "narrow range" in the previous sentence. I mean, if a TNAuthList is only for 5 TNs, it in some sense exposes more data than a SPC does - it may let you infer that all 5 of the TNs are owned by the same administrative entity, say.
    
    Section 12
    
    It might be worth noting that the delegation mechanism allows for STIR
    to be used in scenarios where unauthenticated spoofing would otherwise
    be used, thereby improving the security of the ecosystem.

Okay.
    
    It also seems that RFC 8226 should have linked to the security
    considerations of RFC 3986 for the case where the TN Authorization List
    is included in the certificate by reference ("contents available at the
    URI may change over time", etc.); since those topics are relevant for us
    as well, it seems like we should at least do so ourselves even if we
    can't retroactively make 8226 talk about it.
    
Okay.

    I would also suggest reiterating that since STIR certificates use the
    TNAuthList, rather than conventional X.509 naming schemes, that the
    "encompassing" check has to be added to the process for determining
    whether a given certification chain is authorized and valid.  (Yes, that
    is basically the whole point of the document, but it may be worth saying
    again.)

Okay.
    
       Security Considerations.  Also see the Security Considerations of
       [RFC8226] for general guidance on the implications of the use of
       certificates in STIR.
    
    I'd suggest also calling out the discussions of revocation and the
    risks of caching authorization information due to "skew" over time in,
    e.g., the SPC database.

This seems to be largely the same comment as two comments above? Anyway, added a bit about revocation.
    
    It might also be worth a callout to Section 8 and the "specialized
    expertise and infrastructure" involved in operating a CA.

Works for me.
    
    Section 14.1
    
    It's a little debatable whether RFC 3261 is a normative reference for
    this document (though it certainly is for the ecosystem in which the
    mechanism described by this document are used).

Fair enough. Moved to informative.
    
    Section 14.2
    
    As alluded to previously, the acme authority-token drafts are on the
    borderline of normative and informative.
    
I think they just allude to normative behavior that is in the authority-token docs.

    I think RFC 5280 needs to be a normative reference (not least for the
    AuthorityKeyIdentifier, SubjectKeyIdentifier, and BasicConstraints
    extensions).

Okay
    
    The X.680-series references are not used in the body of the document,
    nor is X.520.

I'm sure those were left over from the template cut-and-paste, they are now cut.

Jon Peterson
Neustar, Inc.