DN subordination

Apologize for the last message, my fingers are faster than my brain.

The message should go like this...

<<Steve Kent wrote:>>
   I'm puzzled by your statement about a problem with residential
   PCAs and CAs with regard to name subordination.  I had hoped that one
   of the many note I sent a week ago, when I finallly crawled out of my
   mail hole, had clarified how residential PCAs were supposed to work.
   The "trick" is for a residential PCA to establish placeholder CAs for
   appropriate geographical CAs, e.g., states under C=US.  That way the
   name subordination rule still applies since users can be registered
   under a CA with an appropriate name.  I reproduced the Paul Revere
   example from 1422 to illustrate this point.  Is there a residual
   problem?

Allow me to illuminate the source of Ray's confusion.  Ray inquired
(earlier this year) about the certification services that RSADSI is
actively providing in support of the Apple AOCE offering.  There is a
"root" certifier known as C=US, O="RSA Data Security, Inc.",
OU=Commercial Certification Authority.  Under this there are a number
of commercial certifiers with organizational names.  Under the policy
of the hierarchy, all such organizational CAs are required to follow
subordinance rules when they certify affiliates.  Under this root
there is also a certifier known as the Unaffiliated User Certification
Authority (or UUCA).  The UUCA DN is C=US, O="RSA Data Security,
Inc.", OU=Unaffiliated User Certification Authority".  The UUCA will
certify users with residential DNs (i.e. no Org attribute) thereby
breaking the subordinate rules.  The explanation follows:

<<<Ray wrote:>>>
   There's something funky about the UUCA in that it doesn't fit strictly under
   the Internet PEM hierarchy (assuming the high assurance Commercial CA
   will be a PCA) since it issues certificates to subjects not related to
   it DN wise.

<<<My response>>>
    That's correct.  In the last days before the PEM standards became
    final I lobbied hard to remove this restriction or make it a policy
    decision.  Our decision to break this rule may have some far reaching
    consequences, however, we feel that it was the right decision given
    the alternatives.  For the record (I'm sure we will get asked this
    again) I will justify our decision.  In order to adhere to the
    subordinance rule for residential or unaffiliated users, we would have
    had to follow one of these models:

    Plan A:

    Assume one of the following issuer names:

    C=US

    -or-

    C=US
    S=California

    -or-

    C=US
    S=California
    L=Belmont

    in order to have the subordinance rule work for a name like:

    C=US
    S=California
    L=Belmont
    CN=Steve Dusse

    One of the most important requirements in our hierarchy is that each
    CA shall show proof of the "right to use" their DN.  Well, C=US is
    already taken (by ANSI).  Since we couldn't secure such right from
    each of the states and localities (much less even educate them about
    the concept) we ruled this out.

    Plan B:

    Assume an issuer name like:

    C=US
    O=RSA Data Security, Inc.
    OU=Unaffiliated User Certification Authority

    and sign up subordinates like:

    C=US
    O=RSA Data Security, Inc.
    OU=Unaffiliated User Certification Authority
    S=California
    L=Belmont
    CN=Steve Dusse

    This works with the "right-to-use" rule as well as the subordinate
    rule.  Unfortunately it breaks the aesthetics rule, looks like an
    affiliated certificate (everyone works for RSA) and also makes every
    residential user DN look like an advertisement for RSA Data Security
    (this works for me but not for our AOCE friends).

    So we decided to break the subordinate rule.  Strictly speaking, PEM
    compliant implementations have every right to complain.  This will be
    very carefully documented in our COmmercial CA policy statement and
    has, in fact, been a major reason for our reluctance to even publish
    this statement.
    
    I hope this answers your questions.  I apologize for the slow response
    on the Commercial CA key and DN, we have been waiting to get the key
    holders together to issue the self-signed cert, it sounds like you
    already have the info you need.

I hope this clears up the confusion.  For the reasons stated, I
believe that the goals and the market for the RSA Commercial Hierarchy
are not in line with the PEM subordination requirements, hence either
the PEM specs or the RSA CH is broken.

Cheers,
Steve Dusse