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.