Subject: Comment on draft-santesson-pkix-vccrl-00.txt

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 9 Nov 2006 15:17:51 +0100

Stefan,

Your current proposal is limited to propose a new CRLextension:

id-pe-validationCerts OBJECT IDENTIFIER ::= { id-pe nn }

The problem is the following: if a CA chooses to issue CRLs with that new extension, 
then all CRLs will augment in size.

I would rather prefer to be able to provide relying parties with the choice between :

  - CRLs that carry that new extension, and 
  - CRLs "as usual".

This would be achieved, if you were proposing at the same time a new certificate extension 
that would allow to retrieve CRLs that have the new extension (e.g. a new CRLDP extension 
that would point where the bigger CRL is).

Current applications would continue to ignore both new extensions and would not be impacted 
in any way, whatever the choice of the CA would be.

All this story is a trade off between this additional complexity both on the CA side and 
on the relying party side and the saving of  one exchange.

Denis

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 9 Nov 2006 10:56:15 -0800

I believe I understand Denis concern, I would personally be OK with the
proposal as stands if its use was limited to only the scenarios where it
is needed and the text in the document strongly made that limitation
apparent; specifically indirect cases.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Thursday, November 09, 2006 6:18 AM
To: pkix
Subject: Comment on draft-santesson-pkix-vccrl-00.txt

Stefan,

The problem is the following: if a CA chooses to issue CRLs with that
new extension, 
then all CRLs will augment in size.

I would rather prefer to be able to provide relying parties with the
choice between :

This would be achieved, if you were proposing at the same time a new
certificate extension 
that would allow to retrieve CRLs that have the new extension (e.g. a
new CRLDP extension 
that would point where the bigger CRL is).

Current applications would continue to ignore both new extensions and
would not be impacted 
in any way, whatever the choice of the CA would be.

All this story is a trade off between this additional complexity both on
the CA side and 
on the relying party side and the saving of  one exchange.

Denis

---

From: "Kemp David P." <[email-masked]>
Date: Thu, 9 Nov 2006 16:13:33 -0500

A technical standard that documents interfaces for the purpose of
interoperability shouldn't be giving "strongly"-worded guidance
concerning business processes.

I agree with Denis' approach.  A CA that encapsulates certs
inside CRLs may increase the efficiency of some customers
(by reducing the number of fetch operations) while simultaneously
decreasing the efficiency of other customers (by expanding the
size of CRLs).

A standard that gives CAs a mechanism for offering expanded CRLs
must also give customers a mechanism for accepting or declining
that offer.  I suggest that a standard of this type should enable
certificates to point to three forms of CRL data:
1) normal CRLs
2) CRLs containing certificates
3) a bag containing CRLs and certificates

It would be up to CAs to choose which of these options to offer.
I would recommend that "my" CAs support options 1 and, where
appropriate, 3.  For certificates that support more than one
option, the client can choose at runtime which is best.
There is no reason to choose expanded CRLs if the client has
previously obtained and cached the CRL issuer's certificate.

This capability could be expressed as three different CRLDP
extension OIDs (with the same extension syntax), or as a single
extension with some other mechanism (such as a standardized
http: "?" query option) to signal what type(s) of CRL data 
are available and which is being requested.  But a standard
of this type must define some way for the client to choose.
I would not support an RFC that does not provide the ability
to request normal CRLs as Denis has proposed.

Dave

-----Original Message-----
On Behalf Of Ryan Hurst

Ryan

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 9 Nov 2006 15:29:36 -0800

David - I agree regarding business practices, however I think the
guidance here is about interoperability not business practice.

Networking protocols (like EAP) already have problems with certificate
payload being so large that sessions fail or take a very long time to
establish (due to re-try's related to lack of fragmentation support
pre-IP) example environments include high latency environments (metro
WANs, etc.). 

There are also environments where devices have constrained amounts of
storage (phones, etc.) where storing multiple copies of a object is
prohibitive.

On the other hand these same scenarios often can't work with indirect
CRLs without manual provisioning because they don't know how to do
discovery of the appropriate certificates and/or the resource at the end
of a AIA:IssuerCert in the CRL is not available or times out.

I guess what I am trying to say is that if this capability is to be
provided guidance of when the capability should be used (eg a well
worded applicability statement) should be included so that people don't
go out and include it everywhere.

I would have the same concern if we did the CMS wrapped CRL and
intermediate approach.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp David P.
Sent: Thursday, November 09, 2006 1:14 PM
To: pkix
Subject: RE: Comment on draft-santesson-pkix-vccrl-00.txt

Dave

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

Ryan