RE: Dedicated CRL signing keys

["David Cross" <dcross@xxxxxxxxxxxxx>]

Optional please - it will take time to build up a large support base for
this on the client side.

David B. Cross
 

 



-----Original Message-----
From: Housley, Russ [mailto:rhousley@xxxxxxxxxxxxxxx] 
Sent: Tuesday, April 24, 2001 5:55 PM
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
Subject: RE: Dedicated CRL signing keys


Santosh:

The profile already allows CAs and clients to include the features your
are 
advocating.  We are debating which are mandatory to implement vs.
optional.

Russ


At 03:41 PM 4/24/2001 -0400, Santosh Chokhani wrote:

>Russ:
>
>May be there is a middle ground in terms not requiring the clients to
>process the chains, but also not declaring PKI that have CA and clients

>that conform to this.
>
>I would like us to accommodate both without requiring ALL clients to 
>have
>the capability.
>
>For example, we can say that the client need not process these types of
>trust paths, but CA who use separate keys and clients who can build and

>process these chains are also compliant.
>
>-----Original Message-----
>From: Housley, Russ
>[<mailto:rhousley@xxxxxxxxxxxxxxx>mailto:rhousley@xxxxxxxxxxxxxxx]
>Sent: Tuesday, April 24, 2001 2:27 PM
>To: Santosh Chokhani
>Cc: ietf-pkix@xxxxxxx
>Subject: RE: Dedicated CRL signing keys
>
>Santosh:
>
>Interoperability is just as important as security.  Further, complexity

>leads to implementation flaws which reduces security.  In several 
>places, the working group has decided that interoperability is more 
>important than security.  In fact, the PKIX profile does not require 
>that a CA issue CRLs (see section 3.3, last paragraph).
>
>The PKIX profile places requirements on CAs and clients.  How can we 
>say that clients MUST be able to handle certs and CRLs signed with 
>different keys when we do not require CAs to issue them at all?  
>Further, placing such a requirement on clients forces them to be able 
>to build certification paths during CRL checking.  We already know that

>some clients cannot do this (an interoperability issue).  And, asking 
>them to do so will add complexity (a security assurance issue).
>
>Russ
>
>At 08:54 AM 4/24/2001 -0400, Santosh Chokhani wrote:
>
> >Russ:
> >
> >One of your comments yesterday was that we can make a choice between 
> >simpler client and operational security when I said that some 
> >implementations require separate CRL signing keys for operational 
> >security reasons.
> >
> >While I agree with you that this is a trade-off an enterprise needs 
> >to make.  But, I think the Internet RFC should not make such a 
> >choice.  I am saying that the RFC should permit both:  simple client 
> >(same key for certificate and CRL signing) as well as different keys 
> >for certificate and CRL signing.
> >
> >PKIX working group is after all, all about security.  We should not 
> >say that a secure implementation is not compliant with PKIX.