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

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

Benjamin Kaduk has entered the following ballot position for
draft-ietf-stir-cert-delegation-03: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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


----------------------------------------------------------------------
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
% [...]

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

   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>")?

   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.