A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-22
Discuss
Yes
(Stewart Bryant)
No Objection
(Adrian Farrel)
(Dan Romascanu)
(David Harrington)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 22 and is now closed.
Alexey Melnikov Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2011-03-21)
Unknown
[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 IESG member
Yes
Yes
(2011-03-10)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Harrington Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2011-03-17)
Unknown
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 IESG member
No Objection
No Objection
(2011-03-17)
Unknown
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 IESG member
No Objection
No Objection
(2011-03-15)
Unknown
Minor editorial suggestion: In the Abstract, s/Resources (INRs)/Internet Number Resources (INRs)/
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2011-03-17)
Unknown
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.