Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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.) (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.) (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://tools.ietf.org/html/rfc8226#section-10 is enough to cover that. (It would be nice to have some data on the relative lifetime of database mappings and certificate lifetimes, though.) (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. (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://tools.ietf.org/html/draft-ietf-tls-subcerts-09#section-7.3 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. (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. (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.)
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 % [...] 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" certificates. Every STIR delegate certificate identifies its parent certificate with a standard [RFC5280] Authority Key Identifier extension. And RFC 5280 §22.214.171.124 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. certificate's scope: it must be "encompassed." For example, a parent certificate with a TNAuthList that attested authority for the numbering range +1-212-555-1000 through 1999 could issue a certificate to one delegate attesting authority for the range +1-212-555-1500 through 1599, and to another delegate a certificate for the individual number +1-212-555-1824. 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>")? 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. 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. 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? 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). 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.) 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?) 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...) 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] 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://cabforum.org/information-for-auditors-and-assessors/ or https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf if we wanted to scare people with exactly how specialized this stuff is... 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? 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. 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. 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. 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. 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. 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. 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.) 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. It might also be worth a callout to Section 8 and the "specialized expertise and infrastructure" involved in operating a CA. 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). Section 14.2 As alluded to previously, the acme authority-token drafts are on the borderline of normative and informative. I think RFC 5280 needs to be a normative reference (not least for the AuthorityKeyIdentifier, SubjectKeyIdentifier, and BasicConstraints extensions). The X.680-series references are not used in the body of the document, nor is X.520.
Please respond to the Gen-ART review.
I support Ben Kaduk’s DISCUSS positions. ** Given that this document specifies the delegation model alluded to in Section 5 of RFC8226 with normative guidance, is there a reason it doesn’t formally update RFC8226? ** Section 4. Should this guidance be a normative MUST: “… each delegate certificate _must_ have a TNAuthList scope that is equal to …” ** Section 4. Should this guidance use a normative MAY: “… Delegate certificates _may_ also contain a basic constraints extensions with the cA boolean …” ** Section 4.1. Per the inheritance described in: “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”, can a parent certificate specify a SPC and the child certificate have a telephone number range; or is the delegation only of the same types? ** Section 4.*. Can you please clarify the use of the AIA extension in delegation as posed by the SECDIR reviewer (thanks to Carl Wallance for doing the review!). Additionally, can AIA be used in delegated certificates? ** Section 7. With regard to the use of “x5u” vs. “x5c”, what is the normative guidance on these elements? ** Section 8.1. Per “Service providers that want the capability to rapidly revoke delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] mechanism”, please clarify this text. The intent is correct, but ACME STAR doesn’t actually revoke certificates. ** Editorial Nits: -- Section 5. This text doesn’t parse “… and if that certificate has a own parent …” -- Section 7. Typo. s/certificate path are/certificates paths are/
S/has a own parent/has their own parent Sec 7. You may want to specify what happens if the PASSporT contains both x5c and x5u (presumably, ignore the former). It also says “ The certificate path [RFC5280] ordering MUST be organized from the trust anchor towards the signer“, which to me, means the trust anchor would be first. This is the opposite of what the rest of the paragraph says.
[[ nits ]] [ section 1 ] * s/holder of certificate/holder of a certificate/ perhaps [ section 4 ] * s/needs contain/needs to contain/? [ section 4.1 ] * How should I read "to deference the "x5u" field"? Is this 'dereference'? [ section 5 ] * "has a own parent" -> "has its own parent", perhaps [ section 8.1 ] * "object with suitable for"? s/with//?
Thank you for this document. I found it a clear and easy read, even for people not skilled in STIR / certificate stuff. It describes the issues / motivation and solution well.
I agree with a lot of what’s in Ben’s ballot, and quite a few things he noted were in my notes as well, as I went through the document. After reading Ben’s review, I find that I have nothing to add beyond that, and I look forward to the resolutions of his DISCUSS and comments.
Thank you for the work put into this document. It is simple to read and appears to address an important problem. The ideas behind section 4.1 are also smart. Please find below a couple of non-blocking COMMENTs, an answer to those comments will be welcome. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 6 -- As this document requires additional procedures to RFC 8224 and RFC 8225, should this document formally update those 2 RFCs ? -- Section 8 -- I wonder how the last paragraph of this section works/scales in the case of phone number portability as the granularity could be down to the individual phone number.