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