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

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 1 Nov 2010 13:23:41 -0400

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, October 14, 2010 3:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

	Title           : X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
	Author(s)       : D. Cooper, S. Santesson
	Filename        : draft-ietf-pkix-rfc2560bis-02.txt
	Pages           : 42
	Date            : 2010-10-14

This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2560bis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 2 Nov 2010 12:45:05 +0100

I am concerned as well.

In order to allow for backwards interoperability, the designated OCSP responder certificate 
MUST be signed by the same key that certificate in question was signed.

I sent emails on this topic :
on October, 8:  12 comments on draft-cooper-pkix-rfc2560bis-00 (re-sent), and
on October 12: 12 comments on draft-cooper-pkix-rfc2560bis-00

In the later e-mail, I  have proposed text to solve the issues that have been raised.

I would appreciate a response to these emails, at least from the authors of the draft.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2010-11-01, 18:23:41
Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-02.txt

David,

-----Original Message-----

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 30 Nov 2010 11:10:22 -0500

Denis,

While you say that your goal is to "allow for backwards
interoperability", your proposed changes would result in a change to
the OCSP protocol, which is outside of the scope of this effort.  On
September 10, I provided a detailed response to your message proposing,
among other things, that 2560bis require OCSP responses or OCSP
responder certificates to be signed using the same key as the target
certificate
(http://www.ietf.org/mail-archive/web/pkix/current/msg28345.html).
While you have since then sent proposed text that would impose a "same
key" requirement, you never responded to my September 10 message.  I
argued why a "same key" requirement would be inconsistent with RFC 2560
(and RFC 5280 and X.509).  If my argument was wrong, why haven't you
responded with an explanation of what it was about my argument that was
incorrect?

Dave

On 11/02/2010 07:45 AM, Denis Pinkas wrote:

I am concerned as well.

In order to allow for backwards interoperability, the designated
OCSP responder certificate

on October, 8:  12
comments on draft-cooper-pkix-rfc2560bis-00 (re-sent), and

on October 12: 12 comments on
draft-cooper-pkix-rfc2560bis-00

In the later e-mail, I  have proposed text to solve the issues
that have been raised.

I would appreciate a response to these emails, at least from
the authors of the draft.

Denis

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 30 Nov 2010 11:49:22 -0500

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,