A Profile for X.509 PKIX Resource Certificates
RFC 6487

Note: This ballot was opened for revision 22 and is now closed.

(Alexey Melnikov) Discuss

Discuss (2011-03-21 for -)
[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.
Comment (2011-03-12 for -)
No email
send info
4.4.  Issuer

   The value of this field is a valid X.501 distinguished name.

A reference to the document defining DNs is needed here. (One of the LDAP documents might do.)

   An Issuer name MUST contain one instance of the Common Name attribute
   and MAY contain one instance of the Serial Number attribute.  If both
   attributes are present, it is RECOMMENDED that they appear as a set.
   The Common Name attribute MUST be encoded as a printable string.

Similarly, a reference for printable string is needed.

   Issuer names are not intended to be descriptive of the identity of
   Issuer.

4.9.8.1.  SIA for CA Certificates

   The ordering of URIs
   in this accessDescription sequence reflect the CA's relative
   preferences for access methods to be used by RPs, with he first

s/he/the

   element of the sequence being the most preferred by the CA.


6.2.1.  CRMF Resource Certificate Request Template Fields

      version
         This field SHOULD be omitted.  If present, it MUST specify a
         request for a Version 3 Certificate.  It

Unfinished sentence?

(Stewart Bryant) Yes

(Sean Turner) Yes

Comment (2011-03-10 for -)
No email
send info
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.

(Jari Arkko) No Objection

Comment (2011-03-17 for -)
No email
send info
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"?

(Ron Bonica) No Objection

(Ralph Droms) No Objection

Comment (2011-03-15 for -)
No email
send info
Minor editorial suggestion: In the Abstract,
s/Resources (INRs)/Internet Number Resources (INRs)/

(Adrian Farrel) No Objection

(David Harrington) (was Discuss, No Objection) No Objection

(Russ Housley) No Objection

(Tim Polk) No Objection

Comment (2011-03-17 for -)
No email
send info
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.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-03-17 for -)
No email
send info
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.

(Robert Sparks) No Objection