Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX

From: Steve Tuecke <[email-masked]>
Date: Mon, 02 Sep 2002 21:43:58 -0500

Denis,

PKIX has already influenced the content of the proxy cert profile 
substantially.  I realized after my last email that "languished" was 
perhaps a poor choice of words.  In fact, the document has progressed 
substantially since its initial submission, based in part upon discussions 
with several PKIX participants.  It would perhaps be better to describe it 
as "languishing" (present tense), as it seems that changes have reached a 
plateau, with no clear path or energy to move it forward in PKIX.  (Though 
maybe this discussion will change that.)

The document is definitely still influenceable, if people are willing to 
expend the effort to attempt to influence it in the near future.  The 
document has evolved substantially during the year and a half it has been 
out there, such that the authors are now pretty happy with it.  But 
frankly, there really is not all that much to this profile. (See 
below.)  If there is acceptance of the fundamental approach of having a 
proxy cert signed by an end-entity cert or another proxy cert, then I think 
reaching consensus on the details should not be hard or take very long 
given the progress we have already made.

But that is where I see that the problem lies.  As I mentioned in my 
previous emails, we have also had conversations with PKIX people that led 
to my belief that there may we irreconcilable differences of opinion about 
this approach.  There are those who apparently believe that the approach is 
fundamentally at odds with X.509 and PKIX world views, and should not be 
sanctioned.

Perhaps this is the straw poll that needs to be taken...

Should PKIX sanction the advancement of a proxy cert draft based on the 
current fundamental approach?  We can argue about the details more later, 
but the fundamental approach at issue is whether it is reasonable to use 
end-entity public key certificates to sign proxy certificates. Possible 
answers are:
   1) No.
   2) Yes, but only as Informational Track.
   3) Yes, as Standards Track.

In order better inform voters, it is perhaps useful for me to summarize the 
approach, and some of the discussions that have occurred.  Note that I have 
purposely omitted names in the following text.  As none of the referenced 
discussions with PKIX people happened in a public forum, I don't want to 
drag them into a public debate against their will.  But of course, I'm 
happy if they jump in and take credit for (and argue for) the suggestions 
and critiques describe below.

A proxy cert is denoted by the presence of the proxyCertInfo extension, 
which must be marked critical.  A proxy cert is signed/issued by either an 
end-entity cert, or by another proxy cert.  The subject of the proxy cert 
is derived from that of its issuer, by taking the issuer DN and appending a 
common name whose value should be unique amongst all proxy certs issued by 
a particular issuer.  The subjectAltName must be empty, and there are rules 
for what is allowed in the proxy cert's key usage and extended key usage 
relative to its issuer.

The proxyCertInfo extension carries three things: a version number, so more 
info can be added to it in a subsequent revision, if desired; a 
pCPathLenConstraint to limit the proxy path length; and a proxyPolicy that 
is just a 2-tuple containing an OID of a policy language, and a policy blob 
expressed in that language.  There are two simple policies defined in the 
draft: one that states that the proxy cert is allowed to impersonate its 
issuer (that is, it inherits all rights that the issuer has), and one that 
states that the proxy cert is independent of its issuer (that is, it 
inherits no rights from its issuer).  Other policy languages can be defined 
that allow for finer grain inheritance of rights from the issuer.

Changes are required to the path validation algorithm, in order to verify 
that the proxy subject is properly derived from the subject of its issuer, 
to verify the key usage and extended key usage are correctly derived from 
the issuer, and to check the pCPathLenConstraint.

That's about it.

The biggest change to the draft came with the -02 version.  Based on 
discussions and suggestions from PKIX members, we changed the way subject 
names were handled in proxies, in order to make them work better with 
attribute certificates.  Prior to that version, we went to some length to 
avoid providing a useful proxy subject, so that a proxy really just 
inherited its name from its issuing end-entity cert.  In other words, it 
was more of a straight impersonation approach -- in essence, we were 
basically just binding temporary keys to an existing end-entity 
subject.  This changed to the approach described above, in which each proxy 
cert is given a unique subject DN, derived from that of its issuer.  This 
allows a proxy cert to be the holder of an attribute cert.

The concern that has been expressed by various PKIX people is that we are 
using end-entity certs to issue proxy certs.  The argument is that we are 
using the end-entity cert like a CA cert, which violates the fundamental 
X.509 and PKIX world view.

At some conceptual level, this is obviously true -- we are creating a key 
pair, creating a unique subject name, and then using the end-entity cert to 
sign a certificate containing the public key, name, and other information 
including the proxyCertInfo.  However:

   1) A proxy certificate is not an end-entity certificate -- a proxy 
cert's reason for existing is quite different from an end-entity cert.  The 
whole point of proxy certs is to allow for relatively short-lived entities, 
which are dynamically created and destroyed, to be given an authenticatable 
identity, optionally accompanied with some delegated rights from the 
issuer.  Issuing certificates using a traditional CA model is not practical 
or efficient for such entities.

   2) Existing code that does not implement proxy cert path validation will 
reject a proxy cert that is presented to it for 2 reasons: (1) the 
BasicConstraints.cA bit of the issuing end-entity is false, and (2) the 
proxyCertInfo extension is marked critical.  So unless existing code is 
horribly mis-implemented (even these most basic checks are not done in its 
path validation), there should be no concern about problems that proxy 
certs can cause to existing implementations.

   3) Code that properly implements proxy cert path validation cannot 
confuse an end-entity cert with a proxy cert.  The proxy cert path 
validation will reject an end-entity cert signed by a proxy cert, or a 
proxy cert that tries to spoof some subject name that is not properly 
derived from that of the issuing end-entity.  So in new code that 
implements proxy cert's, there is clear delineation between the two.

So while at some level an end-entity and proxy cert look a lot alike, they 
are really distinct things, used for distinct purposes, and cannot be 
confused with each other either by an existing implementation that does not 
implement the proxy cert profile, or by a new implementation that properly 
implements the proxy cert profile.

The only alternative approaches that were suggested were:

   A) Have existing CAs issue end-entity certificates with the 
BasicConstraints.cA bit set to true, and name constraints set to restrict 
the subjects of any certs signed by that end-entity.  In other words, 
instead of issuing end-entity certs, issue subordinate CA certs.  An 
advantage to this approach is that it lives within the current X.509/PKIX 
model.  But I believe this approach has a few problems.  First, of the CA 
operators I have talked to, none of them would issue "end-entity" certs 
with the cA bit set to true, as they found that even more counter to the 
X.509/PKIX world view than the introduction of proxy certs.  Second, many 
existing implementations do not implement name constraints, which not only 
means new code would need to be rolled out anyway (just like it does for 
proxies), but that existing code could easily be spoofed by an end-entity 
that signs another end-entity subject.  On this last point, an advantage to 
the current proxy cert profile is that code that has not been explicitly 
coded to accept proxies will reject them due to the existing fundamental 
path validation rules.

   B) Create an CA which automatically issues new end-entity certs on 
demand for the dynamically created entities.  The primary problem with this 
approach is scalability, particularly in a large, widely distributed system 
with lots of dynamically created entities (which is exactly what we are 
building today in various Grid applications using proxy certs).  The 
advantage of the current proxy cert profile is that a proxy can be 
unilaterally created by an existing entity (the holder of an end-entity 
cert or existing proxy cert), with no need for centralization.

   C) Forget X.509, and just use raw keys for what we are trying to 
do.  But the reason we went down the proxy cert path in the first place was 
so that they could drop into existing code base (e.g. SSL/TLS libraries) 
with little modification.  Technical details aside, I also found this 
argument to be curious coming from a PKIX person -- given that PKIX 
specifications as they exist today do not meet our needs, does it make more 
sense to augment the current PKIX specifications as we have done, or is it 
better to just bail on X.509 entirely?

-Steve

At 02:58 AM 8/30/2002, Denis Pinkas wrote:
>Russ,
>
> > 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...
>
>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
>
> > Russ
> >
> > At 12:24 AM 8/28/2002 -0500, Steve Tuecke wrote:
> > >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:
> > >>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:
> > >>>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:
> > >>>>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:
> > >>>>
> > >>>>>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, 03 Sep 2002 09:54:00 -0400

>   3) Yes, as Standards Track.

I would vote for 3.  I think that the inclusion of a critical extension in 
proxy certificates is key.  This extension keeps proxy certificates from 
being confused with other CA certificates.

Russ

---

From: David Hopwood <[email-masked]>
Date: Tue, 03 Sep 2002 18:31:11 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> certs can cause to existing implementations.

But remember that MSIE's certificate checking *is* horribly mis-implemented.
Of course this doesn't lead to a security problem that is not already present
in MSIE, but it could lead to significant user confusion (because a proxy cert
looks to the user exactly like an attempted exploit of the BasicConstraints
checking bug).

Would the critical proxyCertInfo extension cause MSIE to reject proxy certs?

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 04 Sep 2002 15:12:12 +0200

Steve,

> Denis,

Since my first name appears at the top of this very loooong e-mail, 
I feel forced to reply.

> expend the effort to attempt to influence it in the near future.  

Fine. This clarifies the issue that I raised.

> The

I do not have that kind of problem as long as the draft is using everywhere
"proxy certificate" and is NOT using the terminology "public key
certificate".

RFC 3280 is about a public key certificate, as mentioned in some text
extracted from RFC 3280 below:

   Users of a public key require confidence that the associated private
   key is owned by the correct remote subject (person or system) with
   which an encryption or digital signature mechanism will be used.
   This confidence is obtained through the use of public key
   certificates, which are data structures that bind public key values
   to subjects.  The binding is asserted by having a trusted CA
   digitally sign each certificate.  

As far as ASN.1 is concerned since the issuer field identifies "the entity
who has signed and issued the certificate", there is no problem as well.  

> which must be marked critical.  

Compliant software SHALL then reject such a certificate, if that extension
is present and they do not know how to process it. 

> A proxy cert is signed/issued by either an end-entity cert, 

Fine.
 
> or by another proxy cert.  

This may be much more complicated to handle.

> The subject of the proxy cert
> a particular issuer.  

> The subjectAltName must be empty, and there are rules
 
> that allow for finer grain inheritance of rights from the issuer.

My own belief is that impersonation only is VERY dangerous and thus I see
little value for that draft, unless the target(s) where the proxy
certificate can be used can be restricted. So I am NOT talking about a finer 
grain inheritance of rights from the issuer (which would be useful as well) 
but about a finer grain of usage of the rights from the issuer (which may 
simply be its identity).
 
> the issuer, and to check the pCPathLenConstraint.

Maybe this is where we have a problem. This is not a *change* in the path
validation algorithm, but this should be an *addition* to the basic path
validation algorithm to say how to process the proxy certificate(s).

> allows a proxy cert to be the holder of an attribute cert.

 ... but this complicates even more the design.

> X.509 and PKIX world view.

Not really. If there is no basic constraints extension field in the proxy
certificate, then there cannot be any violation. 
 
> BasicConstraints.cA bit set to true, 

No. This violates X.509.

> and name constraints set to restrict
> demand for the dynamically created entities.  

No. This violates X.509.

> The primary problem with this
> with little modification.  

Once again, this is where the issue lies. What would be "existing code base
with little modification" ? You could *add* some code to handle proxy
certificates. 

> Technical details aside, I also found this

The middle issue is to use existing code for public key certificates and 
*add* to it the handling of proxy certificates. Would this be infeasible ?

Denis

PS: Thank you for this very detailed and very clear summary, but next time,
try to make the e-mail shorter.