I just wanted to say that the approach to the Trust Model document was to show 
how the actions of the browser and the CA provide trust between the subscriber 
and the relying party. A basic model was shown and then some variants. The 
reason was to show the reality out there that may help people understand the 
realities and develop better policies. For instance, many people did not 
understand the issues of a CA issuing a CA certificate.  This was not discussed 
in browser policies and not referenced in WebTrust 1.0. However, when DigiNotar 
and Digicert Malaysia were blacklisted, this reality had to be accounted for.



Some general comments on this approach would be useful.



I have also provided some responses to Paul's comments below.



Thanks, Bruce.



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of 
Paul Hoffman
Sent: Monday, June 24, 2013 6:56 PM
To: Sharon Boeyen
Cc: wpkops WG ([email protected])
Subject: Re: [wpkops] Silence is deafening - Trust Model Paper



The model in draft draft-webpki-trustmodel does not match the charter for this 
WG. It over-reaches by talking about "certificate-using clients" that are not 
web browsers.

[Bruce Morton] Sorry if this is outside the charter. We might want to consider 
opening up the charter just a little bit as the relying parties might be using 
something other than a browser. This might be opening up more and more in the 
mobile world.



Even if the document is more narrowly scoped to meet the charter, it still has 
many problems. It blithely assumes that all CAs follow their certificate 
policies (which we have seen is not true), and states that such certificate 
polices are "accepted" by client suppliers, which is only true if "accepted" 
means "without any real checking, and generally without any punishment after 
lapses are found".

[Bruce Morton]  I think the CAs would concur that a CP and/or CPS is developed 
based on the requirements from the OS/browser developers. Most CAs have a 
policy authority to define policy. They may have internal auditors to ensure 
they are meeting policy and they are annually audited to show compliance to 
their policies. There are cases where a CA does not meet their policy. There 
are also cases where the policy is incorrect. In general all CAs endeavor to 
meet their policies and put corrective action in place where a mistake has been 
made.



The draft also says that "the relying party implicitly accepts" the root store 
without discussing what this implicit acceptance means. There is no discussion 
of what user expectations might be (such as surprise that governments can cause 
certificates issued for sites of enemy governments).

[Bruce Morton] I agree that Relying Party is an issue which is why the word 
implicit is used. In reality, the Relying Party uses a browser and may respond 
to a trust dialogue if it appears.



The WG should consider instead requiring the draft apply to the real-world Web 
PKI where browsers makers do not hold CAs accountable when lapses are found and 
users do not understand anything about the role of the root store.

[Bruce Morton] We have seen that OS/browsers do hold CAs accountable. In the 
past we have seen that DigiNotar and Digicert Malaysia CA certificates have 
been blacklisted. The browsers also take other actions is counteract the 
actions of the CAs. Microsoft has rejected all certificates with keys less than 
1024-bit RSA. Chrome uses CRLsets rather than the full CRL issued by the CA. CA 
certificates with MD2/MD5 signatures have been untrusted. I also expect to see 
CAs with 1024-bit RSA keys to be untrusted in some browsers in the next year.



In other words, the WG should consider a much more realistic draft. Otherwise, 
a reader might think that the WG's eventual RFC describes something 
operationally useful.



--Paul Hoffman

_______________________________________________

wpkops mailing list

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/wpkops
_______________________________________________
wpkops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/wpkops

Reply via email to