Subject: RE: Certs in CRLs - New standards task?

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 19 Sep 2006 12:28:29 -0700

Ryan,

Can you explain why "without having to go on the wire" makes sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst
Sent: Tuesday, September 19, 2006 2:21 PM
To: Russ Housley; Jean-Marc Desperrier; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 19 Sep 2006 14:12:56 -0700

Hi Santosh - I think there are numerous benefits, for example:
1. Pre-IP scenarios that have the CRL but not the intermediates; more
likely in indirect cases.
2. Post-IP scenarios where all the intermediates and trust anchors' are
there except the indirect certificate so chain discovery must go online
to complete discovery; more likely in indirect cases.
3. Post-IP scenarios where no intermediates are present and the
implementing chain validation API must return in a specific time and the
allotted time is already used through other discovery and validation
phases, additional wire retrievals introduce more latency and should be
avoided if possible.

These are just a few off the top of my head, I am sure Stefan has
others.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Tuesday, September 19, 2006 12:28 PM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Ryan,

-----Original Message-----

Ryan
-----Original Message-----

What am I missing?

Russ

this way.
interoperability ?

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 21 Sep 2006 13:04:10 +1000

How about allowing a CRL to be delivered as a multipart/related value, but only when this MIME type is explicitly preferred over application/pkix-crl by an HTTP Accept header.

The requested CRL SHALL be the root body part, SHALL be the first body part, and shall use the application/pkix-crl MIME type.  Other body parts MAY hold certificates: one per body part using the application/pkix-cert MIME type.  The receiver SHALL silently ignore any body part with an unexpected MIME type.  For instance, a body part holding, say, an OCSP response will not cause a receiver expecting only a CRL and certificates to fail.

--->
GET /ca/main.crl HTTP/1.1
Host: id.example.org
Accept: multipart/related, application/pkix-crl; q=0.5

<---
HTTP/1.1 200 Ok
Content-type: multipart/related; boundary=123 ; type=" application/pkix-crl"

--123
Content-Type: application/pkix-crl

MIIBYDCBygIBATANBgkqhkiG9w0BAQUFADBDMRMwEQYKCZImiZPyLGQBGRYDY29t
MRcwFQYKCZImiZPyLGQBGRYHZXhhbXBsZTETMBEGA1UEAxMKRXhhbXBsZSBDQRcN
MDUwMjA1MTIwMDAwWhcNMDUwMjA2MTIwMDAwWjAiMCACARIXDTA0MTExOTE1NTcw
M1owDDAKBgNVHRUEAwoBAaAvMC0wHwYDVR0jBBgwFoAUCGivhTPIOUp6+IKTjnBq
SiCELDIwCgYDVR0UBAMCAQwwDQYJKoZIhvcNAQEFBQADgYEAItwYffcIzsx10NBq
m60Q9HYjtIFutW2+DvsVFGzIF20f7pAXom9g5L2qjFXejoRvkvifEBInr0rUL4Xi
NkR9qqNMJTgV/wD9Pn7uPSYS69jnK2LiK8NGgO94gtEVxtCccmrLznrtZ5mLbnCB
fUNCdMGmr8FVF6IzTNYGmCuk/C4=
--123
Content-Type: application/pkix-cert

--123--

References:
* RFC 2387 The MIME Multipart/Related Content-type (Aug 1998)
* RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 (Jun 1999)
* RFC 2585 PKIX Operational Protocols: FTP and HTTP (May 1999)