[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Here is a quote from RFC 3280. To me, it is clear that a CRL issuer has a certificate. Obviously, all certificates need to be validated, which includes certification path construction and certification path validation. 

5.1.1.3  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
   is used as the input to the signature function.  This signature value
   is encoded as a BIT STRING and included in the CRL signatureValue
   field.  The details of this process are specified for each of the
   supported algorithms in [PKIXALGS].

   CAs that are also CRL issuers MAY use one private key to digitally
   sign certificates and CRLs, or MAY use separate private keys to
   digitally sign certificates and CRLs.  When separate private keys are
   employed, each of the public keys associated with these private keys
   is placed in a separate certificate, one with the keyCertSign bit set
   in the key usage extension, and one with the cRLSign bit set in the
   key usage extension (section 4.2.1.3).  When separate private keys
   are employed, certificates issued by the CA contain one authority key
   identifier, and the corresponding CRLs contain a different authority
   key identifier.  The use of separate CA certificates for validation
   of certificate signatures and CRL signatures can offer improved
   security characteristics; however, it imposes a burden on
   applications, and it might limit interoperability.  Many applications
   construct a certification path, and then validate the certification
   path (section 6).  CRL checking in turn requires a separate
   certification path to be constructed and validated for the CA's CRL
   signature validation certificate.  Applications that perform CRL
   checking MUST support certification path validation when certificates
   and CRLs are digitally signed with the same CA private key.  These
   applications SHOULD support certification path validation when
   certificates and CRLs are digitally signed with different CA private
   keys.

Russ

At 01:12 PM 4/28/2005, Denis Pinkas wrote:

Stefan and Russ,


Denis,



Russ and I have taken a thorough look at your text proposal and we have
edited a counter proposal where we try to meet your needs as much as
possible without compromising what we think is the core purpose of the
draft (to enable certificate discovery bottom-up).



The conclusion is that we suggest changes to the introduction section
but we keep the old security considerations intact.
I would suggest that a merge would need to be done between the "old" security considerations section and the "new" one.
The "old" security considerations section is mentionning a solution which does NOT suppress the problem, but minimize the risk only in case the CAs are really "honest".
The old" security considerations section does not provide a solution in case the name collsion between two CRL issuer name is deliberate, whereas the "new" security considerations section provides a secure solution in one case and clearly mentions that all other cases are dependant about "zillions" of *local* trust conditions which cannot all be standardized.
The main purpose of a security considerations section is to provide the adequate warnings and solutions when they exist and not to hide the problems. 


That is not because
we necessarily disagree with all of the statements in your proposal, but
in the cases we don't, we still think it is out of scope for this work.


This is clearly within the scope of a security considerations section.


The new introduction proposal based on your input is:
--------------------------------------------------------------
RFC 3280 [PKIX1] specifies the validation of certification paths.  One
aspect involves the determination that a certificate has not been
revoked, and one revocation checking mechanism is the Certificate
Revocation List (CRL).  CRL validation is also specified in RFC 3280,


I would love this last sentence to be true but the reality is that:
"CRL validation is NOT specified in RFC 3280". :-(


which involves the constructions of a valid certification path for the
CRL issuer.


There is no such a statement in RFC 3280.


Building a CRL issuer certification path from the signer of


There is no notion of "CRL issuer certification path" in RFC 3280.
The primary requirement is to make sure that the CRL issuer designated by the CA is indeed the right one. In some (but not all) cases, I mean among the zillion of cases, there MAY be a need to construct a CRL issuer certification path. 


the CRL to a trust anchor is straightforward when the certificate of the
CRL issuer is present in the certification path associated with the
target certificate, but it can be complex in other situations.
From the comments above, you can see that I cannot agree with the above revised text. The remaining of the text is acceptable in general, but could possibly be slightly revised to be more in continuation with the changes there are needed above (i.e. it is not cast in concrete). 

Denis


There are several legitimate scenarios where the certificate of the CRL
issuer is not present, or easily discovered, from the target
certification path.  This can be the case when indirect CRLs are used,
when the certification Authority (CA) that issued the target certificate
changes its certificate signing key, or when the CA employs separate
keys for certificate signing and CRL signing.
Methods of finding the certificate of the CRL issuer are currently
available, such as though an accessible directory location or through
use of the Subject Information Access extension in intermediary CA
certificates.
Directory lookup requires existence and access to a directory that has
been populated with all of the necessary certificates.  The Subject
Information Access extension, which supports building the CRL issuer
certification path top-down (in the direction from the trust anchor to
the CRL issuer), requires that some certificates in the CRL issuer
certification path includes an appropriate Subject Information Access
extension.
RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths
through the Authority Information Access extension, where the
id-ad-caIssuers access method may specify one or more accessLocation
fields that reference CA certificates associated with the certificate
containing this extension.
This document enables the use of the Authority Information Access
extension in CRLs, enabling a CRL checking application to use the access
method (id-ad-caIssuers) to locate certificates that may be useful in
the construction of a valid CRL issuer certification path to an
appropriate trust anchor.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security



-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
Sent: den 18 april 2005 13:41
To: Stefan Santesson
Cc: Russ Housley; pkix
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>

Stefan,



Denis,



I will come back and comment on your text proposals, but before

that,


> a few questions/comments:



<snip>



You point out some well known issues related to the lack of

absolute


cryptographic binding between CRL and certificates where the
certificate and CRL is not signed by the same key.


Not really. It is indeed possible to have an absolute cryptographic
binding between CRL and certificates where the certificate and CRL

is


not


signed by the same key, but the key point is that proposed

extension


>> is *not* the means to provide such a binding (and you agree with

this


>> further down in this e-mail).



We agree that this extension does not add to the concept of
cryptographic binding. But how do you mean it can be done?


Would this mean that you believed this could not be done ? :-)

I already provided the information, but since at that time you were
focussing on another issue, you probably missed the point.

I would encourage you to read again that thread, but I will provide a
short
reply here to your question.

This can be done using cRLIssuer from the CRL DP. cRLIssuer contains

the


DN
of the CRL Issuer and we all know that CAs are free to assign the DNs

they


wish. The next point is for a verifier to make sure that the DN which
identifies the CRL Issuer (in the CRL DP) is indeed the one that was

meant


by the CA. The CRL must be issued by a CRL Issuer that has the same

DN.


The
CRL Issuer will have a certificate issued by a CA.

Case a): the CA that has issued that certificate is the same as the CA
that
has issued the target certificate (which contains the hereabove

mentionned


CRL DP). This is easy to check for a verifier since the verifier must
first
build the certification path and then test the revocation status of

every


element of the path. So the verifier knows the validated sequence of

DNs


starting from a self-signed certificate. It must then use the same
sequence
of DNs to validate the CRL Issuer certificate.

This is a general rule which does not require any extra local trust
information.

Case b) : the CA that has issued that certificate is NOT the same as

the


CA
that has issued the target certificate. This case requires extra

*0local*


trust information. There are many such trust conditions possible and

thus


this cannot be defined in general. Cases a) and b) are thus not

equivalent


and have to be distinguished.



<snip>



This draft only introduces a new way to locate certificates
that can be helpful in building this path.


At least one sentence of which we both agree !
It should be copied and pasted in the abstract.


Good, then I suggest that we leave unrelated topics out of this

draft


and focus on the issues that are related to this limited scope.


This is what I did in my proposal, except that we need to have a

security


considerations section and the goal of that section is not to hide
problems
but to correctly warn users. Thus why an informatiove annex on the

topics


mentionned in the security considerations section would be quite

useful.


In fact, its content would be along the lines of the explanations

which


are
just above.

I hope this e-mail will help us to progress.

Denis



Stefan Santesson
Program Manager - Standards Liaison
Windows Security