Russ:
Optional is sufficient. It should NOT be mandatory to have separate signing keys for certificates and CRLs.
Thanks. I think we agree.
-----Original Message-----
From: David Cross [mailto:dcross@xxxxxxxxxxxxx]
Sent: Tuesday, April 24, 2001 9:21 PM
To: Housley, Russ; Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
Subject: RE: Dedicated CRL signing keys
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.