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

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 20 Sep 2006 11:18:36 -0700

Thanks to Ryan for providing the following definitions of Pre-IP and
Post-IP off list.

"Pre IP = Situations like establishing network connectivity or verifying
signatures in boot before network connectivity.
Post IP = Situations where host or user has full IP connectivity."

Using the above definitions, it does not seem that adding the extension
is a particularly good idea to solve the problem for the connectivity
challenged scenarios.  The following is my thinking:

The question is how did we get the CRL (indirect or for that matter
direct one) in the first place.  The CRL is stored as an attribute of
the CRL issuer and hence when the CRL is obtained, certificate can also
be obtained, obviating the need.

Another alternative is for the CA that issued a certificate and
delegated indirect CRL issuer, can put in its AIA p7c bag the
certification path for the indirect CRL issuer.

Now, whoever is doing pre-IP fetch of certificates and CRL and is
loading the cache can have all these certificates.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:13 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

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,

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: Wed, 20 Sep 2006 13:28:16 -0700

I understand the point, and in-fact it is why I originally recommended
the same solution you call out bellow with AIA in certs pointing to a
p7c; however connectivity is not as much an constant as we often like to
think.

With that in-mind there are other related scenarios to keep in mind when
evaluating a solution here:
1) General connectivity problems, you may have access to the url in the
CDP to acquire the CRL but not have access (server down, url is internal
to network but rp is out of network, etc) to the CRLs issuer certificate
referenced in its AIA.
2) Unreliable network connectivity, with the increase in mobile hosts
the chances of the connectivity going down after getting the CRL but
before the intermediate has been retrieved.
3) API performance - When building a generalized certificate handling
API its often necessary to have a "contract" with your callers, e.g. I
will return in n seconds reliably in these cases its desirable to reduce
the number of sockets being created.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, September 20, 2006 11:19 AM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:13 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Ryan

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

Ryan,

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

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

What am I missing?

Russ

this way.
interoperability ?