Subject: RE: Certificates in CRLs

From: Sharon Boeyen <[email-masked]>
Date: Thu, 21 Dec 2006 15:50:14 -0500

I also much prefer the "bag of CRL and certificate" approach and prefer it
to be an additional service that could be offered but not the sole means of
obtaining revocation status info. There should always be a way to obtain
that without the baggage of certificates - whether it be by CRLs or OCSP.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kemp, David P.
Sent: Thursday, December 21, 2006 10:16 AM
To: [email-masked]
Subject: RE: Certificates in CRLs

What's unrealistic about an RP that has a certificate (from a prior CRL) not
wishing to download that same certificate over and over again?

I agree with Denis - I am opposed to this work item unless it explicitly
addresses a standard mechanism to obtain the normal CRL.   In addition,
I am opposed because it is the wrong approach.   A bag of CRL and
certificate (e.g. a directory attribute that aggregates independent data
objects, a la crossCertificatePair) is the correct approach to minimizing
round trips.  Just because X.509 defines a flexible extension mechanism does
not mean that extensions are the proper place for everything including the
kitchen sink.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, December 21, 2006 8:00 AM
To: Denis Pinkas; [email-masked]
Subject: RE: Certificates in CRLs

As with anything else, the relying party can get what the CA offers.

I don't think there is any realistic scenario where the CA has a reason to
offer CRLs both with and without certificates. To offer this capability to
RP is however not a matter for this protocol. It would be a matter for the
CRL referencing model, i.e. CDP and/or directory schema.

I don't think that extra complexity however is very useful.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf- 
> [email-masked]] On Behalf Of Denis Pinkas
> Sent: den 20 december 2006 17:05
> To: [email-masked]
> Subject: Re: Certificates in CRLs
>
>
>
> It is necessary to provide relying parties with the choice to get :
>
>   - CRLs "as usual", or
>   - CRLs that carry that new extension.
>
> The current proposal does not allow for it.
>
> Until the draft is changed, I am against the addition of this work
item
> to the program of the PKIX WG.
>
> Denis
>
>
_______________________________________________________________________
> _______
>
> >Since last IETF a new draft was posted: 
> >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-00.txt
> >
> >There is a request to add this draft to the PKIX work and I would
> encourage to start the discussion about this decision in this thread.
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
>
>
>

---

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 22 Dec 2006 09:43:32 +0100

Stefan,

>I don't think there is any realistic scenario where the CA has a reason to offer CRLs both with and without certificates.

You are asking for a realistic scenario where both would be needed. Here is one :

1 - For current RPs, they already know how to get certificates, so they do not need to bother 
with the "new" CRLs. They do not need to fetch "longer" CRLs.

2 - For newly developped RPs, that have a local cache for certificates, the RP fetches 
the "normal" CRL as usual. If the cached certificates do not allow to build 
the certification path, then the "new" CRL will be fetched. 

3 - For newly developped RPs, that do not have a local cache for certificates, they directly fetch 
the "new" CRLs.

>To offer this capability to RP is however not a matter for this protocol. 

The point is that CAs must be able to generate both types of CRLs and make both types of CRLs available.
This can be solved at the protocol level, e.g. by adding an extra parameter when the RP is using the CRLDP, 
that would allow to get the "new" CRL.

To be clear: the CRLDP in the certificate would be unchnaged, but adding an extra parameter to it, 
would allow to obtain the "new" CRL, if the CA has chosen to issue it.

In the mean time, my opinion remains the same: until the draft is changed, I am against the addition of this work item
to the program of the PKIX WG.

Denis

> It would be a matter for the CRL referencing model, i.e. CDP and/or directory schema.
>

>> Until the draft is changed, I am against the addition of this work item

Regards,

Denis Pinkas