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

[Ballot comment]
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.

[Ballot comment]
[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  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?

[Ballot comment]
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

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

[Ballot comment]
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.

[Ballot comment]
Thank you for this document -- I found it a clear and easy read, even for someone not skilled in STIR / certy-things :-)

[Ballot comment]
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/

[Ballot comment]
[[ 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//?

[Ballot comment]
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.

[Ballot comment]
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.

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

[Ballot 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 +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 ")?

  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.

[Ballot comment]
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.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-stir-cert-delegation-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

The following Last Call announcement was sent out (ends 2020-08-26):

From: The IESG
To: IETF-Announce
CC: housley@vigilsec.com, draft-ietf-stir-cert-delegation@ietf.org, stir@ietf.org, Russ Housley , superuser@gmail.com, stir-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (STIR Certificate Delegation) to Proposed Standard


The IESG has received a request from the Secure Telephone Identity Revisited
WG (stir) to consider the following document: - 'STIR Certificate Delegation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-08-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Secure Telephone Identity Revisited (STIR) certificate profile
  provides a way to attest authority over telephone numbers and related
  identifiers for the purpose of preventing telephone number spoofing.
  This specification details how that authority can be delegated from a
  parent certificate to a subordinate certificate.  This supports a
  number of use cases, including those where service providers grant
  credentials to enterprises or other customers capable of signing
  calls with STIR.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards track RFC is requested.  Yes, this appears on the
  title page of the Internet-Draft.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Secure Telephone Identity Revisited (STIR) certificate profile,
  which is specified in RFC 8226, provides a way to attest authority
  over telephone numbers and related identifiers for the purpose of
  preventing telephone number spoofing.  This specification details
  how that authority can be delegated from a parent certificate to a
  subordinate certificate.  This delegation supports a number of use
  cases, including those where service providers grant credentials to
  enterprises or others capable of signing a PASSporT object for a
  call as specified in RFC 8225.

Working Group Summary

  The STIR WG reached consensus, and there is support for
  publication of this document.

Document Quality

  Several people have expressed interest in implementing this
  specification.

Personnel

  Russ Housley is the Document Shepherd.
  Murray Kucherawy is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd did a complete review of -02 and -03, and all
  items of concern were corrected.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns at all.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No additional review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns at all.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  The author has confirmed that he is unaware of any IPR
  disclosures that need to be submitted.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures have been submitted against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The STIR WG reached consensus, and there is support for
  publication of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened to appeal or expressed discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits raises one warnings, which is easily resolved as part of IETF
  Last Call:
 
  == Outdated reference: draft-ietf-acme-star has been published
    as RFC 8739

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No additional formal review is needed for this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, informative and normative references appear is separate
  sections in the document.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  None.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No, publication of this document will not change the status of
  any other documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA actions are needed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None is needed for this document.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards track RFC is requested.  Yes, this appears on the
  title page of the Internet-Draft.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Secure Telephone Identity Revisited (STIR) certificate profile,
  which is specified in RFC 8226, provides a way to attest authority
  over telephone numbers and related identifiers for the purpose of
  preventing telephone number spoofing.  This specification details
  how that authority can be delegated from a parent certificate to a
  subordinate certificate.  This delegation supports a number of use
  cases, including those where service providers grant credentials to
  enterprises or others capable of signing a PASSporT object for a
  call as specified in RFC 8225.

Working Group Summary

  The STIR WG reached consensus, and there is support for
  publication of this document.

Document Quality

  Several people have expressed interest in implementing this
  specification.

Personnel

  Russ Housley is the Document Shepherd.
  Murray Kucherawy is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd did a complete review of -02 and -03, and all
  items of concern were corrected.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns at all.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No additional review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns at all.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  The author has confirmed that he is unaware of any IPR
  disclosures that need to be submitted.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures have been submitted against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The STIR WG reached consensus, and there is support for
  publication of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened to appeal or expressed discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits raises one warnings, which is easily resolved as part of IETF
  Last Call:
 
  == Outdated reference: draft-ietf-acme-star has been published
    as RFC 8739

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No additional formal review is needed for this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, informative and normative references appear is separate
  sections in the document.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  None.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No, publication of this document will not change the status of
  any other documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA actions are needed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None is needed for this document.

As best I can tell, I made a state editing error during the fray of IETF105 which made this look like it had been pubreq'ed. It has not, and is still under WG discussion. Apologies for any confusion my error introduced.