Hash Of Root Key Certificate Extension

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

Roman Danyliw Yes

Barry Leiba Yes

Comment (2019-05-28 for -05)
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).

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2019-05-28 for -05)
The CTIA acknowledgement seems unusual since it doesn't acknowledge any actual contribution to the document.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-06-28 for -06)
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).

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-05-29 for -05)
No email
send info
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).

(Mirja Kühlewind) No Objection

Comment (2019-05-22 for -05)
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?

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Magnus Westerlund No Objection

Comment (2019-05-21 for -05)
No email
send info
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.