headers
Manger, James H | 1 Jun 2012 01:50

Re: Way Forward: Name Constraints Criticality

> I guess I just don't see why you'd include NC in a cert but *not* mark it
> critical.  Non-critical NC basically says "Beyond this point you should
> {only see/never see} the following names, but we don't actually care if
> you pay attention."

The last phrase is better re-phrased as:
"..., but we [the CA] don't actually force you [the relying parties] to pay attention -- that is your choice/responsibility."

RFC5280 almost gives each relying party the choice by saying they SHOULD (not MUST) handle name
constraints on domain names, but then effectively takes away that choice by forcing a CA to make one
decision for all relying parties (critical constraint, or no constraint). 

--
James Manger

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Phillip Hallam-Baker | 1 Jun 2012 04:19
Picon

Re: Way Forward: Name Constraints Criticality

I am not going to reply to the points discussed at length already.


I do however note that the security considerations for marking name constraints critical are markedly different for bridge CA configurations.

In particular you are going to be a most unhappy bunny if you try to operate a bridge CA type infrastructure and do not mark your NCs as critical. In particular every CA in the bridge becomes a defacto root for every other member and the whole point of the bridge is utterly lost.


Whether it is a must or a should, we probably don't want that particular point to get lost.
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Jun 2012 07:14
Picon
Favicon
Gravatar

Re: RFC 5742 review of draft-hotz-kx509 and about RFC 4211

denis.pinkas <at> bull.net writes:

> I skimmed through the document and read the following two sentences:

>    The public key in the request is sent in the clear, and without any
>    guarantees that the requestor actually possesses the corresponding
>    private key.

>    [RFC4211], Appendix C contains a more detailed discussion of why 
>    proof-of-possession is important.

> I have concerns with both sentences.

> [RFC4211] is incorrect and this has security implications on the
> proposed protocol.

Hi Denis,

As Henry has mentioned, we have the limitation with this particular
document that we're attempting to document an existing, deployed protocol
sufficiently that interoperable implementations can be created.  This
protocol is deficient in multiple ways, and designing a better protocol is
expected follow-on work.  Changing something fundamental, such as
requiring confidentiality in this protocol exchange, would defeat the
point of the current work.

Therefore, I think that any remedy here should be limited to clearly
documenting the issue in the Security Considerations section rather than
changing the protocol.

If I'm understanding your message properly, you're saying that there is a
partial defense against the lack of proof-of-possession by adding
confidentiality protection to the exchange.  I'm not sure in this context
whether this really changes the security analysis of this protocol, given
that no confidentiality is used.  But if I'm missing something, could you
suggest something that we could add to Security Considerations?

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 3 comments |
headers
Tomas Gustavsson | 1 Jun 2012 08:08
Picon

Re: Integrated OCSP Responders / Key Usage bits


On 05/31/2012 03:45 PM, Rob Stradling wrote:
> On 29/05/12 09:24, Rob Stradling wrote:
>> On 25/05/12 10:04, Rob Stradling wrote:
>>> Which Key Usage bits (if any) are required to be present in a CA
>>> Certificate that directly signs OCSP Responses?
>> <snip>
>>> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or not
>>> the CA Certificate can directly sign OCSP Responses, but sadly I can
>>> find no text to support this idea.
>>
>> I've unearthed some text to support this idea, so at least I'm now sure
>> I didn't completely make it up myself!
>>
>> RFC2459 said...
>> "The cRLSign bit is asserted when the subject public key is used for
>> verifying a signature on revocation information (e.g., a CRL)."
>> "The digitalSignature bit is asserted when the subject public key is
>> used with a digital signature mechanism to support security services
>> other than...revocation information signing (bit 6)."
>>
>> Obviously an OCSP Response's signature is "a signature on revocation
>> information".
>>
>> Why did RFC3280 change the required bit for signing non-CRL revocation
>> information from "cRLSign" to "digitalSignature"?

That is interesting. Way back, a long time ago when we started 
development of integrated OCSP in EJBCA I had to assert digitalSignature 
in the CA certificate in order for things to work in, I think browsers. 
I had never considered that this behaviour might have changed, but it 
sounds as it has.

>>
>> Could we change it back, or at least allow either "cRLSign" or
>> "digitalSignature" to be deemed acceptable for signing non-CRL
>> revocation information?
>
> PHB just noted in another thread that "The point of standards is to
> achieve interoperability". I'll restate my question with this thought in
> mind.
>
> We (Comodo) sign OCSP Responses directly from CA Certificates that have
> the keyCertSign and cRLSign bits set but the digitalSignature bit unset.
> This is/was fully compliant with RFC2459, but (I realized only this
> week) not compliant with 3280/5280.
>
> Thus far, I've not encountered any client software that rejects our OCSP
> Responses.
>
> But to "achieve interoperability", I wish to ensure that no future
> client software rejects our OCSP Responses on the basis that the
> digitalSignature bit is not set in the CA Certificates.
>
> So, can we please reinstate the 2459 text that "The cRLSign bit is
> asserted when the subject public key is used for verifying a signature
> on revocation information" or at least say that cRLSign and/or
> digitalSignature is sufficient for this purpose?
>

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
denis.pinkas | 1 Jun 2012 09:24
Picon

Re: RFC 5742 review of draft-hotz-kx509 and about RFC 4211

First of all, thank you for both of you for your fast response.

I am not arguing there is an RFC 5742 conflict with this document.

Since you said that is an attempt to document an existing deployed protocol, we cannot change it.

Since you said that designing a better protocol is an expected follow-on work, I raise the question to both the editors and the WG chairs
whether the document should be on the experimental track rather than on the informational track.

Clearly, I believe that only changes to the security consideration sections should be made, keeping in mind that
confidentiality an integrity protection can be done at lower layers. This is what the security considerations section should recommend.

Finally, I believe an errata on RFC 4211 should be prepared, but this is a separate concern with Jim.

Denis



De :        Russ Allbery <rra <at> stanford.edu>
A :        denis.pinkas <at> bull.net
Cc :        hotz <at> jpl.nasa.gov, Jim Schaad <ietf <at> augustcellars.com>, pkix <pkix <at> ietf.org>
Date :        01/06/2012 07:20
Objet :        Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211



denis.pinkas <at> bull.net writes:

> I skimmed through the document and read the following two sentences:

>    The public key in the request is sent in the clear, and without any
>    guarantees that the requestor actually possesses the corresponding
>    private key.

>    [RFC4211], Appendix C contains a more detailed discussion of why
>    proof-of-possession is important.

> I have concerns with both sentences.

> [RFC4211] is incorrect and this has security implications on the
> proposed protocol.

Hi Denis,

As Henry has mentioned, we have the limitation with this particular
document that we're attempting to document an existing, deployed protocol
sufficiently that interoperable implementations can be created.  This
protocol is deficient in multiple ways, and designing a better protocol is
expected follow-on work.  Changing something fundamental, such as
requiring confidentiality in this protocol exchange, would defeat the
point of the current work.

Therefore, I think that any remedy here should be limited to clearly
documenting the issue in the Security Considerations section rather than
changing the protocol.

If I'm understanding your message properly, you're saying that there is a
partial defense against the lack of proof-of-possession by adding
confidentiality protection to the exchange.  I'm not sure in this context
whether this really changes the security analysis of this protocol, given
that no confidentiality is used.  But if I'm missing something, could you
suggest something that we could add to Security Considerations?

--
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 2 comments |
headers
denis.pinkas | 1 Jun 2012 09:48
Picon

Re: Integrated OCSP Responders / Key Usage bits

Rob,

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 perfect solution,
but it is the most acceptable.

Denis




De :        Rob Stradling <rob.stradling <at> comodo.com>
A :        mrex <at> sap.com
Cc :        "pkix <at> ietf.org" <pkix <at> ietf.org>
Date :        31/05/2012 23:39
Objet :        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 the
>> "crlSign" bit to authorize the CA certificate as an Integrated Responder?
>
> 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 authors
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 behaviour
> 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!!

> -Martin
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  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 the
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.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 4 comments |
headers
Henry B. Hotz | 1 Jun 2012 10:17
Picon
Picon
Favicon

Re: RFC 5742 review of draft-hotz-kx509 and about RFC 4211


On Jun 1, 2012, at 12:24 AM, <denis.pinkas <at> bull.net> wrote:

> First of all, thank you for both of you for your fast response. 

No prob.

> I am not arguing there is an RFC 5742 conflict with this document. 

OK.  Thanks.

> Since you said that is an attempt to document an existing deployed protocol, we cannot change it. 
> 
> Since you said that designing a better protocol is an expected follow-on work, I raise the question to both
the editors and the WG chairs whether the document should be on the experimental track rather than on the
informational track. 

The question has come up before, at least generically.  (With Steve Kent IIRC.)  I don't think it should be
standards track because we want to fix it.  I don't think it's actually experimental because it's somewhat
widely deployed.  I don't think it's historic because it's currently in use and we don't have a replacement
designed yet.  I do think it's informational because, well, the document is providing useful information
about a real internet protocol.

> Clearly, I believe that only changes to the security consideration sections should be made, keeping in
mind that confidentiality an integrity protection can be done at lower layers. This is what the security
considerations section should recommend. 

As I said in other email, adding confidentiality will probably be done in a future, incompatible version. 
Integrity protection is already provided (though without algorithm agility which will also be added in a
future, incompatible version).  The existing deployments are over bare UDP.

> Finally, I believe an errata on RFC 4211 should be prepared, but this is a separate concern with Jim. 
> 
> Denis 
> 
> 
> 
> De :        Russ Allbery <rra <at> stanford.edu> 
> A :        denis.pinkas <at> bull.net 
> Cc :        hotz <at> jpl.nasa.gov, Jim Schaad <ietf <at> augustcellars.com>, pkix <pkix <at> ietf.org> 
> Date :        01/06/2012 07:20 
> Objet :        Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 
> 
> 
> 
> denis.pinkas <at> bull.net writes:
> 
> > I skimmed through the document and read the following two sentences:
> 
> >    The public key in the request is sent in the clear, and without any
> >    guarantees that the requestor actually possesses the corresponding
> >    private key.
> 
> >    [RFC4211], Appendix C contains a more detailed discussion of why 
> >    proof-of-possession is important.
> 
> > I have concerns with both sentences.
> 
> > [RFC4211] is incorrect and this has security implications on the
> > proposed protocol.
> 
> Hi Denis,
> 
> As Henry has mentioned, we have the limitation with this particular
> document that we're attempting to document an existing, deployed protocol
> sufficiently that interoperable implementations can be created.  This
> protocol is deficient in multiple ways, and designing a better protocol is
> expected follow-on work.  Changing something fundamental, such as
> requiring confidentiality in this protocol exchange, would defeat the
> point of the current work.
> 
> Therefore, I think that any remedy here should be limited to clearly
> documenting the issue in the Security Considerations section rather than
> changing the protocol.
> 
> If I'm understanding your message properly, you're saying that there is a
> partial defense against the lack of proof-of-possession by adding
> confidentiality protection to the exchange.  I'm not sure in this context
> whether this really changes the security analysis of this protocol, given
> that no confidentiality is used.  But if I'm missing something, could you
> suggest something that we could add to Security Considerations?
> 
> -- 
> Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
> 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 0 comments |
headers
Erik Andersen | 1 Jun 2012 10:55
Picon

Re: Integrated OCSP Responders / Key Usage bits

I am not arguing for a OCSPsign bit. However, if it is seen useful, the time is now if we want it to be in the next edition of X.509, which is almost finalised. Otherwise, it would be delayed probably another four years.

 

Implementers will have to judge whether introducing such a bit at this late state will cause interworking problems.

 

Erik

 

Fra: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] På vegne af denis.pinkas <at> bull.net
Sendt: 1. juni 2012 09:49
Til: Rob Stradling
Cc: pkix <at> ietf.org
Emne: Re: [pkix] Integrated OCSP Responders / Key Usage bits

 

Rob,

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 perfect solution,
but it is the most acceptable.

Denis




De :        Rob Stradling <rob.stradling <at> comodo.com>
A :        mrex <at> sap.com
Cc :        "pkix <at> ietf.org" <pkix <at> ietf.org>
Date :        31/05/2012 23:39
Objet :        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 the
>> "crlSign" bit to authorize the CA certificate as an Integrated Responder?
>
> 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 authors
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 behaviour
> 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!!

> -Martin
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  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 the
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.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 1 comment |
headers
Martin Rex | 1 Jun 2012 11:50
Picon
Favicon

Re: Integrated OCSP Responders / Key Usage bits

Rob Stradling wrote:
> 
> 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)."

Hmmmm.  I think you have a point here.  This definition still applies
to rfc3280 and rfc5280, actually:

http://tools.ietf.org/html/rfc3280#page-29

      The cRLSign bit is asserted when the subject public key is used
      for verifying a signature on certificate revocation list (e.g., a
      CRL, delta CRL, or an ARL).  This bit MUST be asserted in
      certificates that are used to verify signatures on CRLs.

http://tools.ietf.org/html/rfc5280#page-31

      The cRLSign bit is asserted when the subject public key is used
      for verifying signatures on certificate revocation lists (e.g.,
      CRLs, delta CRLs, or ARLs).

Although 2459/3280/5280 are "profiles of X.509", it seems sensible
to have it apply to technologies that were born/defined in the IETF
and not part of X.509 itself.

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

I'm sorry, I misexplained myself.  In order to make something enforcable
on the RP, it first of all will have to be enforced on the component
that creates that structure/element (=applies the signature).

Our OEM PKI software originally refused to sign a PKCS#10 request
(request for renewal) when the current certificate was already expired,
and I had to employ a special API feature (do not check Validity when
signing) in order to obtain the signature.

When writing PKI software, it would not be sensible to add a check to
the RP part of the software prior to ensuring that the signature
creation part enforced that feature to be correct.

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

This is actually something that I consider a defect in rfc5280.

Support of OCSP is purely optional (even less that MAY), so support of
CRLs being optional would imply that support of revocation is optional
-- which might be the reason why nobody hard-fails...

http://tools.ietf.org/html/rfc3280#page-49   Last paragraph of Section 5.0

   Conforming CAs are not required to issue CRLs if other revocation or
   certificate status mechanisms are provided. 

                                         Conforming applications are NOT
   REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
   with a scope other than all certificates issued by one CA.

-Martin
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 11 comments |
headers
Rob Stradling | 1 Jun 2012 13:21
Favicon

Re: Integrated OCSP Responders / Key Usage bits

On 01/06/12 08:48, denis.pinkas <at> bull.net wrote:
> Rob,
>
> 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.

2459 section 3.3 describes CRLs as just "one method of certificate 
revocation" and then says "Message formats and protocols supporting 
on-line revocation notification may be defined in other PKIX 
specifications."

So I think it's pretty clear that the authors of 2459 anticipated that 
new certificate revocation methods to be invented.

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

At the time 2560 was issued, 2459 was in force.  And 2459 says:
"The cRLSign bit is asserted when the subject public key is used for 
verifying a signature on revocation information (e.g., a CRL)."

OCSP Responses are "revocation information".  "e.g., a CRL" doesn't mean 
"MUST be a CRL".

So presumably the authors of 2560 believed "cRLSign" to be the 
applicable Key Usage bit for Integrated Responder OCSP, but didn't feel 
the need to express this in 2560 because 2459 already expressed it clearly.

> Nobody raised the point at the proper time.

It seems to me that there was no point to raise back then.  2459 was 
clear that "cRLSign" was the appropriate bit to set.

Then 3280 came along and (it seems) changed the rules without clearly 
expressing (IMHO) what the new rules were.

> It seems too late now. So asserting instead the DS bit is not the
 > perfect solution, but it is the most acceptable.
>
> Denis
>
>
>
>
> De : Rob Stradling <rob.stradling <at> comodo.com>
> A : mrex <at> sap.com
> Cc : "pkix <at> ietf.org" <pkix <at> ietf.org>
> Date : 31/05/2012 23:39
> Objet : 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 the
>  >> "crlSign" bit to authorize the CA certificate as an Integrated
> Responder?
>  >
>  > 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 authors
> 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 behaviour
>  > 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!!
>
>  > -Martin
>  >
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> COMODO CA Limited, Registered in England No. 04058690
> Registered Office:
> 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 the
> 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.org
> https://www.ietf.org/mailman/listinfo/pkix
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   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 the 
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.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 1 comment |

Gmane