A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-22
Discuss
Yes
No Objection
Note: This ballot was opened for revision 22 and is now closed.
(Alexey Melnikov; former steering group member) Discuss
[Updated as per Sam Hartman's SecDir review discussion and a further discussion with Sam] This is a well written document and I generally support its publication. I was originally planning to file a DISCUSS on this issue, but though that the WG knows better. However Sam's SecDir review has changed my mind: Sam wrote: I do not believe the concerns I raised in my secdir review have been addressed and I still have a deep architectural concern with the decision to prevent relying parties from accepting unknown non-critical extensions. There seems to be agreement with several points I raised: 1) The profile does prohibit unknown extensions. 2) I think there is agreement that before we can start using an error correction or new feature, we have to upgrade all software in the wild that might see the certificates. 3) Everyone including me thinks that strong restrictions on what certificates are created is good for this profile. The question is what about restrictions on what people receive. If the IETF changes the standard in the future do we want to have to upgrade issuers and consumers or just issuers before we start using the new spec in what we issue. 4) We may find ourself in a situation where we made a mistake or need to expand what the RPKI does. Adding from myself: I think there is no disagreement that extensions not listed in this profile SHOULD NOT (or even MUST NOT) be generated. However I think the WG is shooting itself in the foot by making receivers reject certificates with unrecognized non critical extensions. A much better architectural approach would be to say that such non critical extensions "MUST be ignored". This is a pretty standard trick in the Apps Area and allows for safe extensibility.
(Sean Turner; former steering group member) Yes
Need to add normative reference to RFC 2119 as per: http://www.rfc-editor.org/policy.html#policy.2119ref "Valid From" should be "Not Before" and "Valid To" should be "Not After" to match the name of fields in RFC 5280.
(Stewart Bryant; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) (was Discuss, No Objection) No Objection
(Jari Arkko; former steering group member) No Objection
From Ari Keränen's review:
1. Introduction
o a conformation of a public key match between the CRL issuer and
the Resource Certificate issuer is required, and
Should that be "confirmation"?
(Peter Saint-Andre; former steering group member) No Objection
Although I am provisionally balloting "No Objection" pending discussion within the IESG, I too am concerned about the issues raised in Alexey Melnikov's DISCUSS.
(Ralph Droms; former steering group member) No Objection
Minor editorial suggestion: In the Abstract, s/Resources (INRs)/Internet Number Resources (INRs)/
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
I support Alexey's discuss-discuss: the upgrade path for sidr-res-certs is not typical for IETF publications. It would be good for the IESG to discuss the merits and drawbacks of the wg's consensus approach. However, I should note that I personally am comfortable with the approach based on the unique attributes of its intended deployment and application. Various aspects of this problem have been actively discussed since Stockholm.