Ballot for draft-ietf-lamps-hash-of-root-key-cert-extn
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
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).
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).
The CTIA acknowledgement seems unusual since it doesn't acknowledge any actual contribution to the document.
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).
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.
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?