Sorry for using a valid subject line. :-) On Feb 24, 2014, at 11:28 PM, Ben Laurie <[email protected]> wrote:
> On 24 February 2014 21:43, Daniel Kahn Gillmor <[email protected]> wrote: >> On 02/24/2014 04:25 PM, Melinda Shore wrote: >> >>> As for relevance, right now therightkey is the best place >>> for discussion of other approaches to fixing PKI, while trans >>> is specifically for discussion of certificate transparency. >>> The only thing that's in our charter at the moment is 6962bis. >>> That doesn't mean that other applications of CT are out-of- >>> scope, but that we'd need to recharter to take them on >>> as work items. >> >> I think you're saying you want the slot in London to focus on getting >> the mechanism right, and not trying to propose policy, which is >> completely reasonable. I'm happy to stay focused. >> >> There's nothing in RFC 6962 (and i hope there won't be in 6962bis) that >> is HTTPS-specific, though; it's defined as a mechanism for logging X.509 >> certificates for use in TLS, regardless of the application layer traffic >> within the TLS session. >> >> So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other >> application" -- it's still TLS. If we suspect that CT is somehow valid >> only for X.509 certs used by HTTPS servers, we should make that more >> explicit in the draft (but i hope we don't!) > > I agree. One observation: CT as applied to HTTPS uses the CA signature > as a spam limitation mechanism. > > I believe most SMTP certs are not CA issued, so the question arises: > how would you propose to limit spam? At the earlier CT meeting, I think someone proposed that there could be a check that the cert was in actual use at the place it said it was. > I am open, by the way, to running CT logs at Google with alternate > spam limitation mechanisms to allow this kind of usage. I think that > not having a spam limitation mechanism is dangerous. Spam limitation is needed for both attacks on CT to weaken it and accidental misconfiguration that could look a lot like an attack. --Paul Hoffman _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
