[Last-Call] Re: draft-ietf-stir-certificates-shortlived-05 ietf last call Opsdir review

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

Thanks for the review Gen, a few notes below:


Minor Issues
- No "Operational Considerations" section presented, since carriers are mainly
responsible with certificates request to ACME server and the running of STIR
mechanism.

<JFP> Okay I added some Ops Considerations in a new section. </JFP>

- Some descriptions in the document are not complied with the key
words in section 2, this could make the readers confusing on what should be
complied with. (examples: "As an optimization, this specification requires the
conveyance of the certificate chain for a short-lived certificate via the "x5c"
JWS header element" in section 4, here the "requires" is suggested to be
replaced with key words in section 2)

<JFP> Section 2, the introduction, is not normative. The statement in Section 4 is far more precise about exactly who needs to support and use exactly what. To avoid confusion, I will replace the word “requires” in 2 with “specifies”, so no one thinks it is a stray keyword. Did the same for another “requires”. </JFP>

- x5c is standardized in JWS (RFC 7515)
but its use with short-lived certificates in high-volume SIP networks is
unproven at scale. There is no clarification on the performance risks involved.

<JFP> I did put a bit about that in the new Ops Consideration. </JFP>

Nits
The document didn't specify reasonable default values for critical parameters,
such as:
- Certificate lifetime: Vague ("days or even hours"). No default or
recommended value

<JFP> I’m not sure it’s our place to recommend a value. I think there are scenarios where doing it for days works, and others where generating a new certificate on a per-call basis would work. </JFP>

- ACME pre-fetch window: how long before expiry to request
renewal

<JFP> As with above, I’m not sure there’s a one-size-fits-all recommendation I favor, or even T-shirt sizes. I did mention this in Ops Considerations. </JFP>

- Retry policy: Aggressive retries overwhelm CA

<JFP> This is also mentioned in Ops Considerations now. </JFP>

Jon Peterson
TransUnion