Note: This ballot was opened for revision 03 and is now closed.
Please respond to the Gen-ART review.
Thank you to Carl Wallace for the SECDIR review, and thanks for responding to it. Updated for 2021-04-22 telechat. Thanks for addressing my COMMENTS from the 2020-09-09 telechat review on -03.
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.
[edited to remove a speculative statement shown to be false by the existence of draft-ietf-acme-star-delegation] I'd still be interested in seeing some discussion about what timescales the SPC-to-number mapping remains stable at, though presumably this will vary across deployments so maybe there is not much useful to say about it. Section 4.1 Whichever approach is taken to representing the delegated resource, there are fundamental trade-offs regarding when and where in the architecture a delegation is validated: that is, when the delegated TNAuthList is checked to be "encompassed" by the TNAuthList of its parent. This might be performed at the time the delegate certificate 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. I do see the response to my discuss point (6) that says the CA is expected to always or nearly-always make the check, with addditional check on the authentication/verification service for "belt and suspenders". But this "might be performed at [...], or at [...]" formulation is not very strong. Is there a granularity of scope (deployment?) for which we can say "a given <scope> MUST specify at least one point in processing where the encompassing check is performed"? Section 5 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 its own parent, the entire certification path SHOULD be validated. I see the response to my discuss point (6) that justifies the first "SHOULD NOT" with an alternative scenario that works fine. In this context is the second "entire certification path SHOULD be validate" referring only to the validation of the phone number check? As written it sounds like it could refer to the entire X.509 chain-building and validation exercise, which kind of has to happen in order for the system to work (but, IIRC, is also mandated as part of normal PASSporT handling). So maybe we could tweak the wording a little bit here ("the authorization for calling party number in the entire certification path SHOULD be validated"). Section 8 Note that the allocation to a service provider of a certificate with a basic constraints extension with the cA boolean set to "true" does not require that a service provider act as a certification authority itself; [...] I am not sure if this text was intending to refer to the now-removed behavior where the CA certificate directly signed the PASSporT or some other scenario. If the latter, do we have an example of some sort that we could point to (does a third-party authentication service that's given the private key count)? Section 9 public key that could sign PASSporTs. The TLS subcerts system has furthermore exploring leveraging ACME to issue short-lived certificates for temporary delegation as a means of obviating the need for revocation. Specification of a mechanism similar to TLS I don't think that subcerts and STAR are particularly closely related, so mentioning "the TLS subcerts system" here doesn't seem right. I might consider a rewording as: NEW: TLS subcerts provide a very time-limited means to issue a credential that is used as a delegated version of a longer-lived credentials. A similar technology being explored by ACME is short-lived certificates that can be automatically renewed if the issued credentials/authority are to remain valid. This is not explicitly a delegation mechanism, as the issued credentials are issued directly by the ACME CA, but can reflect a delegation of authority if the certificate and private key are delegated to a different entity than the one that controls the ACME account used for issuance. subcerts for STIR is future work, and will be undertaken only if the market require it. nit: s/require/requires/ Section 12 Also that note if the HTTPS service housing the by-reference telephone number list is improperly secured, that too can lead to vulnerabilities. Ultimately, the CA that issued a delegated certificate populates the URL in the AIA field, and is responsible for making a secure selection. Service providers acting as CAs are directed to the cautionary words about running a CA in Section 8 regarding the obligations this entails for certificate revocation and so on. I'm a little confused about the need to call out the AIA field here, with the previous discussion having been about the use of by-reference TNAuthLists. Isn't the AIA only going to contain information about the CA itself that is doing the issuing?
[[ 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.
Thanks for the work on this document. I only have one minor comment about a missing reference. certificate list is available. While baseline JSON Web Signature (JWS) also supports an "x5c" element specifically for certificate FP: Please add a reference to RFC 7515 for JWS. (I believe Informative should be enough, given the context) Francesca
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.