Skip to main content

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)

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.