Re: [EXT] Mozilla requirements of Symantec

[Nick Lamb via dev-security-policy]

On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin  wrote:
> We think it is critically important to distinguish potential removal of 
> support for current roots in Firefox versus across NSS. Limiting Firefox 
> trust to a subset of roots while leaving NSS unchanged would avoid 
> unintentionally damaging ecosystems that are not browser-based but rely on 
> NSS-based roots such as code signing, closed ecosystems, libraries, etc.

Abusing NSS to support code signing or "closed ecosystems" would be an error 
regardless of what happens to Symantec, it makes no real sense for us to 
prioritize supporting such abuse. To the extent that m.d.s.policy represents 
consumers of NSS certdata other than Firefox, they've _already_ represented 
very strongly that what they want is for this data to follow Mozilla's trust 
decisions more closely not less.

I have no doubt that Symantec believes it could make more money if archaic 
Symantec-controlled CA roots remain in NSS certdata forever but it doesn't 
serve Mozilla's wider purpose to allow that, nor does it serve the purpose of 
the non-Mozilla people on m.d.s.policy.

Further the use of NSS certdata in libraries is absolutely key to a secure Web 
PKI. I spent a good portion of last week and will probably spend more time yet 
chasing problems with such libraries. It may well suit Symantec to be able to 
tell their customers "We can issue you anything [for a fee] and it'll be 
trusted by libraries" knowing you've advocated for this, but it hurts the 
Relying Parties because it exposes them to unlimited risk which will be 
disclaimed later as "not affecting Firefox".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Mozilla requirements of Symantec

[Steve Medin via dev-security-policy]

> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Wednesday, June 07, 2017 2:51 PM
> To: Steve Medin ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Cc: Kathleen Wilson 
> Subject: [EXT] Mozilla requirements of Symantec
>
> Hi Steve,
>
> I'm writing to you in your role as the Primary Point of Contact for Symantec
> with regard to the Mozilla Root Program. I am writing with a list of Mozilla-
> specific additions to the consensus remediation proposal for Symantec, as
> documented by Google.
>
> We note that you have raised a number of objections and queries with
> regard to the consensus proposal. As you know, we are considering our
> responses to those. We reserve the right to make additional requests of
> Symantec in relation to any changes which might be made to that proposal,
> or for other reasons.
>
> However, we have formulated an initial list of Mozilla-specific addenda to
> the consensus proposal and feel now is a good time to pass them on to
> Symantec for your official consideration and comment. We would prefer
> comments in mozilla.dev.security.policy (to which this notice has been
> CCed), and in any event by close of business on Monday 12th June.
>
> 1) Mozilla would wish, after the 2017-08-08 date as documented in the
> consensus proposal, to alter Firefox such that it trusts certificates issued 
> in
> the "new PKI" directly by embedding a set of certs or trust anchors which
> are part of that PKI, and can therefore distrust any new cert which is issued
> by the old PKI on a "notBefore" basis. We therefore require that Symantec
> arrange their new PKI and provide us with sufficient information in good
> time to be able to do that.
>

Symantec supports creation of a new PKI. Limiting Firefox trust of new 
certificates to those issued off of the new PKI is a practical path forward, 
due to Firefox’s contained scope and auto-update capabilities.

The same does not hold true for the removal of current PKI roots from NSS and 
the entirety of NSS dependents.

We understand the cutoff date to mean that any end entity cert issued after 
that date from the current PKI would not be trusted, but this date would have 
no effect on the trust of existing current PKI certs, their issuers, or their 
roots. Mozilla has not yet chosen the notBefore milestone date, and we 
interpret your proposal as intent to set a date and announce that date with 
enough advance notice to support public notice to affected parties. To that 
end, based on our research, we believe the 2017-08-08 date is not achievable 
given the magnitude of the transition that would need to occur and we propose 
that Mozilla not conclude on final dates for Symantec certificates at this time.

In response to the Google proposal, Symantec is currently evaluating a third 
party “SubCA” approach, which requires substantial operational changes. We have 
conducted outreach to candidate partners (SubCAs) to understand the potential 
constraints, timelines and the integration work that might be needed. We have 
also formalized and issued an RFP with specific questions around timing, 
logistics and dependencies. We expect to have the required feedback to inform a 
project plan by the end of June, at which time we will come back to Mozilla and 
the community regarding suggested dates that are both aggressive and achievable 
under this approach, by Symantec and the SubCA(s).

> 2) Mozilla would wish, at some point in the future sooner than November
> 2020 (39 months after 2017-08-08, the date when Symantec need to be
> doing new issuance from the new PKI), to be certain that we are fully
> distrusting the old PKI. As things currently stand technically, distrusting 
> the
> old PKI would mean removing the roots, and so Symantec would have to
> move their customers to the new PKI at a rate faster than natural certificate
> expiry. Rather than arbitrarily set a date here, we are willing to discuss 
> what
> date might be reasonable with Symantec, but would expect it to be some
> time in 2018.
>
> As you know, Firefox currently does not act upon embedded CT
> information, and so CT-based mechanisms are not a suitable basis for us to
> determine trust upon. Were that to change, we may be able to consider a
> continued trust of CT-logged certs, but would still want to dis-trust non-CT-
> logged certs sooner than November 2020.
>

We think it is critically important to distinguish potential removal of support 
for current roots in Firefox versus across NSS. Limiting Firefox trust to a 
subset of roots while leaving NSS unchanged would avoid unintentionally 
damaging ecosystems that are not browser-based but rely on NSS-based roots such 
as code signing, closed ecosystems, libraries, etc.

As one example, we note that libraries that rely on NSS in non-browser based 
applications, many of which are not easily updated, may have unintended 
negative impact in automobiles, 

Re: New undisclosed intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Jun 8, 2017, at 05:17, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 08/06/17 00:42, Jonathan Rudenberg wrote:
>> Yet another batch of undisclosed intermediates has shown up in CT:
> 
> Like, seriously?

Another one appeared this weekend:

https://crt.sh/?sha256=0330286df3612c0e968dcd518a7a316d5e0790d1ca324b906b0ef017c0be3ea7
 (WoSign DV SSL CA issued by Certum just under a month ago)

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 08/06/17 14:15, Rob Stradling via dev-security-policy wrote:

On 08/06/17 13:24, Kurt Roeckx via dev-security-policy wrote:

On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL 
Distribution Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by 
the same CA:


Sorry, I meant to write "listed at https://crt.sh/?id=149444544;.


That shows:
http://www.cert.fnmt.es/crls/ARLFNMTRCM.crl


This CA tends to put multiple CRL URLs in a single DistributionPoint, 
rather than put each CRL URL in its own DistributionPoint.  Most CAs do 
the latter, but IINM the former is also valid (see [1]).


Currently, crt.sh only processes the first URL in each 
DistributionPoint.  (Bug at [2] - I'm treating it as GENERAL_NAME rather 
than GENERAL_NAMES - I'll get that fixed).


Fixed.

crt.sh now processes all CRL URLs that have been observed in all 
"fullName" DistributionPoints (rather than just the first URL in each 
"fullName").


http://www.cert.fnmt.es/crls/ARLFNMTRCM.crl isn't the first CDP URL in 
any DistributionPoint of any cert known to crt.sh, and so crt.sh hasn't 
noticed that URL yet.


crt.sh has now noticed and processed this CRL successfully, and 
therefore the error messages have now disappeared from 
https://crt.sh/?id=149444544, etc.



But tries to use:
http://www.cert.fnmt.es.testa.eu/crls/ARLFNMTRCMEU.crl


This is the first CDP URL in these two certs:
https://crt.sh/?id=50915068
https://crt.sh/?id=50915069


[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.13
   "If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL.  For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.

[2] https://github.com/crtsh/libx509pq/blob/master/x509pq.c#L2513


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Ángel via dev-security-policy]

On 2017-06-08 at 04:31 -0700, richmoore44--- via dev-security-policy
wrote:
> This one is interesting since the domain name of the CRL resolves to an RFC 
> 1918 IP address. Surely that is a violation of the baseline requirements.
> 
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> 
> Regards
> 
> Rich.


Nope. The domain name of the CRL (www.cert.fnmt.es.testa.eu) does not
resolve to an RFC 1918 IP address. It directly doesn't resolve.
10.0.1.10 is the dns server used by crt.sh

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy