Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Andrew Ayer via dev-security-policy]

On Fri, 12 Mar 2021 04:57:56 -0800 (PST)
Pablo D__az via dev-security-policy
 wrote:

> [...]
>
> I completely agree that "Human error" is not an acceptable analysis,
> and "training improvement" is not the optimal solution.  We have
> worked to apply as many automatic controls as possible to reduce any
> possible human error to a minimum, and the team of engineers who made
> those mistakes at that time are no longer in our organization.

The fact that this team of engineers is no longer in your organization
doesn't address the concerns; if anything, it raises more concerns.
The reason we reject human error as a root cause, which you don't seem
to understand because you mention the engineers, is that failures are
NOT the fault of humans who make mistakes.  They're the fault of the
system which failed to prevent the mistakes.

The mention of the engineers, coupled with the note in the incident
report about "Disciplinary Measures and Sanctions", suggests that ANF
intends to use the threat of punishment to try to prevent mistakes.
Meanwhile, ANF is still relying on error-prone manual domain
validation, as we shall see below.

> [...]
>
> Regarding domain validation, we are able to use the BR methods
> (3.2.2.4.2), (3.2.2.4.4) or (3.2.2.4.15). Measures have been applied
> to ensure that domain validation is not skipped:
> * In the request
> process, emails built using 'admin', 'administrator', 'webmaster',
> 'hostmaster', or 'postmaster' + @ + apex domain are automatically
> listed. The random request confirmation code will be automatically
> sent to this email. 

What is the process for verifying that the applicant knows the correct
Random Value?

> * In case of being multidomain, one of them is
> chosen to send the confirmation code and the rest, each one will be
> manually validated in the validation process (which also includes
> verification of documentation and other data) by our IRM staff
> (Issuance Reports Managers) 

This alone should be grounds for rejecting the application, and shows
that your above claim that ANF has applied "as many automatic controls
as possible" is false.  We've repeatedly seen how error-prone manual
domain validation processes are.  CAs, especially those who have a
history of failure, should not be issuing certificates using manual
domain validation.

> * Before confirming the issuance order,
> the IRM staff must indicate, for EACH domain, which domain validation
> method (of those indicated in ANF AC CP) was used, with current BR
> version number and attach files that provide evidence for this.
> Othewise it cannot proceed with issuance.

In an automated system, it's unnecessary for staff to manually indicate
this, as the system knows which domain validation method was used.
What is the process for ensuring that staff do not report the incorrect
validation method, or report that domain validation was completed when
it really wasn't?

> In addition to this, we have automatic pre-issuance lint using
> cablint, x509lint and zlint.

While this is good practice for ensuring that RFC 5280-violating certificates
are not issued, it does not prevent certificates from being issued without
proper domain validation, so it's not responsive to the core concern of
ANF's failure to perform domain validation.

Although this response does highlight some good practices that ANF has
adopted, like preissuance linting and subscribing to the CA-related
components in Bugzilla, it ultimately reinforces the core concerns I
raised in my original post: the reliance on manual domain validation,
and an incident response philosophy that blames humans instead of
addressing root causes.

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

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

[Andrew Ayer via dev-security-policy]

On Wed, 10 Mar 2021 13:43:55 -0700
Ben Wilson via dev-security-policy
 wrote:

> This is to announce the beginning of the public discussion phase of
> the Mozilla root CA inclusion process for the ANF Secure Server Root
> CA.

I'd like to draw attention to the first misissuance mentioned
in  and
.
Although this misissuance occurred under ANF's old hierarchy, that
hierarchy is/was trusted by Apple and Microsoft, and ANF was requesting
its inclusion in Mozilla, so the incident is relevant to understanding
how ANF operates a publicly-trusted certificate authority.

In 2019, ANF issued a server certificate

with a DNS name of cdcdcd.  Obviously, they could not have possibly
validated domain control of this hostname, which is a serious failure
considering that domain validation is the most important task a
CA performs.  However, their incident report doesn't mention domain
validation at all.  They blamed the incident on human error by "junior
engineers" and their resolution was to implement a blocklist of words
that indicate a test certificate ("Test", "Testing", "Prueba"), provide
more training for junior engineers, and update their "Disciplinary
Measures and Sanctions document, in order to have this resources
available in case of infringement".  None of these resolutions address
the root failure to perform domain validation.  Had this incident
report been written several years earlier, it may have been excusable,
but by 2019 it was very clear to anyone following mdsp and CA incidents
that "human error" is not acceptable analysis and training is not an
adequate resolution.

Additionally, their incident report shows some pretty concerning
misunderstandings of PKI and the BRs:

1. A belief that the CABF's Test Certificate extension OID is meant for
testing their CA rather than a (now forbidden) domain validation method.

2. A belief that the CABF's Test Certificate extension OID is to be put
in the certificate policy extension rather than used as the ID for a
poison extension.

3. A conflation of the subject serial number and the certificate serial
number, stating that the subject serial number must contain 64 bits of
entropy.

Finally, note that the new hierarchy has issued zero end-entity
certificates known to CT, so the fact that the new hierarchy hasn't
misissued any certificates doesn't speak to the competence of ANF.
On the other hand, the history of misissuance in the old hierarchy,
ANF's misunderstandings of PKI, and the incredibly poor incident report
speak very poorly to ANF's competence and trustworthiness.  There is
no indication that they've corrected the root cause of their failure to
perform domain validation, and no reason to believe that their
compliance problems won't reoccur under their new hierarchy.

When Mozilla trusts a CA, Mozilla is giving an assurance to its users
that they won't be harmed by the CA.  A CA which has lax technical
controls, a poor understanding of PKI, and an inability to learn from
and improve when mistakes are made is at heightened risk of
exploitation by malicious actors that would harm Mozilla users.  I do
not believe Mozilla can give assurance to their users that ANF is safe.
Therefore, this application should be rejected.

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

The CAA DNS Operator Exception Is Problematic

[Andrew Ayer via dev-security-policy]

The BRs permit CAs to bypass CAA checking for a domain if "the CA or
an Affiliate of the CA is the DNS Operator (as defined in RFC 7719)
of the domain's DNS."

Much like the forbidden "any other method" of domain validation, the DNS
operator exception is perilously under-specified. It doesn't say how
to determine who the DNS operator of a domain is, when to check, or for
how long this information can be cached.  Since the source of truth for a
domain's DNS operator is the NS record in the parent zone, I believe the
correct answer is to check at issuance time by doing a recursive lookup
from the root zone until the relevant NS record is found, and caching
for no longer than the NS record's TTL.  Unfortunately, resolvers do
not typically provide an implementation of this algorithm, so CAs would
have to implement it themselves.  Considering that CAs are not generally
DNS experts and there are several almost-correct-but-subtly-wrong ways
to implement it, I have little faith that CAs will implement this
check correctly.  My experience having implemented both a CAA lookup
algorithm and an algorithm to determine a domain's DNS operator is that
it's actually easier to implement CAA, as all the nasty DNS details can
be handled by the resolver. This leads me to conclude that the only CAs
who think they are saving effort by relying on the DNS operator exception
are doing so incorrectly and insecurely.

A manifestation of my concerns is this incident involving Microsoft PKI
Services:

https://bugzilla.mozilla.org/show_bug.cgi?id=1670337

Until last month, Microsoft was not checking CAA, but instead relying on
the DNS operator exception.  Despite this, they misissued certificates
for both a nonexistent domain and a domain for which they were not the
DNS operator, demonstrating that they had not correctly implemented
the exception.  Although Microsoft is now checking CAA for routine
issuances, they are retaining the DNS operator exception for "one off"
issuances, and the process they intend to use involves manually using
the websites https://dns.google.com/ and
https://toolbox.googleapps.com/apps/dig/, which is both a forbidden use
of Delegated Third Parties, and probably not correct because these
tools don't allow you to make non-recursive requests directly to
authoritative servers as required by the above algorithm.

Considering the under-specification of the DNS operator exception and
the risk of CAs being enticed by the apparent but false simplicity of
the exception, I think Mozilla should ban the use of the DNS operator
exception just as it banned "any other method" of domain validation.
At the very least, it deserves a mention on the list of Problematic
Practices.

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

Re: Mozilla's Response to Camerfirma's Compliance Issues

[Andrew Ayer via dev-security-policy]

On Mon, 25 Jan 2021 22:21:31 -0700
Ben Wilson via dev-security-policy
 wrote:

> Camerfirma has responded to the list of issues by providing a Remediation 
> Plan,
> https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing,
> with a commitment to align Camerfirma to the highest level of standards of
> the Mozilla community.

For years, Camerfirma has promised to improve but failed to
deliver.  In 2017, they promised technical controls over DNS
names 
yet in 2019 they misissued for an unregistered domain
name because they "did not have the automatic controls yet"
.  In 2017,
they promised linting of all certificates, and are promising it
again in their latest remediation plan.  In 2019 they assured
Mozilla that they had contractual control over their sub-CAs
including mandatory revocation and use of a central lint service
.  Yet their
sub-CA Intesa Sanpaolo continued to delay revoking certificates
 that were
misissued with invalid stateOrProvinceNames
.  Now Camerfirma
is once again proposing to use contractual controls to remediate their
sub-CAs' problems.

Given Camerfirma's past behavior, why should Mozilla trust Camerfirma to
deliver on their latest remediation plan?  Mozilla's users should not
have to assume the risk of trusting Camerfirma while we wait to see if
this time, Camerfirma finally becomes a competent and trustworthy CA.
Instead of making Mozilla users assume the risk, Camerfirma should be
distrusted now.  When Camerfirma applies for re-inclusion, Mozilla can
evaluate whether the remediation plan has worked.

On Tue, 26 Jan 2021 16:01:31 -0700
Ben Wilson via dev-security-policy
 wrote:

> First, it has been Mozilla's long-standing position that, "We believe
> that the best approach to safeguarding secure browsing is to work with CAs
> as partners, to foster open and frank communication, and to be diligent
> in looking for ways to keep our users safe."  So, expect that we will
> take a well-thought and deliberate approach to this issue with Camerfirma.

The other part of this is "participation in Mozilla's CA Certificate
Program is at our sole discretion, and we will take whatever steps are
necessary to keep our users safe."

Mozilla has been working with Camerfirma since 2017 through the
many compliance bugs in Bugzilla.  In several cases, Camerfirma's
communications were lackluster or sluggish rather than "open and
frank.", e.g.:

- Failure to disclose misissuance that they were aware of:


- 4 week delay publishing incident report:


- 2 month delay publishing incident report:


- Failure to provide timely updates or explain reason for remediation
delays: 

Mozilla's years-long effort to work with Camerfirma has not produced
sufficient improvement.  It's now time for Mozilla to exercise its
discretion and distrust Camerfirma to keep its users safe.

> So, expect that we will take a well-thought and deliberate approach to this 
> issue with Camerfirma.

As a point of comparison, the "Summary of Camerfirma's Compliance Issues"
thread has received 20 comments from 12 distinct community-members which
are overwhelmingly critical of Camerfirma, including several comments
calling explicitly for distrust.  This new thread has attracted further
critical comments. The most similar previous incidents (small CAs with
a large number of compliance problems) were PROCERT and Certinomis.
Those discussion periods lasted just 14 and 30 days respectively, and
fewer people commented on them compared to the Camerfirma discussion.
The Camerfirma discussion has gone on for nearly 8 weeks at this point.
Camerfirma has received more deliberation than similar CAs did, and it's
inconsistent for Mozilla to prolong the discussion further.

> So there is another issue that needs to be considered, if distrust is
> chosen, whether to remove just the websites trust bit or to take action
> against all 4 roots, and if so, on what basis?

Like Wayne, I don't believe we have any reason to trust that Camerfirma
manages S/MIME certificate issuance any better than TLS certificate
issuance. Mozilla should distrust all Camerfirma roots so that both
Firefox and Thunderbird users are protected.

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

Re: Summary of Camerfirma's Compliance Issues

[Andrew Ayer via dev-security-policy]

On Sun, 17 Jan 2021 00:51:29 -0800 (PST)
Ramiro Mu__oz via dev-security-policy
 wrote:

> Some certificates may have been syntactically
> incorrect due to misinterpretation, but we have never compromised any
> vetting, identification or information validation.

This is false, as shown by incidents like
https://bugzilla.mozilla.org/show_bug.cgi?id=1672423
(issuing for a non-existent domain) and
https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 (not checking CAA),
not to mention the validation failures by sub-CAs for which Camerfirma
is ultimately responsible.  And even misissuances that are just
"syntactically incorrect" are concerning because they show a disregard
for the policies that exist to prevent harm to innocent parties.

It's troubling that even at this stage, Camerfirma still doesn't seem
to grasp the seriousness of their compliance problems. Today,
they are arguing that there was no security threat from a certificate
issued for a domain without authorization because the subdomain
in the certificate "does not exist": 
https://bugzilla.mozilla.org/show_bug.cgi?id=1672409#c8

Camerfirma was warned in 2018 that trust in their CA was in jeopardy,
yet compliance problems continued.  There is no reason to believe
Camerfirma will improve, and there are many indications that they won't.
Mozilla's users deserve CAs that take security more seriously than this.
It's time to take action to protect Mozilla's users by distrusting
Camerfirma.

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

Re: Digicert issued certificate with let's encrypts public key

[Andrew Ayer via dev-security-policy]

On Sat, 16 May 2020 14:02:42 +0200
Kurt Roeckx via dev-security-policy
 wrote:

> https://crt.sh/?id=1902422627
> 
> It's a certificate for api.pillowz.kz with the public key of Let's
> Encrypt Authority X1 and X3 CAs.
> 
> It's revoked since 2020-01-31, but I couldn't find any incident
> report related to it.

Hi Kurt,

It's not obvious what's non-compliant about this certificate - could you
explain?  Note that there is no requirement or security need for CAs to
validate proof of possession of a private key.  Therefore, it's
entirely acceptable for a subscriber to request a certificate for
someone else's public key, although the certificate would be useless to
them.

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

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Andrew Ayer via dev-security-policy]

Like others, I am concerned with the lack of transparency around this
proposal. Many of the options under consideration would be a departure
from Mozilla's no exceptions policy, which could have serious
consequences that undermine trust in Mozilla's root program.  This
ought to require compelling justification.  Yet the only evidence
provided are two examples of unrelated changes.

It is therefore not clear whether the EKU change (which as others have
pointed out is rather modest) is a problem for the entire industry,
just one CA (and if so, why only them?), or not a problem at all. And
given the history of CAs seizing whatever justification is available at
the moment, no matter how tenuous it may be, to try to delay changes,
the presumption should be that no delay is necessary.  Therefore, Mozilla
should not even be considering these alternatives without the CA first
providing solid evidence of the necessity, in an open and transparent
manner here on m.d.s.p.

Regards,
Andrew


On Sun, 19 Apr 2020 15:41:34 -0600
Ben Wilson via dev-security-policy
 wrote:

> Dear MDSP community,
> 
> As you are aware from past discussions on this list, there has been a
> concern about the impact of COVID-19 on CA operations.  COVID-19
> continues to impact certain areas of the world more severely than
> others. For example, there has been a recent resurgence of COVID-19
> in Japan.[1]  Globally, COVID-19 has not leveled out.[2]
> 
> Recently at least one CA has expressed concern about Action 3 of
> Mozilla's January 2020 CA Communication [3] and enforcement of
> Section 5.2 of Mozilla___s Root Store Policy, which provide that as of
> 1-July-2020, end-entity certificates MUST include an EKU extension
> containing KeyPurposeId(s) describing the intended usage(s) of the
> certificate, and the EKU extension MUST NOT contain the KeyPurposeId
> anyExtendedKeyUsage. See [4].
> 
> Some CAs (and their customers) located in Japan, the U.S., and
> elsewhere are dealing with new priorities that were not apparent back
> in January.  Some have had to reorganize to deal with reduced staff
> and reallocate resources, while other companies have modified their
> schedules to delay changes that might cause instability.[5], [6]
> 
> For some parties, the benefit of a 3-month delay (to 1-October-2020)
> in enforcement of Mozilla___s EKU requirement may result in more
> flexibility, resilience and secure operations.
> 
> Several options are being considered:
> 
> 1.   Require that a CA request an extension, to be submitted on
> Bugzilla and flagged as ___covid-19___, similar to audit delays [7] AND
> 
> a.   Not require an incident report, OR
> 
> b.   Require an incident report
> 
> 2.   Grant a blanket 3-month extension and not require revocation
> of certificates that do not comply
> 
> 3.   Replace July 1 with October 1 in section 5.2 of the Mozilla
> Root Store Policy and publish a new version
> 
> 4.   Recognize broader exceptions for COVID-19 issues, e.g.
> enlarge the scope of the delayed-audit approach to include other
> non-conformities/other issues and not require immediate certificate
> revocations
> 
> I look forward to hearing your opinions and suggestions.
> 
> Sincerely yours,
> 
> Ben Wilson
> 
> Endnotes:
> 
> [1]  https://apnews.com/9140ddd7283d534d8464778d9c4bd92a
> 
> [2]
> https://ourworldindata.org/coronavirus#what-is-the-total-number-of-confirmed-cases
> 
> [3]
> https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3waNOW=Q00086,Q00087,Q00097
> 
> 
> [4]
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices
> 
> [5]
> https://docs.microsoft.com/en-us/security/trusted-root/2020/april2020
> 
> [6]
> https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html
> 
> [7]  https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
> ___
> 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: About upcoming limits on trusted certificates

[Andrew Ayer via dev-security-policy]

On Wed, 11 Mar 2020 15:39:34 -0700
Kathleen Wilson via dev-security-policy
 wrote:

> What do you all think about also limiting the re-use of domain
> validation?

I'm strongly in favor of this change, and think domain validation reuse
should eventually be limited to a period much shorter than one year (days
or even hours), even if certificates lifetimes remain capped at one year.

Others have already touched on the issue of domain ownership transfer
(BygoneSSL), but I'd like to highlight a related issue: if a domain's
DNS, email, or web infrastructure is ever compromised, even briefly,
then the attacker can obtain two-year-long domain validation
authorizations from any number of CAs.  Then at any point in the next
two years, the attacker can obtain a one-year certificate, and ask the
CA not to log it to CT. Even if Firefox did enforce CT, the attacker
could wait to log the certificate until right before using it in an
attack.

The consequence of the above is that even if a website suffers a
fleeting compromise, they and their users are at risk of attack from
an illegitimate certificate for three entire years.  Anecdotally, I've
found that website operators are surprised when they learn this.  It's
intuitive that the attack window would be lower-bounded by certificate
lifetime, but the additional attack time from domain validation
reuse comes as an unpleasant surprise.

Therefore, Firefox should aim to make the attack window as close to the
maximum certificate lifetime as possible, which requires reducing
validation reuse time to the order of hours/days.  Limiting to one year
is a good first step.

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

Re: DigiCert OCSP services returns 1 byte

[Andrew Ayer via dev-security-policy]

On Fri, 13 Sep 2019 08:22:21 +
Rob Stradling via dev-security-policy
 wrote:

> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?

Yes, it's long past time that we clarified what this means:

"This signature indicates the CA's intent to issue the certificate.  This
intent is considered binding (i.e., misissuance of the precertificate is
considered equivalent to misissuance of the corresponding certificate)."

The goal is that a precertificate signature creates an unrebuttable
presumption that the CA has issued the corresponding certificate. If a
CA issues a precertificate, outside observers will treat the CA as if
it had issued the corresponding certificate - whether or not the CA
really did - so the CA should behave accordingly.

It's worth explicitly mentioning the implications of this:

* The CA needs to operate revocation services for the corresponding
certificate as if the certificate had been issued.

* If the corresponding certificate would be misissued, the CA will be
treated as if it had really issued that certificate.

Are there any other implications that 6962-bis should call out
explicitly?

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

Re: DigiCert OCSP services returns 1 byte

[Andrew Ayer via dev-security-policy]

Hi Wayne,

> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with Mozilla policy for all Precertificates as if
> > the corresponding certificate exists, and (ii) a CA must be able to revoke
> > a Precertificate if revocation of the certificate is required under Mozilla
> > policy and the corresponding certificate doesn’t actually exist and
> > therefore cannot be revoked.
> >
> 
> I will again welcome everyone's constructive feedback on this proposal, and
> when there are no further comments I'll add this to our wiki.

I'm concerned that the last paragraph could be interpreted as requiring
CAs to operate OCSP services for the literal precertificates issued by
dedicated precert signing CAs, rather than the corresponding
certificates. This is not intended or useful, and as Tim Shirley
notes it would double the OCSP signing load for any CA using precert
signing CAs.

I think it's better to frame the language not as operating OCSP
services for precertificates themselves, but for certificates presumed
to exist based on the presence of a precertifiate (even if the
certificate doesn't actually exist).

Here's some suggested wording for the last paragraph:

> This means, for example, that (i) a CA must provide OCSP services
> and responses in accordance with Mozilla policy for all certificates
> presumed to exist based on the presence of a Precertificate, even if the
> certificate does not actually exist, and (ii) a CA must be able to revoke
> a certificate presumed to exist, if revocation of the certificate is required
> under Mozilla policy, even if the certificate does not actually exist.

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

Re: Disclosure and CP/CPS for Cross-Signed Roots

[Andrew Ayer via dev-security-policy]

On Wed, 24 Jul 2019 16:41:53 +
Rob Stradling via dev-security-policy
 wrote:

> [Wearing crt.sh hat]
> 
> https://crt.sh/mozilla-disclosures now has two new buckets:
> - Disclosed, but with Inconsistent Audit details
> - Disclosed, but with Inconsistent CP/CPS details
> 
> (I started discussing this new feature with Kathleen, Wayne and
> Sleevi off-list a few months ago, but I was not able to finish
> implementing it until a few days ago).
> 
> I've also made the checks for the "Disclosure Incomplete" bucket 
> stricter.  Missing/incomplete disclosures of BR and/or EV audits are
> now flagged.

Thanks, Rob.  This is a really valuable feature.

I noticed some false positives, for example where one disclosure URL
refers directly to the CP/CPS and the other refers to a repository
page which links to the CP/CPS.  Perhaps it's time to require CAs to
disclose the URL of the actual CP/CPS rather than a repository page, as
discussed a few months ago:

https://groups.google.com/d/msg/mozilla.dev.security.policy/DyF-5NcYpJI/UNoF46XXAgAJ

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

Re: Disclosure and CP/CPS for Cross-Signed Roots

[Andrew Ayer via dev-security-policy]

On Thu, 18 Jul 2019 11:40:31 -0700
Wayne Thayer via dev-security-policy
 wrote:

> Andrew Ayer filed two bugs yesterday [1] [2] that might be worthy of
> a bit of discussion.

There's a third bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1567062

Like the GoDaddy case, the intermediate supposedly having the same
CP/CPS/audits as parent is not listed in the parent's audit report, so
this too looks like an incorrect disclosure.

Regarding Sectigo and Web.com, although their CPSes use extremely
similar language, they are not consistent, since they list different
CAA domains.

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

Re: Certinomis Issues

[Andrew Ayer via dev-security-policy]

I would like to highlight the many examples of Certinomis' poor incident
response.

Sometimes Certinomis ignores problems entirely - for example, in
, a misissued
certificate is still unrevoked and unacknowledged three months after
being reported.  Other times, they respond with very sparse details,
for example 
from yesterday.

Most of the time Certinomis appears to copy and paste the list
of problematic certificates that were reported to them instead
of performing their own investigation.  In some cases additional
problematic certificates are later discovered that they missed - for
example  from
this year and 
from last year.

The worst example is
 from yesterday,
in which Certinomis didn't even examine the full list of problematic
certificates that were reported to them.  I reported 174 certificates
with an OCSP status of "unknown."  In their incident response,
Certinomis stated that their "Web CA" issuer doesn't suffer from this
problem, even though seven of of the certificates in my report were
issued from this CA.  Furthermore, between the time of my report and
Certinomis' response, two additional certificates were issued from "Web
CA" with an unknown OCSP status.  Neither was included in Certinomis'
response - instead, Certinomis just linked to the list I provided them.

As recently as last month, Certinomis blamed human error in
their incident response, stating that issuing certificates to
unregistered domains was "a single human error not a systemic issue"
, even though
the fact that human error is possible is the systemic issue, and even
though this incident was far from the first time Certinomis had issued
certificates without doing domain validation.

On May 6, 2019, François CHASSERY stated: "I confirm
that pre-issuance linting is now operationnal."

On the basis of that response,
 and
 were resolved.

However, on May 13, 2019, Certinomis issued four certificates with
an invalid DNS SAN (lrcopro.), which is trivially detectable by
linting: 

In response, Certinomis stated that pre-issuance linting is actually
only operational under two of their issuing CAs, "Web CA" and "Safe CA".
Therefore, pre-issuance linting was never fully operational at
Certinomis, and it was misleading for them to state "pre-issuance
linting is now operationnal." This, combined with the incomplete
remediation last year in
, calls into
question any other remediation which they claim has been completed.

A CA that performs bad incident response will be unable to correctly
fix problems because they will fail to identify the full scope of the
issue or identify the root cause that needs to be fixed.  I believe the
evidence shows that Certinomis performs very poor incident response,
and continues to do so despite the new technical management.  They are
therefore unlikely to improve and will remain a risk to Firefox users.
They should be distrusted.

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

Re: Reported Digicert key compromise but not revoked

[Andrew Ayer via dev-security-policy]

On Thu, 9 May 2019 14:47:05 +
Jeremy Rowley via dev-security-policy
 wrote:

> Hi Han - the proper alias is rev...@digicert.com. The support alias
> will sometimes handle these, but not always.

Is that also true of SSL certificates?  supp...@digicert.com is listed
first at
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport

That should be fixed if supp...@digicert.com is not the right place to
report problems with SSL certificates.

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

Re: Unretrievable CPS documents listed in CCADB

[Andrew Ayer via dev-security-policy]

On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy
 wrote:

> As an aside, I noticed that several URLs listed in CCADB are “Legal
> Repository” web page URLs that contain a list of many CP/CPS
> documents. My recommendation is to slightly amend CCADB Policy to
> require CAs to provide URLs to the specific document in question
> rather than a general “Legal Repository” page, where it is left up to
> the reader to decide which hyperlink on the page is the correct
> document.

+1.  It's often a real hassle to find the CP/CPS for a CA.  Linking
directly to the document would help a lot.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Survey of (potentially noncompliant) Serial Number Lengths

[Andrew Ayer via dev-security-policy]

On Mon, 25 Mar 2019 22:16:27 +
Rob Stradling via dev-security-policy
 wrote:

> Even better than that (and many thanks to Andrew Ayer for suggesting 
> this idea)...
> 
> To enable folks to do more thorough statistical analysis, I've
> produced another, richer summary table (named
> serial_number_entropy_20190325) on the crt.sh DB where each row
> contains...
> - the CA ID.
> - a count of the total number of unique serial numbers.
> - 160 counts, representing the number of times a given serial number
> bit is 1.  (Serial numbers of <20 octets were left-padded with 0x00
> bytes).
> 
> This report covers all serial numbers in certs known to crt.sh where:
> - there is an unrevoked serverAuthentication trust path to a Mozilla 
> built-in root.
> - the notBefore date is between 2018-04-01 and 2019-02-22.
> 
> Duplicate serial numbers (i.e., precertificate/certificate pairs) are 
> deduplicated.

Thanks for creating this report Rob!

I used the following query to estimate the serial number entropy of
every CA which has issued more than 1,000 certificates:

SELECT issuer_ca_id,(SELECT COUNT(*) FROM (SELECT 
unnest(bit_position_sums)/(cert_count::float) AS ratio) subq WHERE ratio >= 
0.45 AND ratio <= 0.55) AS entropy_estimate FROM serial_number_entropy_20190325 
WHERE cert_count > 1000 ORDER BY issuer_ca_id;

(This query considers a bit "random" if it's 1 between 45% and 55% of
the time.)

Fortunately, this did not find any CA not already listed in Rob's
spreadsheet.

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

Re: Applicability of SHA-1 Policy to Timestamping CAs

[Andrew Ayer via dev-security-policy]

On Fri, 22 Mar 2019 12:50:43 -0600
Wayne Thayer via dev-security-policy
 wrote:

> I've been asked if the section 5.1.1 restrictions on SHA-1 issuance
> apply to timestamping CAs. Specifically, does Mozilla policy apply to
> the issuance of a SHA-1 CA certificate asserting only the
> timestamping EKU and chaining to a root in our program? Because this
> certificate is not in scope for our policy as defined in section 1.1,
> I do not believe that this would be a violation of the policy. And
> because the CA would be in control of the entire contents of the
> certificate, I also do not believe that this action would create an
> unacceptable risk.

It was the intent of section 5.1.1 to apply to such certificates, and
the wording in 5.1.1, which talks about "CAs" signing "SHA-1 hashes"
means that 5.1.1 applies even when the apparent signed data isn't a
certificate in scope of Mozilla policy.  This is necessary because the
problem with hash collisions is that while the data the CA thinks it's
signing might not be a certificate in scope of Mozilla policy, the hash
might collide with a certificate that *is* in scope.

Although this isn't a risk when the CA controls all the data to be signed,
5.1.1 doesn't distinguish this case.

However, 5.1.1 provides an exception if a CA needs to issue a SHA-1
intermediate certificate:

> CAs MAY sign SHA-1 hashes over intermediate certificates which chain
> up to roots in Mozilla's program only if the certificate to be signed
> is a duplicate of an existing SHA-1 intermediate certificate with the
> only changes being all of:
>
> * a new key (of the same size);
> * a new serial number (of the same length);
> * the addition of an EKU and/or a pathlen constraint to meet the
> requirements outlined above.

This is the only compliant way a CA can sign a SHA-1 intermediate that
chains up to a root that's included by Mozilla.

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

Re: DRAFT November 2017 CA Communication

[Andrew Ayer via dev-security-policy]

Hi Kathleen,

I suggest being explicit about which CAA errata Mozilla allows.

For CNAME, it's erratum 5065.

For DNAME, it's erratum 5097.

Link to errata: https://www.rfc-editor.org/errata_search.php?rfc=6844

We don't want CAs to think they can follow any errata they like, or to
come up with their own interpretation of what "natural" means :-)

Regards,
Andrew

On Wed, 25 Oct 2017 12:46:40 -0700 (PDT)
Kathleen Wilson via dev-security-policy
 wrote:

> All,
> 
> I will greatly appreciate your thoughtful and constructive feedback
> on the DRAFT of Mozilla's next CA Communication, which I am hoping to
> send in early November.
> 
> https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
> 
> Direct link to the survey:
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7
> 
> Thanks,
> Kathleen
> 
> ___
> 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: CAA Certificate Problem Report

[Andrew Ayer via dev-security-policy]

On Sat, 9 Sep 2017 18:10:02 -0700
Peter Bowen  wrote:

> On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer 
> wrote:
> > On Sat, 9 Sep 2017 13:53:52 -0700
> > Peter Bowen via dev-security-policy
> >  wrote:
> >
> >> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer 
> >> wrote:
> >> >
> >> > drill is buggy and insecure.  Obviously, such implementations can
> >> > be found.  Note that drill is just a "debugging/query" tool, not
> >> > a resolver you would actually use in production.  You'll find
> >> > that the production-grade resolver from that family (unbound)
> >> > correctly reports an error when you try to query the CAA record
> >> > for refused.caatestsuite-dnssec.com: https://unboundtest.com/
> >>
> >> Just as I received this, I finished testing with unbound, to see
> >> what it does.  See the results below.  For your blackhole,
> >> servfail, and refused cases it clearly says insecure, not bogus.
> >
> > That is very clearly against RFC4033, which says defines Insecure
> > as:
> >
> > The validating resolver has a trust anchor, a chain
> > trust, and, at some delegation point, signed proof of the
> > non-existence of a DS record.  This indicates that
> > subsequent branches in the tree are provably insecure.  A
> > validating resolver may have a local policy to mark parts of the
> > domain space as insecure.
> >
> > There is no "signed proof of the non-existence of a DS record" for
> > blackhole, servfail, and refused, so it cannot possibly be insecure.
> 
> I just found another tool that does checks and has a similar but
> distinct response set:
> 
> https://portfolio.sidnlabs.nl/check/expired.caatestsuite-dnssec.com/CAA
> (bogus)
> https://portfolio.sidnlabs.nl/check/missing.caatestsuite-dnssec.com/CAA
> (bogus)
> https://portfolio.sidnlabs.nl/check/blackhole.caatestsuite-dnssec.com/CAA
> (error)
> https://portfolio.sidnlabs.nl/check/servfail.caatestsuite-dnssec.com/CAA
> (error)
> https://portfolio.sidnlabs.nl/check/refused.caatestsuite-dnssec.com/CAA
> (error)
> https://portfolio.sidnlabs.nl/check/sigfail.verteiltesysteme.net/A
> (bogus)
> https://portfolio.sidnlabs.nl/check/bogus.d4a16n3.rootcanary.net/A
> (insecure) https://portfolio.sidnlabs.nl/check/www.google.com/A
> (insecure)
> https://portfolio.sidnlabs.nl/check/www.dnssec-failed.org/A (bogus)

According to https://portfolio.sidnlabs.nl/form this tool is just a web
frontend for libunbound, so it suffers from the same libunbound bug (reported
here: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439).

> Given that there does not seem to be a consistent definition on how
> "broken" DNSSEC should be handled, I think it is reasonable that CAs
> should be given benefit of the doubt on the broken DNSSEC tests.

I believe the following two facts are not disputed:

1. refused.caatestsuite-dnssec.com, servfail.caatestsuite-dnssec.com,
and blackhole.caatestsuite-dnssec.com cause lookup failures.

2. The Baseline Requirements permit CAs to treat a lookup failure as
permission to issue only when "the domain's zone does not have a DNSSEC
validation chain to the ICANN root."

What is disputed is whether these three domains' zones have a DNSSEC
validation chain to the ICANN root.  Considering the definition given
in RFC 4033, incorporated by reference from RFC 6844, I say that they
do, and that the CA is capable of determining this.  What about these
rules is so unclear it justifies giving CAs the benefit of the doubt
for issuing for these three FQDNs?  I do not believe the existence of a
single DNS implementation that violates RFC 4033 and 4035 by neglecting
to consider a response bogus in some situations is evidence of
unclarity as to what constitutes a validation chain.

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

Re: CAA Certificate Problem Report

[Andrew Ayer via dev-security-policy]

On Sat, 9 Sep 2017 13:53:52 -0700
Peter Bowen via dev-security-policy
 wrote:

> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer 
> wrote:
> >
> > drill is buggy and insecure.  Obviously, such implementations can
> > be found.  Note that drill is just a "debugging/query" tool, not a
> > resolver you would actually use in production.  You'll find that the
> > production-grade resolver from that family (unbound) correctly
> > reports an error when you try to query the CAA record for
> > refused.caatestsuite-dnssec.com: https://unboundtest.com/
> 
> Just as I received this, I finished testing with unbound, to see what
> it does.  See the results below.  For your blackhole, servfail, and
> refused cases it clearly says insecure, not bogus.

That is very clearly against RFC4033, which says defines Insecure as:

The validating resolver has a trust anchor, a chain 
trust, and, at some delegation point, signed proof of the
non-existence of a DS record.  This indicates that subsequent
branches in the tree are provably insecure.  A validating resolver
may have a local policy to mark parts of the domain space as
insecure.

There is no "signed proof of the non-existence of a DS record" for
blackhole, servfail, and refused, so it cannot possibly be insecure.

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

Re: CAs not compliant with CAA CP/CPS requirement

[Andrew Ayer via dev-security-policy]

On Fri, 8 Sep 2017 15:22:52 -0700 (PDT)
Andy Warner via dev-security-policy
 wrote:

> Google Trust Services published updated CP & CPS versions earlier
> today covering CAA checking. I'd suggest checking all CAs again
> tomorrow. Given the range of timezones CA operational staffs operate
> across, some may not have had a chance to publish their updates yet.

At the time I checked, it was already September 8 in all timezones.

> In terms of the 'rush' I suspect many CAs have had language prepared
> to publish well in advance, but were holding off given the number of
> discussions in various forums about how to interpret some sections of
> the RFC and BRs. Many of those discussions continued until the last
> moment, so holding off to ensure published details aligned with
> community consensus was a reasonable approach.

Could you point to a discussion that would suggest that not checking CAA
at all (which is what many CAs' CP/CPSes said, including Google Trust
Services') was a reasonable interpretation of the BRs?

The published details need to align with what the CA is doing.  In some
cases there may be ongoing discussions about how to interpret
requirements (though I believe in the case of CAA they had all
concluded well before the deadline), but that shouldn't stop a CA from
publishing how _they_ have interpreted the requirements, so that
relying parties know what the CA is doing.

Regards,
Andrew

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

Re: CAA Certificate Problem Report

[Andrew Ayer via dev-security-policy]

On Sat, 9 Sep 2017 06:57:39 -0400
Jonathan Rudenberg via dev-security-policy
 wrote:

> 
> > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy
> >  wrote:
> > 
> > In all three of these cases, the "domain's zone does not have a
> > DNSSEC validation chain to the ICANN root" -- I requested SOA,
> > DNSKEY, NS, and CAA records types for each zone and in no case did
> > I get a response that had a valid DNSSEC chain to the ICANN root.
> 
> This comes down to what exactly “does not have a valid DNSSEC chain”
> means.

As I explained in my reply to Peter, it's not "valid DNSSEC chain", but
rather a "validation chain", which is defined by RFC4033, albeit under
the synonymous term "authentication chain".

> I had assumed that given the reference to DNSSEC in the BRs that the
> relevant DNSSEC RFCs were incorporated by reference via RFC 6844 and
> that DNSSEC validation is required. However, this is not entirely the
> case, using DNSSEC for CAA lookups is only RECOMMENDED in section 4.1
> and explicitly “not required.” Which means this is all pretty
> pointless. The existence or non-existence of DNSSEC records doesn’t
> matter if there is no requirement to use them.

The BRs could arguably be interpreted to not require DNSSEC validation
during lookups, although as I explained in my reply to Jeremy I do not
find this to be a very compelling interpretation.

However, it is not at all ambiguous that a request must be denied if
the lookup fails for non-DNSSEC reasons, if there is DNSSEC validation
chain to the ICANN root.  Given the reference to RFC4033 from RFC6844
in the definition of DNSSEC, CAs should be able to figure out what this
means. Therefore, the blackhole and refused certs are unquestionably
misissuances, if not also missing and expired.

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

Re: StartCom communication

[Andrew Ayer via dev-security-policy]

On Mon, 4 Sep 2017 12:10:19 +
Inigo Barreira via dev-security-policy
 wrote:

> [...]
>
> a. Test certificates
> 
> It__s been detailed in bugzilla #1369359. There__s an attachment with a
> detailed explanation what happened, when, who, what was done to
> remediate and to avoid it happening in the future. Those certs were
> all the time under our control and lived for some minutes while
> testing the CT behaviour.
> 
> Actions: removed issuance rights for the CA administrator

Could you clarify whether you removed the issuance rights of the
particular administrator who issued the test certificates, or if you
removed the ability for administrators in general to issue certificates
bypassing technical controls?

Considering that your incident report names the CA administrator and
internal checker 10 times each, and states the reason for the incident
as "Operators of EJBCA server didn't follow the operating protocol
of StartCom", one could conclude that StartCom sees its failures as a
problem with individual people, rather than a systemic problem of
insufficient technical controls.  What has StartCom done to correct
this?


> b. Pre-certificates
> 
> It__s explained in bugzilla #1386894. Perhaps I was wrong with the word
> __intent__ and then no need to revoke as they were not real
> certificates, but once we had to do it, had to work with Primekey to
> revoke those certs, because they didn__t exist for the EJBCA system as
> they only have certificates, not pre-certificates. 

What has been done to fix the underlying issue so that in the future
you won't create a pre-certificate unless you really intend to issue
the final certificate?

> [...]
> 
> a. apply newest version of EJBCA v6.9.0
> 
> Primekey has just released the new version of EJBCA, v6.9.0 (end of
> august).
> 
> This new version comes with some important improvements, such as:
> 
> -  CAA automatic checking
> 
> -  Perform public key validation (RSA and ECC) 
> 

Will EJBCA 6.9.0 be deployed by September 8, when CAA checking becomes
mandatory? If not, how will you be checking CAA on September 8?

Does your/EJBCA's implementation of CAA pass the test suite I recently
posted to the CABF list? https://caatestsuite.com/

> b. integrate cablint/x509lint in CAProxy
> 
> These tools have been integrated at the issuance process. We__ll check
> all certificates issued and will send an email internally to act
> accordingly, i.e, revoking the cert and to start an inmediate
> investigation of the error.

This is a good step, but it's too late to stop the misissuance.
Instead, you should check the TBSCertificate, and not sign if there is
an error.

Regards,
Andrew

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

Per-intermediate CAA/problem reporting info

[Andrew Ayer via dev-security-policy]

Currently, CAA identifiers and problem reporting information are
collected on a per-CA basis and published in the "CA Information
Report"[1].

However, externally-operated sub-CAs generally have their own CAA
identifiers and problem reporting information, and this information
is not currently collected.  Would it be possible to collect this
information on a per-intermediate basis and to publish it in
the intermediate CA report[2]?  There could also be "same as parent"
option, as with CPS/audit information.

Having this information readily available would make it possible
to build some useful tools such as:

1. Auto-generate a CAA policy for a domain based on certificates currently
logged to CT.  (I want this for my CAA record generator[3].)

2. Monitor CT and make sure that issued certificates are compliant with
the domain's published CAA policy (modulo DNS changes between time-of-issue
and time-of-check).

3. Given a misissued certificate, display problem reporting
information.  (Might be handy for misissued.com)

Regards,
Andrew


[1] https://ccadb-public.secure.force.com/mozilla/CAInformationReport

[2] https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCerts

[3] https://sslmate.com/labs/caa
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PROCERT issuing certificates with non-random serial numbers

[Andrew Ayer via dev-security-policy]

On Wed, 16 Aug 2017 19:56:45 -0700
Andrew Ayer via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> Every certificate known to CT issued by PROCERT with a notBefore
> date after September 30, 2016 has what appears to be a non-random
> serial number: https://crt.sh/?Identity=%25=750

These are now being tracked on misissued.com: https://misissued.com/batch/12/

> In addition, their OCSP responder is returning a status of "Good" for
> adjacent serial numbers, suggesting sequential assignment of serial
> numbers.

Actually, their OCSP responder is returning good for unissued
certificates, which is itself a BR violation.  I've attached a sample
OCSP response to the
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1391058

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

PROCERT issuing certificates with non-random serial numbers

[Andrew Ayer via dev-security-policy]

Every certificate known to CT issued by PROCERT with a notBefore
date after September 30, 2016 has what appears to be a non-random
serial number: https://crt.sh/?Identity=%25=750

1e:4d:94:48:00:00:00:00:0c:79
2f:84:26:06:00:00:00:00:0b:1b
3d:94:73:d1:00:00:00:00:0a:ab
4b:53:8c:18:00:00:00:00:09:db
4c:94:f1:d5:00:00:00:00:0a:bd
4c:f3:00:86:00:00:00:00:0a:c0
4d:a7:2c:6a:00:00:00:00:0a:c3
4e:11:32:b3:00:00:00:00:0a:c7
6f:d3:c3:24:00:00:00:00:0c:56
7b:33:8f:17:00:00:00:00:0c:96
7b:98:a8:b1:00:00:00:00:0c:97
11:bb:b9:9f:00:00:00:00:0b:af
14:e9:6d:a4:00:00:00:00:0a:fa
16:8e:a3:9d:00:00:00:00:0b:f5
17:93:5a:4f:00:00:00:00:09:a6
17:96:d7:b8:00:00:00:00:09:a7
18:94:8a:f4:00:00:00:00:09:5a
18:98:dc:bb:00:00:00:00:09:5b
35:ce:d9:af:00:00:00:00:0c:02
43:ed:d4:a7:00:00:00:00:0a:b1
51:33:c5:60:00:00:00:00:0a:36
62:fa:e6:81:00:00:00:00:08:ad
69:4d:2f:c1:00:00:00:00:08:b4
76:81:87:9b:00:00:00:00:0b:65

In addition, their OCSP responder is returning a status of "Good" for
adjacent serial numbers, suggesting sequential assignment of serial
numbers.

This violates section of 7.1 of the BRs, which state:

"Effective September 30, 2016, CAs SHALL generate non-sequential
Certificate serial numbers greater than zero (0) containing at least 64
bits of output from a CSPRNG."

I have not reported this to PROCERT since their problem reporting
mechanism is a link to a non-English web page.

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

Re: TrustCor root inclusion request

[Andrew Ayer via dev-security-policy]

On Mon, 14 Aug 2017 20:27:05 +0100
Neil Dunbar via dev-security-policy
 wrote:

> Note that TrustCor is capable of removing SHA-1 as a signature hash on
> OCSP responses, if the community determines it presents risk to the
> relying parties. However, this does raise the risk to some clients
> that would fail to understand the signature on the response.  We
> should prefer to service as many clients as faithfully as we can while
> remaining true to the security principles of this community.

Yes, OCSP responses signed with SHA-1 do present a risk, since a
chosen prefix attack can be performed to forge OCSP responses and even
certificates:
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html

Even if you technically constrain your OCSP responder certificates as
required by Mozilla policy section 5.1.1, forged OCSP responses are
still possible if you use SHA-1.  That would allow attackers to use
revoked certificates.  So it would be better if you didn't use SHA-1 at
all for OCSP responses.

Thanks for your consideration of security feedback from the community.

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

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

[Andrew Ayer via dev-security-policy]

On Tue, 20 Jun 2017 21:23:51 +0100
Rob Stradling via dev-security-policy
 wrote:

> [CC'ing rev...@digicert.com, as per 
> https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028]
> 
> Annie,
> 
> "but these have been known about and deemed acceptable for years"
> 
> Known about by whom?  Deemed acceptable by whom?  Until the CA
> becomes aware of a key compromise, the CA will not know that the
> corresponding certificate(s) needs to be revoked.
> 
> Thanks for providing the Spotify example.  I've just found the 
> corresponding certificate (issued by DigiCert) and submitted it to
> some CT logs.  It's not yet revoked:
> https://crt.sh/?id=158082729
> 
> https://gist.github.com/venoms/d2d558b1da2794b9be6f57c5e81334f0 does 
> appear to be the corresponding private key.

24 hours later, this certificate is still not revoked, so DigiCert is
now in violation of section 4.9.1.1 of the BRs.

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

Re: Unknown Intermediates

[Andrew Ayer via dev-security-policy]

On Fri, 16 Jun 2017 10:29:45 -0700
Tavis Ormandy via dev-security-policy
 wrote:

> On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling
>  wrote:
> 
> > On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
> >
> >> Hello, I was crawling the pkcs7 blobs in public pdf files and
> >> found some intermediate certificates that don't appear in crt.sh.
> >>
> >> I forwarded them to Rob, I don't know if this is useful to anyone
> >> else, but
> >> they're available here.
> >>
> >> https://lock.cmpxchg8b.com/intermediates.zip
> >>
> >> Tavis.
> >>
> >
> > Thanks Tavis.  I've just submitted all of these intermediates to
> > some CT logs.
> >
> > This list just grew considerably...
> > https://crt.sh/mozilla-disclosures#undisclosed
> >
> > (I have a larger collection if anyone wants them, but many have
> > unknown
> >> critical extensions, or are name or usage constrained, etc)
> >>
> >
> > Yes please.  :-)
> >
> >
> Is there an easy way to check which certificates from my set you're
> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
> for fuzzing).
> 
> I collected these from public sources, so can just give you my whole
> set if you already have tools for importing them and don't mind
> processing them, I have around ~8M (mostly leaf) certificates, the
> set with isCa will be much smaller.

Please do post the whole set.  I suspect there are several people on
this list (including myself and Rob) who have the tools and experience
to process large sets of certificates and post them to public
Certificate Transparency logs (whence they will be fed into crt.sh).

It would be useful to include the leaf certificates as well, to catch
CAs which are engaging in bad practices such as signing non-SSL certs
with SHA-1 under an intermediate that is capable of issuing SSL
certificates.

Thanks a bunch for this!

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

Re: Symantec: Draft Proposal

[Andrew Ayer via dev-security-policy]

On Fri, 5 May 2017 17:18:38 +0100
Gervase Markham via dev-security-policy
 wrote:

> On 05/05/17 17:09, Peter Bowen wrote:
> > We know that the RAs could use different certificate profiles, as
> > certificates they approved had varying issuers, and "Issuer DN" has
> > the same "No(1)" that CP has in the table in the doc you linked.  I
> > don't see any indication of what profiles each RA was allowed to
> > use. It could be that Symantec provided one or more profiles to the
> > RA that contained EV OIDs.
> 
> So the question to Symantec is: "did any of the RAs in your program
> have EV issuance capability? If not, given that they had issuance
> capability from intermediates which chained up to EV-enabled roots,
> what technical controls prevented them from having this capability?"
> Is that right?

It may be useful to note that Certsuperior, Certisur, Certisign, and
Crosscert were all advertising EV certificates on their websites at
some point in 2016:

http://web.archive.org/web/20160428051833/https://www.certsuperior.com/SecureSiteProEV.aspx

http://web.archive.org/web/20161114232112/https://www.certisur.com/soluciones/sitios-seguros

http://web.archive.org/web/2016110634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada

http://web.archive.org/web/20161223000146/http://www.crosscert.com/

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

Grace Period for Sub-CA Disclosure

[Andrew Ayer via dev-security-policy]

[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 
]

Mozilla's CA Certificate Policy says:

> All certificates that are capable of being used to issue new
> certificates, that are not technically constrained, and that directly
> or transitively chain to a certificate included in Mozilla's CA
> Certificate Program MUST be audited in accordance with Mozilla's CA
> Certificate Policy and MUST be publicly disclosed in the CCADB by the
> CA that has their certificate included in Mozilla's CA Certificate
> Program.

One cannot disclose a sub-CA certificate without first signing it, so
there will always be some delay between the creation of a sub-CA and
its disclosure in the CCADB.  How long can a CA delay the disclosure?
All the policy currently says is this:

> The CA with a certificate included in Mozilla's CA Certificate
> Program MUST disclose this information before any such subordinate CA
> is allowed to issue certificates.

My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.  If the sub-CA is created as a backup that is never used, the
disclosure would never need to happen.

I think this is bad.  An upper limit on the delay should be precisely
specified by the policy.  My opinion is that it should be on the order
of days, although the policy might need to afford some leeway to CAs
that are new to the Mozilla program and do not have access yet to CCADB.

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

[Andrew Ayer via dev-security-policy]

On Fri, 24 Feb 2017 07:08:54 -0800 (PST)
"blake.morgan--- via dev-security-policy"
 wrote:

> Trustis has some time ago, migrated all TLS certificate production to
> SHA-256 Issuing Authorities.  The small number of previously issued
> SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes
> extending beyond 1 Jan 2017, were revoked towards the end of 2016.

Below is an unrevoked SHA-1 serverAuth certificate for
getset.trustis.com issued from this CA with a Not Before date of
2016-11-07.

Regards,
Andrew

-BEGIN CERTIFICATE-
MIIFYjCCBEqgAwIBAgIQXk1LkWmIzHB+YFd0TZ1TTDANBgkqhkiG9w0BAQUFADBS
MQswCQYDVQQGEwJHQjEYMBYGA1UEChMPVHJ1c3RpcyBMaW1pdGVkMSkwJwYDVQQL
EyBUcnVzdGlzIEZQUyBUVCBJc3N1aW5nIEF1dGhvcml0eTAeFw0xNjExMDcxNTE4
NTZaFw0yMDAxMTcxMTQ1NTZaMGsxCzAJBgNVBAYTAkdCMRgwFgYDVQQKEw9UcnVz
dGlzIExpbWl0ZWQxJTAjBgNVBAsTHEhNUkMgU0VUIENlcnRpZmljYXRlIFNlcnZp
Y2UxGzAZBgNVBAMTEmdldHNldC50cnVzdGlzLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMMvz9cWfI8vaGUdYPPr7uh41whxzhx0pFd6D0yTg2gd
MR8fqA93VViWV2XGqbFdbUnRQHksFZ0Vx6kA4BbyP/zRpaC3vOtcYpYqWnfudZLw
wRxVOwzVkz6ImhxiSWjbX1BdsDCohTmCBha4CKdtUewxeXQlIt2Cz//oxRvsZM+S
owY76YEDMF5V5lGgtYQXgyj/Oau7PAVurKtGB5IUbSBjXsfZsg4W//qsJzhlPLym
lmnWM2Yg/ykDLFKWeehRFa6jCz8w0JiRK5ynGu0aps//g65w+jeHiZyFzldWazqf
PpgvvKNtEYlT4pWc27Tk38ZzH8jNUksa9T9RBBnKUFcCAwEAAaOCAhkwggIVMB8G
A1UdIwQYMBaAFMCiJVnUHgITg9QvBIhUSiCNb43+MIIBOgYDVR0gBIIBMTCCAS0w
ggEpBgorBgEEAah1AQEDMIIBGTAtBggrBgEFBQcCARYhaHR0cDovL3d3dy50cnVz
dGlzLmNvbS9wa2kvZnBzaWEvMIHnBggrBgEFBQcCAjCB2hqB10lzc3VlZCBpbiBh
Y2NvcmRhbmNlIHdpdGggYW5kIGdvdmVybmVkIGJ5IHRoZSBUcnVzdGlzIEZQUyBJ
c3N1aW5nIEF1dGhvcml0eSBDZXJ0aWZpY2F0ZSBQb2xpY3kgd2hpY2ggY2FuIGJl
IGZvdW5kIGF0IGh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLyAgIFRy
dXN0aXMgRlBTLCBhIGRpdmlzaW9uIG9mIFRydXN0aXMgTGltaXRlZCAod3d3LnRy
dXN0aXMuY29tKQ0KMHAGA1UdHwRpMGcwZaBjoGGGLmh0dHA6Ly93d3cudHJ1c3Rp
cy5jb20vcGtpL2Zwc2lhL2NybC90dC1lZS5jcmyGL2h0dHA6Ly9zY2NzLnRydXN0
aXMuY29tL3BraS9mcHNpYS9jcmwvdHQtZWUuY3JsMBMGA1UdJQQMMAoGCCsGAQUF
BwMBMA4GA1UdDwEB/wQEAwIFoDAdBgNVHQ4EFgQUudovYJjp2vzykUX0GuDVS6oL
hLMwDQYJKoZIhvcNAQEFBQADggEBAB/xHCvYydnefZrndUVVUMpUBCPkfmSAjWna
G/cu6xrLxy+SwNXqpUydcIKNj3MyoZCIfzzSGpB0GbE2fXKvVt0vW3+fqcPGBtz/
szYldrROH2DVbg4e3GbkV65SomwMpnQfvwBydLOa7eCyqD5uYQ4BVyT0bAnoiRHj
QrWpkbVknpgnvIDQR7NO6msg2hwiNH1j3VyfWaPTxLT2tybzgQzC2uH0ivTJim4n
Kbya3zUApBKgP5ylJSXh/t5sVKlB32Qby8fpxoDsPLexJZPiRJSJx6t/iCxpshB2
v8gl8IWKHF3xIdWfW4H72U/zIyEKnyR+1C/0KxnZP56tbtxWGp0=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIFEDCCA/igAwIBAgIRAOvV+QArW1IlExGq8Ft+41EwDQYJKoZIhvcNAQEFBQAw
RTELMAkGA1UEBhMCR0IxGDAWBgNVBAoTD1RydXN0aXMgTGltaXRlZDEcMBoGA1UE
CxMTVHJ1c3RpcyBGUFMgUm9vdCBDQTAeFw0xMDEyMDExMjQyMzBaFw0yMDAxMTgx
MTQyMzBaMFIxCzAJBgNVBAYTAkdCMRgwFgYDVQQKEw9UcnVzdGlzIExpbWl0ZWQx
KTAnBgNVBAsTIFRydXN0aXMgRlBTIFRUIElzc3VpbmcgQXV0aG9yaXR5MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAk7x4ogwd5RxiVm5ucUkaPjD592H3
fWNa+1jSz/GdP2VaCigGdAYGC9CdPrO5q+X2liSTjcW23OOoJxV//Dv5o73c+qmP
24LlUmhoddbk6yn6sBAZLqw0GbqITqQz+hSUD5V+JzV6LJfSmSBtBOT3ALQwgssC
RO5H/RkyGfKmdHqFfgorzwrUjSmuSPx2+ke9Q3kR2yL0Sk4741gRaPq5fo9XgZNY
80FLYnNthHM5wq9koUkmbogYW2qtO5aKv9N8KLWoW3dfLizloLqRiR+Kkuscgnty
LEvumNVF0o5LBk+h8KIqgTJWUyEmlAMQ0vFbCRFXVr+mu7CgJNK5gGIRGQIDAQAB
o4IB7DCCAegwHwYDVR0jBBgwFoAUuvpxJXmLV0ElIYYLceuyZA6LIWcwDwYDVR0T
AQH/BAUwAwEB/zCCAUcGA1UdIASCAT4wggE6MIIBNgYKKwYBBAGodQEBAzCCASYw
LQYIKwYBBQUHAgEWIWh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLzCB
9AYIKwYBBQUHAgIwgecwChYDQ1BTMAMCAQEagdhJc3N1ZWQgaW4gYWNjb3JkYW5j
ZSB3aXRoIGFuZCBnb3Zlcm5lZCBieSB0aGUgVHJ1c3RpcyBGUFMgSXNzdWluZyBB
dXRob3JpdHkgQ2VydGlmaWNhdGUgUG9saWN5IHdoaWNoIGNhbiBiZSBmb3VuZCBh
dCANCmh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLw0KDQpUcnVzdGlz
IEZQUywgYSBkaXZpc2lvbiBvZiBUcnVzdGlzIExpbWl0ZWQgKHd3dy50cnVzdGlz
LmNvbSkwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy50cnVzdGlzLmNvbS9w
a2kvZnBzL2NybC9pYS5jcmwwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTAoiVZ
1B4CE4PULwSIVEogjW+N/jANBgkqhkiG9w0BAQUFAAOCAQEAVF6ttbAx8r0dwLlr
0wz/gHOC9ham3PHHDvlcC09QvoD3uOgqfdrtlLeTUHZHu4bYRELsEofUfsF5cHQS
M08SinUam3LWYrNygmwU4XNYk8M475Igun2wM30cx9TiBhL4VmdpG7T9Q2GF89YE
0YQf3xki3FltHOC7KtOHlBTktYgYwPdCdp0I0nEKMLUtd0OBPG2jPKU5gmBf5nxX
LlQpt5JkxY7Eg2PVXUkIEaKiCqjzLepLdFXCuAI1ONBxKNhD8bcq2NCT/e4+WRXk
7cqqnpseNaUdV7PRNjR/JttcYjXNCZ5dVYnpvlVLOonPI7mleR6ikAJX3mZiVSwY
bFKzCg==
-END CERTIFICATE-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy