Skip to main content

Secure Telephone Identity Revisited (STIR) Certificate Delegation
RFC 9060

Revision differences

Document history

Date Rev. By Action
2021-09-18
04 (System)
Received changes through RFC Editor sync (created alias RFC 9060, changed title to 'Secure Telephone Identity Revisited (STIR) Certificate Delegation', changed abstract to 'The …
Received changes through RFC Editor sync (created alias RFC 9060, changed title to 'Secure Telephone Identity Revisited (STIR) Certificate Delegation', changed abstract to '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.', changed pages to 12, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-09-18, changed IESG state to RFC Published)
2021-09-18
04 (System) RFC published
2021-09-14
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-06-16
04 (System) RFC Editor state changed to AUTH48
2021-05-20
04 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Carl Wallace. Submission of review completed at an earlier date.
2021-05-14
04 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Carl Wallace.
2021-05-05
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-04-26
04 (System) RFC Editor state changed to EDIT
2021-04-26
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-04-26
04 (System) Announcement was received by RFC Editor
2021-04-26
04 (System) IANA Action state changed to No IANA Actions from In Progress
2021-04-26
04 (System) IANA Action state changed to In Progress
2021-04-26
04 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-04-26
04 Amy Vezza IESG has approved the document
2021-04-26
04 Amy Vezza Closed "Approve" ballot
2021-04-26
04 Amy Vezza Ballot approval text was generated
2021-04-22
04 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2021-04-22
04 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-04-21
04 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-04-20
04 Roman Danyliw
[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 …
[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.
2021-04-20
04 Roman Danyliw Ballot comment text updated for Roman Danyliw
2021-04-19
04 Murray Kucherawy IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2021-04-19
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-04-19
04 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-04-15
04 Tero Kivinen Request for Telechat review by SECDIR is assigned to Carl Wallace
2021-04-15
04 Tero Kivinen Request for Telechat review by SECDIR is assigned to Carl Wallace
2021-04-14
04 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-04-13
04 Benjamin Kaduk
[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 …
[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?
2021-04-13
04 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2021-04-13
04 Amy Vezza Telechat date has been changed to 2021-04-22 from 2020-09-10
2021-04-13
04 Francesca Palombini
[Ballot comment]
Thanks for the work on this document. I only have one minor comment about a missing reference.

  certificate list is available.  While …
[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
2021-04-13
04 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-04-01
04 Benjamin Kaduk
[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 …
[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?
2021-04-01
04 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-03-01
04 Russ Housley Added to session: IETF-110: stir  Fri-1530
2021-02-22
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-02-22
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-02-22
04 Jon Peterson New version available: draft-ietf-stir-cert-delegation-04.txt
2021-02-22
04 (System) New version approved
2021-02-22
04 (System) Request for posting confirmation emailed to previous authors: Jon Peterson
2021-02-22
04 Jon Peterson Uploaded new revision
2020-09-10
03 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-09-10
03 Alissa Cooper [Ballot comment]
Please respond to the Gen-ART review.
2020-09-10
03 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-09-10
03 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-09-09
03 Warren Kumari
[Ballot comment]
Thank you for this document. I found it a clear and easy read, even for people not skilled in STIR / certificate stuff. …
[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.
2020-09-09
03 Warren Kumari Ballot comment text updated for Warren Kumari
2020-09-09
03 Warren Kumari
[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]
Thank you for this document -- I found it a clear and easy read, even for someone not skilled in STIR / certy-things :-)
2020-09-09
03 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-09-09
03 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-09-09
03 Roman Danyliw
[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 …
[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/
2020-09-09
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-09-09
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-09-08
03 Erik Kline
[Ballot comment]
[[ nits ]]

[ section 1 ]

* s/holder of certificate/holder of a certificate/ perhaps

[ section 4 ]

* s/needs contain/needs to …
[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//?
2020-09-08
03 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-04
03 Éric Vyncke
[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 …
[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.
2020-09-04
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-03
03 Barry Leiba
[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, …
[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.
2020-09-03
03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-09-03
03 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Carl Wallace.
2020-09-03
03 Benjamin Kaduk
[Ballot discuss]
Despite the length of the list of numbered points, this document is
actually in pretty good shape -- most of them just relate …
[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.)
2020-09-03
03 Benjamin Kaduk
[Ballot comment]
Section 3

  A user might also roam from their usual service provider to a
  different network or administrative domain, for various …
[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.
2020-09-03
03 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-08-31
03 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from No Record
2020-08-31
03 Martin Duke
[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 …
[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.
2020-08-31
03 Martin Duke Ballot comment text updated for Martin Duke
2020-08-27
03 Cindy Morgan Placed on agenda for telechat - 2020-09-10
2020-08-26
03 Murray Kucherawy IESG state changed to IESG Evaluation from Waiting for Writeup
2020-08-26
03 Murray Kucherawy Ballot has been issued
2020-08-26
03 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2020-08-26
03 Murray Kucherawy Created "Approve" ballot
2020-08-26
03 Murray Kucherawy Ballot writeup was changed
2020-08-26
03 Ines Robles Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Ines Robles. Sent review to list.
2020-08-26
03 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-08-25
03 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-08-25
03 Michelle Cotton
(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 …
(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
2020-08-21
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2020-08-21
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2020-08-14
03 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2020-08-14
03 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2020-08-13
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2020-08-13
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2020-08-12
03 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-08-12
03 Amy Vezza
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 , …
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.




2020-08-12
03 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-08-12
03 Amy Vezza Last call announcement was changed
2020-08-11
03 Murray Kucherawy Last call was requested
2020-08-11
03 Murray Kucherawy Ballot approval text was generated
2020-08-11
03 Murray Kucherawy Ballot writeup was generated
2020-08-11
03 Murray Kucherawy IESG state changed to Last Call Requested from AD Evaluation
2020-08-11
03 Murray Kucherawy Last call announcement was changed
2020-08-06
03 Murray Kucherawy IESG state changed to AD Evaluation from Publication Requested
2020-08-05
03 Russ Housley
(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?  …
(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.
2020-08-05
03 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-08-05
03 Russ Housley IESG state changed to Publication Requested from AD is watching
2020-08-05
03 Russ Housley Tag Doc Shepherd Follow-up Underway cleared.
2020-08-05
03 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-08-05
03 Russ Housley
(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?  …
(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.
2020-08-05
03 Russ Housley Notification list changed to Russ Housley <housley@vigilsec.com>
2020-08-05
03 Russ Housley Document shepherd changed to Russ Housley
2020-08-05
03 Russ Housley Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WG cleared.
2020-07-13
03 Jon Peterson New version available: draft-ietf-stir-cert-delegation-03.txt
2020-07-13
03 (System) New version approved
2020-07-13
03 (System) Request for posting confirmation emailed to previous authors: Jon Peterson
2020-07-13
03 Jon Peterson Uploaded new revision
2020-05-19
02 Russ Housley Tag Revised I-D Needed - Issue raised by WG set.
2020-05-19
02 Russ Housley Changed consensus to Yes from Unknown
2020-04-07
02 Murray Kucherawy IESG process started in state AD is watching
2020-04-07
02 (System) Earlier history may be found in the Comment Log for /doc/draft-peterson-stir-cert-delegation/
2020-03-25
02 Amy Vezza Shepherding AD changed to Murray Kucherawy
2020-03-11
02 Robert Sparks Extended WGLC because of proximity to IETF107.
2020-03-11
02 Robert Sparks IETF WG state changed to In WG Last Call from WG Document
2020-03-09
02 Jon Peterson New version available: draft-ietf-stir-cert-delegation-02.txt
2020-03-09
02 (System) New version approved
2020-03-09
02 (System) Request for posting confirmation emailed to previous authors: Jon Peterson
2020-03-09
02 Jon Peterson Uploaded new revision
2019-11-04
01 Jon Peterson New version available: draft-ietf-stir-cert-delegation-01.txt
2019-11-04
01 (System) New version approved
2019-11-04
01 (System) Request for posting confirmation emailed to previous authors: Jon Peterson
2019-11-04
01 Jon Peterson Uploaded new revision
2019-09-01
00 Robert Sparks
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. …
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.
2019-09-01
00 Robert Sparks IESG state changed to I-D Exists from Publication Requested
2019-09-01
00 Robert Sparks IETF WG state changed to WG Document from Submitted to IESG for Publication
2019-07-24
00 Robert Sparks Responsible AD changed to Adam Roach
2019-07-24
00 Robert Sparks Intended Status changed to Proposed Standard
2019-07-24
00 Robert Sparks IESG process started in state Publication Requested
2019-07-24
00 (System) Earlier history may be found in the Comment Log for /doc/draft-peterson-stir-cert-delegation/
2019-07-24
00 Robert Sparks Working group state set to Submitted to IESG for Publication
2019-07-12
00 Russ Housley Added to session: IETF-105: stir  Mon-1000
2019-07-08
00 Jon Peterson This document now replaces draft-peterson-stir-cert-delegation instead of None
2019-07-08
00 Jon Peterson New version available: draft-ietf-stir-cert-delegation-00.txt
2019-07-08
00 (System) New version approved
2019-07-08
00 Jon Peterson Request for posting confirmation emailed  to submitter and authors: Jon Peterson
2019-07-08
00 Jon Peterson Uploaded new revision