Dear Peter:
Here is an ATTEMPT to answer/clarify your questions, keeping in mind
that our first, fully operational PEM/CMS (Certificate Management System)
is (hopefully) (a) PEM RFC compliant and (b) open for suggestions and
improvements.
Which hierarchy are you referring to?
COST Low Level Assurance
I assume its an naming and/or
registration hierarchy; ---> YES + CERTIFICATION HIERARCHY
but is this instance specifically one
maintained by COST (with its own naming schema and architecture), or
some other?
YES, maintained by COST, i.e. all CAs in the hierarchy must be
named and registered by COST PCA (and therefore "known" to COST PCA).
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.
Our procedure is the following: We have the Registration Form with
(selected) X.520 attributes. A customer (company, department) decides
on its RDN (for one CA), fills the form, sends to us. The company may
of course register several CAs in any particular structure of
a sub-hierarchy. With "locations" of all CAs in the hierarchy,
we combine the RDN of each CA with RDNs of CAs above up to the top
BUT NOT INCLUDING OUR PCA RDN and in such a way we establish the DN
of that CA.
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,
...
Your CA will have the same DN as your RDN, as it is immediately
under COST PCA, so COST PCA DN ---> WILL NOT BE A PART OF YOUR CA'S DN !
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.
NO: Users will be named their RDNs + DN of your CA --- O N L Y !
W E H O P E T H A T T H I S I S H O W R F C 1422 REQUIRES !
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.
I HOPE THAT FROM MY PREVIOUS EXPLANATION YOU SEE THAT THIS IS NOT THE CASE.
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?
In the current version our PCA supports only our (SW+DB) CAs.
The reason is that we have extended (in the engineering sence, not
concept !) some features, not specified in teh RFC1422, which were
needed fro smooth and user-frinedly functioning of our CMS.
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)
How do you provide/guarantee the uniqueness of DNs ? Does your CA
has two separate DNs under each PCA or ...
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.
Very interesting idea, indeed, I mean our PCA to support CAs developed
by other implementors. We are very open to this idea. However, we see in
this moment two preoblems:
a.) functionality, as I said that our CAs are much more functional
than "classical" RFC1422 CAs
b.) compliance to our security policy.
But, I would hope that tuning a.) would also solve b.) The bst would
be for you (if you are coming to San Diego where we have the paper
on all these issues) to have a cup of coffee with Nada and Alan and
discuss further details of this cooperation.
Great leadership.
Just humble research, development and market requirements !!!
Regards,
Sead Muftic