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 email
send info
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


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 email
send info
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.

(David Harrington) No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection