[stir] Benjamin Kaduk's No Objection on draft-ietf-stir-cert-delegation-04: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-stir-cert-delegation-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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 START are particularly closely related,
so mentioning "the TLS subcerts system" here doesn't seem right.  I'm
also not entirely sure to what extent the ACME STAR work is specifically
intended as a *delegation* mechanism, though I do think I see the
analogy being made here.  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?