Steve,
Thanks for your comments on the X9F1 trust model. Some further updates:
Regarding the centralized v. decentralized model, X.509 does indeed allow
both approaches (although the example uses the decentralized model). We
certainly don't intend to preclude the PEM approach, and in fact will add
text discussing it. It is certainly useful in some scenarios, e.g. a bank
issuing certificates to its employees. I see four basic types of domains
in which the standard will be used:
1. A small group of banks, each of which is certified by a single CA (the
degenerate case of a single-level hierarchy).
2. Users within a single bank, in which the PEM model is applicable.
3. A retail (e.g. bankcard) environment in which an organization issues
certificates to its customers. One could visualize a Visa hierarchy
in which member banks certify their customers and there is a shallow
(likely regional) hierarchy on top of this. This would be one case
where the "least common ancestor" model *might* be used.
4. Tying all of these domains together. How/whether this would be done,
and what the proper model is, is an open issue.
In all cases, I think the naming constraints are a critical part of the
certificate validation process.
Regarding our X.509 "extensions", the extension is, as you suggest, a
separate signed structure, for all of the reasons you cite (based on a
conversation on PEM-DEV a few years ago, as a matter of fact). The motivation
originally was to be able to leverage off existing CA applications for
creating public key certificates, particularly since not all environments
will require the extended certificates. Also, separation of duties might
suggest a different CA(s) sign the authorization certificate. The difference
with ECMA PACs is that the lifetime of our "authorization certificates" is of
the same order as that of the public key certificate rather than a single
"association".
I agree the use of multiple signaturess is more useful for messages than
for certificates. The initial suggestion (prior to my joining the working
group) suggested the requirement for multiple signatures on certificates
used in "high risk" applications, i.e. to sign high value wire transfers.
(These certificates also contained a number of auxiliary fields which were
moved to our "authorization certificate".) There is a substantial amount of
text in the latest draft addressing multiple signatures on actual messages.
I think an authorization certificate which contained the monetary limit on
transactions you could sign might be subject to the multiple signature
requirement (maybe requiring as many issuers as a transaction does signers,
and requiring at least one of those issuers to have a limit greater than or
equal to the one you are given). In the absence of these authorization
certificates, I suppose one could apply this to the public key certificates,
but this seems to move the responsibility for determining the number of
signatures required, out to the application code. For myself, I favor making
everything explicitly visible in authorization certificates, but I only have
one vote...
The standard is a year or so away from being released, so no doubt we will
rehash these issues several times. My goal is to lay out the models in the
draft, along with suggested uses, strengths, and weaknesses. It may well be
the case that other X9F committees are responsible for selecting the
appropriate model used for each application.
If you have no objection, pem-dev does seem to be one suitable forum (which
I can access) to float some of these ideas for outside review.
Regards,
Rich