On Fri, Aug 26, 2011 at 11:14 AM,
<ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf