Names in Proxy Certificate

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

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.