Subject: Names in Proxy Certificate

From: "Housley, Russ" <[email-masked]>
Date: Mon, 03 Dec 2001 12:19:00 -0500

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).

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.

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.

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: "Markus Lorch" <[email-masked]>
Date: Wed, 5 Dec 2001 08:51:04 -0500

Steve,

the application of attribute certificates to the GSI and to proxy
certificates is work we are currently looking into here at Virginia
Tech in the context of a collaborative high-level grid interface.
Russ Housley had pointed out the question to what certificate
our attribute certs should be bound if proxy certs are used in a recent
meeting at VT. See comments on our intended usage at end of your quote:

>>attribute certificates issued against the long-term certificate to apply
>>to the proxy certificates as well?  This seems possible if the attribute

>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.

Our plan is to use proxy certs for authentication and granting of a basic
set of user rights and then use attribute certs to grant additional rights,
e.g.
for group collaboration and role support. Collaboration support is the main
concern.
We envision users (end entities) to issue to each other ACs that convey
access rights
to files, program components, devices etc.

Right now we believe a viable approach might be to bind the ACs to the DN or
the
issuer/serial combination of the EEC. The path validation of a PC would
give us this information. We did not think of having ACs for proxies that
differ
from the set of ACs associated with the delegating EEC. However, this might
be
an interesting case to consider. If we use ACs also for proxies, a subset of
an
entities rights can be created through a new, more restricted PCs together
with
a set of attributes associated with this PC. This would allow for finer
grained
control over which PCs can actually be used with which ACs. In turn this
would
require that a process delegating a PC can also delegate ACs which appears
to make
this system more complex than originally envisioned.
A resource would have to do a path validation on the PC as well as an
independent
path validation on an AC. Also as PCs are rather short lived it may lead to
a number of problems when the PC expires. Right now the PC draft proposes to
use
random subject names, thus we could not bind such ACs to the subject of the
PC
but only to the serial and thus bind it to the lifetime of the PC.

Markus

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Markus Lorch
Graduate Student in Computer Science
Virginia Tech
http://csgrad.cs.vt.edu/~mlorch