Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-keyroll-08
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Adrian Farrel; former steering group member) Yes
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.
(Stewart Bryant; former steering group member) Yes
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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.
(Wesley Eddy; former steering group member) No Objection