Subject: RE: IDP indirectCRL flag

From: "Manger, James H" <[email-masked]>
Date: Tue, 26 Jul 2005 11:49:26 +1000

> Can you explain me why we would want to change the standard
> and impose these additional constraints for indirect CRL?

I don't want to.
I was trying to point out to Denis that even if his rules worked under one assumption ("CRL for 1 CA"), there was no way to tell if that assumption held in any instance.  Consequently, you must not make that assumption so you must not use Denis's rules.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, 25 July 2005 10:09 PM
To: 'pkix'
Subject: RE: IDP indirectCRL flag

James Manger and Denis,

Can you explain me why we would want to change the standard and impose these
additional constraints for indirect CRL?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Manger, James H
Sent: Sunday, July 24, 2005 9:43 PM
To: pkix
Subject: RE: IDP indirectCRL flag

Denis,

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.

A certificate with a CRL-DP.cRLIssuer field tells the RP that the named CRL
issuer handles certificates from at least the issuer of this certificate.
It gives no information about how many other CAs (if any) the CRL issuer may
also handle, nor whether the CRL issuer is also a CA itself.  A
CRL-DP.cRLIssuer field tells the RP that some CRLs from the named CRL issuer
should cover this certificate, but it does not tell the RP that all CRLs do.

P.S. A CRL issuer may as well use the same name as the CA if it is only ever
going to issue revocation info for that CA's certificates.  That is, the CA
delegates CRL issuance to a separate key, not to a separate name.  This
avoids CRL-DP.cRLIssuer, IDP.indirectCRL & CRL-ENTRY.certificateIssuer
fields completely.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 27 Jul 2005 17:21:48 +1000

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

The example Denis has been asking for:

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

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

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.

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: "Aisenberg, Michael" <[email-masked]>
Date: Wed, 27 Jul 2005 06:05:56 -0400

Secure Electronic Commerce. Ford & Baum. 2d ed.  Chp. 5

 -----Original Message-----
From: 	Manger, James H [mailto:[email-masked]]
Sent:	Wed Jul 27 04:47:36 2005
To:	pkix
Subject:	RE: IDP indirectCRL flag

Wrong.

P.S. To Stefan:

---

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 28 Jul 2005 11:13:38 +0100

Stephen,

>> 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.

Not at all.

>> However we are back with the vocabulary issue about "indirect CRLs" and 
>> "delegated CRLs".
>
>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?

The IETF meeting is now very close. 
Let us have some face to face discussions there.

Denis

>Stephen.