On Wed, May 13, 2020 at 9:00 PM Matt Palmer via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> 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").
I'm afraid this grossly misrepresents what URLs are, and RFC 5280. A
URL describes a resource at a location, it does not describe the
potential responses for retrieving that URL. RFC 5280 places a
requirement on the content of the resource at the location, but that
does not mean or constrain the possible responses for that resource.
While it's true a 404 indicates that no such resource exists, and thus
/is/ a violation, a 403 indicating that the resource is forbidden from
access is not, in and of itself, a violation, no different than
responding 301 or 302, or 300 indicating multiple resources.
Put differently, the language you're citing a statement about the
content of the URL when that resource is *successfully* dereferenced,
without an obligation upon that URL to be successfully dereferenced by
the client.
The canonical example is for internally-operated CAs, it's perfectly
fine to put an intranet URL in. In fact, every local CA will do that
(e.g. Active Directory Certificate Services does that by default).
That's the interoperability that 5280 permits, and you can't simply
say those certificates don't conform with the profile.
So no, it's *nothing* like a requirement the URL be accessible, and
that's why I'm wanting to push to see if there's a more compelling
argument here. Right now it just seems an emotional response based on
personal opinion, but not much to support the opinion, and that seems
unfortunate.
> > > 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>
While cute, your own sentence below shows that you were making a
generalized statement.
1. You cannot deny legitimate users access to the resource.
2. Legitimate users use legitimate tools
3. Wget is a legitimate tool that legitimate users use
Ergo ("thus")
4. You cannot block wget from access to the source
I'm pointing out the flaw here, which is the assumption that wget is a
tool only legitimate users use is a statement without evidence (and
"obviously" false). Yet for the above to hold, despite this, then it's
saying that "You cannot deny legitimate users access to the resource"
is a higher principle and priority than "wget is a tool sometimes used
by illegitimate users", and that's a problematic statement to make.
Which you double down on, below.
> 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.
On its face, the argument remains problematic, because 'legitimate'
tools can and are used for problematic purposes, and suggesting that
some tools ("legitimate ones") cannot be blocked (because they deny
"legitimate users access to the resource") instantly creates and
incentivizes illegitimate tools to disguise themselves as legitimate
tools.
You haven't really addressed this. Yes, I don't disagree that blocking
by UA has side-effects, but in the above argument, you're again
suggesting that there's some rule making about when such side-effects
are acceptable and not acceptable, without actually spelling out what
those are. That's why I pushed in my previous mail, and why I'm still
pushing to see if there's something being overlooked. Below, you set
an entirely unreasonable standard, by suggesting that if, taken as
written, at least two users are affected, the CA must show everything
possible to prevent that. I don't find that compelling, and certainly
not compelling enough to suggest that the CA has done "something
wrong". So if the suggestion is that something is "unacceptable," on
the basis that any impact to >= 2 users is unacceptable, then that's
not at all compelling.
>
> 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?
Uh, yes, that's my point? Is it unacceptable, to you, if a CA omits
it, ensuring that the URL, whatever it is, cannot be dereferenced by
anyone because _they don't know it_. If omitting it is fine, and it is
in some cases, then why is including it, and making it inaccessible to
some, unacceptable in all cases?
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
