Subject: Re: RE: IDP indirectCRL flag

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 26 Jul 2005 16:09:34 +0100

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

A this time of the discussion, I would say that the most complex case of indirect CRLs 
(i.e. the CRL MAY contain revocation status information from more than one CA) will 
need to have some sentences "polished".

The CRL general algorithm will need to be made secure to correctly support CRL name 
collisions and also to clarify how it is made sure that the CRL is signed by the "right" entity 
(this applies to the simplest case where the CA itself is signing the CRL).

The current algorithm would also need to support the case of a cache that contains :

 a) "old" but still usable CRLs,

 b) more than one CRL valid at time t.  

Having said that, I wonder that due to the number of extensions that MUST be supported, 
the current algorithm, when handling indirect CRLs, will be widely deployed.

On another end, I have identified a case that would allow a much simpler implementation 
and would promote the separation between the CA and the CRL Isssuer. This will apply only 
when the CRL Issuer serves one CA.

We might call that case "delegated CRL" and that case could coexist with the more complex 
case of "indirect CRLs".

See below additional responses to James. 

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

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.

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

True.

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

Yes, but that information is not necessary.

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

Well in the simple case where the CRL is complete, the algorithm I have presented applies.

If there is a CRL splitting then the algorithm would be more complicated.

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

I wonder if the current algorithm in RFC 3280 handles that case explicitly.
My I-D handles the two cases.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 26 Jul 2005 12:00:12 -0400

Denis,

See responses in-line under [Santosh:].  Text not deemed cogent may be
redacted.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Tuesday, July 26, 2005 11:10 AM
To: Santosh Chokhani; 'pkix'
Subject: Re: 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?

A this time of the discussion, I would say that the most complex case of
indirect CRLs 
(i.e. the CRL MAY contain revocation status information from more than one
CA) will 
need to have some sentences "polished".

[Santosh: The text in 3280 biz seems ok.]

The CRL general algorithm will need to be made secure to correctly support
CRL name 
collisions and also to clarify how it is made sure that the CRL is signed by
the "right" entity 
(this applies to the simplest case where the CA itself is signing the CRL).

[Santosh: We have gone over this again and again.  This is not an ICRL issue
alone.  It impacts the direct CRL also.  The authors are leaning towards
requiring the same TA and adding text to Security Considerations.  While not
the best solution, this is something we can live with.]

The current algorithm would also need to support the case of a cache that
contains :

[Santosh: These are relying party detail and the standard should provide
some leeway in using thisUpdate and nextUpdate and associated grace period.
I would rather the standard provides some flexibility and guidance in
security considerations as opposed to mandate something.]

Having said that, I wonder that due to the number of extensions that MUST be
supported, 
the current algorithm, when handling indirect CRLs, will be widely deployed.

[If you want to propose a single delegated CRL, this must be done via a new
extension or show how existing implementations can stay compliant with it.
If you choose the new extension approach, it may also need to be vetted
through X.509]

On another end, I have identified a case that would allow a much simpler
implementation 
and would promote the separation between the CA and the CRL Isssuer. This
will apply only 
when the CRL Issuer serves one CA.

[Santosh: See the comment above]

We might call that case "delegated CRL" and that case could coexist with the
more complex 
case of "indirect CRLs".

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Manger, James H
>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.

[Santosh: If the CRL may contain revocation status of certificates not
issued by the CRL issuer, there must be an IDP or a new extension defined
(most likely critical)]

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

True.

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

Well in the simple case where the CRL is complete, the algorithm I have
presented applies.

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

Denis