On Wed, May 13, 2020 at 08:28:03AM -0400, Ryan Sleevi wrote: > On Tue, May 12, 2020 at 11:47 PM Matt Palmer via dev-security-policy < > [email protected]> wrote: > > 1. As Hanno said, it's a public resource, and as such it should, in > > general, > > be available to the public. > > This is worded as a statement of fact, but it’s really an opinion, right?
It's a statement of fact, in my opinion. <trollface> > You might think I’m nitpicking, but this is actually extremely relevant > and meaningful. The requirements in 7.1.2 are only a SHOULD level, and do > not currently specify access requirements. Your position seems to be that > they’re better by omitting AIA than including a URL you can’t access, or > that they’re prohibited from including URLs you can’t access, and neither > of those requirements actually exist. On the contrary, unless there's an override of RFC5280 4.2.2.1 in the BRs that I can't find, the requirement of universal access does exist. RFC5280 4.2.2.1 says, in relevant part: "Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate [or a "certs-only" CMS]" A CA is permitted to carefully weigh "the full implications" before deciding to not abide by the SHOULD in BRs 7.1.2.3(c), but if they choose to put caIssuers into AIA, it is an "absolute requirement" that the URI provide a DER-encoded certificate (or a "certs-only" CMS). A URI that returns a 403 is not a URI that "point[s] to [...] a single DER encoded certificate". That sounds to me an *awful* lot like a requirement that the URL be accessible and return a DER-encoded certificate (and, by construction, "that they’re prohibited from including URLs [I] can’t access"). Of course, one could argue that blocking attackers violates this. If you block an attacker, but nobody else hears, does it make a violation? I guess we'll find out when a botnet operator complains to m.d.s.p that they got blocked. > > 2. wget is a legitimate tool for downloading files, thus blocking the > > wget user agent is denying legitimate users access to the resource. > > This seems to be saying that there can be zero negative side-effects, > regardless of the abuse. I don’t find this compelling either. <clippy>You appear to be trying to extract a general rule from a specific statement.</clippy> I stated that the apparently-permanent blocking of a general purpose UA from being able to access a caIssuers URL was unacceptable. I gave several reasons why, in my professional experience dealing with Internet abuse, blocking a general purpose UA has both noticeable impact on legitimate users, and a very limited impact on attackers. If you'd like a more general rule to go by, here's my take: if a CA's method of blocking abuse negatively impacts legitimate users, the CA has an obligation to demonstrate that no other method of blocking abuse, one with less negative impact on legitimate users, is capable of reasonably dealing with the threat. I use the present tense in the preceding paragraph, but it's past tense in this particular case -- as far as I can discern, the UA blocking has been removed from the URLs listed in the OP. > If we say it’s ok to not be accessible to any, because it’s not present, > where’s the harm in not being accessible to some, when it is? Conversely, if there's no harm in it not being available to some, where's the harm in it not being available to any? - Matt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
