From: "Santosh Chokhani" <chokhani@orionsec.com>
To: <ietf-pkix@imc.org>
Subject: RE: Current status of CRL validation ?
Date: Wed, 7 Apr 2004 16:02:41 -0400
Message-ID: <018c01c41cdb$48899c10$9a00a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
In-Reply-To: <20040407163512.GA1250@cryptolog.com>
Importance: Normal
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Julien:

There is still poor terminology being used.  Neither multiple concurrent key
pairs nor rekey will lead to the same CA to have the same key. Actually, it
is the other way around.  The DN will be the same and the keys will be
different.

Nonetheless, I will try to deal with your example assuming that it is the
same CA.

First of all, if you can not find a CRL that does not mean you conclude the
certificate to be valid.

Second, if the certification path you have for the CRL does not match, you
do not give up, you try other paths.

One of the basic tricks is: try to verify the signature on the CRL using the
same CA public key as you used to verify the signature on the certificate
whose status you want to check.

If that does not succeed, you can create variation of that path one link at
a time to account for re-key.

Your example has errors and lack of specificity to answer the question.

The simply answer is that you do not need a separate path for CRL since PK4
is used to sign both the certificate and CRL.

It is also not clear what your thesis or agenda is.

May be you are still trying understand it.  If you are challenging the rules
we have proposed for CRL path, let me know.

May be you are saying that certificate issuing CA may not be the only
authoritative source for revocation information.  If that is the case, I
agree with you, but your example does not illustrate that.

 

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Julien Stern
Sent: Wednesday, April 07, 2004 12:35 PM
To: ietf-pkix@imc.org
Subject: Re: Current status of CRL validation ?



On Wed, Apr 07, 2004 at 12:07:34PM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> I am not sure that two distinct CAs with the same key (putting aside 
> the same DN) should be the basis for analysis.  That situation will 
> always lead to problems.  We are relying on randomness of large 
> numbers to help us that this will not happen.
> 
> Consider providing an example where different CAs do not have the same 
> key.

You should view my "two" CAs as the same CA with two different keys. I might
not have been totally clear about that, sorry. This can be "either due to
multiple concurrent key pairs or due to changeover" (to quote RFC3280 :)).

--
Julien

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern
> Sent: Wednesday, April 07, 2004 10:45 AM
> To: ietf-pkix@imc.org
> Subject: Re: Current status of CRL validation ?
> 
> 
> 
> On Tue, Mar 23, 2004 at 11:56:01AM -0500, Stephen Kent wrote:
> > 
> > Julien,
> > 
> > The confusion stems from somewhat sloppy use of terminology in these 
> > discussions.
> > 
> > Only the issuer of a cert can revoke it and in X.509 (unlike PGP) 
> > there is only one issuer for a given cert. So, the revocation 
> > question as you stated it was not well formed.
> 
> Stephen,
> 
> I do not believe that only the issuer of a cert can revoke it, notably 
> when indirect CRL are used.
> 
> > A cert is either revoked or not.
> 
> Well, I'm sincerely starting to believe this is not true :) and not 
> because of lack of available information. Please point me to the flaw 
> in the following setting:
> 
>        +-----+        +-----+    I have a certificate (Cert). Two
>        | CA1 |        |     |    Different CAs (CA4 and CA5) have
>        | DN1 |        | DN1 |    matching issuer DN and keys for it.
>        | PK1 |        |     |
>        +-----+        +-----+    These two CAs have two super CAs
>         /   \            |       signed by the same root.
>   +-----+   +-----+   +-----+
>   | CA2 |   | CA3 |   |     |    I also have a CRL which refers to
>   | DN2 |   | DN3 |   | DN3 |    the certificate but whose only
>   | PK2 |   | PK3 |   |     |    chain up to DN1 is going through
>   +-----+   +-----+   +-----+    DN4 and DN3 (but NOT DN2).
>      |         |         |
>   +-----+   +-----+   +-----+    Now assume that the left path
>   | CA4 |   | CA5 |   |     |    (CA1 -> CA2 -> CA4 -> Cert)
>   | DN4 |   | DN4 |   | DN4 |    is valid for SOME policies, and
>   | PK4 |   | PK4 |   |     |    the right path is valid for some
>   +-----+   +-----+   +-----+    OTHER policies.
>        \     /           |
>        +-----+        +-----+
>        |Cert |        | CRL |
>        +-----+        +-----+
>  
> If I try to validate the certificate with the "left" policy mappings, 
> only the "left" chain will be valid. Then, I will check the chain for 
> the CRL, which will be valid and will match the DN matching rule, so I 
> will conclude that the certificate is revoked.
> 
> If I try to validate the certificate with the "right" policy mappings, 
> onle the "right" chain will be valid. Then, I will check the chain for 
> the CRL, which will not match the DN matching rule, so I will not be 
> able to verify the validity of the CRL, and hence conclude that the 
> certificate is valid.
> 
> Sincerely,
> 
> --
> Julien
>