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

[Stefan Santesson <stefan@xxxxxxxxxxx>]

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


On 09-08-10 6:04 PM, "Santosh Chokhani" <SChokhani@xxxxxxxxxxxx> wrote:

> 
> 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"
>