RE: 3280bis: CRL validation

["Alberti Antoine" <aalberti@xxxxxxxxx>]

The fact that a cert is a trust anchor becomes very personal when using a cross-certified model: two parties are not supposed to have the same ones, but can still communicate.

> -----Message d'origine-----
> De : owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]De la part de Denis Pinkas
> Envoyé : jeudi 26 mai 2005 10:44
> À : pkix
> Objet : 3280bis: CRL validation
> 
> 
> 
> To the list,
> 
> I changed the name of the thread which is now under 3280bis.
> 
> As Tim mentioned: "it is clear that the current content of 
> 3280bis with 
> respect to CRL validation does not enjoy consensus within the 
> working group".
> 
> Issues 33 and 43 are directly related to this topic. They are 
> both copied 
> below:
> 
> 33) The certificateIssuer CRL entry extension contains a 
> GeneralNames. 
> While RFC 3280 does not state this, there seems to be general 
> agreement that 
> the certificateIssuer extension should only contain the DN 
> from the issuer 
> field of the certificate being revoked.
> 
>    3280bis states: "Conforming CRL issuers MUST include in [the
>    certificateIssuer] extension the distinguished name (DN) from the
>    issuer field of the certificate that corresponds to this CRL entry.
>    The encoding of the DN MUST be identical to the encoding 
> used in the
>    certificate."
> 
> 
>   43) It should be noted in 3280bis that there is a risk that 
> two different
>       CAs (or a CA and a CRL issuer) may issue certificates 
> and CRLs under
>       the same name and that if this happens there is a risk 
> that a relying
>       party will validate a certificate issued by one of 
> these entities
>       using a CRL issued by the other.
> 
>    The security considerations section of 3280bis states that 
> CAs and CRL
>    issuers should be formed in a way that reduces the 
> likelihood of name
>    collisions.  It also states that implementations 
> validating CRLs MUST
>    ensure that the certification path of the target 
> certificate and the
>    CRL issuer certification path used to validate the target 
> certificate
>    terminate at the same trust anchor.
> 
> Both statements are incorrect.
> 
> For issue 43: name collisions are possible and a design 
> cannot be based on 
> the assumption that name collisions, whether accidental or 
> intentional, will 
> never happen. This means that chosing names to "reduce the 
> likehood of name 
> collisions" is not a way to solve the issue. Termination at 
> the same trust 
> anchor without additional details does not solve the issue either.
> 
> For issue 33: the certificateIssuer extension is defined as :
> 
>       certificateIssuer ::= GeneralNames
> 
> with
> 
>       GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> It is not defined as:
> 
>       certificateIssuer ::= GeneralName
> 
> ... and this is NOT an error.
> 
> To go directly to the point, certificateIssuer may contain in 
> practice either:
> 
>   - one name, or
>   - a sequence of names.
> 
> If it contains one name, this means that this name MUST be 
> certified by the 
> CA that has issued the certificate where the extension appears.
> 
> If it contains a sequence of names, this means that the 
> certification path 
> of the CRL issuer certificate formed using that sequence of 
> names MUST also 
> terminate at the trust anchor of the target certificate.
> 
> This is secure and avoids any name collision, either 
> deliberate or intentional.
> 
> Denis
> 
>