On Fri, Aug 26, 2011 at 11:14 AM, <ned+ietf@xxxxxxxxxxxxxxxxx> wrote: > > +1. If you want signatures, do them properly. Don't pretend a transfer > protection mechanism covering exactly one hop provides real object security, > because it doesn't. > It ensures that what you're getting is the same as what the IETF has on file, and (assuming you trust the IETF's archive integrity, which is a separate problem) what everyone else on the list received. It seems to me it's more important to know that than to know that stuff sent to the list actually came from who it claims to come from. Does it really matter if a proposed standard wasn't really designed by who the archive says it was designed by? > And as for the "encrypt so the really secret stuff doesn't stand out" argument, > that's fine as long as it doesn't cause inconvenience to anyone. That's clearly > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > really fly: Certificates aren't a "set it and forget it" thing, so if you > haven't noted expiration dates on someone's to-do list so they can be updated > before expiration, you're not doing it right. Yeah, it seems like the IETF would be on top of certificate expiration, having invented it. But I think having the encryption is a very good thing. Some government interests would be happy to keep information about some aspects of IETF business away from their citizenry, and have the resources to launch a MITM attack. (Of course, those governments may also have the resources to sign a fake certificate, but that is, again, a separate problem.) Once the certificate expiration business is fixed, it should be fairly simple to make sure it's kept up to date so that this sort of thing doesn't happen again. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf