Bruce, Iñigo and Karen,
I recently reviewed your internet draft on Trust Model. I agree with some
who have commented about the section on security considerations -- it seems
it may open a Pandoras Box of issues, considerations, etc. to be considered
and discussedbooks could be written if they havent already.
I dont know how best to scope or organize all of the content in the
security considerations area. I certainly wouldnt want to present the
trust model in 3-4 pages and then discuss all of the issues in another
300-400 pages.
Here are some additional suggestions:
Definition of Root store I think it should say, a set of root
certificates embedded in a certificate-using client that anchors the
certificate chains of end entity certificates. (This definition cold go on
to explain this further, but Im assuming that taking the minimalist
approach in the definitions is better because it raises less room for debate
about whether a particular implementation falls within the definition.)
I would replace this sentence with two sentences - The root store provider
determines how trustworthiness will be established and provides a trust
indication through its certificate-using client to the relying parties.
Suggested: The root store provider sets requirements for inclusion of
root certificates in the root store and manages trust indications (i.e.
client behavior) for various certificate-related system behaviors and
environmental conditions. These are communicated through its
certificate-using client to relying parties.
By mentioning trust indicators, client behavior, etc. for system behavior
and environmental conditions we are providing context that leads into the
work of the others in this working group who will discuss these topics.
In the section discussing hierarchy, here is a sample diagram to help (I
hope these pipes come through OK):
+---------+
+ -----------| Root CA |---------+
| +---------+ |
+-----------------+ |
| Intermediate CA |-----+ |
+-----------------+ | |
| | |
v v v
+---------+ +---------+ +---------+
| Issuing | | Issuing | | Issuing |
+--| CA |-+ | CA |---+ | CA |------+
| +---------+ | +---------+ | +---------+ |
| | | | | | |
|
v v v v v v v
v
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
Finally, in section 3.2, I think it helps to explain how each model is
different than the preceding one.
So, in 3.2.2, it would say " Unlike the situation in section 3.2.1, the
subordinate issuing CA is not recognized independently by any direct
relationship with the root store provider."
In 3.2.3 you might say, "Unlike the situation presented in section 3.2.2,
the third party registration authority is not identified in a CA certificate
as an issuing CA."
And in 3.2.6, you might say, "This is also sometimes referred to as an
enterprise subordinate CA, however the difference between this arrangement
and that described in section 3.2.5 is that the entity operating the root CA
has immediate operational control of the CA and physical possession of the
CA private key."
Cheers,
Ben
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops
