Skip to main content

Hash Of Root Key Certificate Extension
draft-ietf-lamps-hash-of-root-key-cert-extn-07

Yes

Roman Danyliw

No Objection

Éric Vyncke
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
(Suresh Krishnan)

Note: This ballot was opened for revision 05 and is now closed.

Roman Danyliw
Yes
Warren Kumari
No Objection
Comment (2019-05-29 for -05) Not sent
THank you for writing this -- I was initially fairly uncomfortable that this could be used if a CA's keys were ever compromised by an attacker to persist their access (they could publish a new certificate to a captive population listing a new key which they control), but I *think* that this is addressed / is true of the current situation. Things like RFC5011 include hold-down timers to mitigate this type of isse, but I *think* that this isn't needed here, because this isn't (from what I parse) rollover, just an assertion of what to expect for the next key (delivered though some other means).
Éric Vyncke
No Objection
Barry Leiba Former IESG member
Yes
Yes (2019-05-28 for -05) Sent
Useful stuff and well written; thanks very much.

I, too, wonder why this isn't Proposed Standard (and why the shepherd writeup doesn't explain that).
Alissa Cooper Former IESG member
No Objection
No Objection (2019-05-28 for -05) Sent
The CTIA acknowledgement seems unusual since it doesn't acknowledge any actual contribution to the document.
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-06-28 for -06) Sent
Thank you for addressing my Discuss (and Comment) points!

It looks like the ASN.1 module changes from the -05 to the -06
left a stale definition of HashAlgorithmId (but if it is not stale
then the import of DIGEST-ALGORITHM would need to be restored).
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (2019-05-21 for -05) Not sent
I would appreciate if one could explain why this document is being published as an informational one. I am sure there are reasons, but they are not evident from the writeup.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-05-22 for -05) Sent
Why is the intended status informational? Unfortunately, this is not further explained in the shepherd write-up. What was the discussion in the group and why was informational selected? As this doc defines a protocol extension, informational does not seem appropriate for me. Should it be experimental instead?

Quick question/comment: The document mentions two “error” cases where a new self-signed certificate needs to be deployed. If that is an option that always need to be taken into account, the benefits of this mechanism are less clear to me. What is the exact attack scenarios this mechanism tries to protect?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -05) Not sent