We've beaten the stuffing out of Logotype, imho.
- CAs want to add it
- Root stores don't
- The BRs permit it (probably).
- I'll report you to the DoJ,
- I'll revoke our Roots,
- bla bla bla

My personal view is that CAs should be able to include data in extensions as
long as they document how they validate it in their CPS.  I understand and
agree that using existing Subject DN attributes is dangerous, but using
custom extensions to convey data should be fine.  If you understand how to
decode it, then you understand what it is and to what extent you can trust
it based on the CA CPS, right?

Wayne, your initial proposal was this:

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'm guessing you have concerns beyond just logos but picked on this one
because of the thread.

I think we should move on and: 
- work on a standardized way to represent Logos along with the associated
validation of the contents.
- apply this same logic (define standard validation rules and
well-structured formatting) to other things that we need to include (or that
we are already including like LEIs).  I'm certain that there are even more
industry uses for certain (not misleading) values in the OU, and those are
excellent candidates for including in a uniform way, just like we did for
PSD2 data.  As long as we have a well defined data structure and a
definition for how the data was validated, I don't believe that we should be
concerned with how strongly the data was validated (leave that up to the
application or person consuming the data based on the stated validation
method).

Doug

-----Original Message-----
From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On
Behalf Of Phillip Hallam-Baker via dev-security-policy
Sent: Thursday, July 11, 2019 11:53 PM
To: Wayne Thayer <wtha...@mozilla.com>
Cc: mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org>; hous...@vigilsec.com
<russ.hous...@gmail.com>
Subject: Re: Logotype extensions

On Thu, Jul 11, 2019 at 12:19 PM Wayne Thayer <wtha...@mozilla.com> wrote:

> On Wed, Jul 10, 2019 at 7:26 PM Phillip Hallam-Baker < 
> ph...@hallambaker.com> wrote:
>
>> Because then the Mozilla ban will be used to prevent any work on 
>> logotypes in CABForum and the lack of CABForum rules will be used as 
>> pretext for not removing the ban.
>>
>> I have been doing standards for 30 years. You know this is exactly 
>> how that game always plays out.
>>
>
> Citation please? The last two examples I can recall of a Browser 
> clarifying or overriding CAB Forum policy are:
> 1. banning organizationIdentifier - resulting in ballot SC17 [1] , 
> which properly defines the requirements for using this Subject attribute.
> 2. banning domain validation method #10 - resulting in the ACME TLS 
> ALPN challenge [2], which is nearly through the standards process.
>
> In both examples, it appears that Browser policy encouraged the 
> development of standards.
>

It is what happened when I proposed logotypes ten years ago.



> If you don't want to use the extension, that is fine. But if you 
> attempt
>> to prohibit anything, ruin it by your lawyers first and ask them how 
>> it is not an a restriction on trade.
>>
>> It is one thing for CABForum to make that requirement, quite another 
>> for Mozilla to use its considerable market power to prevent other 
>> browser providers making use of LogoTypes.
>>
>
> If this proposal applied to any certificate issued by a CA, I might 
> agree, but it doesn't. CAs are free to do whatever they want with 
> hierarchies that aren't trusted by Mozilla. It's not clear to me how a 
> CA would get a profile including a Logotype through a BR audit, but 
> that's beside the point.
>

Since Mozilla uses the same hierarchies that are used by all the other
browsers and are the only hierarchies available, I see a clear restraint of
trade issue.

It is one thing for Mozilla to decide not to use certain data in the
certificate, quite another to prohibit CAs from providing that data to other
parties.

The domain validation case is entirely different because the question there
is how data Mozilla intends to rely on is validated.


A better way to state the requirement is that CAs should only issue
>>>> logotypes after CABForum has agreed validation criteria. But I 
>>>> think that would be a mistake at this point because we probably 
>>>> want to have experience of running the issue process before we 
>>>> actually try to standardize it.
>>>>
>>>>
>>> I would be amenable to adding language that permits the use of the 
>>> Logotype extension after the CAB Forum has adopted rules governing its
use.
>>> I don't see that as a material change to my proposal because, either 
>>> way, we have the option to change Mozilla's position based on our 
>>> assessment of the rules established by the CAB Forum, as documented 
>>> in policy section 2.3 "Baseline Requirements Conformance".
>>>
>>> I do not believe that changing the "MUST NOT" to "SHOULD NOT" 
>>> reflects the consensus reached in this thread.
>>>
>>> I also do not believe that publicly-trusted certificates are the 
>>> safe and prudent vehicle for "running the issue process before we 
>>> actually try to standardize it".
>>>
>>
>> You are free to ignore any information in a certificate. But if you 
>> attempt to limit information in the certificate you are not intending 
>> to use in your product, you are arguably crossing the line.
>>
>>
> It's quite clear from the discussions I've been involved in that at 
> least one goal for Logotypes is that Browsers process them.  You 
> implied so yourself above by stating that this proposal would "prevent 
> other browser providers making use of LogoTypes." So you are now 
> suggesting that Browsers ignore this information while others are
suggesting precisely the opposite.
>

Mozilla is free to make the choice to ignore it. If you want to go ahead and
use your significant market power to prevent the logotypes being added to
other browsers to use them and are confident that it is compliant with US
anti-trust law, EU competition law (and the 27 member states) plus any other
state you may have picked a fight with recently, well go ahead.

In case you hadn't noticed, there is a storm brewing over 'big-tech' on
capitol hill. It is not yet clear which issues are going to be picked up or
by whom. It is not certain that the WebPKI will be the focus of that but I
would not count on avoiding it. It would be prudent for every party with
significant market power to constantly ask themselves if they would be
comfortable justifying their positions in a House or Senate hearing.



> If publicly-trusted certificates containing Logotypes are issued prior 
> to some agreement on the rules, then we have created a "legacy" 
> problem and made it more difficult for Browsers to support them. And 
> again, there is a simple solution to this problem: don't issue certs 
> with Logotypes from a Mozilla-trusted hierarchy until validation standards
are in place.
>

Certificates have issue dates and policy identifiers.

If you want to avoid trusting legacy certs, all you would need to do is to
ignore logotypes in certificates issued before the issuing rules become
effective. Since the early adopters would almost certainly be a small,
highly motivated group, they would probably get their revalidation done and
certificates re-issued to comply.


--
Website: http://hallambaker.com/
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
            • Re: Log... Ryan Sleevi via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Fwd: Lo... Phillip Hallam-Baker via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Logotyp... Phillip Hallam-Baker via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • RE: Log... Doug Beattie via dev-security-policy
            • Re: Log... Ryan Sleevi via dev-security-policy
            • RE: Log... Jeremy Rowley via dev-security-policy
            • Re: Log... Ryan Sleevi via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Fwd: Lo... Phillip Hallam-Baker via dev-security-policy
          • Re: Logotype... kirkhalloregon--- via dev-security-policy
            • Re: Log... Corey Bonnell via dev-security-policy
  • Re: Logotype extensions kirkhalloregon--- via dev-security-policy

Reply via email to