Subject: RE: straw poll on certs in CRLs

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 6 Mar 2007 09:59:35 -0800

Yes

People want the feature, better to specify a standard than have it end up EXPRIMENTAL or INFORMATIONAL.

There is nothing to stop Microsoft cutting this off their own OID space. It is much better if this is done off the PKIX arc. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Monday, March 05, 2007 12:06 PM
> To: [email-masked]
> Subject: straw poll on certs in CRLs
> 
> 
> Folks,
> 
> In the last few weeks I have seen a number of messages 
> supporting the notion of a CRL extension that would enable a 
> CA to include a CA cert (or certs) in a CRL.  Earlier we had 
> some traffic on this topic, but is was all negative. So, it 
> seem like its time for a straw poll, so we can gauge WG 
> consensus. Since Stefan is a proponent of this notion, I will 
> conduct the poll.
> 
> Plesse send a message to the list (indicating YES or NO) on 
> the following question:
> 
> Should PKIX develop a standard for a non-critical CRL 
> extension that can hold one or more certs for use in 
> validating the CRL in question?
> 
> The poll begins today, and will close on March 16. I will, 
> announce the results during the PKIX session at the IETF 
> meeting in Prague.
> 
> Steve
> 
> 
> 
>

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 6 Mar 2007 15:01:06 -0500

People want the feature; they don't necessarily want the currently
proposed mechanism for achieving it.  Given that there are better
alternatives for achieving the same result (namely putting a CRL and
cert(s) into a simple attribute or a PKCS-7), PKIX OIDs should be
assigned to the globally-optimal solution.

Locally-optimized solutions are properly documented as EXPERIMENTAL
with private OIDs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, March 06, 2007 1:00 PM
To: Stephen Kent; [email-masked]
Subject: RE: straw poll on certs in CRLs

Yes

People want the feature, better to specify a standard than have it end
up EXPRIMENTAL or INFORMATIONAL.

There is nothing to stop Microsoft cutting this off their own OID space.
It is much better if this is done off the PKIX arc.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Mar 2007 13:57:05 -0800

At 9:59 AM -0800 3/6/07, Hallam-Baker, Phillip wrote:
>People want the feature,

Yes, they want the feature; they don't have to get it in the way that 
is proposed in this question.

>better to specify a standard than have it end up EXPRIMENTAL or INFORMATIONAL.

Better to have the feature come in a way that everyone agrees to.

>There is nothing to stop Microsoft cutting this off their own OID 
>space. It is much better if this is done off the PKIX arc.

It is much better if whoever wants the feature does it in a way that 
the rest of the community wants. You make it sound like Microsoft 
intends to ram this down users' throats regardless of what the IETF 
wants; they have said nothing of the sort.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 7 Mar 2007 11:07:35 +0000

Paul,

In line.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 6 mars 2007 22:57
> To: [email-masked]

I would like to see a standard, but I'm not locked on document type. But I don't think that is what this straw-poll is about. IMO it is if pkix should develop the feature at all.

> Better to have the feature come in a way that everyone agrees to.

I'm open to changes to how the feature is specified. I just want the capability. Again, I see this straw poll as a vote about whether the feature should be developed, not if the current draft should pass unchanged. And may I add, even if this straw poll turns out positive, this group does not need to pass the document if it is not happy with how it turns out.

> wants; they have said nothing of the sort.

This is a feature that you can't ram down anybody's throat. You are right that we have not expressed any plans to go any further with this if this initiative is turned down, and I know of no such plans. But even if we or someone else defined an extension for this identified by a non PKIX OID, then those CRLs would be compatible with current clients. They would just ignore this optional and non-critical extension and move on with business as usual. X.509 is designed to give this freedom to anyone. Implementers and organizations has defined and used private extensions in the past in this way.

Some examples from my private collection:
Cross Certificate Distribution Points   1.3.6.1.4.1.311.10.9.1  Microsoft
MS_CERTIFICATE_TEMPLATE                 1.3.6.1.4.1.311.20.2    Microsoft
CertServ CA Version                     1.3.6.1.4.1.311.21.1    Microsoft
CRL Self CDP                            1.3.6.1.4.1.311.21.14   Microsoft
CertServ Previous Certificate Hash      1.3.6.1.4.1.311.21.2    Microsoft
CertServ Cross CA Version               1.3.6.1.4.1.311.21.22   Microsoft
CRL Virtual Base                        1.3.6.1.4.1.311.21.3    Microsoft
CRL Next Publish                        1.3.6.1.4.1.311.21.4    Microsoft
Certificate Template                    1.3.6.1.4.1.311.21.7    Microsoft
Netscape Certificate Type               2.16.840.1.113730.1.1   Netscape
Netscape SSL Server Name                2.16.840.1.113730.1.12  Netscape
Netscape Comment                        2.16.840.1.113730.1.13  Netscape
Netscape Base URL                       2.16.840.1.113730.1.2   Netscape
Netscape Revocation URL                 2.16.840.1.113730.1.3   Netscape
Netscape CA Revocation URL              2.16.840.1.113730.1.4   Netscape
Netscape Certificate Renewal URL        2.16.840.1.113730.1.7   Netscape
Netscape CA Policy URL                  2.16.840.1.113730.1.8   Netscape

Some of these are obsolete but some are still in use, yet they are not rammed down anybody's throat. The mostly they have represented optional features for optional use.

Further, the S/MIME Capabilities extension was previously such private defined extension that was there for optional use (without anybody being hurt by it). This is an example where IETF originally turned down the initiative to create such extension but where we (Microsoft) decided to offer it anyway (because we needed it), using the RSA OID from PKXS#9. It turned out to be of such value that IETF later adopted it as RFC 4262.

/Stefan

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 07 Mar 2007 15:12:38 +0100

> I would like to see a standard, but I'm not locked on document type. But I don't think that is what this straw-poll is about. IMO it is if pkix should develop the feature at all.
If the straw-poll is about developing the feature, then it should be  
written another way.

I'm thinking if the crl is downloaded through http, the client could 
tell the server with an Accept header if he is ready to have this 
format  rammed down his throat :-) But we'd need something else for ldap 
and ftp.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2007 08:58:55 -0800

At 11:07 AM +0000 3/7/07, Stefan Santesson wrote:
>I would like to see a standard, but I'm not locked on document type. 
>But I don't think that is what this straw-poll is about. IMO it is 
>if pkix should develop the feature at all.

Please re-read the poll that your co-chair wrote:

Should PKIX develop a standard for a non-critical CRL extension that 
can hold one or more certs for use in validating the CRL in question?

That is quite clearly about the proposed solution being in CRLs, not 
about the feature.

>This is a feature that you can't ram down anybody's throat.

Fully disagree. If a significant vendor of software used as CAs 
started putting such an extension in its software and turned it on by 
default, it would be rammed down the throats of every system that 
validated using CRLs. As many people have pointed out, putting the 
extra information in the CRL makes it so that there is no 
negoitiation on the recipient's part about whether or not they want 
it, need it, or can even understand it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 08 Mar 2007 11:35:52 +0100

No.

I think that there are possibilities to use precisions or enhancements
in the operational protocols that allow to achieve the intended goal
without the (I admit small) overhead. example:
with ldap the client can retrieve the cert at a place nearby
with http, one might allow the client to use an accept header to
inform the crl repository to select either a crl or a pkcs7
or one might allow to specify a querystring.
The certs returned may even depend on the client that asks.

Peter