Subject: Names in Proxy Certificate

From: "Housley, Russ" <[email-masked]>
Date: Fri, 30 Nov 2001 09:50:45 -0500

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.