[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Current status of CRL validation ?
Santosh,
thanks a lot for your reply.
One point still makes me very confused however.
With this verification system, it seems to me that a certificate
is never simply "revoked". It is always "revoked" in a particular
context.
We wanted to attempt to test our validation algorithm in the
following case, but we now really do not know what we should except:
We have a user certificate C.
We reconstruct the paths to trust anchors.
Say the algorithms gives 2 candidate paths.
I) We start to verify the first path, it requires us to reconstruct
paths to verify the CRL. Say the reconstruction algorithm gives us 2
possible paths to trust anchors.
Now, let us say that the first path does not have the matching DN,
so we ignore it. The second path validates all right
=> we conclude the certificate is not revoked (?)
II) Say that we started by verifying the second path. Now, the first CRL
path matches all the DN, and it turns out that the CRL issuer
certificate is revoked
=> what are we supposed to conclude ?
Sincerely,
--
Julien
On Mon, Mar 22, 2004 at 01:46:13PM -0500, Santosh Chokhani wrote:
>
> Julien:
>
> See responses in-line in [].
>
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
> Behalf Of Julien Stern
> Sent: Monday, March 22, 2004 11:34 AM
> To: ietf-pkix@xxxxxxx
> Subject: Current status of CRL validation ?
>
>
>
> Dear list,
>
> In November 2003, Santosh Chokhani raised a problem in the validation of CRL
> paths. I was wondering what was the current status of CRL validation
>
> [My impression from informal discussions with RFC 3280 authors is that they
> plan to add the text to 3280. I am also drafting amendment to X.509 Annex
> B]
>
> and also have a few questions:
>
> My current understanding is the following:
>
> We have two different setups
> 1) direct CRL (signed by the CA itself)
> 2) Indirect CRL (signed with a certificate signed with the CA itself
> + a few other bindings in extensions (crlIssuer, etc)
>
> [The indirect CRL issuer need not be issued a certificate by the CA that
> issued the certificate whose status is being checked]
>
> Santosh Chokhani suggested (I'm summarizing, see his post for the exact
> words) that the path validating the certificate and the path validating the
> CRL should have the same trust anchor and the same Issuer DNs one-by-one
> (expect for the last cert in case 2, of course).
>
> [The same "trust anchor" should be changed to "the subject DN of the trust
> anchors in the two paths should be identical. This is to account for when
> root uses separate keys for signing certificates and CRLs and o account for
> root key rollover]
>
> [The one-by-one matching should ignore self-issued certificates]
>
> ["except for last certificate" should be replaced with the logic that
> terminates the name matching when one of the path ends. This permits the CA
> to create subordinates for CRL issuance and permits CA to nominate a higher
> authority to issue CRL]
>
> Question 1: what is the status of this proposal ?
>
> [See previous answer]
>
> Question 2: How do you validate the cert path associated to the CRL ?
> Some of the certificates included in this path might have
> been revoked. Do you have to construct a third path to validate
> the CRL which has information on the certificates in the CRL
> validation path ? (And possibly a fourth, a fifth, etc ?)
>
> [Certification path development and validation for CRL is no different than
> path development for anything else. Unless you can get an authenticated
> public key to verify signature on a CRL, you are out of luck]
>
> Do you really have to through all the following to validate this
> hypothetical 2 level scheme:
>
> Let us say that I have
> - a Trust Anchor (CA1)
> - a subCA (CA2)
> - user certificates
>
> CA1 -> CA2 -> Cert
>
> To validate the chain, do I really have to:
> 1) start applying the X509 validation algorithm
> 2) obtain the CRL for CA2
> 3) reconstruct the path to validate the certificate which signs it.
> 4) start applying a new X509 validation algorithm to this new path
> + the additional Trust Anchor and DN matching rules
> 5) Possibly repeat steps 3-4 until I find a path that I have already
> fully validated
> 6) verify the CRL and check that CA2 is not in.
> 7) obtain the CRL for user certificates
> 8) reconstruct the path to validate the certificate which signs it.
> 9) start applying a new X509 validation algorithm to this new path
> + the additional Trust Anchor and DN matching rules
> 10) Possibly repeat steps 8-9 until I find a path that I have already
> fully validated
> 11) verify the CRL and check the certificate is not in.
>
> [I do not have time to review if you listed everything, but the idea is that
> you do need to develop paths for CRL. There are efficiency techniques one
> can use]
>
> Question 3: How to you replace CRL processing by OCSP in X509 path
> validation ? In particular, how do you check that the OSCP server
> certificate has not been revoked if it is different that the CA one
> ?
>
> [It is not different from other certification path validation issues. Your
> local policy decides whether OCSP needs to start with the same root. The
> revocation status of OCSP server itself can be ignored if no-check extension
> is present in the OCSP server certificate]
>
> Thank you very much.
>
> --
> Julien
>
>