Re: [IETF-PKIX] Definition of terms

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

David,

You said:

b) Whatever words are chosen, I object to the fact that community
   underlined 1)-- in your definition is the same as community 2)--.
   I believe that cross-certification should *never* be a transitive
   process: if MISSI wants to verify users under Entrust and VeriSign,
   MISSI MUST issue cross-certs to both.  If MISSI issues a cross-cert
   to VeriSign, and VeriSign issues one to Entrust, that should never
   be a sufficient condition for dave@MISSI to be able to validate
   a signature from tim@Entrust.

   Communities 2) and 3) should be use one word (subscriber/subject/...),
   and community 1) should be the other word (relying party/...).

I believe that I would agree with you with respect to the
cross-certification of what are effectively top-level CAs (PCAs in the old
PEM vernacular).

But do you mean to specifically prohibit the inclusion of subordinate CAs
under a PCA as a result of a cross-certification?

In other words, if VeriSign has issued a Class 3 certificate to XYZ Corp.,
and MISSI cross-certifies the VeriSign Class 3 issuing CA, you would not
want a MISSI subscriber/subject/user/relying party to be able to accept an
XYZ cert?

Now take the case of a certificate issued by the USPS to the Smithsonian
Institution.  Assuming MISSI cross-certifies USPS, shouldn't the MISSI
community accept the Smithsonian's certificates?

If the State of Utah certifies MISSI as a licensed CA under Utah law, are
you saying that no one should trust an subordinate CAs under MISSI, unless
Utah checks out each and every one of them, and cross-certifies them
individually?

I think we are going to have a huge problem of scalability with this
approach, especially when we start to extend electronic commerce
internationally.

I believe that the way to solve the problem of uncontrolled extension of
transitive trust you are rightly concerned about is with legal agreements
between the primary CA's that are cross-certifying , to include a
requirement for flow-down provisions that would affect any subordinate CAs
that were so certified. This would be enforced technically by the use of
policy OID constraints, and if necessary controls over how deep the chain
can get.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.,
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com