On Thu, Dec 27, 2018 at 12:12 PM Wayne Thayer <wtha...@mozilla.com> wrote:
> On Wed, Dec 26, 2018 at 2:42 PM Peter Bowen via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> In the discussion of how to handle certain certificates that no longer
>> meet
>> CA/Browser Forum baseline requirements, Wayne asked for the "Reason that
>> publicly-trusted certificates are in use" by the customers. This seems to
>> imply that Mozilla has an opinion that the default should not be to use
>> "publicly-trusted certificates". I've not seen this previously raised, so
>> I want to better understand the expectations here and what customers
>> should
>> consider for their future plans.
>>
>
> The context for the question is that at least one of the organizations
> having difficulty with the underscore sunset stated that they couldn't just
> replace the certificates - they need to ship updates to the client. If you
> are hard-coding certificate information into client software, it's fair to
> ask why you're using publicly-trusted certificates (PTCs).
>
I was not aware of this being an issue in this case. Thanks for this
explanation.
I believe a similar concern was discussed at length during the SHA-1 sunset
> in relation to payment terminals. As has been suggested, maybe it's simply
> a matter of cost. I suspect, however, that it is more about a lack of
> recognition of the responsibilities that come along with using PTCs. In the
> spirit of incident reporting, I think it would help to have a better
> understanding of the decisions that are driving the use of PTCs in these
> use cases
>
I agree that many people developing products do not understand the fully
scope of the responsibilities that come with using Mozilla PTCs. From what
I've personally observed, the requirements are frequently: "I want to have
a third party manage the CA at no cost to me", "I want that third party to
make it relatively easy and fairly inexpensive for arbitrary people and
organizations to get certificates that are signed by/chain to the CA", "I
want some level of assurance that the third party is doing the right things
without having to figure out what the right things are", and (usually only
realized much later) "I want to be able to make a decision on whether the
risk of not revoking a given a certificate outweigh the benefit of leaving
it unrevoked and have the third party not suffer any negative consequences
from my decision".
I have seen these requirements from organizations large and small. They
are not usually written out in these terms, rather there are other
requirements that boil down to these.
> Is the expectation that "publicly trusted certificates" should only be used
>> by customers who for servers that are:
>> - meant to be accessed with a Mozilla web browser, and
>>
>
> No.
>
> - publicly accessible on the Internet (meaning the DNS name is publicly
>> resolvable to a public IP), and
>>
>
> No.
>
> - committed to complying with a 24-hour (wall time) response time
>> certificate replacement upon demand by Mozilla?
>>
>> Committed to comply with section 4.9.1.1 (Reasons for Revoking a
> Subscriber Certificate) of the BRs - yes.
>
In recent revisions to the BRs, it seems that this is extended to 5 days
for many cases, including this underscore case. However I think that many
customers ("subscribers" in BR terminology) would be very surprised at this
requirement, even though it is long standing.
> Is the recommendation from Mozilla that customers who want to allow Mozilla
>> browsers to access sites but do not want to meet one or both of the other
>> two use the Firefox policies for Certificates (
>>
>> https://github.com/mozilla/policy-templates/blob/master/README.md#certificates
>> ) to add a new CA to the browser?
>>
>> No, that was not my intent. Rather, I am hoping for a better recognition
> of the commitments (per the Subscriber Agreement and CPS) and risks
> involved when an organization chooses to use PTCs, especially for
> non-browser use cases.]
>
I think this is a good callout. Mozilla PTCs are a fairly unique situation
because there is very little ability to negotiate terms. Most large
organizations are accustomed to having a set of requirements as a starting
point but working person to person (or organization to organization) to
modify the terms to meet their needs. It is clear that this is not an
option for Mozilla PTCs and this lack of option is very surprising to the
organizations. I'm not sure what can be done about existing deployments of
roots in places other than Mozilla software, but it is clear that CAs
should be working on options for future non-Mozilla software cases if their
customers need more policy flexibility and do not need compatibility with
Mozilla software.
Thanks,
Peter
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
