Last Call Review of draft-ietf-acme-star-06
review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21-00

Request Review of draft-ietf-acme-star
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-08-01
Requested 2019-07-11
Draft last updated 2019-07-21
Completed reviews Genart Last Call review of -06 by Meral Shirazipour (diff)
Opsdir Last Call review of -06 by Mehmet Ersue (diff)
Assignment Reviewer Mehmet Ersue
State Completed
Review review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/qLfRZ1cvylhRqaWEDbHtD_KMGKA
Reviewed rev. 06 (document currently at 09)
Review result Has Nits
Review completed: 2019-07-21

Review
review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21

I reviewed the document "Support for Short-Term, Automatically-Renewed (STAR) Certificates in        Automated Certificate Management Environment (ACME) (draft-ietf-acme-star-06) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  
These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Intended status: Standards Track
Current IESG state: In Last Call (ends 2019-08-01)   
IANA State: IANA - Review Needed 

Summary: 

The document proposes an ACME extension to enable the issuance of short-term and automatically renewed (STAR) X.509 certificates.
There are no nits in the document.

As far as I can see the document does not cause any issues related to operations and management. 
Though I have two suggestions:

1) 
> 4.2.  Impact on Certificate Transparency (CT) Logs
...
>      The input received from most members of the CT community when the
>      issue was raised was that this should not represent a problem for the
>      CT architecture.

This statement is pretty vague for a standard track document. I assume the reader will be asking what "most members" mean and why it shouldn't represent a problem for the CT architecture.

2)
> 7.1.  No revocation
...
>      More discussion of the security of STAR certificates is available in
>      [Topalovic].

AFAIU the external paper referred to does not adress security considerations directly. If you think there are concrete security considerations related to "No revocations" I would like to suggest to list them here.

Thanks,
Mehmet