[stir] Re: AD evaluation: draft-ietf-stir-certificate-transparency-02 (now -03)

["Charles Eckel (eckelcu)" <[e-mail]>]

Hi Chris,

Thanks for this. I have requested Last Call on -05.

Cheers,
Charles

On Oct 21, 2026, at 8:27 PM, Chris Wendt <[e-mail]> wrote:

Hi Charles,

Sorry for missing this, I’ve submitted a new -05 with the requested changes.

-Chris

On Oct 20, 2026, at 1:18 PM, Charles Eckel (eckelcu) <[e-mail]> wrote:

Hi Chris,

I’d like to start Last Call on this draft. The only open item from my AD evaluation is the mixed normative language in the second paragraph of Section 9. Since Sections 7.2.1 and 7.2.2 already carry the MAY and the MUST, Section 9 can simply point to them, e.g.:

“Section 7.2.2 requires a Verification Service (VS) to verify the embedded Signed Certificate Timestamps (SCTs) before relying on a certificate, and Section 7.2.1 permits an Authentication Service (AS) to do so before signing.”

If you can post a -05, I’ll start Last Call on it.

Thanks,
Charles

On Aug 18, 2026, at 4:26 PM, Charles Eckel (eckelcu) <eckelcu=[e-mail]> wrote:

Hi Chris,

Thanks for the quick iterations on this. I am good with all of the changes except one:

626   Verification of the embedded Signed Certificate Timestamps (SCTs) is
627   required of a Verification Service (VS) before a certificate is
628   relied upon, as specified in Section 7.2.2, and MAY also be performed
629   by an Authentication Service (AS) before signing.  A log public key
630   obtained without the authenticity assurance applied to trust anchors
631   does not distinguish a valid SCT from a forged one.

This sentence is inconsistent in its use of normative language in that it uses “required” followed by “MAY”.
I believe “required” and “may” would be fine in this case.

Cheers,
Charles


On Aug 17, 2026, at 6:49 AM, Chris Wendt <[e-mail]> wrote:

Thanks Charles, thanks for the prompts on fixing implementation vs interop points and the security considerations I did a much needed, in retrospect, revamp based on your suggestions. All in new -04, inline below.

On Aug 14, 2026, at 7:13 PM, Charles Eckel (eckelcu) <eckelcu=[e-mail]> wrote:

Hi Chris,

Thanks for making these changes. Please see inline.

On Aug 5, 2026, at 5:59 PM, Chris Wendt <[e-mail]> wrote:

Thanks Charles, appreciate the suggestions. All of the changes below are in -03.
Responses inline.

### normative language

All updated: 363, 379, 417 and 522 to MUST; 507 and 634 to SHOULD.

On 627, MUST is right for the Verification Service but not for the Authentication Service, and the original sentence applied one keyword to both. A VS receives the certificate from an untrusted party and the SCT check is what the framework depends on, so that is a MUST. An AS is checking SCTs embedded in its own certificate, obtained through its own issuance process, so that is a local check, and the body of the document already says the AS MAY perform it. The sentence now uses MUST for the VS and MAY for the AS.

That looks good, but there are some cases that I believe are worth examining. My apologies if some of these are things that were changed as a result of my previous comments.

467       *  Implementations SHOULD pre-compute and cache these checks at
468          certificate activation time so that per-call signing incurs
469          only an O(1) lookup.

This is an implementation consideration rather than an interoperability or security requirement.
Perhaps s/SHOULD/are strongly encouraged to

Changed to "are strongly encouraged to”


496   Implementations SHOULD cache certificates and validated SCT objects
497   for the lifetime of the certificates' notAfter field to amortize step
498   3 across many calls.

This is an implementation consideration rather than an interoperability or security requirement.
Perhaps s/SHOULD/are strongly encouraged to

Changed to "are strongly encouraged to"


506   *  Key caching - Log public keys are static and SHOULD be loaded at
507      process start-up; reload only on key-roll events signaled via CT
508      or operator policy.

This is an implementation consideration rather than an interoperability or security requirement.
Perhaps s/SHOULD/should

Changed to lowercase "should".


The next four are all in the security considerations, which i think needed more than keyword changes. Most of that section was written as requirements when it should have been describing what the mechanism does and doesn't do. It is now four paragraphs of considerations, and the one real normative requirement moved into the body. I think this was much needed revision so glad you prompted it.


627   Logs SHOULD be monitored for inconsistent Signed Tree Heads (STHs).

I am not sure what is necessary here or what is the impact of inconsistent STHs. Should this be “MUST” instead of “SHOULD”. If “SHOULD”, in what scenario(s) is it ok to not monitor for inconsistent STHs?

Dropped the SHOULD rather than raising it to MUST. A verifier has no way to determine whether a log is being audited by another party, so there is no one to put any requirement on. The text now states the impact you asked about: SCTs from an unaudited log are not evidence that a certificate appears in the record monitors observe.

Your question here also made us notice the document never said normatively that a VS has to verify SCTs. Verification Service Processing now says the VS MUST perform the listed steps before relying on the certificate, and the security considerations point at it. Step 3 changed from "verify signature against cached log key" to "against a log public key the VS trusts", since caching is an optimization the document only encourages.


633   signatures.  The log public keys used for this verification SHOULD be
634   obtained and updated through the same mechanism as trust anchors.

Should this be “MUST” instead of “SHOULD”. If “SHOULD”, in what scenario(s) is it ok to not do this?

Dropped the SHOULD. "Same authenticity assurance as trust anchors" is not testable, so a MUST would not be checkable. The text now says a log public key obtained without that assurance does not distinguish a valid SCT from a forged one.


640   two.  Detection depends on the logs being monitored and on the
641   results being acted upon: monitors SHOULD track Telephone Number (TN)
642   and Service Provider Code (SPC) associations and alert stakeholders
643   if certificates are issued outside of authorized ranges.

Should this be “MUST” instead of “SHOULD”. If “SHOULD”, in what scenario(s) is it ok to not do this?

Dropped the SHOULD. Not every participant runs a monitor, and some rely on monitoring performed on their behalf. The text says mis-issuance is detected only where logs are monitored and Signed Tree Heads are audited, and points at those sections.


647   TNAuthList and the entity named in it.  Where that association is
648   sensitive, a deployment SHOULD consider whether a service provider
649   code or a number range would suffice in place of individual numbers.

I don’t think we can say “SHOULD consider.” How about:
"If that association is sensitive, a deployment SHOULD use a service provider code or a number range in place of individual numbers unless …”
or:
"If that association is sensitive, a deployment MUST use a service provider code or a number range in place of individual numbers.”

Took your first option. MUST would prohibit certificates scoped to individual telephone numbers whenever the association is sensitive, and that is what RFC 9060 delegate certificates are for. It now reads: where that association is sensitive and the deployment does not require certificates scoped to individual telephone numbers, a service provider code or a telephone number range SHOULD be used instead.



###  tighten language in security considerations

Agreed, and this prompted us to look at the section as a whole. Two of the paragraphs were not saying anything a reader could act on, so they are gone rather than reworded.

"must be managed" and "reputable entities" are removed. We could not make "reputable" verifiable, and which logs to accept is a property of the ecosystem's policy rather than something this document specifies. "Performed securely" was meant to refer to the log public keys used to verify SCTs, which is now stated directly.

The paragraph beginning "While CT does not prevent mis-issuance" restated the introduction. It now says that an SCT proves a certificate was logged and not that it was legitimately issued, which is the consideration a reader needs, and it carries the SHOULD from 634.

On privacy, the original asked implementers to "consider" something without saying what could be done about it, and redaction would remove the detection the log exists to provide. The text now identifies what is disclosed and the one thing a deployment controls, which is whether the TNAuthList enumerates individual numbers or uses a service provider code or a range.

Line 642, on rate limiting and redundant storage, is removed. It applies to any network service, and the section already inherits the security considerations of RFC 6962.

Note that two of these are longer than the text they replace. The original phrasings were short because they did not say what they meant.

### Comments

All fixed as suggested: both abstract rewrites taken as written, "its" to "their", "certificate change" to "certificate chains", "role" used consistently for all three, your wording for the third parties sentence and for the extra "in" and "that", and "asking" to "checking". The trust anchors sentence is reworded to say that each chain is required to end in a trust anchor the log accepts, and that the accepted set is the authorized set or a subset of it.

24   numbers.  This involves requiring and refusing to honor STI
25   certificates that are not listed in an established log.  This

Thanks for updating this, but I think "requiring and refusing” is not clear.

s/This involves requiring and refusing/This involves requiring STI certificates and refusing

Fixed: "This involves requiring STI certificates to be listed in an established log and refusing to honor those that are not." Your change, reworded to avoid saying "STI certificates" twice.


### Nits

All applied: eco-system to ecosystem, stir to STIR, pre-certificate to precertificate, provides to provide, and "There is three" to "There are three". The "a established" instance was in the abstract sentence rewritten above.

On the formatting issue, yes, that was meant to be a list. The blank line after the introducing colon was missing, so kramdown treated the items as a continuation of the paragraph. Fixed.

Thanks,
Charles



On Jul 13, 2026, at 8:14 PM, Charles Eckel (eckelcu) <eckelcu=[e-mail]> wrote:

# Charles Eckel, ART AD, AD evaluation: draft-ietf-stir-certificate-transparency-02
CC @eckelcu

* line numbers:
 - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-stir-certificate-transparency-02.txt&submitcheck=True

* comment syntax:
 - https://github.com/mnot/ietf-comments/blob/main/format.md

## Discuss

### normative language

```
363   must include all necessary intermediate certificates to validate the

379   Logs must publish a list of accepted root certificates, which aligns

417   Logs must produce an STH within the Maximum Merge Delay (MMD) to

507   *  Key caching - Log public keys are static and should be loaded at

522       transparency logs for new entries.  The Monitor must be

627   Signed Certificate Timestamps (SCTs) should be verified by

634   and monitors should track Telephone Number (TN) and Service Provider
```

Should each of these be MUST/SHOULD?
And in case of line 627, why not MUST?

### tighten language in security considerations

```
620   The use of Certificate Transparency (CT) within the STIR ecosystem
621   enhances accountability but also introduces operational and security
622   risks that must be managed.  Trust in the system depends on the
623   integrity of CT logs and therefore, logs should be operated by
624   reputable entities and monitored to detect mis-issuance or
625   inconsistent Signed Tree Heads (STHs).
642   CT logs and Certification Authorities (CAs) should implement
```

What does "must be managed" imply and is there a way to verify that logs are operated by "reputable entities"?

```
630   keys to prevent forgery or replay.  Key rotation and distribution
631   should be performed securely.
```

What is meant to be performed securely?

```
639   and entities, implementers should consider privacy implications and
```

How can this be done?

## Comments

### Abstract, establishment of trust

```
22   logs themselves.  The intent is for the establishment of a level of
23   trust in the STI eco-system that depends on the verification of
24   telephone numbers requiring and refusing to honor STI certificates
25   that do not appear in a established log.  This effectively ...
```

I find this sentence difficult to parse.

s/numbers requiring/numbers by requiring

Or break the sentence in two, e.g.,

"The intent is to establish a level of trust within the STI ecosystem that relies on the verification of telephone numbers. This involves requiring and refusing to honor STI certificates that are not listed in an established log."

### Abstract, avoidance of issuance

```
29   number resource.  The primary role of CT in the STI ecosystem is for
30   verifiable trust in the avoidance of issuance of unauthorized
31   duplicate telephone number level delegate certificates or provider
32   level certificates.  This provides a robust auditable mechanism for
```

The phrase "avoidance of issuance of" is clunky, and if I understand correctly, CT does not prevent or avoid issuance; rather, it ensures that issuance is publicly detectable, which is what creates the "verifiable trust." How about something like the following:

"In the STI ecosystem, the primary role of CT is to provide verifiable trust by detecting the unauthorized issuance of duplicate telephone number level delegate certificates or provider level certificates."

### unclear who/what is meant by "its"

```
150   system (DNS).  This document describes a conceptually similar
151   framework that directly borrows concepts like transparency receipts
152   in the form of SCTs and how they are used in certificates and its
153   specific use as part of the larger STIR framework for call
154   authentication.  This framework is defined for the specific use with
```

### certificate change

```
168   issuance of STI certificates and certificate change that are intended
```

Is this supposed to be certificate chains?

### actor vs role vs actor role

```
177   There is three primary actors in the certificate transparency
```

In the text that follows, all three variations are used. Use one consistently.

### interested third parties

```
223   logs.  Note, in [RFC6962] it is possible for certificate holders to
224   directly contribute their own certificate chains or interested third
225   parties,
```

Should this instead read as follows:

"Note, in [RFC6962] it is possible for certificate holders and interested third parties to contribute certificate chains, ..."

### extra "in" and "that"

```
225   parties, however because in stir eco-systems that generally consist
```

s/because in stir eco-systems that generally consist/because STIR ecosystems generally consist

### trust anchors

```
229   authorized to participate as valid trust anchors.  It is required
230   that each chain ends with a trust anchor that is accepted by the log
231   which would include those authorized trust anchors or a subset of
232   them.
```

I am not sure what this is saying. I believe it should be reworded.

### asking a log file?

```
239   the logs, asking them regularly for all new entries, and can thus
```

s/asking/checking

## Nits

### global replace

```
s/eco-system/ecosystem
s/stir/STIR
s/pre-certificate/precertificate
```

### typos

```
201   web PKI environments, but provides a specific framework designed for
```

s/provides/provide

```
25   that do not appear in a established log.  This effectively ...
```

s/a established/an established

```
177   There is three primary actors in the certificate transparency
```

s/There is three/There are three

### formatting issue

```
606   The main differences are: - The expected certificate types are STI
607   certificates as defined in [RFC8226] and [RFC9060], with TNAuthList
608   extensions. - Submitters are limited to STI Certification Authorities
609   and Subordinate Certification Authorities. - Monitoring and auditing
610   are focused on detection of mis-issued telephone number or service
611   provider codes (SPCs). - The client roles (e.g., VS, AS) interact
612   with certificates and logs in ways specific to SIP call
613   authentication.
```

It seems this was meant to be formatted as a list?
---
_______________________________________________
stir mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]


_______________________________________________
stir mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]


_______________________________________________
stir mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]