Subject: RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 10 Aug 2009 12:04:17 -0400

I had sent the following comments and Recommendations for the I-D to
Stefan last week.  This may of interest to others.

COMMENT 1
Section 2, Paragraph 1 states: "A particular OCSP server
   may or may not be provided by the CA that issued the certificate
   whose status is being queried and may or may provide a realtime
   indication of the certificate status or a time delayed status
   indication.".

The above should be changed to: "An OCSP Responder may or may not be
issued an OCSP Responder certificate by the CA that issued the
certificate whose status is being queried.  An OCSP Responder may
provide pre-signed OCSP responses, OCSP responses freshly signed in
response to an OCSP request, or a combination of the two."

COMMENT 2
Section 2, Paragraph 4 states: "While the responder may apply heuristics
such as using the signature
   algorithm employed by the certificate issuer, such heuristics fail in
   many common real-world situations where multiple signature algorithms
   are employed:"

The whole premise of using certificate signing algorithm seems to be
false.  It should be based on CRL signing.  Second 2 starting with
paragraph 4 and including first set of bullets and short paragraph
following the bullets should be revised as follows:

"While an OCSP Responder may apply rules such as using the signature
algorithm employed by the CA for CRL signing, the rule may not work in
the following circumstances:

o Algorithm used to sign the CRL may not be consistent with key pair
being used by the OCSP Responder to sign responses."

I do not see how the remaining three bullets will be applicable.

COMMENT 3
The following should be deleted from Section 2: "The last criterion is
significant as it occurs frequently in real world PKI deployments and
cannot be resolved through the information
   available from in-band signalling using the RFC 2560 [RFC2560]
   protocol without modification"

COMMENT 4
Section 2 states "In addition, a system that employs a signature
algorithm other than
   the de-facto default is frequently doing so to achieve very specific
   security properties that may not be captured by a heuristic
   assumptuion designed to facilitate interoperability rather than
   performance.  In particular:

   o  An implementation may intentionally employ an algorithm for
      certificate status response that is less computationally demanding
      than for signing the certificate itself, thus allowing for more
      frequent certificate status validation.

   o  An implementation may intentionally wish to guard against the
      possibility of a compromise resulting from a signature algorithm
      compromise by employing two separate encryption algorithms."

This should be changed as follows: "An OCSP Responder may wish to employ
different signature algorithm that the CRL signing algorithm for the
following reasons:

   o  In order to generate pre-signed response more frequently or to
meet the demand, the OCSP Responder may wish to employ a signing
algorithm that is computationally less demanding for signature
generation that the CRL signing algorithm
      
   o  A PKI may wish to guard against the possibility of a compromise
resulting from a signature algorithm compromise by employing two
separate signature algorithms for CRL and OCSP signing, thus allowing
the relying parties to employ one mechanism or other for certificate
status validation."

COMMENT 5
Section 3 states: "A client MAY declare a preferred set of algorithms
algorithms in a
   request using the preferred signature algorithm extension."

Change it as follows: "A client MAY declare a preferred set of
algorithms in a request using the preferred signature algorithms
extension."

COMMENT 6
Section 3, Should there be an indication these should be Algorithm
Identifiers asserted in SIGNED MACRO and Signature field as opposed to
those asserted in subject public key information?

COMMENT 7
Section 3, Should it discuss what the impact is of the curves to be
used?  Clients may not employ the curves in use by the server.

COMMENT 8
Section states: "If a set of preferred signature algorithms is declared
the client
   MUST support each of the specified algorithms"

This should be changed to "If a set of preferred signature algorithms is
specified by the client in the OCSP request, the client MUST support
each of the specified algorithms."

COMMENT 9
Section 4.1 and 4.2 need to stress that the OCSP Responder SHALL use
signing algorithm whose cryptographic bit security is acceptable to the
OCSP Responder.

COMMENT 10
Section 4.1, 2nd choice should be CRL signing algorithm.  Thus, switch
number 2 and 3.

COMMENT 11
Section 7.2 should be revised as follows:

   "The mechanism to support client indication of preferred signature
   algorithms is not protected against a man in the middle downgrade
   attack.  This constraint is not considered to be a significant
   security concern since the OCSP Responder MUST NOT sign OCSP
Responses using weak algorithms even if requested by the client.  In
addition, the client can reject OCSP responses that do not meet its own
criteria for acceptable cryptographic security no matter what mechanism
is used to determine the signing algorithm of the response.  This can be
achieved using the DSSC I-D."

COMMENT 12
The document needs additional editing.

Santosh Chokhani
CygnaCom Solutions

"Questioning conventional wisdom is key to innovation"

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Aug 2009 15:06:09 +0200

Santosh,

Thank you for your extensive review.

Instead of arguing all details in a mail, I have updated the draft,
following most of your recommendations.

The new draft is available here:
http://www.ietf.org/id/draft-ietf-pkix-ocspagility-02.txt

I have done nothing about comment 6 and 7.
Do you have any proposal on what specific changes you would like to make?

Let me know if this draft resolves your comments?

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 12 Aug 2009 10:11:59 -0400

Stefan,

Thanks.  I will  review version 2 and make comments including
suggestions for the two comments mentioned below by you. 

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Wednesday, August 12, 2009 9:06 AM
> To: Santosh Chokhani; ietf-pkix
> Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt
> 
> Santosh,
> 
> Instead of arguing all details in a mail, I have updated the 
> draft, following most of your recommendations.
> 
> > Section 2, Paragraph 4 states: "While the responder may apply 
> > heuristics such as using the signature
> > This should be changed as follows: "An OCSP Responder may wish to 
> > employ different signature algorithm that the CRL signing algorithm 
> > for the following reasons:
> > 
> > Section states: "If a set of preferred signature algorithms is 
> > declared the client
> > This should be changed to "If a set of preferred signature 
> algorithms 
> > is specified by the client in the OCSP request, the client MUST 
> > support each of the specified algorithms."
> > 
> > COMMENT 9
> > signing algorithm whose cryptographic bit security is acceptable to 
> > the OCSP Responder.
> > 
> > COMMENT 10
> > addition, the client can reject OCSP responses that do not meet its 
> > own criteria for acceptable cryptographic security no matter what 
> > mechanism is used to determine the signing algorithm of the 
> response.  
> > This can be achieved using the DSSC I-D."
> > 
> > COMMENT 12

---

From: "Seth Hitchings" <[email-masked]>
Date: Fri, 14 Aug 2009 10:47:05 -0400

Hi Stefan,

I have two reasonably straightforward comments.

1. Section 3 defines an OCSP request extension, but neglects to specify
which of the two extension lists (requestExtensions or
singleRequestExtensions) the extension should be included in.

2. Section 4.1, item 3 refers to the "signing algorithm used to sign the
CertID specified in the query", however, the CertID is not signed. Is
this meant to specify that the server use the signing algorithm used by
the client to sign the entire OCSPRequest, or to specify that the server
use the signing algorithm used by the CA to sign the certificate
identified by the CertID? If the answer is the latter, what is the
expected behavior if the request queries multiple certificates that were
signed using different signature algorithms?

Thanks,
Seth Hitchings
CoreStreet, Ltd.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, August 12, 2009 9:06 AM
To: Santosh Chokhani; ietf-pkix
Subject: Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt

Santosh,

I have done nothing about comment 6 and 7.
Do you have any proposal on what specific changes you would like to
make?

/Stefan

> Section 2, Paragraph 4 states: "While the responder may apply
heuristics
> This should be changed as follows: "An OCSP Responder may wish to
employ
> Section states: "If a set of preferred signature algorithms is
declared
> signing algorithm whose cryptographic bit security is acceptable to
the
> addition, the client can reject OCSP responses that do not meet its
own

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 Aug 2009 08:53:29 +0200

Thanks Seth. Good catches both of them.

Comments in line.

> singleRequestExtensions) the extension should be included in.

As this is a declaration of the general preference of the client It must be
included in requestExtensions.

I'll add a note.

> signed using different signature algorithms?

It's meant to specify the signing algorithm used to sign the request if the
request is signed.