[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D Action:draft-ietf-pkix-ocspagility-01.txt
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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
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,
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"
>