>We have developed something what we call "PCA Certification Hierarchy
>Registration Program", which accepts the RDN of a new CA and its location
>in the hierarchy, creates the DN under the subordination rule, CHECKS
>FOR NAME DUPLICATES in local database and creates configuration file
>for the new CA.
Dr Muftic,
Which hierarchy are you referring to? I assume its an naming and/or
registration hierarchy; but is this instance specifically one
maintained by COST (with its own naming schema and architecture), or
some other?
(Its perfectly reasonable for the COST PCA domain to maintain a private
"CA Name" hierarchy for its subscribers, and harmonize this offline
with all other PCAs.)
Your program "accepts" CA immediate parent Names (listing location in
the hierarchy, I assume) and RDNs for a (new) CA as named by the actual
parent, or its closely-associated Naming Authority.
But, What Name subordination rule are you referring to? you seem to
imply that a PCA must dominate a CA in this COST hierarchy.
Lets take an example:
My CA is informally named (relatively) "US, NASA, ARC, ANA development"
where this name is a multi-valued RDN. Im happy for it (or any
components thereof) to be placed at any location in the DIT where users
might want to look for it, including under any COST PCA listings. (I
assume Ill be able to meet the low-assurnace requirements of the COST
PCA policy.)
Now, what Names shall I give to my users which are PEM conformant, and
COST conformant operationally?
Let me assume the COST PCA is named "SE, COST Enterprises Inc, COST Low
Assurance PCA"
Will the CA be named SE, COST Enterprises Inc, COST Low Assurance PCA, US +
NASA + ARC + ANA development'?
or,
Will the CA be named SE, COST Enterprises Inc, COST Low Assurance PCA, US +
NASA + ARC, ANA development'?
or,
...
If this is the case, then users will have to be named
"SE, COST Enterprises Inc, COST Low Assurance PCA, US + NASA + ARC + ANA
development, Peter Williams"
or,
"SE, COST Enterprises Inc, COST Low Assurance PCA, US + NASA + ARC, ANA
development, Peter Williams"
or,
...
to meet PEM rules.
It strikes me that the COST PCA rule of requiring its primary
organizational or residential CAs to be hierarchically named beneath the PCA is
introducing service provider elements into the naming. This requirement
goes beyond the prescriptions of PEM, though is fine for a domain's
operating policy, if its consequences are acceptable to users. ONE
CONSEQUENCE IS THAT THE CA and all subordinate CAs *MUST* INCORPORATE
THE PCA NAME INTO EVERY USER CERTIFICATE. A USER IN TWO COMPETING LOW
ASSURANCE DOMAINS MUST THEREFORE HAVE TWO CERTIFICATES. This would be a
reason for anyone to worry significantly at such a PCA policy.
Now, I would ask, does the COST PCA *mandate* that COST-authorized CA
operate using COST software, or that software *must* operate using COST
PCA configuration files?
Our CA operates (already) in multiple PCA domains, each with a separate
key pair and CA certificate; the user certificates are already issued. (i
doubt we would incur the costs of reissuing certificates)
The procedures used by subordinate CAs are private, though can be
assumed to be assured to be conformant to non-implementation specific
portions of a low-assurnace policy. To be constrained to a given
implementation would be hard on us to adopt the policy of any PCA that
required such, especially if we will be also then be required to create new
certificates in order to sign up to the new PCA.
I suppose the thing to do is to try it for one of our existing PEM
CAs. Do you have a (free) test service available?
Id would want to try it and determine any consequences on our existing
infrastructure, before handling over any money to obtain the
commercial-grade service. However, Im exited by the prospect of what
COST is doing if its service is indeed commercial and about
ready-to-go.
Great leadership.