Subject: Withdrawl of Proxy Cert Profile draft from PKIX

From: Steve Tuecke <[email-masked]>
Date: Tue, 27 Aug 2002 11:47:39 -0500

All,

In February 2001 we wrote a first draft of "Internet X.509 Public Key 
Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) and 
introduced it into the Global Grid Forum (GGF, www.gridforum.org).  Shortly 
after that, because it seemed to relate to the work in PKIX, we also 
introduced it into the PKIX working group.  Tim and Steve accepted this 
draft into PKIX and gave me time at several IETFs to present progress on 
this draft (for which we are most grateful!), which led to many useful 
discussions with IETF folks.  Over the past year and a half, we have 
continued to refine the draft as a result of this input and our own 
continuing work in this area.

We are now trying to reach closure on this draft, so that various groups, 
including our Globus Project, can implement and deploy to a non-moving 
target.  There is strong support in the GGF Grid Security Infrastructure 
(GSI) working group to finalize the draft, and push it on to become a Grid 
Forum Document (GFD), which is GGF's equivalent of an RFC. However, within 
the PKIX community I think its fair to say that it has received little 
attention, and the reactions that have been expressed have been mixed -- 
everywhere from strong disagreement to strong support of the approach.

We have a new, significantly cleaned up draft available at 
http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet submitted it 
to IETF, pending the outcome of this discussion.

Our current intention is to withdraw this document from PKIX consideration, 
and finish it up within GGF.  (The previous draft-ietf-pkix-proxy-02 
expires this month.)  However, if there is a public ground swell to 
complete it within PKIX, we are happy to reconsider.

Meanwhile, this draft is currently in last-call in the GGF GSI working 
group, prior to submitting it for consideration to become a GFD.  We would 
be happy to receive and incorporate feedback to the latest GGF draft (see 
above URL), prior to the final submission (hopefully within in a couple weeks).

Thanks,
-Steve
------------------------------------------------------------------------
Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 252-8711
[email-masked]     Argonne National Laboratory  cell: (630) 842-6917
http://www.mcs.anl.gov/~tuecke   Argonne, IL 60439   fax: (630) 252-5986

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 27 Aug 2002 14:01:56 -0400

Steve:

I understand the need for you to make progress.  And, I will support any 
pragmatic decision that you make.  However, I would prefer to see this 
profile published as an RFC.

Russ

At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:

>introduced it into the Global Grid Forum (GGF, 
>www.gridforum.org).  Shortly after that, because it seemed to relate to 
>the work in PKIX, we also introduced it into the PKIX working group.  Tim 
>and Steve accepted this draft into PKIX and gave me time at several IETFs 
>to present progress on this draft (for which we are most grateful!), which 
>led to many useful discussions with IETF folks.  Over the past year and a 
>half, we have continued to refine the draft as a result of this input and 
>our own continuing work in this area.
>
>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet submitted 
>it to IETF, pending the outcome of this discussion.
>
>Our current intention is to withdraw this document from PKIX 
>consideration, and finish it up within GGF.  (The previous 
>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a 
>public ground swell to complete it within PKIX, we are happy to reconsider.
>

---

From: Steve Tuecke <[email-masked]>
Date: Tue, 27 Aug 2002 14:05:11 -0500

Russ,

There are, of course, two avenues to RFC -- one through a working group, 
and the other as an individual submission.  I am curious what you think of 
each of these avenues, and more generally why you would prefer to see it 
published as an RFC.  For broad acceptability of the profile, the best 
route is obviously PKIX.  But if that doesn't happen, is there any value to 
it being an individually submitted informational RFC, in addition to a GGF 
(RFC-like) GFD?  (The GGF document process is pretty similar to IETF.)

-Steve

At 01:01 PM 8/27/2002, Housley, Russ wrote:
>>to present progress on this draft (for which we are most grateful!), 
>>which led to many useful discussions with IETF folks.  Over the past year 
>>and a half, we have continued to refine the draft as a result of this 
>>input and our own continuing work in this area.
>>
>>(GSI) working group to finalize the draft, and push it on to become a 
>>Grid Forum Document (GFD), which is GGF's equivalent of an RFC. However, 
>>within the PKIX community I think its fair to say that it has received 
>>little attention, and the reactions that have been expressed have been 
>>mixed -- everywhere from strong disagreement to strong support of the approach.
>>
>>group, prior to submitting it for consideration to become a GFD.  We 
>>would be happy to receive and incorporate feedback to the latest GGF 
>>draft (see above URL), prior to the final submission (hopefully within in 
>>a couple weeks).
>>
>>Thanks,
>>-Steve

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 27 Aug 2002 15:57:22 -0400

Steve:

I would like to see certificate handling libraries support the delegation 
environment, and the people that write such libraries are currently paying 
attention to the PKIX WG.  So, that is my preferred route.

Russ

At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
>route is obviously PKIX.  But if that doesn't happen, is there any value 
>to it being an individually submitted informational RFC, in addition to a 
>GGF (RFC-like) GFD?  (The GGF document process is pretty similar to IETF.)
>
>-Steve
>
>>>the work in PKIX, we also introduced it into the PKIX working 
>>>group.  Tim and Steve accepted this draft into PKIX and gave me time at 
>>>several IETFs to present progress on this draft (for which we are most 
>>>grateful!), which led to many useful discussions with IETF folks.  Over 
>>>the past year and a half, we have continued to refine the draft as a 
>>>result of this input and our own continuing work in this area.
>>>
>>>We are now trying to reach closure on this draft, so that various 
>>>groups, including our Globus Project, can implement and deploy to a 
>>>non-moving target.  There is strong support in the GGF Grid Security 
>>>Infrastructure (GSI) working group to finalize the draft, and push it on 
>>>to become a Grid Forum Document (GFD), which is GGF's equivalent of an 
>>>RFC. However, within the PKIX community I think its fair to say that it 
>>>has received little attention, and the reactions that have been 
>>>expressed have been mixed -- everywhere from strong disagreement to 
>>>strong support of the approach.
>>>
>>>draft (see above URL), prior to the final submission (hopefully within 
>>>in a couple weeks).
>>>
>>>Thanks,
>>>-Steve

---

From: Steve Tuecke <[email-masked]>
Date: Wed, 28 Aug 2002 00:24:27 -0500

Russ,

So how do we get there from here?

One fundamental obstacle may be that there are some PKIX participants who 
seem to be fundamentally opposed to the approach taken in the proxy cert 
profile.  Having had a number of conversations with such people, my belief 
is that it is likely an irreconcilable difference.  It seems to be more of 
a difference in world-view than in any specific technical detail -- they 
believe that using an end-entity certificate to sign proxy certificates is 
at fundamental odds with X.509 and PKIX philosophies.

But even if we are able to resolve this difference (e.g. either through 
finding an approach that we all agree on, or by agreeing to disagree but 
moving forward anyway), I guess its not clear to me how we overcome the 
energy barrier to advance it to an RFC.  There seems to be a general apathy 
within PKIX participants toward advancing this draft.  (And please realize 
that I am not faulting anybody by making this statement.  We all have our 
own agendas within PKIX, and it may just be that mine is too far off the 
radar for most.)

I'm completely comfortable with PKIX making a consensus decision that the 
Proxy Cert Profile should not be considered further in PKIX.  I'm also 
happy to push forward with it if there is support for doing so.  But given 
that it is currently languishing in PKIX, and that I don't see an obvious 
path toward reaching consensus in PKIX on this profile, I felt the most 
reasonable route was to suggest the withdrawal of the draft from PKIX.

-Steve

At 02:57 PM 8/27/2002, Housley, Russ wrote:
>>and the other as an individual submission.  I am curious what you think 
>>of each of these avenues, and more generally why you would prefer to see 
>>it published as an RFC.  For broad acceptability of the profile, the best 
>>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02) 
>>>>and introduced it into the Global Grid Forum (GGF, www.gridforum.org). 
>>>>Shortly after that, because it seemed to relate to the work in PKIX, we 
>>>>also introduced it into the PKIX working group.  Tim and Steve accepted 
>>>>this draft into PKIX and gave me time at several IETFs to present 
>>>>progress on this draft (for which we are most grateful!), which led to 
>>>>many useful discussions with IETF folks.  Over the past year and a 
>>>>half, we have continued to refine the draft as a result of this input 
>>>>and our own continuing work in this area.
>>>>
>>>>Infrastructure (GSI) working group to finalize the draft, and push it 
>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent of 
>>>>an RFC. However, within the PKIX community I think its fair to say that 
>>>>it has received little attention, and the reactions that have been 
>>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet 
>>>>submitted it to IETF, pending the outcome of this discussion.
>>>>

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 28 Aug 2002 14:48:31 +0200

I wander if anyone on this list have experience/opinions on using wildcard
names in SSL server certificates.

E.g. having the name *.domain.com  in one certificate instead of having
xxx.domain.com and secure.domain.com as common name in 2 separate
certificates.

Several CA service providers offer wildcard certificates on the market
today.

Talking to Steve Kent in Yokohama, he implied that this practice is against
current standards (but I can't recall how) and that it is known to create
problems in certain environments.

Are there any opinions on the list?

1) Is this braking any standards?
2) What environments have problems with wildcard certificates?
3) What are the problems?

/Stefan

---

From: Eric Norman <[email-masked]>
Date: Wed, 28 Aug 2002 11:41:58 -0500 (CDT)

> 3) What are the problems?

We did some experimentation a few years ago with a mail server that needs
to support lots of different domains.  We found that wildcards work with
both Netscape and IE browsers.  However, there is a difference in whether
a wildcard can span a dot or not.  That is, in one browser (I think it's
Netscape-Mozilla) *.wisc.edu will match a.b.wisc.edu; in the other,
you need *.*.wisc.edu to match.  We got around this minor inconvenience
by using two different IP numbers.

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 28 Aug 2002 09:49:38 -0700

>xxx.domain.com and secure.domain.com as common name in 2 separate

I've only ever seen "*" in a cert, but Netscape implements a fairly full 
form of regular expressions. The source is available in Mozilla, though I 
think it has a few bugs in the more esoteric nested expressions.

>Several CA service providers offer wildcard certificates on the market

I think an SSL implementation that didn't handle the wild cards, at least 
*, would have problems operating against many SSL sites. I haven't checked 
the IE, but I expect it does it or Thawte wouldn't be able to issue the 
certs it does.

>problems in certain environments.

Not sure what standard that would be. My understanding is that PKIX doesn't 
necessarily apply to SSL, or at least no one has written down how it 
applies. Also don't recall running into standard, PKIX or other, that says 
how the CN should be matched to the hostname.

LL

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 28 Aug 2002 13:36:15 -0400

Laurence Lundblade wrote:

> Not sure what standard that would be. My understanding is that PKIX 
> doesn't necessarily apply to SSL, or at least no one has written down 
> how it applies. Also don't recall running into standard, PKIX or 
> other, that says how the CN should be matched to the hostname.

I don't know how products handle wildcards, but I did take a quick look 
to try to determine what the relevant standards might be:

1) Section 3.1 of RFC 2818 (HTTP Over TLS) specifies how to match the 
identity of a server to the information in a certificate. It specifies 
that the identity may either be in the dNSName component of 
subjectAltName or a common name component of the subject name (CAs are 
encouraged to put the DNS information in the dNSName component of 
subjectAltName). The specification includes a description of wildcard 
matching.

2) Section 4.2.1.7 of RFC 3280 specifies that the dNSName component of 
subjectAltName MUST be in the "preferred name syntax," as specified by 
RFC 1034.

3) RFC 1034 states that in the preferred name syntax, the "*" character 
is not allowed. Combining this with RFC 3280 means that names with a 
wildcard should only be placed in the common name component of the 
subject field.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Aug 2002 19:33:19 -0400

At 9:49 AM -0700 8/28/02, Laurence Lundblade wrote:
>	<SNIP>
>doesn't necessarily apply to SSL, or at least no one has written 
>down how it applies. Also don't recall running into standard, PKIX 
>or other, that says how the CN should be matched to the hostname.
>
>LL

RFC 3280 defines what characters can appear in a DNS name appearing 
in the subject alternative name (by reference to RFC 1034), which is 
one of the two places that the server name might appear. The "*" 
character is not allowed there, and this is the preferred location in 
a cert for a DNS name.

The other alternative for DNS name representation defined by 3280 is 
to put the server DNS name into a DN as a series of domain 
components, and that too would preclude use of a "*" in the name.

What is often done by our beloved TTPs, is to represent a server DNS 
name as a common name, in what is clearly a bastardized use of a DN. 
This is not consistent with PKIX standards. I'm not familiar with any 
limitations on the use of "*" in a common name, but I think it fair 
to say that it is not within the realm of what X.500 envisioned for 
CNs.

This is the basis for my comment to Stefan.

Steve

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 29 Aug 2002 09:54:21 -0400

Steve:

I think that a straw poll is in order.  If the consensus of the group is 
that this work should proceed, then we simply follow the usual process.  If 
the consensus of the group is that this work should not proceed, then 
withdrawal is the appropriate course of action.

Would the PKIX WG Chairs please conduct the poll...

Russ

At 12:24 AM 8/28/2002 -0500, Steve Tuecke wrote:
>energy barrier to advance it to an RFC.  There seems to be a general 
>apathy within PKIX participants toward advancing this draft.  (And please 
>realize that I am not faulting anybody by making this statement.  We all 
>have our own agendas within PKIX, and it may just be that mine is too far 
>off the radar for most.)
>
>>environment, and the people that write such libraries are currently 
>>paying attention to the PKIX WG.  So, that is my preferred route.
>>
>>Russ
>>
>>>it published as an RFC.  For broad acceptability of the profile, the 
>>>best route is obviously PKIX.  But if that doesn't happen, is there any 
>>>value to it being an individually submitted informational RFC, in 
>>>addition to a GGF (RFC-like) GFD?  (The GGF document process is pretty 
>>>similar to IETF.)
>>>
>>>-Steve
>>>
>>>>I understand the need for you to make progress.  And, I will support 
>>>>any pragmatic decision that you make.  However, I would prefer to see 
>>>>this profile published as an RFC.
>>>>
>>>>Russ
>>>>
>>>>>Shortly after that, because it seemed to relate to the work in PKIX, 
>>>>>we also introduced it into the PKIX working group.  Tim and Steve 
>>>>>accepted this draft into PKIX and gave me time at several IETFs to 
>>>>>present progress on this draft (for which we are most grateful!), 
>>>>>which led to many useful discussions with IETF folks.  Over the past 
>>>>>year and a half, we have continued to refine the draft as a result of 
>>>>>this input and our own continuing work in this area.
>>>>>
>>>>>an RFC. However, within the PKIX community I think its fair to say 
>>>>>that it has received little attention, and the reactions that have 
>>>>>been expressed have been mixed -- everywhere from strong disagreement 
>>>>>to strong support of the approach.
>>>>>

---

From: Steve Tuecke <[email-masked]>
Date: Thu, 29 Aug 2002 19:02:01 -0500

I agree.
-Steve

At 08:54 AM 8/29/2002, Housley, Russ wrote:
>that this work should proceed, then we simply follow the usual 
>process.  If the consensus of the group is that this work should not 
>proceed, then withdrawal is the appropriate course of action.
>
>>profile.  Having had a number of conversations with such people, my 
>>belief is that it is likely an irreconcilable difference.  It seems to be 
>>more of a difference in world-view than in any specific technical detail 
>>-- they believe that using an end-entity certificate to sign proxy 
>>certificates is at fundamental odds with X.509 and PKIX philosophies.
>>
>>happy to push forward with it if there is support for doing so.  But 
>>given that it is currently languishing in PKIX, and that I don't see an 
>>obvious path toward reaching consensus in PKIX on this profile, I felt 
>>the most reasonable route was to suggest the withdrawal of the draft from PKIX.
>>
>>-Steve
>>
>>>I would like to see certificate handling libraries support the 
>>>delegation environment, and the people that write such libraries are 
>>>currently paying attention to the PKIX WG.  So, that is my preferred route.
>>>
>>>Russ
>>>
>>>>There are, of course, two avenues to RFC -- one through a working 
>>>>group, and the other as an individual submission.  I am curious what 
>>>>you think of each of these avenues, and more generally why you would 
>>>>prefer to see it published as an RFC.  For broad acceptability of the 
>>>>profile, the best route is obviously PKIX.  But if that doesn't happen, 
>>>>is there any value to it being an individually submitted informational 
>>>>RFC, in addition to a GGF (RFC-like) GFD?  (The GGF document process is 
>>>>pretty similar to IETF.)
>>>>
>>>>-Steve
>>>>
>>>>>>and introduced it into the Global Grid Forum (GGF, 
>>>>>>www.gridforum.org). Shortly after that, because it seemed to relate 
>>>>>>to the work in PKIX, we also introduced it into the PKIX working 
>>>>>>group.  Tim and Steve accepted this draft into PKIX and gave me time 
>>>>>>at several IETFs to present progress on this draft (for which we are 
>>>>>>most grateful!), which led to many useful discussions with IETF 
>>>>>>folks.  Over the past year and a half, we have continued to refine 
>>>>>>the draft as a result of this input and our own continuing work in this area.
>>>>>>
>>>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent 
>>>>>>of an RFC. However, within the PKIX community I think its fair to say 
>>>>>>Meanwhile, this draft is currently in last-call in the GGF GSI 
>>>>>>working group, prior to submitting it for consideration to become a 
>>>>>>GFD.  We would be happy to receive and incorporate feedback to the 
>>>>>>latest GGF draft (see above URL), prior to the final submission 
>>>>>>(hopefully within in a couple weeks).
>>>>>>
>>>>>>Thanks,
>>>>>>-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 30 Aug 2002 09:58:28 +0200

Russ,

> Would the PKIX WG Chairs please conduct the poll...

Hold on a second.

Is this document going to follow the Standards Track or the Informational
Track ?

I understood that the document is being progressed in the Grid Forum
Document and is well advanced. I wonder if the PKIX WG will have the real
possiblity to influence the content of the document. When a document is
going on the Standards Track, it has to reflect the consensus of the PKIX
WG and we all know by experience that it takes much more than a couple of
months to reach a consensus. I wonder if that time frame is compatible with
the goals of the people supporting that document.

Now, if the document is going to follow the Informational Track, it can do
it within or outside the PKIX WG.

Before any strow poll is conducted, it first needs to be clarified whether
the proposal would be to carry on the work on the Standards Track or the
Informational Track.

Denis