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

[James Olorundare <[e-mail]>]

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]> 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]
> To unsubscribe send an email to [e-mail]
>