Subject: Dedicated CRL signing keys

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 18 Apr 2001 13:32:39 -0700

There has been some discussion regarding the proposal to have CRLs
signed with CA keys which do not also sign certificates. Since this will
not be a mandatory to implement feature, I am concerned about the impact
on pkix compliant clients who encounter CRL signed in this way, and how
we expect them to behave. What seem unacceptable with the current
proposal is that the signage check on the CRL will fail, and the client
will have little clue as to why and if this failure is expected. The
information in the chain, while present, is in the CAs certificate, is
difficult to find and subtle so would be easily missed by someone
debugging this problem. I would like to see some clearer indication in a
critical extension in the CRL itself that would indicate what was going
on. In expressing these semantics in a critical extension, we maintain
the principal that if you don't understand the extension, the client
knows to fail due to its own inadequacies and that failure is by design,
therefore allowing the client's to return an error unsupported option
rather than invalid signature.
Trevor

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 18 Apr 2001 16:40:20 -0700

Hi Russ,
That addresses my concerns. A pkix compliant client can now be
reasonability expected to fail with a more informative error, and the
problem should be in people's faces since the CRL contains a critical
extension.
Trevor

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2001 2:08 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: Dedicated CRL signing keys

Trevor:

I propose the following solution that builds on the Indirect CRL 
capabilities that are already available.  When a CA wants to employ 
separate private keys to sign certificates and CRLs, then that CA MUST 
delegate CRL signing to a separate authority.  That separate authority
MUST 
have a different Distinguished Name that the CA, but it could be
operated 
by the same organization.  In this way, the IDP CRL extension would flag

the "unusual" circumstances.  Clients that do not support Indirect CRLs
can 
fail gracefully (unsupported optional feature), and clients that support

Indirect CRLs can happily handle the certificates and CRLs.

Thoughts?

Russ

---

From: Bengt Ohlsson <[email-masked]>
Date: Thu, 19 Apr 2001 17:10:25 +0200

Trevor and Russ,

I don't see why the clients should fail to verify the signature
on the CRL. Assume a CA uses separate keys, same DN,
for certificate signing and CRL signing and sets the
AuthorityKeyIdentifier extension in both the certificates
and the CRLs. Then PKIX compliant clients should be able
to build the correct certificate chains for verifying both the
certificates and the CRLs.

The legislation may require the CA keys to be stored in
hardware without any copies. If you lose a key due to HW
failure you will probaly want to continue to issue the CRLs
with a new key and the same DN.

This requires the clients to handle the AKI extension to be
able to verify the signature on the new CRLs. This is a
small requirement compared to handle indirect CRLs if
you must change the DN.

Bengt

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: den 19 april 2001 01:40
To: Russ Housley
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Hi Russ,

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2001 2:08 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: Dedicated CRL signing keys

Trevor:

Thoughts?

Russ

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 19 Apr 2001 09:29:49 -0700

Bengt,
Theorizing what could be possible, do not change that support for these
semantics is not mandatory under this profile, which means we are trying
to establish how that client fails gracefully with some kind of
meaningful error
Trevor
-----Original Message-----
From: Bengt Ohlsson [mailto:[email-masked]] 
Sent: Thursday, April 19, 2001 8:10 AM
To: Trevor Freeman; Russ Housley
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Trevor and Russ,

Bengt

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: den 19 april 2001 01:40
To: Russ Housley
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Hi Russ,

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2001 2:08 PM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: Dedicated CRL signing keys

Trevor:

Thoughts?

Russ

---

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Fri, 20 Apr 2001 14:12:59 +0200

Would it not be easier to mandate the support for Authority and Subject key 
identifiers, than to require the CA to use different DNs when different 
keys are used for issuing certificates and CRLs. As Tim noted, this problem 
may occur even for regular CAs (which use the same key for issuing 
certificates and CRLs) after a key pair rollover.

>to establish how that client fails gracefully with some kind of

I agree with Bengt that key identifier extensions provide enough 
information for the client to go looking for the right cert path to perform 
the verification of the signature on the CRL. If the client is not able to 
locate the proper path it can fail with a meaningful error.

Nada

---

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 20 Apr 2001 09:47:29 -0700

Mandating SKI and AKI changes nothing as these are just hints as to
which key signed. The client are already failing since they cannot find
the right public key that signed the CRL. As you not, it is possible to
have CA with multiple keys, so having a different AKI in the CRL may
simply indicate a problem with distribution.

-----Original Message-----
From: Nada Kapidzic Cicovic [mailto:[email-masked]] 
Sent: Friday, April 20, 2001 5:13 AM
To: Trevor Freeman; Bengt Ohlsson; Russ Housley
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Would it not be easier to mandate the support for Authority and Subject
key 
identifiers, than to require the CA to use different DNs when different 
keys are used for issuing certificates and CRLs. As Tim noted, this
problem 
may occur even for regular CAs (which use the same key for issuing 
certificates and CRLs) after a key pair rollover.

I agree with Bengt that key identifier extensions provide enough 
information for the client to go looking for the right cert path to
perform 
the verification of the signature on the CRL. If the client is not able
to 
locate the proper path it can fail with a meaningful error.

Nada

> >debugging this problem. I would like to see some clearer indication
in
>a

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 Apr 2001 13:31:04 -0400

Folks:

Over the last few days, I have suppressed the urge to respond to this
thread, largely because while I have a great deal of respect for the
individuals debating this and know them personally, there either seems to be
a general misunderstanding of the concepts, or their positions seems to be
misstated, or they seem to have simply not explained themselves well enough.

Also, this chain seems to imply that several issues are getting mixed.

So, here is my take on it all.

First, I think that the restriction that a CA who desires to issue Indirect
CRL needs to set itself up as a separate name is unduly restrictive.  There
is no need for a CA to do that.  A CA can issue a full CRL as well as an
Indirect CRL and populate these in the same or different entries (i.e., CRL
DP) in the directory.  Please review Annex B of X.509 for how to process
CRL.  So, may be Russ can explain why this requirement comes about.

Second, when we say that a CA may not use different keys for signing
certificates and CRLs, we are again not thinking of operations.
Operationally, a CA is going to rekey.  When it does, it will have issued
the certificates using the old key and will sign CRL with new key.  There
are your different keys.

Also, I think a standard should be flexible and promote security.  From
operational security viewpoint, a CA may not want to keep the certificate
signing key active all the time, but may need to keep the CRL signing key
active to help meet CRL issuance obligations.  This will mean a separate CRL
signing key since compromise of that key still does not compromise anything.
The attacker needs to compromise some subscriber keys to create a true
compromise, denial-of-service notwithstanding.  Thus, we should accommodate
separate keys for certificates and CRLs.

In short, requiring the CA to use a different name to issue indirect CRL is
not well-grounded and should be deleted.  Requiring a CA to use different
key for indirect CRL is not well-grounded and should be deleted.  Requiring
the same key for certificate and CRL signing may not be possible due to
rekey or operational security requirements and should be deleted.

Finally, as to Steve Farrell's question regarding client simplicity, I wish
I could answer that.  The client will need intelligence to handle rekey and
secure CA who use different keys for certificate and CRL signing.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Saturday, April 21, 2001 4:08 PM
To: Trevor Freeman
Cc: Russ Housley; [email-masked]
Subject: Re: Dedicated CRL signing keys

Hi Trevor,

I'm sympathetic and would also like to see a nice solution that'd 
ease graceful failure for clients. However, if the proposal breaks
existing CAs then its not a solution (as Tim pointed out for a
different reason).

Stephen.

Trevor Freeman wrote:
> 
> Stephen,
> The route problem is that this is an optional feature, and the net
> result with the current proposal of profile compliant clients who
> encounter a CA operating with this option will simply be a signature
> failure. This presents a fairly high bar to anyone trying to establish
> why the revocation check is failing. The rational behind using a
> critical extension in the CRL is that now the conformant client knows
> that failure is by design without understanding what the problem is
> since it does not understand the extension and can return a more
> informative error like option not supported.
> Trevor
> 
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, April 19, 2001 7:07 AM
> To: Russ Housley
> Cc: Trevor Freeman; [email-masked]
> Russ,
> That'd be a bad resolution since it would break deployed CAs who
> use the same name and different cert and CRL signing keys (and
> those do exist and are operating).
> 
> Any other ideas or should we just require clients to understand
> what's going on based on key usage?
> 
> Stephen.
> 
> Russ Housley wrote:
> >
> > Trevor:
> >
> > the "unusual" circumstances.  Clients that do not support Indirect
> CRLs can
> in a
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 23 Apr 2001 16:21:19 -0400

Santosh:

Thanks for posting your summary of the thread.  I hope it will allow us to 
focus on the issues, and reach consensus quickly.

>First, I think that the restriction that a CA who desires to issue 
>Indirect CRL needs to set itself up as a separate name is unduly 
>restrictive.  There is no need for a CA to do that.  A CA can issue a full 
>CRL as well as an Indirect CRL and populate these in the same or different 
>entries (i.e., CRL DP) in the directory.  Please review Annex B of X.509 
>for how to process CRL.  So, may be Russ can explain why this requirement 
>comes about.

I agree that the use of a separate name is overly restrictive.  That 
portion of my suggestion was, in hind sight, a bad idea.  As Tim Polk 
pointed out, CAs cannot change their names when they rekey.

I think that everyone agrees that a CA makes a commitment to provide some 
form of revocation information for the duration of the certificate 
life.  When CRLs are employed, does the CA use the same key to sign the CRL 
as was used to sign the certificate?  Clearly, the CA is permitted to use 
different keys -- the key usage bits are there to allow this 
separation.  However, several clients cannot handle this situation, and 
they would like to see an error message that says "unsupported feature" 
instead of "signature invalid."

Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are 
subsequent CRLs signed with the new key or the old one?  A CA could 
generate one CRL with each key.  They two CRLs could even be distributed by 
different distribution point to avoid the download of CRLs that cannot be 
employed.  Alternatively, the CA could publish one CRL signed with the new 
key.  This leads to the scenario where cert path construction must be 
evoked to generate validate the CRL when trying to validate a certificate 
signed by the old key.  This is the behavior that we are trying to make SHOULD.

Therefore, the CA MUST generate the CRL using the same key as was used to 
sign the certificate, or it MUST include an extension in the CRL to 
indicate that cert path construction might be needed to validate the CRL 
signature.  I proposed that an Issuing Distribution Point (IDP) CRL 
extension might be the correct approach.  The IDP extension will not be 
supported by the simple clients, so they can generate the "unsupported 
feature" error, and the more complex clients can use the information in the 
IDP to support path construction.  They will of course, also use Authority 
Key Identifier extension.

>certificates and CRLs, we are again not thinking of 
>operations.  Operationally, a CA is going to rekey.  When it does, it will 
>have issued the certificates using the old key and will sign CRL with new 
>key.  There are your different keys.

The simple CA could reasonably expect the CA to generate CRLs using the 
same key that was used to sign certificates until all of the certificates 
signed with that key have expired.

>active to help meet CRL issuance obligations.  This will mean a separate 
>CRL signing key since compromise of that key still does not compromise 
>anything.  The attacker needs to compromise some subscriber keys to create 
>a true compromise, denial-of-service notwithstanding.  Thus, we should 
>accommodate separate keys for certificates and CRLs.

We need to balance the complexity of the software that we expect the 
clients to handle and CA operational security.  Errors in either place will 
lead to vulnerabilities.

>In short, requiring the CA to use a different name to issue indirect CRL 
>is not well-grounded and should be deleted.

Agree.

>Requiring a CA to use different key for indirect CRL is not well-grounded 
>and should be deleted.

I do not recall a discussion on this point.  Usually, Indirect CRLs are 
employed to delegate CRL generation responsibility.  I would expect the two 
authorities to have different keys.

>Requiring the same key for certificate and CRL signing may not be possible 
>due to rekey or operational security requirements and should be deleted.

We need to be pragmatic with respect to simple clients.  I hope that I made 
my thoughts clear above.

>Finally, as to Steve Farrell's question regarding client simplicity, I 
>wish I could answer that.  The client will need intelligence to handle 
>rekey and secure CA who use different keys for certificate and CRL signing.

Again, I hope that I made my thoughts clear above.

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 Apr 2001 17:25:01 -0400

Russ:

See comments in line

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Monday, April 23, 2001 4:21 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Santosh:

signed by the old key.  This is the behavior that we are trying to make
SHOULD.

{Santosh Says: Item 1 will require a change to the IDP extension syntax.
Would n't that make PKIX non-compliant with X.509?)

(Santosh Says: That is what I have been advocating.  But, mandating that a
CA retain old private keys and issue multiple CRLs may be excessive.)

Agree.

(Santosh Says: But there is nothing in X.509 that a designated CA can not
issue its own regular CRL and issue an indirect CRL for its peers.  The
designated CA may use the same key.  The requirement you are levying has
marginal benefit for the directories and clients who do not do multi-valued
attributes and that only if the CA does NOT use a CRL DP for the indirect
CRL.  There is no particular need or requirement for having a separate name
or a separate key)

(Santosh Says: I think the best engineering solution is for the CA to keep
the old keys and sign multiple CRLs.  That said, I do not want to mandate it
and I  for sure want the PKIX community to approve the RFC knowing this
implication.)

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 Apr 2001 17:40:41 -0400

I think we should not try to fix the problem of rekey by further
complicating the CRL.

We should either let the CA issue multiple CRLs (no need for IDP) or let the
clients develop two paths: one for the certificate and one for the CRL.

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Monday, April 23, 2001 5:45 PM
To: [email-masked]
Subject: RE: Dedicated CRL signing keys

Russ,

I have a problem with the idea that we need to include a critical extension
in any CRL where some of the certificates covered by that CRL were signed
using a different key than the one used to sign the CRL.

The main problem that I see is the CA rekey issue. Suppose that a CA rekeys
and then issues a single CRL, signed with its new private key, that covers
all of its unexpired certificates. The older certificates issued by this CA
will have been signed with the old key, but the newer certificates will have
been signed with the same (new) key as the CRL. As things stand at the
moment, simple clients will be able to use the CRL when validating the "new"
certificates and will fail when using the CRL to validate "old"
certificates. If we place a critical extension in the CRL that the simple
clients can not process, then they won't be able to use the CRL to validate
any certificates. So, adding a critical extension would actually reduce the
functionality of simple clients.

I also believe that there is already sufficient information available in the
CRLs. A client can simply compare the authority key identifier in the
certificate and the corresponding CRL. If they differ, the client will know
that the certificate and CRL were signed using different keys and can return
an "unsupported feature" error just as if the CRL contained an unrecognized
critical extension.

Right now, simple clients will return an error if a certificate and its
corresponding CRL were signed using different keys. Simple clients that want
to provide an "unsupported feature" error message instead of "signature
invalid" can compare authority key identifiers in order to determine which
error message to return. If we force the CRLs to include critical
extensions, we will be unnecessarily increasing the number of cases in which
simple clients are unable to validate CRLs. So, I think we should leave
things as they are.

Dave 

>I think that everyone agrees that a CA makes a commitment to provide some
form of revocation information for the duration of the certificate life.
When CRLs are employed, does the CA use the same key to sign the CRL as was
used to sign the certificate?  Clearly, the CA is permitted to use different
keys -- the key usage bits are there to allow this separation.  However,
several clients cannot handle this situation, and they would like to see an
error message that says "unsupported feature" instead of "signature
invalid."
>Perhaps CA rekey will lead us to an answer.  When a CA rekeys, does it are
subsequent CRLs signed with the new key or the old one?  A CA could generate
one CRL with each key.  They two CRLs could even be distributed by different
distribution point to avoid the download of CRLs that cannot be employed.
Alternatively, the CA could publish one CRL signed with the new key.  This
leads to the scenario where cert path construction must be evoked to
generate validate the CRL when trying to validate a certificate signed by
the old key.  This is the behavior that we are trying to make SHOULD.
>Therefore, the CA MUST generate the CRL using the same key as was used to
sign the certificate, or it MUST include an extension in the CRL to indicate
that cert path construction might be needed to validate the CRL signature.
I proposed that an Issuing Distribution Point (IDP) CRL extension might be
the correct approach.  The IDP extension will not be supported by the simple
clients, so they can generate the "unsupported feature" error, and the more
complex clients can use the information in the IDP to support path
construction.  They will of course, also use Authority Key Identifier
extension.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Apr 2001 08:54:47 -0400

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.

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 24 Apr 2001 13:01:53 -0400

On a related point, is it agreed by all that directory publication of
CRL signing certificates with the same DN as the CA signing certificate
should occur in the caCertificate attribute, and thus a directory-enabled
client may find CRL signing certificates by scanning that attribute for
certificates which either contain the CRLSign bit within the KeyUsage
extension or don't contain the KeyUsage extension at all?  RFC 2587 doesn't
say anything about this as far as I can tell.

          Tom Gindin

Santosh Chokhani <[email-masked]> on 04/24/2001 08:54:47 AM

To:   [email-masked], "Russell Housley (E-mail)"
      <[email-masked]>
cc:
Subject:  RE: Dedicated CRL signing keys

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.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Apr 2001 12:58:57 -0400

Tom:

I agree with most of what you said.  If the CRL signing certificate is
self-issued, then it should appear in caCertificate attribute.

But, if it is issued by another authority, then it must appear in the
crossCertificatePair attribute.  In addition, if the issuing authority is in
the domain of the subject CA, it must also appear in the caCertificate
attribute.

The above is based on my understanding on LDAP schema language we agreed to
back in 1998 or 1999 after much debate. 

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 1:02 PM
To: Santosh Chokhani
Cc: [email-masked]; Russell Housley (E-mail)
Subject: RE: Dedicated CRL signing keys

          Tom Gindin

Russ:

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Apr 2001 14:26:38 -0400

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

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Apr 2001 15:10:42 -0400

At 05:25 PM 4/23/2001 -0400, Santosh Chokhani wrote:
>{Santosh Says: Item 1 will require a change to the IDP extension 
>syntax.  Would n't that make PKIX non-compliant with X.509?)

The IDP syntax is:

    issuingDistributionPoint ::= SEQUENCE {
         distributionPoint       [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons         [3] ReasonFlags OPTIONAL,
         indirectCRL             [4] BOOLEAN DEFAULT FALSE }

I was simply suggesting that this extension be present if the CRL is signed 
with a key other than the one used to sign the certificate.  I would expect 
the distributionPoint field to be present (probably with a URL 
(ldap://...)).  The boolean flags would be set based on the contents of the 
CRL (probably all FALSE).  The reason codes would also be set based on the 
contents of the CRL (probably absent).

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Apr 2001 15:21:07 -0400

Russ:

But the semantics of that extension does NOT mean that the CRL is signed by
a different key.

Actually, a CA typically uses this extension, chops up the CRL and signs
them all using the SAME key.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 3:11 PM
To: Santosh Chokhani
Cc: Santosh Chokhani; [email-masked]
Subject: RE: Dedicated CRL signing keys

The IDP syntax is:

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Apr 2001 15:41:04 -0400

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:[email-masked]]
Sent: Tuesday, April 24, 2001 2:27 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Santosh:

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Apr 2001 17:23:54 -0400

Santosh:

I know.  The point is that a simple client will encounter an unsupported 
extension.

David Cooper has pointed out that this has the effect that clients that 
might otherwise be able to use the CRL will not be able to use it.  I am no 
longer advocating this approach.

Russ

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

>Russ:
>
>But the semantics of that extension does NOT mean that the CRL is signed 
>by a different key.
>
>From: Housley, Russ 
>[<mailto:[email-masked]>mailto:[email-masked]]

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Apr 2001 20:54:57 -0400

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:

>process the chains, but also not declaring PKI that have CA and clients 
>that conform to this.
>

---

From: "David Cross" <[email-masked]>
Date: Tue, 24 Apr 2001 18:20:38 -0700

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:[email-masked]] 
Sent: Tuesday, April 24, 2001 5:55 PM
To: Santosh Chokhani
Cc: [email-masked]
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

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

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 25 Apr 2001 06:25:45 -0400

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:[email-masked]]
Sent: Tuesday, April 24, 2001 9:21 PM
To: Housley, Russ; Santosh Chokhani
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

David B. Cross

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]] 
Sent: Tuesday, April 24, 2001 5:55 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Santosh:

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 26 Apr 2001 16:47:44 -0400

Russ: Will a CA that signs the certificates and CRLs using different keys,
but same Issuer DN be considered compliant?  If yes, then we agree.
 
-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 4:36 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Dedicated CRL signing keys

Santosh:

If CAs issue CRLs, then the CA can sign certificates and CRLs with the same
key, or the CA can use separate keys.

Certificate-using applications must be able to handle certificates and CRLs
signed by the same key.  Certificate-using applications may handle CRLs
signed by a different key than the certificates.

If you agree with this position, then we agree.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 26 Apr 2001 16:35:49 -0400

Santosh:

Optional is
sufficient.  It should NOT be mandatory to have separate signing
keys for certificates and CRLs.

If CAs issue CRLs, then the CA can sign certificates and CRLs with the
same key, or the CA can use separate keys.

Certificate-using applications must be able to handle certificates and
CRLs signed by the same key.  Certificate-using applications may
handle CRLs signed by a different key than the certificates.

Russ

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 30 Apr 2001 10:45:22 -0700

I prefer the statement as is. Changing the may to a should does not get
the CAs off the hook. A CA has to make a decision as to what
expectations it has for the certificate consuming population of clients
it suports. A should is not a must, so this means that conformant
clients are not mandated to support CRLs signed with different keys.
Vendors thinking of implementing X.509 technology in constrained devices
will start looking at alternatives if the bar is set to high for
conformant client.

Trevor
-----Original Message-----
From: David P. Kemp [mailto:[email-masked]] 
Sent: Monday, April 30, 2001 8:53 AM
To: [email-masked]
Subject: Re: Dedicated CRL signing keys

If certificate-using applications MAY handle CRLs signed by a different
key
than the certificates, then CAs have no real ability to exercise that
option.

I believe:

Certificate-using applications SHOULD handle CRLs signed by a different
key
than the certificates.

Dave

"Housley, Russ" wrote:
> Yes.  So, I guess we agree.
> 
> At 04:47 PM 4/26/2001 -0400, Santosh Chokhani wrote: