On Nov 16, 2013, at 10:37 AM, Learmonth, Iain Ross <[email protected]> wrote: > As for revoking certificates, no extension to TLS is required as long as > there's a method of notifying the server of revocations. With one keypair per > service, it shouldn't be too hard to push a revocation to the service the > keypair is linked to that it can add to its list.
TLS Certificate revocation mechanisms _won't work_ because they allow different sites to tell that a particular key belongs to the same person. > I'd really like to avoid making changes to TLS if possible, as then this > might get complicated. What we are discussing requires substantial changes on both browsers and service provider sites. Trying to crowbar it into the existing support for TLS will probably result in the providers not implementing certificate revocation at all. Service providers don't currently even _allow_ client authentication using client certs anyway. So we're talking about deploying something new; might as well do it right. > We could define a scheme for HTTP only (we'd have to pay attention to section > 5.1.2 of draft-ietf-httpbis-p7-auth) then we could do crazier things, but > working out how to do this at the TLS layer using TLS as it exists means it's > portable to things like mail clients, FTP clients and clients no one's even > thought of yet. I understand why you want to stuff this in at the TLS layer, but realistically you have to change the IMAP, POP, FTP and other implementations to use client certs anyway, so again, why not do it right? I don't see any point in designing something that isn't a complete solution to account for existing implementations that don't exist! :) _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
