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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

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"