On Mon, Feb 24, 2014 at 4:00 PM, Daniel Kahn Gillmor <[email protected]>wrote:
> On Thu 2014-02-20 12:06:08 -0500, Melinda Shore wrote: > > I've uploaded a first crack at an agenda to > > http://www.ietf.org/proceedings/89/agenda/agenda-89-trans. > > Please let me know if anything is missing, or if you'd like > > to request some time on the agenda. > > Thanks for organizing, Melinda! I'd like to try to make a bit of time > in the agenda to talk about the use of CT in the SMTP+STARTTLS > environment. > > Given the current opportunistic mode that TLS is used for in SMTP, we > may decide that there is no reasonable intersection at all today, but i > think it would be worth putting the issue on people's radar with a brief > discussion. > > For example, brief discussion of any of these questions might be useful: > What these all come down to is the question of using the CT log infrastructure as a potential source for authoritative security policy. It is a completely valid approach and one that I am looking at but in the context of SMTP with S/MIME and PGP. Whether or not these is time at the meeting, I suggest this is a discussion we continue on therightkey because I have a feeling that Melinda is going to kick us out pretty quick if we get into discussion of approaches. I would kick me out. This is why I think it is important to distinguish between keeping notary logs for issue of certificates by CAs separate from the issue of how notarize the notary logs. The way I see it we will end up eventually with some collection of 'meta-notaries' which cross notarize at regular intervals making defection or failure of a meta-notary of little concern. Every meta-notary will cross notatrize every other within a 24hour period so they are interchangable from a trust point of view. I would see CT logs of SSL cert issue to be one input to the meta notaries, CT logs of S/MIME certs another, PGP key signings another, security policy statements another and so on. -- Website: http://hallambaker.com/
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
