Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)
Note: This ballot was opened for revision 08 and is now closed.
(Stewart Bryant) Yes
(Adrian Farrel) Yes
Comment (2011-06-21 for -** No value found for 'p.get_dochistory.rev' **)
I have a couple of comments that don't merit a Discuss, but I would be grateful if the authors thought about them and made any necessary changes. --- I found Section 1... This document defines a conservative procedure ...ambiguous. I think that "conservative" needs to be qualified in some way. conservative with respect to conserving keys? Not changing keys often? Not requiring many messages? Not risking security? --- There are a couple of uses of SHOULD which I feel would benefit from an explanation of how/why a variation MAY be allowed. In one case, I am relatively sure you mean MUST rather than SHOULD, viz. To perform a key rollover operation the CA MUST perform the following steps in the order given here. Unless specified otherwise each step SHOULD be performed without any intervening delay. The process MUST be run through to completion. That is, the variance is already handled by "unless specified otherwise" so there is no further scope for variance.
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Stephen Farrell) No Objection
Comment (2011-06-17 for -** No value found for 'p.get_dochistory.rev' **)
4.1 - is it really wise to encourage (even obliquely) re-use of serial numbers? I'd say s/MAY change/SHOULD change/ there would be better. If making that change, it'd be good to say when its ok to re-use serial numbers - that could be when an internal DB design uses certificate.serialNumber as a DB key which may be silly but has been done.