One draft that might be relevant here is my TLS security policy draft which I will update later today and the OCSP 'Does not exist' response proposal which I don't think made it to a draft.
http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-01 The relevance of TLS security policy is that it is a slightly more general version of the proposed 'OCSP Must staple' certificate extension. The idea is that a server puts this extension in a CSR when requesting a certificate and this is then included in the certificate produced. The server knows what version of TLS it supports and whether OCSP stapling is supported and if so whether it is turned on. Putting these in a certificate extension means that an OCSP client that does not get a stapled OCSP response can reject the certificate immediately and hardfail without having to try an OCSP request against the CA server which might be blocked by an attacker or alternatively enable a DoS attack. Including the version might not be strictly necessary but is by far the biggest downgrade attack concern on TLS itself. The relevance to CT is that this extension makes it practical to deliver the CT proofs in the OCSP token rather than the certificate. That in turn means that deployment of CT (1) has far less impact on CA operations and (2) could potentially include a complete and current notary proof that is up to date to the current day. The reason I moved to the more general TLS policy rather than just doing MUST STAPLE is that it is quite possible that we might want to propose new TLS extensions to allow stapling of CT related data such as meta-notary data. The interest in a 'does not exist' response in OCSP is that it allows CAs to deploy a weak form of transparency almost immediately. By weak transparency I mean that a third party can audit the behavior of the CA from public data alone but the requirements of this audit make it unsuitable for incorporation into a client. If an OCSP responder is required to distinguish 'this cert does not exist' from 'this cert is valid' then a third party can check to see if the CA knows which certificates have been issued and which are not by generating requests for random serial numbers. While most CAs would likely deliver the response as unsigned or sign it on the fly (volume should be very small) the use of a scope scheme like I proposed back in 1995 (and there is earlier prior art) allows the 'does not exist' responses to be static as well. The reason this was not done back in 1995 was that people raised objections similar to zone walking. With CT we are asserting that public certs are public knowledge anyway. I would also like to suggest that as an interim step we define a simple JSON format that CAs would use to report the list of all certificates issued in the past hour. This is again a form of weak transparency but I think having that data will make it a lot easier to get to a workable system. The idea of publishing certs is pretty straightforward, the idea of analyzing the published certs is pretty straightforward. Both deliver a significant value that can be realized in a 12 month timeframe. Design of the notary chains and making it possible for clients to do validation is a much harder task. Not saying that it is impossible, just that it will take us some time to do. From a design point of view it is a lot harder than DANE which is now in what, its third year? I would like us to have something that CAs can do right now rather than wait three years before we approach them asking them for action. Three years is a long time in business and people change jobs. If we end up waiting three years before we ask people for action it is quite likely that the people who are saying yes or maybe now will have moved on and we will have to start the argument from scratch. On Wed, Oct 17, 2012 at 10:43 AM, Paul Hoffman <[email protected]>wrote: > Greetings again. The certrans BoF is scheduled for Tuesday after lunch at > the IETF meeting; see <https://datatracker.ietf.org/meeting/85/agenda.html>. > We have two hours, and we may not need all that time. > > This is a call for agenda items. At the moment, we only have > draft-laurie-pki-sunlight, but if anyone turned in any relevant drafts that > I missed, please say so here. > > It would be *very* useful if people continued to discuss > draft-laurie-pki-sunlight and other drafts before the meeting. Meetings are > more valuable for discussing topics that have already been brought up > rather than "here's a presentation on a draft you should have already read". > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
