Subject: Re: RE: IDP indirectCRL flag

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 27 Jul 2005 11:28:48 +0100

James,

>>> Perhaps your rules could work if a CRL issuer is not itself a CA
>>> and it only handles certificates from a single CA.
>>> However, a relying party cannot know (and must not assume)
>>> that this is the case for the CRL issuer.

>> True, but if the CRL IDP is NOT present, then it would mean
>> that this CRL Isssuer MAY not work for multiples CAs.
>> So there is no problem.

>Wrong.
>A CRL without IDP does NOT mean the *CRL issuer* always works for a single CA.  
> It means the scope of this specific CRL is a single CA.  

Security is basically made of a good use cryptography *and* of procedural rules.

When a CA wants to delegate to another entity the responsibilty to issue revocation status 
information, the conditions are negotatied. Among the conditions, the CRL Issuer will  
have to accept to work (under a given name) only for that single CA. If the CRL Issuer 
accepts then the CRL Issuer is "nominated" and a CRL Issuer certificate is issued by the CA. 
If the CRL Isssuer does not accept, then the CRL Issuer certificate is not issued.

> The same CRL issuer may issue other CRLs (with IDP.indirectCRL=true) 
> covering multiple CAs.  So there is a problem with Denis's rules.

Let us see.

>The example Denis has been asking for:

>Cert 1:  { #=100, issuer=Alice, crl-dp.cRLIssuer=Fred }

>CRL 2:  { issuer=Fred, no IDP, revokedCertificates {} }

This is not sufficient. There is also the b) (2) condition, which is:

          (2)  A CRL Issuer certificate issued by the same CA that has 
               issued the target certificate MUST be found.  That 
               certificate MUST have the cRLSign bit set, and MUST 
               include in its subject field the same DN as the one 
               of the DNs present in the crLIssuer field and MUST be 
               within its validity period.

>A relying party verifying cert 1 and possessing CRL 2 would accept the cert 
> according to Denis's rules, falsely ASSUMING Fred only works for Alice.

The CRL Issuer certificate, under the procedural rules mentioned  above, AND
the fact that the CRL does NOT include an IDP extension demonstrates that 
Fred only works for Alice. 

The current text describes the relying party point of view, so procedural rules 
that apply to CAs and CRL Issuers are not to be mentioned in such a section.

This procedural rule should be mentioned in the main body of the document.
However we are back with the vocabulary issue about "indirect CRLs" and 
"delegated CRLs".

Denis

>In fact, Fred also issues his own certs (eg cert 3) and works for Bert (see cert 4).
>
>Cert 3:  { #=48, issuer=Fred }
>Cert 4:  { #=37, issuer=Bert, crl-dp.cRLIssuer=Fred }
>
>CRL 5:  { issuer=Fred, IDP.indirectCRL=true, revokedCertificates {
>            { #=100, extn { critical=true, certificateIssuer=Alice} } }
>
>CRL 5 shows cert 1 is revoked, while cert 3 & 4 are not revoked.
>
>
>P.S. To Stefan:
>Fred's and Alice's DNs are both matched from cert & CRL to determine that cert 1 is revoked.  However, only Fred's (not Bert's) DN is matched to determine that cert 3 is not revoked.  Indirect CRLs can fail if only one DN is ambiguous.
>Perhaps a useful rule would be that at least 1 entry with a certificateIssuer entry must be present in a CRL for every CA within that CRL's scope (other that the CRL issuer).  If no certificates from a CA have been revoked a dummy entry with certificate number -1 (which is unlikely to ever correspond to a real certificate) could be included.  A relying party verifying a certificate with a CRL-DP.cRLIssuer field could require the 2 DN matches before accepting a CRL.
>
>CRL 6:  { issuer=Fred, IDP.indirectCRL=true, revokedCertificates {
>            { #=100, extn { critical=true, certificateIssuer=Alice},
>            { #=-1, extn { critical=true, certificateIssuer=Bert} } }

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Jul 2005 11:19:29 +0100

Denis,

> This procedural rule should be mentioned in the main body of the document.

That seems to go against the mitigate/supress approach you're advocating
in other messages to the list.

> However we are back with the vocabulary issue about "indirect CRLs" and 

IMO a sufficient set of technical concerns have been raised that
this isn't desirable for 3280bis.

And, given that it seems that no-one else wants this distinction, (at
least for now, at least as currently presented), is it really
worthwhile prolonging the discussion when the outcome is almost
inevitable?

Stephen.