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

["DOLLY, MARTIN C" <[e-mail]>]

So not to be a PITA, but is this implementable?


Martin C Dolly

AT&T

Expert Member of Technical Staff

Government & Services Standards

[phone]

________________________________
From: Chris Wendt <[e-mail]>
Sent: Wednesday, August 5, 2026 8:59 PM
To: Charles Eckel (eckelcu) <eckelcu=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [stir] Re: AD evaluation: draft-ietf-stir-certificate-transparency-02 (now -03)

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

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.

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

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


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<https://urldefense.com/v3/__https://author-tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf-stir-certificate-transparency-02.txt&submitcheck=True__;Ly8vLy8!!BhdT!gBXO4ip4QbXF40pzXjxZWeXJ8mqZ44Pi8afnPZcwWnq9FFshaaCYox_rwvMk2Ioy3qTJriqE2ccVZlWJ$>

* comment syntax:
 - https://github.com/mnot/ietf-comments/blob/main/format.md<https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!BhdT!gBXO4ip4QbXF40pzXjxZWeXJ8mqZ44Pi8afnPZcwWnq9FFshaaCYox_rwvMk2Ioy3qTJriqE2ZsPTC5k$>

## 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]