[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-ietf-pkix-ocspagility-01.txt
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:
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?
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
> 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
> 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"