Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Dec 2010 07:54:29 -0500

David,

1.  Section 4.1.2 of the RFC is concerned about name uniqueness since it
may not be enforceable.  So, X.500 argument does not carry.

2.  Section 2.2 calls for requiring the key to belong to the proper
entity.

3.  Section 4.2.2.2 of the RFC calls for certificate matching

These and implementation that have been there lead me to believe that
key and not DN matching is required.

As to 5280 and CRL, that was not a good decision and was made by the
editors of the RFC despite my concerns.  For 5280 statement to provide
security one of the following two has to be true:

1.     There needs to be Global name uniqueness (in which case you do
not need 5280 statement); or

2.     Client trust anchors need to have name uniqueness or disjoint
name constraints asserted

From: David A. Cooper [mailto:[email-masked]] 
Sent: Tuesday, November 30, 2010 11:49 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

Santosh,

As I said in my response to Denis, I cannot find anywhere in RFC 2560
that explicitly mentions or implies that keys should be used for
matching.   Can you point to text in RFC 2560 that supports your
argument?  I only see requirements for "same CA", not for "same key".

Why should the security considerations section for 2560bis need to be
any different from that in RFC 5280?  The same issue appears in RFC 5280
with respect to CRLs (both CRLs issued by the certificate issuer and
indirect CRLs).  This issue also appears with attribute certificates
(RFC 5755), where the Holder is identified either by the entity's name
or by the issuer name and serial number of the entity's public key
certificate.  This is all consistent with X.509, which requires that
names unambiguously identify a single entity.

X.501 says:

9.1.4 (directory) name: A construct that singles out a particular object
from all other objects. A name shall be unambiguous (that is, denote
just one object); however, it need not be unique (that is, be the only
name which unambiguously denotes the object).

9.1.5 (entry) name: A construct that singles out a particular entry from
all other entries.

9.2 Names in general

A (directory) name is a construct that identifies a particular object
from among the set of all objects. A name shall be unambiguous, that is,
denotes just one object.

An object can be assigned a distinguished name without being represented
by an entry in the Directory, but this name is then the name its object
entry would have had were it represented in the Directory.

and X.509 says:

NOTE 1 - Although the CAs are unambiguously defined by a distinguished
name in the DIT, this does not imply that there is any relationship
between the organization of the CAs and the DIT.

For every name form used in the GeneralName type, there shall be a name
registration system that ensures that any name used unambiguously
identifies one entity to both certificate issuer and certificate users.

Dave

On 11/01/2010 01:23 PM, Santosh Chokhani wrote: 

David,
 
I remain concerned about the direction this document has taken.
 
RFC 2560 explicitly mentioned or implied that keys should be used for
matching and not the DN.  The OCSP clients I am familiar except a newly
released client, required designated OCSP responder certificate to be
signed by the same key that certificate in question was signed.
 
The remedy for name collision in Security Considerations section is not
very useful given that many CAs are cross-certified and you can build a
path from a root to many other CAs and uneven use of name constraints.
 
The Appendix E has an acceptable set of trust model, but there is no
client side processing requirement that enforces or verifies that the
trust model is adhered to leaving unintentional or intentional name
collision as a problem.
 
The document should be revised in the following areas.
 
It should require or strongly recommend use of and check for the key
being the same that signed the certificate in question and OCSP Response
(for integrated) or being the same for signing the OCSP certificate and
certificate in question (for designated).
 
The locally trusted responder should be based on trusted key and not
just the name,
 
The security considerations section should describe the limitation of
same trust anchor due to cross certified environments and possible lack
of name constraints.
 
Somewhere there should be warning that while Appendix E provides
acceptable trust model, none of the PKIX standards (i.e., 5280 or
2560/2560bis) have mechanisms for the client to vet adherence to the
trust model.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Dec 2010 08:00:01 -0500

David,

Sorry.

Continuing on, the RFC does not call for DN or name matching either.
The preponderance of evidence when you read the RFC is towards key
matching and not DN matching.  To, me it is like "separation of church
and state" argument in the US constitution.

As I mentioned to you offlist, this RFC, SCVP RFC and may other RFCs
will benefit from having processing rules a la Section 6 of 5280.  As
early as 2000, I made this suggestion for 2560 and having these rules is
important to security.  Just defining ASN.1 ensures interoperability
only and not security.

From: Santosh Chokhani 
Sent: Wednesday, December 01, 2010 7:54 AM
To: 'David A. Cooper'
Cc: [email-masked]
Subject: RE: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

David,

 

Santosh,

X.501 says:

9.2 Names in general

and X.509 says:

Dave

David,