Secure Telephone Identity Revisited (STIR) Certificate Delegation
draft-ietf-stir-cert-delegation-04

[[ 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//?

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 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.

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.

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.

Please respond to the Gen-ART review.

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.

[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?

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.