On Thu, Apr 12, 2018 at 1:03 PM, Wayne Thayer <wtha...@mozilla.com> wrote:

> On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi <r...@sleevi.com> wrote:
>
>>
>>
>> On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer <wtha...@mozilla.com>
>> wrote:
>>
>>> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>> Indeed, I find it concerning that several CAs were more than happy to
>>>> take
>>>> Ian's money for the issuance, but then determined (without apparent
>>>> cause
>>>> or evidence) to revoke the certificate. Is there any evidence that this
>>>> certificate was misissued - that the information was not correct? Is
>>>> there
>>>> evidence that Ian, as Subscriber, or stripe.ian.sh, as domain holder,
>>>> requested this certificate to be revoked?
>>>>
>>>> If anything, this highlights the deeply concerning practices of
>>>> revocation
>>>> by CAs, and their ability to disrupt services of legitimate businesses.
>>>>
>>>> BR 4.9.1.1 states that a CA SHALL revoke a certificate within 24 hours
>>> if "The CA determines that any of the information appearing in the
>>> Certificate is inaccurate or misleading" I'm sympathetic to the arguments
>>> being made here, but the whole point of this discussion is that the EV
>>> information presented to users is misleading, so these CAs did what was
>>> required of them.
>>>
>>
>> In what way is it misleading though? It fully identified the organization
>> that exists, which is a legitimate organization. Thus, the information that
>> appears within the certificate itself is not misleading - and I don't think
>> 4.9.1.1 applies.
>>
>> I would refer you to your email, kicking off the 150+ message thread on
> this topic back in December, that included these statements:
>
> "...and more importantly, how easy it is to obtain certificates that may
> confuse or mislead users"
> "given the ability to provide accurate-but-misleading information in EV
> certificates,..."
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/szD2KBHfwl8/
> kWLDMfPhBgAJ
>

So that seems to support the "it's misleading because some browsers only
display a portion of that information in their security UI". If Firefox
showed the full certificate details, would it have been misleading?
Similarly, if I make a custom fork of Chromium that displays the first four
characters of the O field, and get Eric to say he uses it, does that make
it misleading to (some) browsers?

It's a very slippery slope, and while I agree it's taking the argument to
an obvious extreme, the degree of subjectivity being exercised by CAs here
(and encouraged by Matthew) is worth calling out - that this isn't a
bright-line in any shape, but rather, an entirely subjective and arbitrary
revocation.


>
> Or are we saying it's misleading because some browsers only display a
>> portion of that information in their security UI? If so, is that a failure
>> of the security UI (for not showing all the information present)? Or is the
>> argument that it's misleading if any two entities share the same O and C
>> (the information displayed)? Is it still misleading if the Cs differ? If
>> this is the vein to take, should CAs then be responsible for examining CT
>> (or other sources) to determine if two organizations share the same (or
>> similar?) names, regardless of incorporation location, and refuse to issue
>> if there is an extant cert for a different organization? Or we can continue
>> taking the argument further, by suggesting that if a smaller organization
>> gets the cert first, they could find their cert revoked if a more 'popular'
>> organization with the same name wants a cert instead.
>>
>> In the DNS space, this is an extremely complex, nuanced issue, with the
>> whole Uniform Domain-Name Dispute Resolution Policy established, in part,
>> to try to put parties on semi-equitable footing. The current approach being
>> taken by CAs lacks that, lacks the transparency, and lacks the neutrality -
>> all things one would expect from such policies.
>>
>
> I agree with this, but the current approach taken by CAs is defined in the
> BRs, so pointing fingers at individual CAs is not the solution. Based on
> this argument, the requirement to revoke when a certificate contains
> misleading information should be removed from the BRs.
>

I agree that the BRs and EVGs provide substantial (unlimited) leeway for
CAs to revoke certificates for any reason or no reason at all. Unlike users
who have choices in browsers and devices, however, server operators lack
meaningful choices, as there are only a limited number of trusted
organizations, and unlike the registry/registrar split of the domain name
system (which seeks to balance the interests by separating out the TLD
operators from the domain sellers), the root CAs have concentrated policy
power that they can flow down to their entire hierarchy. So, unlike domain
names, in which if a registrar doesn't want to do business with you, you
can start your own registrar (and the registry must accept if you're
qualified), if you're denied a cert or your service is interrupted for such
capricious reasons, you're SOL.

Because of this, it's incumbent upon interested parties to point fingers at
individual CAs when they abuse that position to capriciously disrupt
otherwise qualified services for arbitrary reasons.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to