To cut Bruce ein bißchen of slack :) he's writing about the trust model, not an observation of all the wonderful and glorious ways PKI has failed. Models don't necessarily reflect reality, so I don't think this paper needs to document how elements have failed to meet the model /as part of the model/. It just needs to extract from current operation where trust relationships exist.
So I agree with Paul, mostly: the trust model paper should talk about browsers explicitly and solely, and how they store and use certificates for SSL specifically. It should describe the CA and its CP/CPS, how the auditor is supposed to use it, how the browser-vendor/trust-store-manager is supposed to use it. It should probably leave the browser-operator out of the trust model, because the indications presented to the browser-operator are disconnected from certificate processing. The paper should not go halves, trying to put what's out there in the context of traditional concepts of PKI. Anticipating a comment, I use "is supposed to" rather than "should". Since we're describing a model, that's appropriate. If you're going to "work to improve the consistency of web security behavior", then you've got to have a target. Substitute "could effectively" if you prefer. I also think the paper could describe the ways the model doesn't support security or inspire trust. Browser-vendors do vet CAs for entry into trust-stores, and do react to catastrophic failures, but don't have an on-going role in CA accountability. Auditors do inspect CA operations, but serve a guidance role, are in the employ of the CA itself, and the audit report is private. These things are inherent to the model, and are problems. The gaps created by PKI elements not supporting or actually subverting trust by violating the model don't really belong in the paper unless the paper increases in scope. I think those issues would still fit within the charter, but go beyond describing a model. On Mon, Jun 24, 2013 at 11:56 PM, Paul Hoffman <[email protected]>wrote: > On Jun 24, 2013, at 7:09 PM, Bruce Morton <[email protected]> > wrote: > > > 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. > > Stopping our work and revisiting the charter discussion is certainly a > possibility. It seems like a bad idea to me, but others might like it. > > > 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. > > This WG is supposed to be documenting "how the Web PKI actually works in > the set of browsers and servers that are in common use today", not on what > CAs would concur about. Your document seems to be about the latter. Maybe > we should stop work and recharter to change the focus of the WG to be what > CAs would concur about; if the charter changes to that, I suspect a good > percentage of the few people who wanted to participate in the WG would walk > away; I certainly would. > > > 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. > > And what is the operational effect of the latter two? *That's* much more > germane to "how the Web PKI actually works in the set of browsers and > servers that are in common use today". > > > In general all CAs endeavor to meet their policies and put corrective > action in place where a mistake has been made. > > How can that statement be measured? Is there a public repository of CA > mistakes (not just those discovered by the public) and the corrective > action that took place? If so, great; if not, such assurances have little > do with ho the Web PKI actually works. > > > 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. > > None of the browsers that I am familiar with display a dialog that says > "The certificate for the site you are visiting, www.cia.gov, is issued by > a CA that is generally believed to be controlled by the government of > <country sometimes unfriendly with the US>. Sound good to you?" The trust > model allows such issuance; the "implicitly accepts" needs to deal with > that, not with dialog boxes that a browser *could* show be never does in > this reality. > > > 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. > > It seems you forgot the word "sometimes" in there. > > > In the past we have seen that DigiNotar and Digicert Malaysia CA > certificates have been blacklisted. > > ...but not some CAs that were found to have defective oversight of > subordinate CAs, for example. > > > 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. > > That is not a lapse on Microsoft's part, it is an explicit policy. > > > Chrome uses CRLsets rather than the full CRL issued by the CA. > > That's unrelated to lapses, yes? > > > CA certificates with MD2/MD5 signatures have been untrusted. > > How on earth is that considered a "lapse"? > > > I also expect to see CAs with 1024-bit RSA keys to be untrusted in some > browsers in the next year. > > Again: that's a policy, not a lapse. > > In summary, it really doesn't feel like this draft meets the current > charter. If folks want to have a recharter discussion, fine, but maybe it > would be better to ask the editor to stick to the current charter. > > --Paul Hoffman > > _______________________________________________ > wpkops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/wpkops >
_______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
