First of all, apologies for the delay in responding to this thread. Secondly, I think Michael makes some excellent points.
Here's a suggestion ... Is not the Security Considerations section precisely the place where one would record the things that might go wrong in the event the model is not properly reflected in reality? There are too many failure modes to be exhaustive. But, one might capture the most serious ones; the ones that experts feel might have a solution within the IETF's ambit. In this way, the body of the document would describe how things should work (as the document does now), and the Security Considerations section would capture relevant failure modes. Thought? All the best. Tim. Michael Jenkins wrote ... 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
_______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
