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

From: [email-masked]
Date: Mon, 03 Oct 2011 05:03:29 -0700

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)       : David Cooper
                          Stefan Santesson
	Filename        : draft-ietf-pkix-rfc2560bis-04.txt
	Pages           : 43
	Date            : 2011-10-03

   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-04.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc2560bis-04.txt

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 4 Oct 2011 12:31:44 -0400

I do not see a need or benefit to progressing this document.

It is a step back from existing RFC 2560.

My security concerns regarding this draft are well documented.

I would support an effort if it required crypto binding for the Responder Key and CA Key or if required Responder Certification Path and Subject Certificate "Certification Path" name matching.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 03, 2011 8:03 AM
To: [email-masked]
Cc: [email-masked]
Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-04.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc2560bis-04.txt
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Oct 2011 11:24:07 +0200

All,

I'm implementing OCSP right now.  I cannot find any discussion about the
ResponderID structure in RFC 2560 nor in RFC2560bis, or I have gone
blind re-reading the same document too many times.

For the responderID.byName field, the document could say the field
should contain the identity of the responder.  That is what I assume
should be in there.  Is there a requirement/assumption for the byName to
be the same as the Subject of the certificate that signed the response,
if any?  Is that a MUST/SHOULD/MAY for responders?  MUST/SHOULD/MAY the
requester validate that property?

I'm concerned with the hard-coded use of SHA1 in the responderID.byKey
field.  I don't see any attack, it is just that there doesn't seem to be
any way to negotiate another hash function.  Could we deprecated the
field?  If most deployments use byName that may be possible.
Alternatively, we could specify an extension where the client can
specify a sequence of preferred hash algorithms and the server can
select an appropriate algorithm and use that instead.  Or the responder
could snuck a byKey SHA-256 hash in a responseExtensions.

Thanks,
/Simon

---

From: Piyush <[email-masked]>
Date: Wed, 5 Oct 2011 21:37:22 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Josefsson
> Sent: Wednesday, October 05, 2011 2:24 AM
> To: [email-masked]
> Subject: [pkix] OCSP ResponderID
> 
> All,
> 
> ResponderID structure in RFC 2560 nor in RFC2560bis, or I have gone blind
re-
> reading the same document too many times.
> 
> For the responderID.byName field, the document could say the field should
> contain the identity of the responder.  That is what I assume should be in
> there.  Is there a requirement/assumption for the byName to be the same as
> the Subject of the certificate that signed the response, if any?  Is that
a
> MUST/SHOULD/MAY for responders?  MUST/SHOULD/MAY the requester
> validate that property?

You are right in saying that the details are missing from the document. I
believe that the purpose of this field is to help the requestor locate the
correct certificate that is used to sign the response. I have not seen a
single implementation that sets it to anything other than the subject name
of the signer (if byname is used). 
In case of name clash, where the responder has multiple signing certificates
(with same name but different signing key), they use the keyhash option.
> field.  I don't see any attack, it is just that there doesn't seem to be
any way
> to negotiate another hash function.  Could we deprecated the field?  If
most
> deployments use byName that may be possible.
> Alternatively, we could specify an extension where the client can specify
a
> sequence of preferred hash algorithms and the server can select an
> appropriate algorithm and use that instead.  Or the responder could snuck
a
> byKey SHA-256 hash in a responseExtensions.
> 

I don't think that hash function used for creating the responder ID has any
security implications. In the worst case, the requestor will find more than
one certificate with the same keyhash and it'll result in an extra signature
check to find the right certificate.

> /Simon

-Piyush