Bruce,
The biggest issue is that of removing root (root certificate, root CA, root
store) with trust anchor. The issue is that in the Web PKI, we use root. The
policies from the embedding vendors use root and the CA/Browser Forum
requirements use root. Root seems to be a common term in the Web PKI and we
thought that using trust anchor would confuse things. On the other hand, we do
agree that the roots are trust anchors and there can be other trust anchors
that are not roots such as a private CA certificate. Perhaps this would be a
good discussion item.
I know that the term "root" or "root CA" is widely used. It is also not
consistently used,
as an analysis of your text showed. So, we do need a way to reconcile
the the root vs. TA
terminology issue in a fashion that is consistent with 5280 and 5419.
The other issue is that in some cases there are definitions that were not
stipulated. We had decided to minimize the definitions and use the terms as
they are used in RFC 5280. If the term was not used in RFC 5280, then a
definition would be provided with hopefully another RFC referenced. For trust
anchor, we have referenced RFC 5419 per your recommendation.
Here are some responses to your comments per the numbers in your pdf:
1. Issuing CA is referenced in RFC 5280
Although the term "issuing CA" is used in 5280, it is not used in a way
that is
consistent with your use. In 5280 the term is used to refer to the CA
that issued a specific
cert. Every CA in the web browser model issues certs. I think the
distinction you are making is
whether a CA issues cert to _customers_. That needs to be specified in
your terminology section.
2. Policy is certificate policy or root embedding policy or CA policy depending
on which TA store you are referencing
please say that explicitly.
3. Exceptions are covered in the variations section of the document
please include forward pointers.
4. An RP changing the TAs would be a variation which could be covered. However,
it was suggested not to discuss RPs.
I thought the goal is to describe the trust model embedded in browsers.
if so, then if a user can
delete a TA/root, that belongs in the doc.
5. Yes, an annual compliance audit is standard in a root store's policy. This
is also covered in the CA/Browser forum policies.
then please reference the relevant doc from the CABF.
6. There are several indications such as removal a the HTTPS indicator or a
mark through HTTPS.
please make that explicit, even if only by examples.
7. Issuing CA is referenced in RFC 5280.
see my comment above.
8. Intermediate CA is referenced in RFC 5280.
yes, but it's use does not seem to align exactly with yours. Every CA
between an EE cert and a TA is an intermediate
cert. is that precisely the way you use this term?
9. CRL and OCSP fields will be provided.
good.
10. By "location" we mean online location.
please be explicit.
11. See item 2 above. Maybe this should be discussed.
yes.
12. Removed reference to requirements.
OK.
13. An example is that Chrome or Safari operating on Windows uses the Windows
root store.
As an Apple guy who usually uses Safari, this is not obvious.
14. Tried to fix the long sentence.
great.
15. This one should be discussed as well.
16. Will fix the RA certificate issue.
good.
17. The owner's name is put in the organization field.
there is no org "field" in a cert. there is an org attribute in the
Subject field.
18. Enforcement is down by legal or technical means.
there's a big difference between the two "means" ...
Steve
p.s. see you in YVR.
_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops
