Re: Mozilla Security Blog re Symantec TLS Certs

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 13, 2018 at 11:26 AM, Kai Engert  wrote:

> On 13.03.2018 15:59, Peter Bowen wrote:
> >>
> >> Which companies, other than Apple and Google, benefit from DigiCert
> >> running the Manager Partner Infrastructure and from DigiCert being part
> >> of the exclusion list?
> >
> > An unlimited set.  Any company who purchases a certificate from
> > DigiCert that is issued by one of the Managed Partner Infrastructure
> > CAs benefits.
>
> Thank you very much for this helpful statement.
>
> I understand that previously, the trust of DigiCert Partner CAs was
> enabled by signing from Symantec CAs.
>
> Because the keys of the managed partner CAs were never controlled by
> Symantec, it is deemed acceptable to allow these to remain trusted.
>
> My conclusion is, the blog post is incomplete.
>

I see. As I didn't write the blog post, I certainly can't speak to the
intent, but I don't agree with your conclusion.


>
> IIUC, the blog post should be updated to add DigiCert as another entity
> controlling subordinate CAs on the exception list.
>
> It might be worth to mention in the article, why the exception for these
> subordinate CAs is deemed acceptable.
>

The consensus plan is linked, and explains these steps. Considering the
importance of ensuring such posts are widely accessible, adding more detail
is regularly shown to be more harmful, rather than helpful, to the overall
discussion and migration.

For a blog post particularly aimed at helping site operators understand,
these nuances about whitelisted CAs only serves to add further problems. As
stated in the blog post, the Consensus Plan was adopted, and that, in
addition to the Managed Partner Infrastructure (which is fully covered in
the consensus plan), the independently-operated-and-audited Sub-CAs of
Apple and Google are being excluded.

All of this information is fully factually accurate. The confusion seems to
be stemming from reading the blog post while ignoring the Consensus Plan
(which is linked). I'm not trying to be negative, but I'm trying to
highlight that the thing you think is missing is addressed (and is linked),
and that likely represents an appropriate-level-of-detail for the likely
intended audience.


> IMHO, it is important to highlight that Apple and Google aren't the only
> entities that own certificates that will remain valid under the Symantec
> hierarchy.
>

That seems more likely to confuse users than to help.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[jsha--- via dev-security-policy]

On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote:
> I'm hoping that LE can provide more details about the change management
> process and how, in light of this incident, it may change - both in terms
> of automated testing and in certificate policy review.

Forgot to reply to this specific part. Our change management process starts 
with our SDLC, which mandates code review (typically dual code review), unit 
tests, and where appropriate, integration tests. All unittests and integrations 
tests are run automatically with every change, and before every deploy. Our 
operations team checks the automated test status and will not deploy if the 
tests are broken. Any configuration changes that we plan to apply in staging 
and production are first added to our automated tests.

Each deploy then spends a period of time in our staging environment, where it 
is subject to further automated tests: periodic issuance testing, plus 
performance, availability, and correctness monitoring equivalent to our 
production environment. This includes running the cert-checker software I 
mentioned earlier. Typically our deploys spend two days in our staging 
environment before going live, though that depends on our risk evaluation, and 
hotfix deploys may spend less time in staging if we have high confidence in 
their safety. Similarly, any configuration changes are applied to the staging 
environment before going to production. For significant changes we do 
additional manual testing in the staging environment. Generally this testing 
means checking that the new change was applied as expected, and that no errors 
were produced. We don't rely on manual testing as a primary way of catching 
bugs; we automate everything we can.

If the staging deployment or configuration change doesn't show any problems, we 
continue to production. Production has the same suite of automated live tests 
as staging. And similar to staging, for significant changes we do additional 
manual testing. It was this step that caught the encoding issue, when one of 
our staff used crt.sh's lint tool to double check the test certificate they 
issued.

Clearly we should have caught this earlier in the process. The changes we have 
in the pipeline (integrating certlint and/or zlint) would have automatically 
caught the encoding issue at each staging in the pipeline: in development, in 
staging, and in production.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[Matthew Hardeman via dev-security-policy]

On Tue, Mar 13, 2018 at 4:02 PM, Ryan Sleevi  wrote:

>
>
> On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy
>  wrote:
>
>> I am not at all suggesting consequences for Let's Encrypt, but rather
>> raising a question as to whether that position on new inclusions /
>> renewals
>> is appropriate.  If these things can happen in a celebrated best-practices
>> environment, can they really in isolation be cause to reject a new
>> application or a new root from an existing CA?
>>
>
> While I certainly appreciate the comparison, I think it's apples and
> oranges when we consider both the nature and degree, nor do I think it's
> fair to suggest "in isolation" is a comparison.
>

I thought I recalled a recent case in which a new root/key was declined
with the sole unresolved (and unresolvable, save for new key generation,
etc.) matter precluding the inclusion being a prior mis-issuance of test
certificates, already revoked and disclosed.  Perhaps I am mistaken.



>
> I'm sure you can agree that incident response is defined by both the
> nature and severity of the incident itself, the surrounding ecosystem
> factors (i.e. was this a well-understood problem), and the detection,
> response, and disclosure practices that follow. A system that does not
> implement any checks whatsoever is, I hope, something we can agree is worse
> than a system that relies on human checks (and virtually indistinguishable
> from no checks), and that both are worse than a system with incomplete
> technical checks.
>
>
I certainly concur with all of that, which is the part of the basis for
which I form my own opinion that Let's Encrypt should not suffer any
consequence of significance beyond advice along the lines of "make your
testing environment and procedures better".


> I do agree with you that I find it challenging with how the staging
> environment was tested - failure to have robust profile tests in staging,
> for example, are what ultimately resulted in Turktrust's notable
> misissuance of unconstrained CA certificates. Similarly, given the wide
> availability of certificate linting tools - such as ZLint, x509Lint,
> (AWS's) certlint, and (GlobalSign's) certlint - there's no dearth of
> availability of open tools and checks. Given the industry push towards
> integration of these automated tools, it's not entirely clear why LE would
> invent yet another, but it's also not reasonable to require that LE use
> something 'off the shelf'.
>

I'm very interested in how the testing occurs in terms of procedures.  I
would assume, for example, that no test transaction of any kind would ever
be "played" against a production environment unless that same exact test
transaction had already been "played" against the staging environment.
With respect to this case, were these wildcard certificates requested and
issued against the staging system with materially the same test transaction
data, and if so was the encoding incorrect?  If these were not performed
against staging, what was the rational basis for executing a new and novel
test transaction against the production system first?  If they were
performed AND if they did not encode incorrectly, then what was the
disparity between the environments which led to this?  (The implication
being that some sort of change management process needs to be revised to
keep the operating environments of staging and production better
synchronized.)  If they were performed and were improperly encoded on the
staging environment, then one would presume that the erroneous result was
missed by the various automated and manual examinations of the results of
the tests.

As you note, it's unreasonable to require use of any particular
implementation of any particular tool but in as far as the other tools
achieve certain results while clearly the LE developed tools did not catch
this issue, it would appear that LE needs to better test their testing
mechanisms and while it may not be necessary for them to incorporate the
competing tools in the live issuance pipeline, it would seem advisable that
Let's Encrypt should pass the output results (the certificates) of tests
within their staging environment through these various other testing tools
as part of a post-staging-deployment testing phase.  It would seem logical
to take the best of breed tools and stack them up whether automatically or
manually and waterfall the final output results of a full suite of test
scenarios against the post-deployment state of the staging environment,
with a view to identifying discrepancies between the LE tool opinion and
the external tool's opinion and reconciling those, rejecting invalid
determinations as appropriate.


>
> I'm hoping that LE can provide more details about the change management
> process and how, in light of this incident, it may change - both in terms
> of automated testing and in certificate policy review.
>
>
>> Another question this incident 

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[jsha--- via dev-security-policy]

On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote:
> availability of certificate linting tools - such as ZLint, x509Lint,
> (AWS's) certlint, and (GlobalSign's) certlint - there's no dearth of
> availability of open tools and checks. Given the industry push towards
> integration of these automated tools, it's not entirely clear why LE would
> invent yet another, but it's also not reasonable to require that LE use
> something 'off the shelf'.

We are indeed planning to integrate GlobalSign's certlint and/or zlint into our 
existing cert-checker pipeline rather than build something new. We've already 
started submitting issues and PRs, in order to give back to the ecosystem:

https://github.com/zmap/zlint/issues/212
https://github.com/zmap/zlint/issues/211
https://github.com/zmap/zlint/issues/210
https://github.com/globalsign/certlint/pull/5

If your question is why we wrote cert-checker rather than use something 
off-the-shelf: cablint / x509lint weren't available at the time we wrote 
cert-checker. When they became available we evaluated them for production 
and/or CI use, but concluded that the complex dependencies and difficulty of 
productionizing them in our environment outweighed the extra confidence we 
expected to gain, especially given that our certificate profile at the time was 
very static. A system improvement we could have made here would have been to 
set "deploy cablint or its equivalent" as a blocker for future certificate 
profile changes. I'll add that to our list of items for remediation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I am not at all suggesting consequences for Let's Encrypt, but rather
> raising a question as to whether that position on new inclusions / renewals
> is appropriate.  If these things can happen in a celebrated best-practices
> environment, can they really in isolation be cause to reject a new
> application or a new root from an existing CA?
>

While I certainly appreciate the comparison, I think it's apples and
oranges when we consider both the nature and degree, nor do I think it's
fair to suggest "in isolation" is a comparison.

I'm sure you can agree that incident response is defined by both the nature
and severity of the incident itself, the surrounding ecosystem factors
(i.e. was this a well-understood problem), and the detection, response, and
disclosure practices that follow. A system that does not implement any
checks whatsoever is, I hope, something we can agree is worse than a system
that relies on human checks (and virtually indistinguishable from no
checks), and that both are worse than a system with incomplete technical
checks.

I do agree with you that I find it challenging with how the staging
environment was tested - failure to have robust profile tests in staging,
for example, are what ultimately resulted in Turktrust's notable
misissuance of unconstrained CA certificates. Similarly, given the wide
availability of certificate linting tools - such as ZLint, x509Lint,
(AWS's) certlint, and (GlobalSign's) certlint - there's no dearth of
availability of open tools and checks. Given the industry push towards
integration of these automated tools, it's not entirely clear why LE would
invent yet another, but it's also not reasonable to require that LE use
something 'off the shelf'.

I'm hoping that LE can provide more details about the change management
process and how, in light of this incident, it may change - both in terms
of automated testing and in certificate policy review.


> Another question this incident raised in my mind pertains to the parallel
> staging and production environment paradigm:  If one truly has the 'courage
> of conviction' of the equivalence of the two environments, why would one
> not perform all tests in ONLY the staging environment, with no tests and
> nothing other than production transactions on the production environment?
> That tests continue to be executed in the production environment while
> holding to the notion that a fully parallel staging environment is the
> place for tests seems to signal that confidence in the staging environment
> is -- in some measure, however small -- limited.


That's ... just a bad conclusion, especially for a publicly-trusted CA :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[Matthew Hardeman via dev-security-policy]

The fact that this mis-issuance occurred does raise a question for the
community.

For quite some time, it has been repeatedly emphasized that maintaining a
non-trusted but otherwise identical staging environment and practicing all
permutations of tests and issuances -- especially involving new
functionality -- on that parallel staging infrastructure is the mechanism
by which mis-issuances such as those mentioned in this thread may be
avoided within production environments.

Let's Encrypt has been a shining example of best practices up to this point
and has enjoyed the attendant minimization of production issues (presumably
as a result of exercising said best practices).

Despite that, however, either the test cases which resulted in these
mis-issuances were not first executed on the staging platform or did not
result in the mis-issuance there.  A reference was made to a Go lang
library error / non-conformance being implicated.  Were the builds for
staging and production compiled on different releases of Go lang?

Certainly, I think these particular mis-issuances do not significantly
affect the level of trust which should be accorded to ISRG / Let's Encrypt.

Having said that, however, it is worth noting that in a fully new and novel
PKI infrastructure, it seems likely -- based on recent inclusion / renewal
requests -- that such a mis-issuance would recently have resulted in a
disqualification of a given root / key with guidance to cut a new root PKI
and start the process over.

I am not at all suggesting consequences for Let's Encrypt, but rather
raising a question as to whether that position on new inclusions / renewals
is appropriate.  If these things can happen in a celebrated best-practices
environment, can they really in isolation be cause to reject a new
application or a new root from an existing CA?

Another question this incident raised in my mind pertains to the parallel
staging and production environment paradigm:  If one truly has the 'courage
of conviction' of the equivalence of the two environments, why would one
not perform all tests in ONLY the staging environment, with no tests and
nothing other than production transactions on the production environment?
That tests continue to be executed in the production environment while
holding to the notion that a fully parallel staging environment is the
place for tests seems to signal that confidence in the staging environment
is -- in some measure, however small -- limited.


On Tue, Mar 13, 2018 at 8:46 AM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, March 13, 2018 at 3:33:50 AM UTC-5, Tom wrote:
> > > During final tests for the general availability of wildcard
> > certificate support, the Let's Encrypt operations team issued six test
> > wildcard certificates under our publicly trusted root:
> >  >
> >  > https://crt.sh/?id=353759994
> >  > https://crt.sh/?id=353758875
> >  > https://crt.sh/?id=353757861
> >  > https://crt.sh/?id=353756805
> >  > https://crt.sh/?id=353755984
> >  > https://crt.sh/?id=353754255
> >  >
> > Somebody noticed there
> > https://community.letsencrypt.org/t/acmev2-and-wildcard-
> launch-delay/53654/62
> > that the certificate of *.api.letsencrypt.org (apparently currently in
> > use), issued by "TrustID Server CA A52" (IdenTrust) seams to have the
> > same problem:
> > https://crt.sh/?id=8373036=cablint,x509lint
>
> I think it's just a coincidence that we got a wildcard cert from IdenTrust
> a long time ago and it happens to have the same encoding issue that we ran
> into. I notified IdenTrust in case they haven't fixed the problem since
> then.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Kathleen Wilson via dev-security-policy]

As I didn't write the blog post, I certainly can't speak to the
intent 




The intent of the blog post was to let folks know about an error they 
may encounter when Firefox 60 goes into Beta. And to have a place to 
point folks to if they run into the error and ask about it.


It was *not* our intent to imply any deviation from the consensus proposal.

If clarification is needed, let's update the wiki page to add it:

https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

Please let me and Wayne know what changes you think should be made to 
the wiki page to clarify the changes.


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

Re: Mozilla Security Blog re Symantec TLS Certs

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 13, 2018 at 11:50 AM, Ryan Sleevi  wrote:

>
>
> On Tue, Mar 13, 2018 at 11:26 AM, Kai Engert  wrote:
>
>> On 13.03.2018 15:59, Peter Bowen wrote:
>> >>
>> >> Which companies, other than Apple and Google, benefit from DigiCert
>> >> running the Manager Partner Infrastructure and from DigiCert being part
>> >> of the exclusion list?
>> >
>> > An unlimited set.  Any company who purchases a certificate from
>> > DigiCert that is issued by one of the Managed Partner Infrastructure
>> > CAs benefits.
>>
>> Thank you very much for this helpful statement.
>>
>> I understand that previously, the trust of DigiCert Partner CAs was
>> enabled by signing from Symantec CAs.
>>
>> Because the keys of the managed partner CAs were never controlled by
>> Symantec, it is deemed acceptable to allow these to remain trusted.
>>
>> My conclusion is, the blog post is incomplete.
>>
>
> I see. As I didn't write the blog post, I certainly can't speak to the
> intent, but I don't agree with your conclusion.
>

If it helps with framing the discussion any, I think one possible
misinterpretation may be reading "Distrust of Symantec" to be "Distrust of
these specific keys". Rather, the Symantec Legacy PKI (as referenced in the
consensus proposal) is the set of infrastructure, practices, policies, and
systems that comprised the failed systems, and all certificates issued by
and all information verified by that information. The Managed Partner
Infrastructure is a new set of infrastructure, practices, policies, and
systems, which issue new certificates and which verify information
correctly.

Distrust in the Legacy PKI is ongoing, and the whitelist is not an
exception from that distrust - it's a reflection that these parties were
not part of the Legacy PKI. DigiCert's Managed/Transition Roots are a new
PKI, as part of the Managed Partner Infrastructure, which the transition
policy explained would be trusted.

Distrusting the keys used as the root of trust for that Legacy PKI is one
technical solution. But, as a technical solution, it distrusts more than
what the consensus proposal required or stated. Hence, whitelists - which
are simply implementations of what the consensus protocol stated. There are
other ways one could imagine accomplishing distrust in the Legacy PKI -
blacklists of intermediates or leaves, for example - that have different
technical tradeoffs and different risks (many of which, incidentally, were
discussed last year).

Perhaps that framing helps think about it - it's not necessarily the keys
being distrusted, it's everything related to those keys. Distrusting the
keys is simply a technically-sound means to accomplish that, but in doing
so, it's also necessary to carve out that which was explicitly not part of
the distrust proposal.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Kai Engert via dev-security-policy]

On 13.03.2018 15:59, Peter Bowen wrote:
>>
>> Which companies, other than Apple and Google, benefit from DigiCert
>> running the Manager Partner Infrastructure and from DigiCert being part
>> of the exclusion list?
> 
> An unlimited set.  Any company who purchases a certificate from
> DigiCert that is issued by one of the Managed Partner Infrastructure
> CAs benefits.

Thank you very much for this helpful statement.

I understand that previously, the trust of DigiCert Partner CAs was
enabled by signing from Symantec CAs.

Because the keys of the managed partner CAs were never controlled by
Symantec, it is deemed acceptable to allow these to remain trusted.

My conclusion is, the blog post is incomplete.

IIUC, the blog post should be updated to add DigiCert as another entity
controlling subordinate CAs on the exception list.

It might be worth to mention in the article, why the exception for these
subordinate CAs is deemed acceptable.

IMHO, it is important to highlight that Apple and Google aren't the only
entities that own certificates that will remain valid under the Symantec
hierarchy.

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

Re: Mozilla Security Blog re Symantec TLS Certs

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 13, 2018 at 10:52 AM, Peter Bowen  wrote:

> On Tue, Mar 13, 2018 at 7:19 AM, Kai Engert via dev-security-policy
>  wrote:
> > On 13.03.2018 14:59, Ryan Sleevi wrote:
> >> the blog post says, the subCAs controlled by Apple and Google are
> the
> >> ONLY exceptions.
> >>
> >> However, the Mozilla Firefox code also treats certain DigiCert
> subCAs as
> >> exceptions.
> >>
> >> Based on Ryan Sleevi's recent comments on this list, I had concluded
> >> that the excluded DigiCert subCAs are used to support companies
> other
> >> than Apple and Google. Is my understanding right or wrong?
> >>
> >>
> >> I think your understanding is incorrect. The DigiCert SubCAs are being
> >> treated as part of the Managed Partner Infrastructure (aka the consensus
> >> plan), and the (cross-signed DigiCert Roots) are excluded to avoid path
> >> building issues in Firefox.
> >
> > Your earlier explanations were very complex, and had increased my
> > uncertainty about who is covered by the Managed Partner Infrastructure.
> >
> > In your earlier explanations, you had mentioned additional company names
> > besides Apple and Google. This had given me the impression that the
> > Managed Partner Infrastructure isn't limited to support the Apple and
> > Google companies, but to also support other companies.
> >
> >
> >> That is, the exclusion of those DigiCert Sub-CAs *is* the consensus plan
> >> referred to - what else could it be?
> >>
> >>
> >> Are Apple and Google really the only beneficials of the exceptions,
> or
> >> should the blog post get updated to mention the additional
> exceptions?
> >>
> >>
> >> Do you think the above clarifies?
> >
> > I hope we are close.
> >
> > I really wish we could bring it down to a simple yes or no question, and
> > you being able to respond with a clear yes or no.
> >
> > Let me try again.
> >
> > Are the DigiCert transition CAs, which are part of the exclusion list,
> > and which you say are used for "Managed Partner Infrastructure",
> > strictly limited to support the needs of the Apple and Google companies?
>
> I'll try answering and let Ryan correct me.
>
> Managed Partner Infrastructure CAs are NOT strictly limited to support
> the needs of Apple/Google.
>
> As I understand it, there are five different sets of CAs when it comes
> to applying trust rules:
>
> 1) CAs that are not cross-signed by any of the roots owned by Symantec
> as of June 2017 ("Symantec roots").  This is the majority of CAs in
> the world.
>
> 2) Online/Non-root CAs that are cross-signed by a Symantec root and
> which had their own non-Symantec audit as of June 2017 and have
> current audits - this is currently a set of CAs owned by Alphabet and
> Apple companies
>
> 3) Root CAs that are cross-signed by a Symantec root and which had
> their own non-Symantec audit as of June 2017 and have current audits -
> this is currently a set of root CAs that are owned by DigiCert and
> that existed prior to DigiCert acquiring the Symantec roots
>
> 4) CAs that are cross-signed by a Symantec root which were explicitly
> created for compatibility with existing clients.  These are not
> cross-signed by any roots that are not Symantec roots.  These were
> created by DigiCert are not under their DigiCert branded CAs; they are
> the "Managed Partner Infrastructure" CAs.
>
> 5) Any CAs not covered above (that is a CAs cross-signed by a Symantec
> root but not in #2, #3, or #4).
>
> CAs in group #2, #3, and #4 are able to continue issuing.  #4 have a
> maximum validity period restriction that is less than the BR maximum.
> #5 CAs are not trusted for certificates issued after
> 2017-12-01T00:00:00Z or before 2016-06-01T00:00:00Z.
>
> Does this make it clear?
> Ryan, did I get this wrong?
>

#4 is only limited in validity if Symantec was involved/validation
information was reused. As stated by DigiCert, there's been zero
involvement in the validation and zero-reuse of validated information,
hence, issuance times are permitted to the maximum BR allowed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Peter Bowen via dev-security-policy]

On Tue, Mar 13, 2018 at 7:55 AM, Kai Engert via dev-security-policy
 wrote:
> On 13.03.2018 15:35, Ryan Sleevi via dev-security-policy wrote:
>>
>>> Are the DigiCert transition CAs, which are part of the exclusion list,
>>> and which you say are used for "Managed Partner Infrastructure",
>>> strictly limited to support the needs of the Apple and Google companies?
>>
>>
>> No.
>
> If the answer is "no", it means there are additional beneficials besides
> Apple and Google.
>
>
>> Apple is Apple. Google is Google. DigiCert is running the Managed Partner
>> Infrastructure from the consensus plan, using the two transition CAs, in
>> addition to the two pre-existing roots participating in Mozilla's root
>> store.
>
> Which companies, other than Apple and Google, benefit from DigiCert
> running the Manager Partner Infrastructure and from DigiCert being part
> of the exclusion list?

An unlimited set.  Any company who purchases a certificate from
DigiCert that is issued by one of the Managed Partner Infrastructure
CAs benefits.

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

Re: Mozilla Security Blog re Symantec TLS Certs

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 13, 2018 at 10:55 AM, Kai Engert  wrote:

> On 13.03.2018 15:35, Ryan Sleevi via dev-security-policy wrote:
> >
> >> Are the DigiCert transition CAs, which are part of the exclusion list,
> >> and which you say are used for "Managed Partner Infrastructure",
> >> strictly limited to support the needs of the Apple and Google companies?
> >
> >
> > No.
>
> If the answer is "no", it means there are additional beneficials besides
> Apple and Google.
>
>
> > Apple is Apple. Google is Google. DigiCert is running the Managed Partner
> > Infrastructure from the consensus plan, using the two transition CAs, in
> > addition to the two pre-existing roots participating in Mozilla's root
> > store.
>
> Which companies, other than Apple and Google, benefit from DigiCert
> running the Manager Partner Infrastructure and from DigiCert being part
> of the exclusion list?
>

Kai,

Please see if Peter's answer helps. I will be happy to answer follow-up
questions if you are still confused, but I do want to stress, the Managed
Partner Infrastructure consensus plan, discussed for months, addresses both
the reasoning and the risk.

Apple and Google *do not* benefit from the Managed Partner Infrastructure.
They could, but at present, they do not. Hopefully, Peter's decomposition
addresses the confusion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Kai Engert via dev-security-policy]

On 13.03.2018 15:35, Ryan Sleevi via dev-security-policy wrote:
> 
>> Are the DigiCert transition CAs, which are part of the exclusion list,
>> and which you say are used for "Managed Partner Infrastructure",
>> strictly limited to support the needs of the Apple and Google companies?
> 
> 
> No.

If the answer is "no", it means there are additional beneficials besides
Apple and Google.


> Apple is Apple. Google is Google. DigiCert is running the Managed Partner
> Infrastructure from the consensus plan, using the two transition CAs, in
> addition to the two pre-existing roots participating in Mozilla's root
> store.

Which companies, other than Apple and Google, benefit from DigiCert
running the Manager Partner Infrastructure and from DigiCert being part
of the exclusion list?

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

Re: Mozilla Security Blog re Symantec TLS Certs

[Peter Bowen via dev-security-policy]

On Tue, Mar 13, 2018 at 7:19 AM, Kai Engert via dev-security-policy
 wrote:
> On 13.03.2018 14:59, Ryan Sleevi wrote:
>> the blog post says, the subCAs controlled by Apple and Google are the
>> ONLY exceptions.
>>
>> However, the Mozilla Firefox code also treats certain DigiCert subCAs as
>> exceptions.
>>
>> Based on Ryan Sleevi's recent comments on this list, I had concluded
>> that the excluded DigiCert subCAs are used to support companies other
>> than Apple and Google. Is my understanding right or wrong?
>>
>>
>> I think your understanding is incorrect. The DigiCert SubCAs are being
>> treated as part of the Managed Partner Infrastructure (aka the consensus
>> plan), and the (cross-signed DigiCert Roots) are excluded to avoid path
>> building issues in Firefox.
>
> Your earlier explanations were very complex, and had increased my
> uncertainty about who is covered by the Managed Partner Infrastructure.
>
> In your earlier explanations, you had mentioned additional company names
> besides Apple and Google. This had given me the impression that the
> Managed Partner Infrastructure isn't limited to support the Apple and
> Google companies, but to also support other companies.
>
>
>> That is, the exclusion of those DigiCert Sub-CAs *is* the consensus plan
>> referred to - what else could it be?
>>
>>
>> Are Apple and Google really the only beneficials of the exceptions, or
>> should the blog post get updated to mention the additional exceptions?
>>
>>
>> Do you think the above clarifies?
>
> I hope we are close.
>
> I really wish we could bring it down to a simple yes or no question, and
> you being able to respond with a clear yes or no.
>
> Let me try again.
>
> Are the DigiCert transition CAs, which are part of the exclusion list,
> and which you say are used for "Managed Partner Infrastructure",
> strictly limited to support the needs of the Apple and Google companies?

I'll try answering and let Ryan correct me.

Managed Partner Infrastructure CAs are NOT strictly limited to support
the needs of Apple/Google.

As I understand it, there are five different sets of CAs when it comes
to applying trust rules:

1) CAs that are not cross-signed by any of the roots owned by Symantec
as of June 2017 ("Symantec roots").  This is the majority of CAs in
the world.

2) Online/Non-root CAs that are cross-signed by a Symantec root and
which had their own non-Symantec audit as of June 2017 and have
current audits - this is currently a set of CAs owned by Alphabet and
Apple companies

3) Root CAs that are cross-signed by a Symantec root and which had
their own non-Symantec audit as of June 2017 and have current audits -
this is currently a set of root CAs that are owned by DigiCert and
that existed prior to DigiCert acquiring the Symantec roots

4) CAs that are cross-signed by a Symantec root which were explicitly
created for compatibility with existing clients.  These are not
cross-signed by any roots that are not Symantec roots.  These were
created by DigiCert are not under their DigiCert branded CAs; they are
the "Managed Partner Infrastructure" CAs.

5) Any CAs not covered above (that is a CAs cross-signed by a Symantec
root but not in #2, #3, or #4).

CAs in group #2, #3, and #4 are able to continue issuing.  #4 have a
maximum validity period restriction that is less than the BR maximum.
#5 CAs are not trusted for certificates issued after
2017-12-01T00:00:00Z or before 2016-06-01T00:00:00Z.

Does this make it clear?
Ryan, did I get this wrong?

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

Re: Mozilla Security Blog re Symantec TLS Certs

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 13, 2018 at 10:19 AM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 13.03.2018 14:59, Ryan Sleevi wrote:
> > the blog post says, the subCAs controlled by Apple and Google are the
> > ONLY exceptions.
> >
> > However, the Mozilla Firefox code also treats certain DigiCert
> subCAs as
> > exceptions.
> >
> > Based on Ryan Sleevi's recent comments on this list, I had concluded
> > that the excluded DigiCert subCAs are used to support companies other
> > than Apple and Google. Is my understanding right or wrong?
> >
> >
> > I think your understanding is incorrect. The DigiCert SubCAs are being
> > treated as part of the Managed Partner Infrastructure (aka the consensus
> > plan), and the (cross-signed DigiCert Roots) are excluded to avoid path
> > building issues in Firefox.
>
> Your earlier explanations were very complex, and had increased my
> uncertainty about who is covered by the Managed Partner Infrastructure.
>
> In your earlier explanations, you had mentioned additional company names
> besides Apple and Google. This had given me the impression that the
> Managed Partner Infrastructure isn't limited to support the Apple and
> Google companies, but to also support other companies.
>

OK, I think the confusion is what Managed Partner Infrastructure is.

There is Apple. There is Google. There is the Managed Partner
Infrastructure. These are three, separate things from the point-of-view of
the Consensus plan.

That consensus document, unchanged since the announcement, is
https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/edit


> Are the DigiCert transition CAs, which are part of the exclusion list,
> and which you say are used for "Managed Partner Infrastructure",
> strictly limited to support the needs of the Apple and Google companies?


No.

Apple is Apple. Google is Google. DigiCert is running the Managed Partner
Infrastructure from the consensus plan, using the two transition CAs, in
addition to the two pre-existing roots participating in Mozilla's root
store.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Kai Engert via dev-security-policy]

On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote:
> Wayne and I have posted a Mozilla Security Blog regarding the current
> plan for distrusting the Symantec TLS certs.
> 
> https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/

Hello Kathleen and Wayne,

could you please clarify the plan for Firefox ESR (Enterprise Support
Version) ?

Firefox 63 and Firefox ESR 60.3 will be released on the same date.

Does Mozilla plan to implement the identical distrust in both Firefox 63
and Firefox ESR 60.3 ?

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

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[josh--- via dev-security-policy]

On Tuesday, March 13, 2018 at 3:33:50 AM UTC-5, Tom wrote:
> > During final tests for the general availability of wildcard 
> certificate support, the Let's Encrypt operations team issued six test 
> wildcard certificates under our publicly trusted root:
>  >
>  > https://crt.sh/?id=353759994
>  > https://crt.sh/?id=353758875
>  > https://crt.sh/?id=353757861
>  > https://crt.sh/?id=353756805
>  > https://crt.sh/?id=353755984
>  > https://crt.sh/?id=353754255
>  >
> Somebody noticed there 
> https://community.letsencrypt.org/t/acmev2-and-wildcard-launch-delay/53654/62 
> that the certificate of *.api.letsencrypt.org (apparently currently in 
> use), issued by "TrustID Server CA A52" (IdenTrust) seams to have the 
> same problem:
> https://crt.sh/?id=8373036=cablint,x509lint

I think it's just a coincidence that we got a wildcard cert from IdenTrust a 
long time ago and it happens to have the same encoding issue that we ran into. 
I notified IdenTrust in case they haven't fixed the problem since then.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Jeremy Rowley via dev-security-policy]

Same question. Does this mean the key used to sign the digicert roots is 
subject to the distrust without exception?

> On Mar 13, 2018, at 1:36 PM, Kai Engert via dev-security-policy 
>  wrote:
> 
>> On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote:
>> Wayne and I have posted a Mozilla Security Blog regarding the current
>> plan for distrusting the Symantec TLS certs.
>> 
>> https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/
> 
> Hello Kathleen and Wayne,
> 
> the blog post says, the subCAs controlled by Apple and Google are the
> ONLY exceptions.
> 
> However, the Mozilla Firefox code also treats certain DigiCert subCAs as
> exceptions.
> 
> Based on Ryan Sleevi's recent comments on this list, I had concluded
> that the excluded DigiCert subCAs are used to support companies other
> than Apple and Google. Is my understanding right or wrong?
> 
> Are Apple and Google really the only beneficials of the exceptions, or
> should the blog post get updated to mention the additional exceptions?
> 
> Thanks
> Kai
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Kai Engert via dev-security-policy]

On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote:
> Wayne and I have posted a Mozilla Security Blog regarding the current
> plan for distrusting the Symantec TLS certs.
> 
> https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/

Hello Kathleen and Wayne,

the blog post says, the subCAs controlled by Apple and Google are the
ONLY exceptions.

However, the Mozilla Firefox code also treats certain DigiCert subCAs as
exceptions.

Based on Ryan Sleevi's recent comments on this list, I had concluded
that the excluded DigiCert subCAs are used to support companies other
than Apple and Google. Is my understanding right or wrong?

Are Apple and Google really the only beneficials of the exceptions, or
should the blog post get updated to mention the additional exceptions?

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

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

[Tom via dev-security-policy]

> During final tests for the general availability of wildcard 
certificate support, the Let's Encrypt operations team issued six test 
wildcard certificates under our publicly trusted root:

>
> https://crt.sh/?id=353759994
> https://crt.sh/?id=353758875
> https://crt.sh/?id=353757861
> https://crt.sh/?id=353756805
> https://crt.sh/?id=353755984
> https://crt.sh/?id=353754255
>
Somebody noticed there 
https://community.letsencrypt.org/t/acmev2-and-wildcard-launch-delay/53654/62 
that the certificate of *.api.letsencrypt.org (apparently currently in 
use), issued by "TrustID Server CA A52" (IdenTrust) seams to have the 
same problem:

https://crt.sh/?id=8373036=cablint,x509lint
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy