--On Tuesday, 05 November, 2013 20:45 -0500 Eric Burger
<eburger(_at_)standardstrack(_dot_)com> wrote:
Because would not someone retrieving an RFC want to know it
really came from the IETF, especially when it says The
protocol MUST provide provisions for lawful intercept and
MUST post a notification when traitorous speech is detected.
;-)
Eric,
I think your joke illustrates the other part of the problem. If
I really want to "know it really came from the IETF", then I
want a digital signature on the document that I can verify after
it is retrieved, regardless of the retrieval mechanism used.
At least until and unless we (and the rest of the community)
manage to clean up the server CA mess --including both killing
off the CAs with bad behavior patterns and making sure that all
HTTPS clients do really careful cert validation-- https may give
me a warm and fuzzy feeling, but it doesn't guarantee document
authorship and integrity. Worse, part of the problem today if
that, if those HTTPS-related tools work well, there is some
history of false negatives (e.g., letting certs expire) that
keep people from getting to documents for no good reason.
I believe in eating our own dogfood, but think an appeal to that
principle requires careful attention to whether the food is
suitable for purpose and safe and nutritious for canine
consumption. In today's environment, claims about HTTPS for
document authenticity and/or integrity fail that test.
I strongly defend keeping HTTPS available for those who want it,
but oppose getting rid of it to punish those who have reasons to
not use it.
john