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

Re: Conclusions: CA Rekey and CRL Validation

To: "Luciano (Pessoal)" <mentes@xxxxxxxxxxx>
Subject: Re: Conclusions: CA Rekey and CRL Validation
From: Jean-Marc Desperrier <jmdesp@xxxxxxx>
Date: Sun, 19 Sep 2004 00:15:35 +0200
Cc: ietf-pkix@xxxxxxx, Santosh Chokhani <chokhani@xxxxxxxxxxxx>
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
References: <> <>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040818

Luciano (Pessoal) wrote:

Not considering the "feature" implemented by MS.

[...]

2) If I can do the verification above, as I suppose, Why need I issue CRLs using the old key (associated with CA2)?

The only reason you need to issue CRL usign the old key is if you consider the "feature" implemented by MS, as has been described MS CAPI will not accept to match by name and not key if an IDP is not present.

But this kind of restriction was also implemented I think by many other implementers who were with reason wary of matching only by name because, without using the algorithm proposed by Santosh, it is dangerous.

References:
- RE: Conclusions: CA Rekey and CRL Validation
  - From: Santosh Chokhani
- Re: Conclusions: CA Rekey and CRL Validation
  - From: Luciano (Pessoal)

Prev by Date: Re: Conclusions: CA Rekey and CRL Validation
Next by Date: Re: Conclusions: CA Rekey and CRL Validation
Previous by thread: Re: Conclusions: CA Rekey and CRL Validation
Next by thread: Re: Conclusions: CA Rekey and CRL Validation
Index(es):
- Date
- Thread