It seems to me that this discussion has veered away from the original
question, which was seeking consent to "experiment" with logotypes in
publicly-trusted certificates. I don't think there is much doubt that RFC
3709 has been and can be implemented, and as pointed out, it can be tested
in private hierarchies. I fail to understand the point of this type of
"experiment", especially when it leaves all of the difficult questions -
such as global trademark validation and the potential to mislead users -
unanswered. The risks of permitting such "experimentation" appear to far
outweigh the benefits.
The discussion has morphed into a question of a CA's right to encode
additional information into a publicly-trusted certificate, beyond the
common profile defined in the BRs, for use in a subset of Browsers or other
client software. The argument here seems to be that BR 7.1.2.4(b)
("semantics that, if included, will mislead a Relying Party about the
certificate information") can't be triggered if the user agent doesn't
understand the data, or that there needs to be proof that the data is
misleading (versus could be misleading) to trigger that clause. This seems
like a much more difficult problem to solve, and one that doesn't need to
be addressed in the context of the original question.
Given this, and the fact that I believe it is in everyone's best interest
to resolve the current ambiguity over Mozilla's policy on logotypes, I
again propose to add logotype extensions to our Forbidden Practices[1], as
follows:
** Logotype Extension **
Due to the risk of misleading Relying Parties and the lack of defined
validation standards for information contained in this field, as discussed
here [2], CAs MUST NOT include the RFC 3709 Logotype extension in CA or
Subscriber certificates.
I will greatly appreciate additional feedback on my analysis and proposal.
- Wayne
[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ
On Fri, Jul 12, 2019 at 2:26 PM Ryan Sleevi <[email protected]> wrote:
> And they will mislead relying parties. Which is why you cannot use *this*
> particular extension. Sorry, that ship sailed in 2005.
>
> A CA that would be remotely be considering exercising this clause would
> strongly benefit from checking with the Root stores they’re in, no matter
> the extension proposed.
>
> It’s also Subject Identifying Information.
>
> On Fri, Jul 12, 2019 at 5:11 PM Jeremy Rowley <[email protected]>
> wrote:
>
>> The language of the BRs is pretty permissive. Assuming Mozilla didn't
>> update its policy, then issuance would be permitted if the CA can show that
>> the following was false:
>>
>> b. semantics that, if included, will mislead a Relying Party about the
>> certificate information verified by
>> the CA (such as including extendedKeyUsage value for a smart card, where
>> the CA is not able to verify
>> that the corresponding Private Key is confined to such hardware due to
>> remote issuance)..
>>
>> I think this is section you are citing as prohibiting issuance correct?
>> So as long as the CA can show that this is not true, then issuance is
>> permitted under the current policy.
>>
>>
>>
>> -----Original Message-----
>> From: dev-security-policy <[email protected]>
>> On Behalf Of Ryan Sleevi via dev-security-policy
>> Sent: Friday, July 12, 2019 3:01 PM
>> To: Doug Beattie <[email protected]>
>> Cc: mozilla-dev-security-policy <
>> [email protected]>; Wayne Thayer <
>> [email protected]>
>> Subject: Re: Logotype extensions
>>
>> Alternatively:
>>
>> There is zero reason these should be included in publicly trusted certs
>> used for TLS, and ample harm. It is not necessary nor essential to securing
>> TLS, and that should remain the utmost priority.
>>
>> CAs that wish to issue such certificates can do so from alternate
>> hierarchies. There is zero reason to assume the world of PKI is limited to
>> TLS, and tremendous harm has been done to the ecosystem, as clearly and
>> obviously demonstrated by the failures of CAs to correctly implement and
>> validate the information in a certificate, or timely revoke them. The fact
>> that were multiple CAs who issued certificates like “Some-State” is a
>> damning indictment not just on those CAs, but in an industry that does not
>> see such certificates as an existential threat to the CAs relevance.
>>
>> It is trivial to imagine how to issue such certificates from non-TLS
>> hierarchies, and to have those still usable by clients. Any CA that can’t
>> think of at least three ways to do that has no business in this industry -
>> because it is truly basic application of existing technologies.
>>
>> The BRs do not permit this. Just like they don’t permit a lot of things
>> that CAs are unfortunately doing. If the CA portion of the industry wants
>> to improve things, such that a single CA could reasonably be believed to be
>> competent enough to issue such certificates, let alone reasonably validate
>> them (as this has been a global challenge for well over a hundred years),
>> perhaps getting the basics right, and formalizing best practices in a way
>> that the whole industry can improve, is a better starting point.
>>
>> I get some folks want to argue this is special, because they want it to
>> be.
>> This is no different than why it’s problematic to have payment terminals
>> using publicly trusted TLS certs, no different than why having drone PKI
>> use a different than profile than TLS, and why having certificate profiles
>> like QWACs or PSD2 not be used for TLS. The quicker we internalize that,
>> the better we can move to having useful and specialized PKIs, instead of
>> the actively harmful attempts, actively dangerous, actively problematic to
>> put it all in a single cert, which they were never intended to do.
>> _______________________________________________
>> dev-security-policy mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
