[stir] Re: Shepherd Review of draft-ietf-stir-certificates-shortlived-03

["Peterson, Jon" <[e-mail]>]

It is Wednesday (November 5) afternoon at 16:00 Eastern (GMT -5), per:

https://datatracker.ietf.org/meeting/124/agenda

Jon Peterson
TransUnion

From: James Olorundare <[e-mail]>
Date: Sunday, November 2, 2025 at 3:25 PM
To: Peterson, Jon <[e-mail]>
Cc: Ben Campbell <[e-mail]>, Russ Housley <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [stir] Re: Shepherd Review of draft-ietf-stir-certificates-shortlived-03

This Message is from a New Sender
This message was sent from a sender with whom you have not previously corresponded.
Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/GX53klZ1TQ0!Y2Oq2O_af5QFZUGjwSeAjK62IWPeXr7fpTC1PVsGqwvfEiZzwKL1IYYlCYm1DLYpCqIzavZDusDoZHqAjqGp8Sa24HJwwuMeD3WDk5CFOMkz3RpuLejsULd9xLfroNGB$>

Please when is the stir meeting in the ongoing IETF124?

Thank you.

Sent from Gmail Mobile of Ojk


On Sun, 2 Nov 2025 at 15:06, Peterson, Jon <Jon.Peterson=[e-mail]<mailto:[e-mail]>> wrote:

Thank Ben, some responses below:




##Standard Questions



- Are you aware of any IPR that needs to be declared?


<JFP> I am not aware of any IPR.


- Do you still want your name on the resulting RFC?


<JFP> Yes.



## Substantive Comments

### Section 1

- “… this document revises the guidance of [RFC8224]…”: Should this draft formally update that RFC? If not, then maybe this should be reworded, otherwise there is a risk of the IESG getting wrapped around this axle.


<JFP> I don’t think it really needs to update RFC8224, as it is only compliance with this specification that makes support for “x5c” mandatory. I can rephrase to remove that implication.


### Section 4

- 2nd paragraph, “… this specification permits the conveyance”: IIUC, this specification _requires_ that conveyance for short-lived certs following this specification.


<JFP> It does indeed, will fix.


- Last paragraph: We are not actually allowing that alternative approach to x5c, right? I think this sentence will cause confusion during the IESG review. Is it actually needed?


<JFP> Um, the last paragraph says a couple of things. Making “x5c” mandatory does not preclude allowing “x5u” to also be present for backwards compatibility reasons. I think I’d like to keep that. And the x5c URL could use cid: or something to point to a MIME body, if we wanted it to, without running afoul of anything else discussed in this spec I think. The fact that MIME doesn’t work as well for OOB doesn’t mean this could never work as an approach. If it seems super confusing maybe it could go in an appendix or something?


<JFP> I’ll address the nits below, they seem fine.



## Minor Comments and Nits



### Section 1

- Paragraph 1: “… the implementation of credentials which identify…”: s/which/that

- “… this document revises the guidance of [RFC8224] to REQUIRE”: I’m guessing REQUIRE should not be capitalized, since this is a statement of fact, not an authoritative normative statement.

### Section 4:

- Example PassPORT: Has this been verified mechanically

### Normative References

- It seems like several of these could be informative and save people the problem of checking against the downref registry

- Are [ATIS-0300251] and [DSS] actually cited in the document somewhere? If so, I missed it.

Jon Peterson
TransUnion
_______________________________________________
stir mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>