pem-dev
[Top] [All Lists]

Re: Two certificate hierarchy questions

1992-04-09 15:20:00
Matt,

Sorry to take so long in replying; too much travel.  I'm copying this
to pem-dev because the issue may be of interest to the whole group
and because it represents an open item forestalling closure on the spec.

   A question about the ICA/PCA/CA model.  Maybe I didn't read
RFC1114E closely enough, but I didn't see any requirement that the
subject be subordinate to the CA -- only that the subject's DN be
subordinate.  So, why could a PCA not charter an "open
organizations" CA which would issue certificates for subjects
affiliated with other organizations, after verifying the
affiliation?  (Such a statement would have to go into the PCA's
policy, of course.)

   Here's an example.  Let's say a PCA has chartered such a CA;
call it "Certificates R Us" (to follow in Steve K's tradition), so
its DN would be /C=US/O="Certificates R US"/.  Dartmouth contacts
them and says that Matt Bishop needs a certificate with the DN
showing affiliation to Dartmouth.  The CA issues me a certificate
with my DN set to /C="US"/O="Certificates R US"/OU="Dartmouth
College"/CN="Matt Bishop"/.  If President Freeman wanted one, the
CA would give him the DN /C="US"/O="Certificates R
US"/OU="Dartmouth College"/CN="James O. Freeman"/ In both cases,
our DNs are subordinate the Dartmouth's which is subordinate to the
issuing CA.  (Of course, if Dartmouth wanted to become a CA not
subordinate to the "Certificates R US" one, we'd all need new
certificates.)

   I couldn't find anything in 1114E that prevents this.  In fact
the persona policy does something very much like this, the only
difference being the subject deals directly with the persona CA,
and no validation of organizational affiliation is required.  So I
don't see why this would not work.  Incidentally, if you are right
that this can't be done, I'd agree: it's way too restrictive.  But
I think it can be done under the current framework.

Matt

There are some aspects of your example that admit alternate possibilities.

1. You have

    /C=US
     /O="Certificates R US"
      /OU="Dartmouth College"
       /CN="Matt Bishop"

   This suggests Dartmouth College is an organizational unit of
   Certificates R US.  I did advocate something like this for my IRS
   example, but I don't think Dartmouth would be comfortable with
   this.  For the residential-certificate-with-a-professional-
   address, I had in mind something like

        /C=US
         /O="Certificates R US"
          /CN="Matt Bishop"
           /postalAddress="Dartmouth College
                           street address
                           city, state zip"

   Thus, "Dartmouth College" appears as his address, but not as
   subordinate unit of Certificates R US.


2. You said "Dartmouth contacts them and says that Matt Bishop needs a
   certificate with the DN showing affiliation to Dartmouth."

   I think once Dartmouth gets into the loop as an institution, it's
   effectively playing the role of a CA.  More on this in the next
   item.  My concern is whether Certificates R US will be permitted to
   issue a certificate like the one above if Matt Bishop provides
   adequate representation that he is who he says he is without
   requiring that Dartmouth College make the request.


3. It might be desirable to offer a service for new or small
   institutions in which all of the administration of the certificate
   process is done by a commercial firm, e.g. Certificates R US.  In
   this capacity, Certificates R US would be operating as a proxy for
   Dartmouth.  It's a bit unclear whether Certificates R US would be
   acting as a PCA or a surrogate CA.  I think if Dartmouth obtains a
   certificate from a PCA, it can contract out to Certificates R US if
   it wants to.  In that case, Certificates R US acts as a surrogate
   CA.  However, if Dartmouth gets its primary certificate from
   Certificates R US, then Certificates R US is really a PCA.


Steve

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Two certificate hierarchy questions, Stephen D Crocker <=