Subject: Re: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt

From: Bruce Morton <[email-masked]>
Date: Mon, 21 Oct 2013 20:06:24 +0000

Hi Stephen,

Thanks for the input. I have tried to incorporate most of your input. 

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.

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
2. Policy is certificate policy or root embedding policy or CA policy depending on which TA store you are referencing
3. Exceptions are covered in the variations section of the document
4. An RP changing the TAs would be a variation which could be covered. However, it was suggested not to discuss RPs.
5. Yes, an annual compliance audit is standard in a root store's policy. This is also covered in the CA/Browser forum policies.
6. There are several indications such as removal a the HTTPS indicator or a mark through HTTPS.
7. Issuing CA is referenced in RFC 5280.
8. Intermediate CA is referenced in RFC 5280.
9. CRL and OCSP fields will be provided.
10. By "location" we mean online location.
11. See item 2 above. Maybe this should be discussed.
12. Removed reference to requirements.
13. An example is that Chrome or Safari operating on Windows uses the Windows root store.
14. Tried to fix the long sentence.
15. This one should be discussed as well.
16. Will fix the RA certificate issue.
17. The owner's name is put in the organization field.
18. Enforcement is down by legal or technical means.
19 HTTP header

Looking forward to your further comments. Perhaps we can discuss some in Vancouver.

All the best, Bruce.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, October 16, 2013 1:36 PM
To: [email-masked]
Subject: Re: [wpkops] FW: New Version Notification for draft-barreira-trustmodel-00.txt

Attached is a PDF of the doc, with a large number of suggested edits, and some notes.

There were numerous presentation problems, especially missing or problematic definitions.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Oct 2013 16:27:23 -0400

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…
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.
> 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.
> 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.