Subject: Re: Names in Proxy Certificate

From: Steve Tuecke <[email-masked]>
Date: Tue, 04 Dec 2001 20:55:48 -0600

At 11:19 AM 12/3/2001, Housley, Russ wrote:
>All:
>
>Please excuse my previous posting with this subject.  I got interrupted 
>while composing the note, and sent it when I wanted to save it and work on 
>it some more.  I hope I have done a better job this time.
>
>In draft-ietf-pkix-proxy-01, section 6.4, the authors talk about end 
>entity names.  Mostly the specification talks about an approach that was 
>rejected.  Finally, I think that the conclusion is that the parent of the 
>proxy certificate contains the real identity information.  Please correct 
>me if I am misreading the text (attached below for simplicity).

Note that section 6.4 is the commentary section.  It is not intended to be 
the specification, but rather to help give some insight on the 
specification (e.g. what was considered but rejected).  At some point it 
may make sense to move this out to a separate informational draft, but we 
figured it was better to keep it all in one spot to begin with.

The relevant portions of the spec here are sections 3.1 and 3.2.

>If I have it right, then have a few concerns.
>
>First, in PKIX, we require that all issuers have a subject DN.  So, empty 
>DNs cannot be used in the long-term certificates if proxy certificates are 
>to be associated with them.  Further, the proxy certificate needs to 
>include a subject DN if proxy certificates are permitted to issue 
>subordinate proxy certificates.

First, let me say that we're not at all married to this particular approach 
to subjects and issuers.  What is in this draft is, in fact, different from 
what we did in the Globus Toolkit.  In writing this draft, we changed the 
approach (though not the proxy concept) to try to make it live better with 
son-of-2459.  But in going back to son-of-2459, I see I missed the relevant 
statement here in 4.1.2.4, of "The issuer field MUST contain a non-empty 
distinguished name (DN)."  I don't know how I missed this one!

The problem (and perhaps why I subconsciously ignored this issuer 
requirement :-) is that I think the current son-of-2459 language puts us 
between a rock and a hard place.  As your comment suggests, what if the End 
Entity Certificate (EEC, or what I think you are referring to as the 
long-term cert) has an empty subject field, and instead only has a 
subjectAltName?  What do we use as the issuer in proxy that is signed by 
that EEC?

Maybe the best thing to do is explain what we are trying to accomplish, 
what I observe the constraints to be, and you might be able to advise us of 
an approach that lives better with son-of-2459.

First, what are we trying to accomplish...  The point of proxies is that we 
are specifically not trying to create a new identity.  Rather, we are 
trying to define a mechanism by which a proxy can be created that is 
associated back only to the subject or subjectAltName of the EEC that is at 
the top of the proxy signing chain.  In essence, we want to bind a new key 
pair back to the subject of the EEC, so that the holder of the new private 
key can make a verifiable claim on the EEC subject name.

What is the nature of that claim?  That's really up to the authorizing 
party.  Having authenticated with a party that is using a proxy 
certificate, and verified its path up through the proxy chain, EEC, and CA, 
I know that this party has a valid proxy that was issued by an EEC with a 
particular subject name.  In practice, the way that we use this is as a way 
to delegate authorization rights.  That is, if I have authenticated a proxy 
that is tied to an EEC with a subject of "Steve", then I apply whatever 
authorization that I would normally apply to "Steve".

And this is where the proxyRestriction field (3.6.1.3) comes into 
play.  What the holder of an EEC typically wants to do is issue a proxy 
that implies a subset of the rights normally associated with that EEC 
subject.  So when such a proxy is presented to me, I would apply the 
intersection of whatever authorization rights I would normally grant to 
"Steve", with those that are defined in the proxyRestriction field of all 
proxies in the signing path.

In the current Globus Toolkit code, the way we handle subject and issuers 
is that we require that the EEC subject be a DN, and then we extend that DN 
with a "/CN=proxy" attribute in each proxy certificate.  Then in the path 
validation we check that the proxy subject is the same as the issuer, 
except for an extra "/CN=proxy" attribute.

So now what are the issues and constraints in making this play nicely with 
son-of-2459:

   * What do we do if the EEC does not have a subject, but instead only has 
a subjectAltName?  Obviously, the approach that we used in the Globus 
Toolkit doesn't work in this case.  And it doesn't seem particularly 
satisfying to say that you can only create a proxy certificate from an EEC 
that has a subject DN.

   * One of the uses of the subject is for path discovery.  So whatever 
approach we choose needs to address this.  What we did in this draft is 
give the proxy subjectAltName a (statistically) unique name, so that the 
path can be discovered from these names.  Another option would be to use 
(or invent) a different field for path discovery, such as 
SubjectKeyIdentifier and AuthorityKeyIdentifier.

   * If we choose a different field for path discovery, this obviously 
liberates us some with respect to the subject and issuer.  Nonetheless, 
requiring a non-empty issuer still seems like a problem.  But ignoring that 
for the moment, what would we want for the subject or 
subjectAltName?  Would it just be a duplicate of the EEC's?  Are there any 
issues with have multiple certificates with the same subject, even though 
the proxies are clearly marked as such with a critical extensions?

   * We must be very careful to not allow proxies to carry, or somehow 
imply, the subject of some other EEC than the one at the top of the proxy 
signing chain.  It seems we have basically 2 choices.  Either make the 
subject (or subjectAltName) meaningless and ignore it.  Or give it meaning 
(e.g. carry along the EEC subject) and check it in the path validation code 
so that some other subject cannot be substituted.  We went with the former 
(modulo path discovery), in the interest of avoiding yet another thing that 
needs to be checked in the path validation code.  But I'd also be 
comfortable with the latter.

Anyway, I'm eager to hear if you have any suggestions for alternative 
approaches.

>Second, in PKIX, we allow attribute certificates to be associated with 
>subject DN or issuer/serial.  Wouldn't it be useful for authorizations in 
>attribute certificates issued against the long-term certificate to apply 
>to the proxy certificates as well?  This seems possible if the attribute 
>certificate uses the subject DN and the proxy certificates also contain 
>this same DN.

Yes, I can certainly imagine this being useful.

Perhaps this is motivation for changing the approach to proxy subject 
names.  For example, we might consider carrying the EEC subject in the 
proxy unchanged, check it in the path validation to make sure it identical, 
and use the KeyIdentifiers for path discovery.  But there is still the 
question of what goes in the issuer field.

But an interesting question with the combination of attribute certs and 
proxy certs is what constraints might you want to put on this?  Do you want 
to be able to associate attribute certs with just EEC's, but not their 
proxies.  Or just with proxies?  Or just with a particular proxy?  Or a set 
of proxies signed by a particular proxy?   Or some other set of proxies?  I 
can imagine arguments for all of these.  This would clearly be an 
interesting avenue to pursue.

-Steve

>Russ
>
>
>
>TEXT FROM THE DRAFT ...
>
>6.4 Carrying Along the End Entity Subject
>
>    Another suggestion was to include the subject of the signing EEC as
>    an informational field in the PC.  This would allow an authorizing
>    process to use only information in the final PC in the chain to
>    determine identity, and not need to walk the chain in order to find
>    out the subject (or subjectAltName) of the EEC that the PC is
>    derived from.
>
>    This approach was rejected for the following reasons:
>
>    *  It would be easy to spoof this informational field.  For example,
>       a PC with an informational subject of "Steve" could be used to
>       create a PC with an informational subject set to "Doug".  This
>       leaves us with two alternatives:
>
>       * We can augment the path validation to check that this
>         informational field of the PC is the same as in the signing PC
>         or EEC.  But this is not desirable, as it complicates the path
>         validation.
>
>       * But if we do not validate this field, we cannot trust the
>         contents of this informational field.  So then there is no
>         point in including this informational field.
>
>    *  Upon closer examination, there is a lot of information in the
>       certificate chain that may be needed during authorization, such
>       as the number of levels of delegation, the CA (or multiple levels
>       of CAs) who signed the original EEC, the constraints and keyUsage
>       values of the signing EEC, possibly Certificate Policies
>       associated with CAs or IAs.  All of these require essentially the
>       same amount of work as retrieving the subject of the EEC that
>       signed the PC.  So why threat the EEC subject specially by
>       including it in an information field?
>
>    In the end, just including the EEC subject name does not seem to be
>    sufficiently useful to justify the addition of another field and the
>    work of verifying that name during the path validation.
>
>    Therefore, to determine the identity of a PC for authorization
>    purposes, the subject of the EEC must be retrieved directly from the
>    EEC in the signing chain.  This approach also has the beneficial
>    side effect of further stressing that a Proxy Certificate has no
>    identity of its own, but rather inherits it from its signing EEC.

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 10 Dec 2001 11:46:10 -0500

Steve Tuecke:

>>proxy certificate contains the real identity information.
>

Section 6.4 was the place that these problems jumped out at me.  I will 
take a look at these sections in the future.

>>DNs cannot be used in the long-term certificates if proxy certificates 
>>are to be associated with them.  Further, the proxy certificate needs to 
>First, let me say that we're not at all married to this particular 
>approach to subjects and issuers.  What is in this draft is, in fact, 
>different from what we did in the Globus Toolkit.  In writing this draft, 
>we changed the approach (though not the proxy concept) to try to make it 
>live better with son-of-2459.  But in going back to son-of-2459, I see I 
>missed the relevant statement here in 4.1.2.4, of "The issuer field MUST 
>contain a non-empty distinguished name (DN)."  I don't know how I missed 
>this one!

This is a very important requirement.  It is in RFC 2459; it is not new in 
Son-of-2459.  If you want all of the discussion, you will have to review 
the mail list archive.  Off the top of my head, I recall two major 
points.  First, CRL entries are identified by issuer DN and serial 
number.  Second, S/MIME v2 identifies the recipient public key only with 
issuer DN and serial number.  S/MIME v3 continues to supports this method 
as well as the subject public key identifiers.

>between a rock and a hard place.  As your comment suggests, what if the 
>End Entity Certificate (EEC, or what I think you are referring to as the 

Yes, I see the end entity certificate as long-lived, and the proxy 
certificate as short-lived.

>what I observe the constraints to be, and you might be able to advise us 
>of an approach that lives better with son-of-2459.
>
>First, what are we trying to accomplish...  The point of proxies is that 
>we are specifically not trying to create a new identity.  Rather, we are 
>associated back only to the subject or subjectAltName of the EEC that is 
>at the top of the proxy signing chain.  In essence, we want to bind a new 
>key pair back to the subject of the EEC, so that the holder of the new 
>private key can make a verifiable claim on the EEC subject name.
>
>certificate, and verified its path up through the proxy chain, EEC, and 
>CA, I know that this party has a valid proxy that was issued by an EEC 
>with a particular subject name.  In practice, the way that we use this is 
>as a way to delegate authorization rights.  That is, if I have 
>authenticated a proxy that is tied to an EEC with a subject of "Steve", 
>then I apply whatever authorization that I would normally apply to "Steve".
>
>is that we require that the EEC subject be a DN, and then we extend that 
>DN with a "/CN=proxy" attribute in each proxy certificate.  Then in the 
>path validation we check that the proxy subject is the same as the issuer, 

In PEM (see RFC 1114 and RFC 1422), similar name subordination rules were 
specified.  Such rules were defined because version 1 certificates were 
employed.  Version 3 extensions allow much better answers (i.e., name 
constraints extensions).  I suggest that you avoid name-oriented conventions.

>   * What do we do if the EEC does not have a subject, but instead only 
> has a subjectAltName?  Obviously, the approach that we used in the Globus 
> satisfying to say that you can only create a proxy certificate from an 
> EEC that has a subject DN.

Some implementations use names to construct paths.  Others use public keys 
(or identifiers of them).  So, if you want all currently fielded software 
to be able to construct a certification path from the proxy certificate 
(PC) to the trust anchor, then you should mandate the subject DN.  On the 
other hand, if you want such software to only construct the certification 
path from the end entity certificate (EEC), then you have more design 
freedom; however, your applications will have to include their own software 
to validate the PCs.

> SubjectKeyIdentifier and AuthorityKeyIdentifier.

As I said above, there is fielded software that works with both 
approaches.  I would prefer both approaches to be supported by the 
specification.

> requiring a non-empty issuer still seems like a problem.  But ignoring 
> that for the moment, what would we want for the subject or 
> subjectAltName?  Would it just be a duplicate of the EEC's?  Are there 
> any issues with have multiple certificates with the same subject, even 
> though the proxies are clearly marked as such with a critical extensions?

Self-signed certificates are part of the architecture in several 
places.  So far, I do not see any reason to invent a new concept.

I think that the PC should contain the identity.  Looking up the chain for 
the first non-PC seems like work that can easily be avoided.  Further, I 
think that you would want to minimize any special processing.  In other 
words, the processing of a PC and an EEC should be kept as similar as possible.

> subject (or subjectAltName) meaningless and ignore it.  Or give it 
> meaning (e.g. carry along the EEC subject) and check it in the path 
> validation code so that some other subject cannot be substituted.  We 
> went with the former (modulo path discovery), in the interest of avoiding 
> yet another thing that needs to be checked in the path validation 
> code.  But I'd also be comfortable with the latter.

Again, I recommend the inclusion of the EEC names in the PC.

>Anyway, I'm eager to hear if you have any suggestions for alternative 

If you are going to be at the IETF in Salt Lake City, we can discuss these 
issues further.

>proxy unchanged, check it in the path validation to make sure it 
>identical, and use the KeyIdentifiers for path discovery.  But there is 
>still the question of what goes in the issuer field.

If you require the EEC to contain a subject DN, then this gets pretty simple.

>proxy certs is what constraints might you want to put on this?  Do you 
>want to be able to associate attribute certs with just EEC's, but not 
>their proxies.  Or just with proxies?  Or just with a particular 
>proxy?  Or a set of proxies signed by a particular proxy?   Or some other 
>set of proxies?  I can imagine arguments for all of these.  This would 
>clearly be an interesting avenue to pursue.

If the Attribute Authority (AA) wants to associate a set of attributes with 
the EEC, or with a particular PC, then the AA can issue the Attribute 
Certificate (AC) with the holder set to the appropriate issuer DN/serial 
number pair.  If the AA wants to associate a set of attributes with the 
identity, then the AA can issue the AC with the holder set to the subject DN.

Russ