Re: BCP56bis - remaining work

Hi Mark,

On Mon, Apr 26, 2021 at 05:46:12PM +1000, Mark Nottingham wrote:
> Again, this is *just* about IETF specifications that define HTTP APIs that
> are for deployment on the open internet.

OK but it till leaves a chicken-and-egg problem by which you could have
to use https to validate https. And quite frankly I continue to think it's
not a necessity for everything, it's very possible that some information
are more valuable if widely delivered than if secured as the transport
level. Look at OCSP for example, it's used in clear and is opened on the
net because the payload is secured by definition. Why should we prevent
some other services from doing the same if there's no risk and the
availability of the information is more valuable than its supposed
confidentiality or integrity ?

Imagine a service used to retrieve signatures of package updates, it's
possible that such signatures are implicitly controllable (e.g. PGP),
and that it's considered better to ease access to the widest possible
amount of requesters than see some of them ignore signatures just because
they can't use HTTPS due to an outdated local cert list, or not having
their clock right.

I really think that a strong recommendation is better, or even a SHOULD
(i.e. it's the expected way of doing it, unless there is a good reason
not to). MUST forces violations when there is a good reason that a spec
authors couldn't imagine, and I don't like encouraging violations.

Regards,
Willy

Received on Monday, 26 April 2021 08:51:27 UTC