I do not "buy" your argumentation,
since it is based on RFC 2459 which is now obsolete and had two successors.
Also, your argumentation is defeated, simply
because RFC 2459 was issued before RFC 2560, which means
before OCSP ever existed.
As I already said on the list , at the
time RFC 2560 was issued, we should have asked to ITU-T to add a OCSPsign
key usage bit.
Nobody raised the point at the proper
time. It seems too late now. So asserting instead the DS bit is not the
but it is the most acceptable.
Rob Stradling <rob.stradling <at> comodo.com>
mrex <at> sap.com
"pkix <at> ietf.org"
<pkix <at> ietf.org>
Re: [pkix] Integrated
OCSP Responders / Key Usage bits
Envoyé par :
pkix-bounces <at> ietf.org
On 31/05/12 16:59, Martin Rex wrote:
> Rob Stradling wrote:
>> Are you saying that trying to "fix" the standards is
not really an option?
>> What security hole would be introduced by once again allowing
>> "crlSign" bit to authorize the CA certificate as an
> This is _NOT_ a defect of rfc2560, it was a conscious design decision,
> and a careful implementor should have seen this.
RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign
bit is asserted when the subject public key is used for verifying a
signature on revocation information (e.g., a CRL)."
So if there was "a conscious design decision" by the RFC2560
regarding which Key Usage bits should be set in the Integrated Responder
case, then surely that decision was in agreement with what I am asking
for and in disagreement with the altered text in RFCs 3280 and 5280!
> So "fixing" does not exist as an option only changing the
> in a successor OCSP spec. But should still account for implementations
> based on rfc2560 alone.
And what about accounting for implementations based on RFC2459 alone?
> What is more confusing to me is that you're PKI software did not
> error on your attempt to sign OCSP responses without the
> DigitalSignature bit in your CA cert. When sensibly implemented,
Our PKI software was written by me, and until this week I hadn't noticed
that RFC3280/5280 changed the rules on which Key Usage bit means what.
Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice
sooner. Call me a careless implementor if you like.
>a signature creation function should perform a number of plausibility
> checks on signature creation (including KeyUsage and Validity),
> because it does not make sense (other than in very limited debug
> situations) to create digital signatures that receipients will
> very probably fail verifying.
Let's look at this from another angle:
What would happen today if a CA decides to implement an
RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs?
If they follow RFC5280's guidance, they will set keyCertSign and
digitalSignature (but NOT cRLSign) in the CA Certificate(s).
Then, what would happen when an RFC2459-compliant client attempts to
perform an OCSP check on an end-entity certificate from this PKI? If
the client enforces the RFC2459 definitions of the Key Usage bits, it
would reject the OCSP Response because the CA Certificate does not have
the cRLSign bit set!!
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
pkix mailing list
pkix <at> ietf.orghttps://www.ietf.org/mailman/listinfo/pkix