Re: New intermediate certs and Audit Statements

[Rob Stradling via dev-security-policy]

On 9th July 2019, Kathleen wrote:
> I propose that to handle this situation, the CA may enter the
subordinate CA's current audit statements and use the Public Comment
field to indicate that the new certificate will be included in the next
audit statements.

Hi Kathleen.  CCADB now automatically shows the following message (when 
relevant) in red text at the top of each intermediate certificate page:

"This certificate was created after the audit period of the current audit 
statement, so please make sure to include it in the CA's next periodic audit 
statement."

Do you still expect CAs to "use the Public Comment field to indicate that the 
new certificate will be included in the next audit statements"?
Or may we stop doing that now?

Thanks.


From: dev-security-policy  on 
behalf of Kathleen Wilson via dev-security-policy 

Sent: 09 July 2019 22:50
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: New intermediate certs and Audit Statements

All,

There is some confusion about disclosure of new intermediate certs that
are issued to subordinate CAs with currently valid audit statements.

Section 5.3.2 of Mozilla's Root Store Policy says: "If the CA has a
currently valid audit report at the time of creation of the certificate,
then the new certificate MUST appear on the CA's next periodic audit
reports."

I think it is reasonable to assume that the same policy applies to
subordinate CAs, such that if the subordinate CA has a currently valid
audit report at the time of creation of a new intermediate certificate,
then the new certificate MUST appear on the subordinate CA's next
periodic audit reports.

The confusion is about how to disclose such a new intermediate
certificate in the CCADB.

I propose that to handle this situation, the CA may enter the
subordinate CA's current audit statements and use the Public Comment
field to indicate that the new certificate will be included in the next
audit statements. (Also, a quick comparison of the cert's Valid-From
date and the audit period dates will indicate this situation.)

Please let me know if you foresee any problems with this approach.

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: CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Rob Stradling via dev-security-policy]

> We already have automation for CCADB. CAs can and do use it for disclosure of 
> intermediates.

Any CA representatives that are surprised by this statement might want to go 
and read the "CCADB Release Notes" (click the hyperlink when you login to the 
CCADB).  That's the only place I've seen the CCADB API "announced".

> Since we're talking Let's Encrypt, the assumption here is that the CRL URLs
> will not be present within the crlDistributionPoints of the certificates,
> otherwise, this entire discussion is fairly moot, since those
> crlDistributionPoints can be obtained directly from Certificate Transparency.

AIUI, Mozilla is moving towards requiring that the CCADB holds all CRL URLs, 
even the ones that also appear in crlDistributionPoints extensions.  Therefore, 
I think that this entire discussion is not moot at all.

Ben's placeholder text:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/26c1ee4ea8be1a07f86253e38fbf0cc043e12d48


From: dev-security-policy  on 
behalf of Ryan Sleevi via dev-security-policy 

Sent: 26 February 2021 06:02
To: Aaron Gable 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 
; Kathleen Wilson 

Subject: Re: CCADB Proposal: Add field called JSON Array of Partitioned CRLs 
Issued By This CA

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On Thu, Feb 25, 2021 at 8:21 PM Aaron Gable  wrote:

> If I may, I believe that the problem is less that it is a reference (which
> is true of every URL stored in CCADB), and more that it is a reference to
> an unsigned object.
>

While that's a small part, it really is as I said: the issue of being a
reference. We've already had this issue with the other URL fields, and thus
there exists logic to dereference and archive those URLs within CCADB.
Issues like audit statements, CP, and CPSes are all things that are indeed
critical to understanding the posture of a CA over time, and so actually
having those materials in something stable and maintained (without a
dependence on the CA) is important.  It's the lesson from those
various past failure modes that had Google very supportive of the non-URL
based approach, putting the JSON directly in CCADB, rather than forcing yet
another "update-and-fetch" system.. You're absolutely correct
that the "configured by CA" element has the nice property of being assured
that the change came from the CA themselves, without requiring signing, but
I wouldn't want to reduce the concern to just that.

* I'm not aware of any other automation system with write-access to CCADB
> (I may be very wrong!), and I imagine there would need to be some sort of
> further design discussion with CCADB's maintainers about what it means to
> give write credentials to an automated system, what sorts of protections
> would be necessary around those credentials, how to scope those credentials
> as narrowly as possible, and more.
>

We already have automation for CCADB. CAs can and do use it for disclosure
of intermediates.


> * I'm not sure CCADB's maintainers want updates to it to be in the
> critical path of ongoing issuance, as opposed to just in the critical path
> for beginning issuance with a new issuer.
>

Without wanting to sound dismissive, whether or not it's in a critical path
of updating is the CA's choice on their design. I understand that there are
designs that could put it there, I think the question is whether it's
reasonable for the CA to have done that in the first place, which is why
it's important to drill down into these concerns. I know you merely
qualified it as undesirable, rather than actually being a blocker, and I
appreciate that, but I do think some of these concerns are perhaps less
grounded or persuasive than others :)

Taking a step back here, I think there's been a fundamental design error in
your proposed design, and I think that it, combined with the (existing)
automation, may make much of this not actually be the issue you anticipate.

Since we're talking Let's Encrypt, the assumption here is that the CRL URLs
will not be present within the crlDistributionPoints of the certificates,
otherwise, this entire discussion is fairly moot, since those
crlDistributionPoints can be obtained directly from Certificate
Transparency.

The purpose of this field is to help discover CRLs that are otherwise not
discoverable (e.g. from CT), but this also means that these CRLs do not
suffer from the same design limitations of PKI. Recall that there's nothing
intrinsic to a CRL that expresses its sharding algorithm (ignoring, for a
second, reasonCodes within the IDP extension). The only observability that
an external (not-the-CA) party has, whether the Subscriber or the RP, is
merely that "the CRL DP for this certificate is different from the CRLDP
for that certificate". It is otherwise opaque how the CA used it, even if
through a large enough corpus from CT, 

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Rob Stradling via dev-security-policy]

Hi Ben.

> *A CA technically capable of issuing server certificates MUST ensure that
> the CCADB field "Full CRL Issued By This CA" contains either the URL for
> the full and complete CRL or the URL for the JSON file containing all URLs
> for CRLs that when combined are the equivalent of the full and complete CRL*

As a consumer of this data (crt.sh), I'd much prefer to see "Full CRL Issued By 
This CA" and "the URL for the JSON file" as 2 separate fields in the CCADB.  
CAs would then be expected to fill in one field or the other, but not both.  Is 
that possible?

To ensure that these JSON files can be programmatically parsed, I suggest 
specifying the requirement a bit more strictly.  Something like this:
  "...or the URL for a file that contains only a JSON Array, whose elements are 
URLs of DER encoded CRLs that when combined are the equivalent of a full and 
complete CRL"

> I propose that this new CCADB field be populated in all situations where the 
> CA is enabled for server certificate issuance.

Most Root Certificates are "enabled for server certificate issuance".  
Obviously CAs shouldn't issue leaf certs directly from roots, but nonetheless 
the technical capability does exist.  However, currently CAs can't edit Root 
Certificate records in the CCADB, which makes populating these new field(s) "in 
all situations" rather hard.

Since OneCRL covers revocations of intermediate certs, may I suggest that CAs 
should only be required to populate these new field(s) in intermediate 
certificate records (and not in root certificate records)?

Relatedly, "A CA technically capable of...that the CCADB field" seems wrong.  
CCADB "CA Owner" records don't/won't contain the new field(s).  Similar 
language elsewhere in the policy (section 5.3.2) says "All certificates that 
are capable of being used to..." (rather than "All CAs...").

Technically-constrained intermediate certs don't have to be disclosed to CCADB, 
but "in all situations where the CA is enabled for server certificate issuance" 
clearly includes technically-constrained intermediates.  How would a CA 
populate the "Full CRL Issued By This CA" field for a technically-constrained 
intermediate cert that has (legitimately) not been disclosed to CCADB?


From: dev-security-policy  on 
behalf of Ben Wilson via dev-security-policy 

Sent: 08 January 2021 01:00
To: mozilla-dev-security-policy 
Subject: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity 
Certificates

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


This is the last issue that I have marked for discussion in relation to
version 2.7.1 of the Mozilla Root Store Policy
.
It is identified and discussed in GitHub Issue #218

 for the MRSP.

I will soon update everyone on the status of the other 13 discussion items
already presented, as some of them are in need of revision based on
comments received thus far.

While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes
a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla
still desires that CRL-based revocation information be available because
CRLite uses CRLs to construct its revocation filters.  (Apple also uses
such CRL information in its certificate validation processes and, as I
understand, is making a similar request of CAs with respect to the new
CCADB field, discussed below.)

While all such CRL information is needed, large CRLs are disfavored because
of the time they take to download and process.  Thus, CAs shard, partition,
or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains,
"Each CRL has a particular scope.  The CRL scope is the set of certificates
that could appear on a given CRL. … A complete CRL lists all unexpired
certificates, within its scope, that have been revoked for one of the
revocation reasons covered by the CRL scope.  A *full and complete CRL*
lists all unexpired certificates issued by a CA that have been revoked for
any reason." (Emphasis 

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Rob Stradling via dev-security-policy]

> Perhaps add: "And also include any other certificates sharing the same
> private/public key pairs as certificates already included in the
> requirements."  (this covers the situation you mentioned where a
> self-signed certificate shares the key pair of a certificate that chains
> to an included root).

Jakob,

I agree that that would cover that situation, but your proposed language goes 
way, way too far.

Any private CA could cross-certify a publicly-trusted root CA.  How would the 
publicly-trusted CA Operator discover such a cross-certificate?  Why would such 
a cross-certificate be of interest to Mozilla anyway?  Would it really be fair 
for non-disclosure of such a cross-certificate to be considered a policy 
violation?


From: dev-security-policy  on 
behalf of Jakob Bohm via dev-security-policy 

Sent: 29 October 2020 14:57
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed 
Certificates

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 2020-10-29 01:25, Ben Wilson wrote:
> Issue #186 in Github 
> 
> deals with the disclosure of CA certificates that directly or transitively
> chain up to an already-trusted, Mozilla-included root. A common scenario
> for the situation discussed in Issue #186 is when a CA creates a second (or
> third or fourth) root certificate with the same key pair as the root that
> is already in the Mozilla Root Store. This problem exists at the
> intermediate-CA-certificate level, too, where a self-signed
> intermediate/subordinate CA certificate is created and not reported.
>
> Public disclosure of such certificates is already required by section 5.3
> of the MRSP, which reads, "All certificates that are capable of being used
> to issue new certificates, and which directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program, MUST be operated
> in accordance with this policy and MUST either be technically constrained
> or be publicly disclosed and audited."
>
> There have been several instances where a CA operator has not disclosed a
> CA certificate under the erroneous belief that because it is self-signed it
> cannot be trusted in a certificate chain beneath the already-trusted,
> Mozilla-included CA. This erroneous assumption is further discussed in Issue
> #186 
> .
>
> The third paragraph of MRSP section 5.3 currently reads, " These
> requirements include all cross-certificates which chain to a certificate
> that is included in Mozilla’s CA Certificate Program."
>
> I recommend that we change that paragraph to read as follows:
>
> "These requirements include all cross-certificates *and self-signed
> certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key
> is signed by the private key) that* chain to a CA certificate that is
> included in Mozilla’s CA Certificate Program*, and CAs must disclose such
> CA certificates in the CCADB*.
>
> I welcome your recommendations on how we can make this language even more
> clear.
>

Perhaps add: "And also include any other certificates sharing the same
private/public key pairs as certificates already included in the
requirements."  (this covers the situation you mentioned where a
self-signed certificate shares the key pair of a certificate that chains
to an included root).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wisemo.com%2Fdata=04%7C01%7Crob%40sectigo.com%7C3bdb53393f1f4056b59e08d87c1aff51%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637395802683146795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sJ1Ar%2BE7qnVvPTdqdGEIKj25tRlyDLX%2F2sbqj4v9%2BlY%3Dreserved=0
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Rob Stradling via dev-security-policy]

Hi Dimitris.  I don't see where you're getting "in order to get an EV audit" 
from.  The proposed language deals with whether or not a CA has got all of the 
audits that Mozilla deems necessary, not with whether or not a CA may obtain 
new audits.


From: Dimitris Zacharopoulos 
Sent: 16 October 2020 12:48
To: Rob Stradling ; Ben Wilson ; 
mozilla-dev-security-policy 
Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy 
Constraints


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Rob,

This looks like a chicken-egg problem. A RootCA that wants to enable EV needs 
to get an EV audit. The proposed language, if I am not misunderstanding 
something, says that in order to get an EV audit, it must be... "EV-enabled"?

Dimitris.

On 2020-10-16 2:33 μ.μ., Rob Stradling wrote:
Hi Ben.  I agree with Dimitris that the proposed language is a bit confusing.

> "(i.e. a subordinate CA under an EV-enabled root that contains no EKU or the 
> id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and a certificatePolicies 
> extension that asserts the CABF EV OID of 2.23.140.1.1, the anyPolicy OID, or 
> the CA's EV policy OID)."

It's not clear from that sentence if "...that contains no EKU or the 
id-kp-serverAuth EKU or anyExtendedKeyUsage EKU" is meant to apply to "a 
subordinate CA" or "an EV-enabled root".  For clarity, I suggest converting 
this sentence into a bulleted list; and to avoid repeating that bulleted list 
unnecessarily, I suggest putting it into a new section 3.1.2.3, which sections 
3.1.2.1 and 3.1.2.2 would then reference.

I've had a go at drafting a PR here: 
https://github.com/robstradling/pkipolicy/pull/1


From: dev-security-policy 

 on behalf of Dimitris Zacharopoulos via dev-security-policy 

Sent: 16 October 2020 12:31
To: Ben Wilson ; 
mozilla-dev-security-policy 

Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy 
Constraints

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 2020-10-15 11:36 μ.μ., Ben Wilson via dev-security-policy wrote:
>   This issue is presented for resolution in the next version of the Mozilla
> Root Store Policy. It is related to Issue #147
> >
>  (previously posted for
> discussion on this list on 6-Oct-2020).
>
> Possible language is presented here:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fpkipolicy%2Fcommit%2Fc1acc76ad9f05038dc82281532fb215d71d537d4data=04%7C01%7Crob%40sectigo.com%7Ca230422a644142b9d71a08d871c70667%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384446910767139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=s4Nf4ViQnw8W2ckrofP%2BGYFeF5P4UHUWGfyEo8lEv4M%3Dreserved=0
>
> In addition to replacing "if issuing EV certificates" with "if capable of
> issuing EV certificates" in two places -- for WebTrust and ETSI 

Re: Sectigo to Be Acquired by GI Partners

[Rob Stradling via dev-security-policy]

Jakob wrote:
> The part needing clarification started with:
>
> > In addition to the questions posted by Wayne, I think it'd be useful
> > to confirm:
> > ...

I did not address that part of Ryan's post, but Tim's delayed message did 
address it.

See 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13782.html
and 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13795.html

The only​ purpose of my post was to say that Tim had posted a message that (we 
believed) had got stuck in a moderation queue.  I felt that I needed to post my 
message because Mozilla expects CAs to answer questions in a timely fashion 
(see https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed).

When a reply from a CA representative doesn't appear on the list, it might look 
like the CA is not answering questions in a timely fashion.  It would not be 
fair for any CA to be penalized just because there's a moderation queue for 
some messages and/or participants.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Rob Stradling via dev-security-policy]

Hi Ben.  I agree with Dimitris that the proposed language is a bit confusing.

> "(i.e. a subordinate CA under an EV-enabled root that contains no EKU or the 
> id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and a certificatePolicies 
> extension that asserts the CABF EV OID of 2.23.140.1.1, the anyPolicy OID, or 
> the CA's EV policy OID)."

It's not clear from that sentence if "...that contains no EKU or the 
id-kp-serverAuth EKU or anyExtendedKeyUsage EKU" is meant to apply to "a 
subordinate CA" or "an EV-enabled root".  For clarity, I suggest converting 
this sentence into a bulleted list; and to avoid repeating that bulleted list 
unnecessarily, I suggest putting it into a new section 3.1.2.3, which sections 
3.1.2.1 and 3.1.2.2 would then reference.

I've had a go at drafting a PR here: 
https://github.com/robstradling/pkipolicy/pull/1


From: dev-security-policy  on 
behalf of Dimitris Zacharopoulos via dev-security-policy 

Sent: 16 October 2020 12:31
To: Ben Wilson ; mozilla-dev-security-policy 

Subject: Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy 
Constraints

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 2020-10-15 11:36 μ.μ., Ben Wilson via dev-security-policy wrote:
>   This issue is presented for resolution in the next version of the Mozilla
> Root Store Policy. It is related to Issue #147
> 
>  (previously posted for
> discussion on this list on 6-Oct-2020).
>
> Possible language is presented here:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fpkipolicy%2Fcommit%2Fc1acc76ad9f05038dc82281532fb215d71d537d4data=04%7C01%7Crob%40sectigo.com%7Ca230422a644142b9d71a08d871c70667%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384446910767139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=s4Nf4ViQnw8W2ckrofP%2BGYFeF5P4UHUWGfyEo8lEv4M%3Dreserved=0
>
> In addition to replacing "if issuing EV certificates" with "if capable of
> issuing EV certificates" in two places -- for WebTrust and ETSI audits --
> it would be followed by "(i.e. a subordinate CA under an EV-enabled root
> that contains no EKU or the id-kp-serverAuth EKU or anyExtendedKeyUsage
> EKU, and a certificatePolicies extension that asserts the CABF EV OID of
> 2.23.140.1.1, the anyPolicy OID, or the CA's EV policy OID)." Thus, Mozilla
> considers that a CA is capable of issuing EV certificates if it is (1) a
> subordinate CA (2) under an EV-enabled root (3) that contains no EKU or the
> id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and (4) a
> certificatePolicies extension that asserts the CABF EV OID of 2.23.140.1.1,
> the anyPolicy OID, or the CA's EV policy OID.
>
> I look forward to your suggestions.

Hello Ben,

I am trying to understand the expectations from Mozilla:

- If a CA that has an EV-capable RootCA , uses a subCA Certificate that
contains the id-kp-serverAuth EKU and the anyPolicy OID that does not
issue EV end-entity Certificates, is this considered a policy violation
if this subCA is not explicitly included in an EV audit scope (ETSI or
WebTrust)?

- If a subCA Certificate that contains the id-kp-serverAuth EKU and the
anyPolicy OID was not covered by an EV-scope audit (because it did not
issue EV Certificates) and it later decides to update the profile and
policies/practices to comply with the EV Guidelines for everything
related to end-entity certificates in order to start issuing EV
Certificates and is later added to an EV-scope audit, is that an allowed
practice? Judging from the current EV Guidelines I didn't see anything
forbidding this practice. In fact this is supported via section 17.4.

The proposed language is a bit confusing so hopefully by getting
Mozilla's position on the above two questions, we can propose some
improvements.


Best regards,
Dimitris.


>
> Thanks,
>
> Ben
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policydata=04%7C01%7Crob%40sectigo.com%7Ca230422a644142b9d71a08d871c70667%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637384446910772135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ofpen2baqYtT4B7HgetKK%2Biq7SEy%2F%2Bq4x3lcI7OKgwU%3Dreserved=0

Re: Sectigo to Be Acquired by GI Partners

[Rob Stradling via dev-security-policy]

> ...clarification of what meaning was intended.

Merely this...

"Hi Ryan.  Tim Callan posted a reply to your questions last week, but his 
message has not yet appeared on the list.  Is it stuck in a moderation queue?"

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

Re: Sectigo to Be Acquired by GI Partners

[Rob Stradling via dev-security-policy]

Hi Jacob.  I don't believe that this list mandates any particular posting style 
[https://en.wikipedia.org/wiki/Posting_style].

Although interleaved/inline posting is my preferred style, I'm stuck using 
Outlook365 as my mail client these days.  (Sadly, Thunderbird's usability 
worsened dramatically for me after Sectigo moved corporate email to Office365 a 
few years ago).  So this is the situation I find myself in...

"This widespread policy in business communication made bottom and inline 
posting so unknown among most users that some of the most popular email 
programs no longer support the traditional posting style. For example, 
Microsoft Outlook, AOL, and Yahoo! make it difficult or impossible to indicate 
which part of a message is the quoted original or do not let users insert 
comments between parts of the original."
[https://en.wikipedia.org/wiki/Posting_style#Quoting_support_in_popular_mail_clients]


From: dev-security-policy  on 
behalf of Jakob Bohm via dev-security-policy 

Sent: 12 October 2020 22:41
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: Sectigo to Be Acquired by GI Partners

Hi Rob,

The e-mail you quote below seems to be inadvertently "confirming" some
suspicions that someone else posed as questions. I think the group as a
whole would love to have actual specific answers to those original
questions.

Remember to always add an extra layer of ">" indents for each level of
message quoting, so as to not misattribute text.

On 2020-10-12 10:43, Rob Stradling wrote:
> Hi Ryan.  Tim Callan posted a reply to your questions last week, but his 
> message has not yet appeared on the list.  Is it stuck in a moderation queue?
>
> 
> From: dev-security-policy  on 
> behalf of Ryan Sleevi via dev-security-policy 
> 
> Sent: 03 October 2020 22:16
> To: Ben Wilson 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: Sectigo to Be Acquired by GI Partners
>
>
> In a recent incident report [1], a representative of Sectigo noted:
>
> The carve out from Comodo Group was a tough time for us. We had twenty
>> years’ worth of completely intertwined systems that had to be disentangled
>> ASAP, a vast hairball of legacy code to deal with, and a skeleton crew of
>> employees that numbered well under half of what we needed to operate in any
>> reasonable fashion.
>
>
> This referred to the previous split [2] of the Comodo CA business from the
> rest of Comodo businesses, and rebranding as Sectigo.
>
> In addition to the questions posted by Wayne, I think it'd be useful to
> confirm:
>
> 1. Is it expected that there will be similar system and/or infrastructure
> migrations as part of this? Sectigo's foresight of "no effect on its
> operations" leaves it a bit ambiguous whether this is meant as "practical"
> effect (e.g. requiring a change of CP/CS or effective policies) or whether
> this is meant as no "operational" impact (e.g. things will change, but
> there's no disruption anticipated). It'd be useful to frame this response
> in terms of any anticipated changes at all (from mundane, like updating the
> logos on the website, to significant, such as any procedure/equipment
> changes), rather than observed effects.
>
> 2. Is there a risk that such an acquisition might further reduce the crew
> of employees to an even smaller number? Perhaps not immediately, but over
> time, say the next two years, such as "eliminating redundancies" or
> "streamlining operations"? I recognize that there's an opportunity such an
> acquisition might allow for greater investment and/or scale, and so don't
> want to presume the negative, but it would be good to get a clear
> commitment as to that, similar to other acquisitions in the past (e.g.
> Symantec CA operations by DigiCert)
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1648717#c21
> [2]
> https://groups.google.com/g/mozilla.dev.security.policy/c/AvGlsb4BAZo/m/p_qpnU9FBQAJ
>
> On Thu, Oct 1, 2020 at 4:55 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>   As announced previously by Rob Stradling, there is an agreement for
>> private investment firm GI Partners, out of San Francisco, CA, to acquire
>> Sectigo. Press release:
>> https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners
>> .
>>
>>
>> I am treating this as a change of legal ownership covered by section 8.1
>> <
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership
>>>
>> of the Mozilla Root Store Policy, which states:
>>
>>> If the receiving or acquiring company is new to the Mozilla root program,
>>> it must demonstrate compliance with the entirety of this policy and there
>>> MUST be a public discussion regarding their admittance to the root
>> program,
>>> which Mozilla must resolve with a positive conclusion in order for the
>>> affected certificate(s) to remain in the root program.
>>
>> In 

Re: Sectigo to Be Acquired by GI Partners

[Rob Stradling via dev-security-policy]

Hi Ryan.  Tim Callan posted a reply to your questions last week, but his 
message has not yet appeared on the list.  Is it stuck in a moderation queue?


From: dev-security-policy  on 
behalf of Ryan Sleevi via dev-security-policy 

Sent: 03 October 2020 22:16
To: Ben Wilson 
Cc: mozilla-dev-security-policy 
Subject: Re: Sectigo to Be Acquired by GI Partners


In a recent incident report [1], a representative of Sectigo noted:

The carve out from Comodo Group was a tough time for us. We had twenty
> years’ worth of completely intertwined systems that had to be disentangled
> ASAP, a vast hairball of legacy code to deal with, and a skeleton crew of
> employees that numbered well under half of what we needed to operate in any
> reasonable fashion.


This referred to the previous split [2] of the Comodo CA business from the
rest of Comodo businesses, and rebranding as Sectigo.

In addition to the questions posted by Wayne, I think it'd be useful to
confirm:

1. Is it expected that there will be similar system and/or infrastructure
migrations as part of this? Sectigo's foresight of "no effect on its
operations" leaves it a bit ambiguous whether this is meant as "practical"
effect (e.g. requiring a change of CP/CS or effective policies) or whether
this is meant as no "operational" impact (e.g. things will change, but
there's no disruption anticipated). It'd be useful to frame this response
in terms of any anticipated changes at all (from mundane, like updating the
logos on the website, to significant, such as any procedure/equipment
changes), rather than observed effects.

2. Is there a risk that such an acquisition might further reduce the crew
of employees to an even smaller number? Perhaps not immediately, but over
time, say the next two years, such as "eliminating redundancies" or
"streamlining operations"? I recognize that there's an opportunity such an
acquisition might allow for greater investment and/or scale, and so don't
want to presume the negative, but it would be good to get a clear
commitment as to that, similar to other acquisitions in the past (e.g.
Symantec CA operations by DigiCert)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1648717#c21
[2]
https://groups.google.com/g/mozilla.dev.security.policy/c/AvGlsb4BAZo/m/p_qpnU9FBQAJ

On Thu, Oct 1, 2020 at 4:55 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  As announced previously by Rob Stradling, there is an agreement for
> private investment firm GI Partners, out of San Francisco, CA, to acquire
> Sectigo. Press release:
> https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners
> .
>
>
> I am treating this as a change of legal ownership covered by section 8.1
> <
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership
> >
> of the Mozilla Root Store Policy, which states:
>
> > If the receiving or acquiring company is new to the Mozilla root program,
> > it must demonstrate compliance with the entirety of this policy and there
> > MUST be a public discussion regarding their admittance to the root
> program,
> > which Mozilla must resolve with a positive conclusion in order for the
> > affected certificate(s) to remain in the root program.
>
> In order to comply with policy, I hereby formally announce the commencement
> of a 3-week discussion period for this change in legal ownership of Sectigo
> by requesting thoughtful and constructive feedback from the community.
>
> Sectigo has already stated that it foresees no effect on its operations due
> to this ownership change, and I believe that the acquisition announced by
> Sectigo and GI Partners is compliant with Mozilla policy.
>
> Thanks,
>
> Ben
> ___
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sectigo to Be Acquired by GI Partners

[Rob Stradling via dev-security-policy]

Hi Wayne.  We are not currently planning any changes to our CP/CPS as a result 
of this change of control.


From: dev-security-policy  on 
behalf of Wayne Thayer via dev-security-policy 

Sent: 02 October 2020 01:32
To: mozilla-dev-security-policy 
Subject: Re: Sectigo to Be Acquired by GI Partners

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Rob: what, if any, changes will be made to the Sectigo CP/CPS as a result
of this change of control?

Thanks,

Wayne

On Thu, Oct 1, 2020 at 1:55 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>  As announced previously by Rob Stradling, there is an agreement for
> private investment firm GI Partners, out of San Francisco, CA, to acquire
> Sectigo. Press release:
> https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners
> .
>
>
> I am treating this as a change of legal ownership covered by section 8.1
> <
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership
> >
> of the Mozilla Root Store Policy, which states:
>
> > If the receiving or acquiring company is new to the Mozilla root program,
> > it must demonstrate compliance with the entirety of this policy and there
> > MUST be a public discussion regarding their admittance to the root
> program,
> > which Mozilla must resolve with a positive conclusion in order for the
> > affected certificate(s) to remain in the root program.
>
> In order to comply with policy, I hereby formally announce the commencement
> of a 3-week discussion period for this change in legal ownership of Sectigo
> by requesting thoughtful and constructive feedback from the community.
>
> Sectigo has already stated that it foresees no effect on its operations due
> to this ownership change, and I believe that the acquisition announced by
> Sectigo and GI Partners is compliant with Mozilla policy.
>
> Thanks,
>
> Ben
> ___
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mandatory reasonCode analysis

[Rob Stradling via dev-security-policy]

Hi Doug.  I didn't filter by any CRL fields, as per option (2) in my original 
post.


From: Doug Beattie
Sent: Wednesday, September 30, 2020 17:53
To: Rob Stradling
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Mandatory reasonCode analysis

Hi Rob,

I'm not sure you filtered this report by "thisUpdate", maybe you did it by
nextUpdate by mistake?

The GlobalSign CRL on this report was created in 2016, thus the question.

Doug


-Original Message-
From: dev-security-policy  On
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 11:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track
of reasonCodes, I thought I would conduct some analysis to determine the
level of (non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs
and OCSP responses with thisUpdate timestamps dated today or afterwards, or
if (2) every CRL and OCSP response currently being served by distribution
points and responders (regardless of the thisUpdate timestamps) is required
to comply.  (I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip
containing all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it, in
whole or in part without the express consent of the sender. Please notify
the sender by reply email, disregard the foregoing messages, and delete it
immediately.


___
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: Mandatory reasonCode analysis

[Rob Stradling via dev-security-policy]

> I also read this language:
> If a CRL entry is for a Certificate not subject to these Requirements and was 
> either issued on-or-after 2020-09-30 or has a notBefore on-or-after 
> 2020-09-30, the CRLReason MUST NOT be certificateHold (6).

I think "was either issued on-or-after 2020-09-30 or has a notBefore 
on-or-after 2020-09-30" is talking about "a Certificate not subject to these 
Requirements", not about when the CRL was issued.


From: dev-security-policy  on 
behalf of Jeremy Rowley via dev-security-policy 

Sent: 30 September 2020 17:41
To: Mozilla 
Subject: RE: Mandatory reasonCode analysis

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


This is a good question. I read the requirements as applying only to CRLs and 
OCSP published after the effective date since the BRs always say explicitly 
when they apply to items before the effective date.

I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was 
either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, 
the CRLReason MUST NOT be certificateHold (6).

Which made me think the language applied only to CRLs and OCSP issued after 
9-30. However, the language does only reference certificateHold and not the 
inclusion of reasonCode language.

That was the analysis I had anyway - that any CRLs and OCSP published after 
9-30 had to have  reasonCode.

-Original Message-
From: dev-security-policy  On 
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Mandatory reasonCode analysis

[Rob Stradling via dev-security-policy]

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


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

Sectigo to Be Acquired by GI Partners

[Rob Stradling via dev-security-policy]

[Posting for Sectigo]

There is an agreement for private investment firm GI Partners, out of San 
Francisco, CA, to acquire Sectigo.  We foresee no effect on our operations due 
to this ownership change.  Press release: 
https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners

This transaction is expected to be finalized during Q4 2020, but presumably the 
public discussion envisaged by 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#81-change-in-legal-ownership
 could occur earlier than that.


--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Rob Stradling via dev-security-policy]

On 06/07/2020 12:47, Rob Stradling via dev-security-policy wrote:

On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:


IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling made an indirect reference in
https://groups.google.com/d/msg/mozilla.dev.security.policy/f5-URPoNarI/yf2YLpKJAQAJ 



(Rob, please correct me if I'm wrong).

There was a follow-up discussion in IETF that resulted that noone should
deal with this issue
(https://mailarchive.ietf.org/arch/msg/spasm/3zZzKa2lcT3gGJOskVrnODPBgM0/). 


A day later, all attempts died off because noone would actually
implement this(?)
https://mailarchive.ietf.org/arch/msg/spasm/_gJTeUjxc2kmDcRyWPb9slUF47o/.
If this extension was standardized, we would probably not be having this
issue right now. However, this entire topic demonstrates the necessity
to standardize the EKU existence in CA Certificates as constraints for
EKUs of leaf certificates.


Oh, I misread.

Standardizing the use of the existing EKU extension in CA certificates 
as a constraint for permitted EKUs in leaf certificates has been 
proposed at IETF before.  Probably many times before.  However, plenty 
of people take the (correct, IMHO) view that the EKU extension was not 
intended to be (ab)used in this way, and so the chances of getting 
"rough consensus" for a Standards Track RFC to specify this seems rather 
remote.


I suppose it might be worth drafting an Informational RFC that explains 
how the EKU extension is used in practice, what the footguns are and how 
to avoid them, what the security implications are of doing EKU wrong, etc.



If only we could edit RFC2459 so that it (1) defined an "EKU
constraints" extension and (2) said that the EKU extension MUST NOT
appear in CA certificates...

Unfortunately, we're more than 20 years too late to do that.  And whilst
it completely sucks that real-world use of the EKU extension comes with
some nasty footguns, I just don't see how you'd ever persuade the WebPKI
ecosystem to adopt a new "EKU Constraints" extension at this point in
history.

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Rob Stradling via dev-security-policy]

On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:


IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling made an indirect reference in
https://groups.google.com/d/msg/mozilla.dev.security.policy/f5-URPoNarI/yf2YLpKJAQAJ 


(Rob, please correct me if I'm wrong).

There was a follow-up discussion in IETF that resulted that noone should
deal with this issue
(https://mailarchive.ietf.org/arch/msg/spasm/3zZzKa2lcT3gGJOskVrnODPBgM0/).
A day later, all attempts died off because noone would actually
implement this(?)
https://mailarchive.ietf.org/arch/msg/spasm/_gJTeUjxc2kmDcRyWPb9slUF47o/.
If this extension was standardized, we would probably not be having this
issue right now. However, this entire topic demonstrates the necessity
to standardize the EKU existence in CA Certificates as constraints for
EKUs of leaf certificates.


If only we could edit RFC2459 so that it (1) defined an "EKU 
constraints" extension and (2) said that the EKU extension MUST NOT 
appear in CA certificates...


Unfortunately, we're more than 20 years too late to do that.  And whilst 
it completely sucks that real-world use of the EKU extension comes with 
some nasty footguns, I just don't see how you'd ever persuade the WebPKI 
ecosystem to adopt a new "EKU Constraints" extension at this point in 
history.


--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Rob Stradling via dev-security-policy]

On 03/07/2020 12:24, Ryan Sleevi via dev-security-policy wrote:


The key destruction is the only way I can see being able to provide some
assurance that “things won’t go wrong, because it’s impossible for them to
go wrong, here’s the proof”


Ryan, distrusting the root(s) would be another way to provide this 
assurance (for up-to-date clients anyway), although I'd be surprised if 
any of the affected CAs would prefer to go that route!


--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Rob Stradling via dev-security-policy]

On 02/07/2020 17:13, Ryan Sleevi via dev-security-policy wrote:

On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell wrote:



If there’s no digitalSignature KU, then the certificate is not a OCSP
responder certificate due to the technical inability to sign OCSP responses
that would be accepted by clients conforming to RFC 5280, section 4.2.1.12.
Therefore, section 4.9.9 is not applicable for those certificates that not
express the digitalSignature KU. This is directly relevant to the topic at
hand.


Alternatively: If the OCSPSigning EKU is present, and it lacks
DigitalSignature, it's misissued by containing an invalidEKU.


As Ryan already mentioned, RFC6960 very clearly says:
  "OCSP signing delegation SHALL be designated by the inclusion of
   id-kp-OCSPSigning in an extended key usage certificate extension
   included in the OCSP response signer's certificate."

The presence or absence of the DigitalSignature Key Usage bit does not 
alter this fact.


RFC6960 doesn't mention the Key Usage extension at all, AFAICT.

https://tools.ietf.org/html/rfc5280#section-4.2.1.12 doesn't use any 
RFC2119 keywords when it says:

  "id-kp-OCSPSigningOBJECT IDENTIFIER ::= { id-kp 9 }
   -- Signing OCSP responses
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation"

The BRs say...
  "If the Root CA Private Key is used for signing OCSP responses, then
   the digitalSignature bit MUST be set."
  and
  "If the Subordinate CA Private Key is used for signing OCSP responses,
   then the digitalSignature bit MUST be set"
...but this is obviously intended to refer to OCSP responses signed 
directly by the CA (rather than OCSP responses signed by a CA that also 
masquerades as a delegated OCSP response signer!)


--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Rob Stradling via dev-security-policy]

Doug,

BR 4.9.9 says:
"...the OCSP signing Certificate MUST contain an extension of type 
id-pkix-ocsp-nocheck, as defined by RFC6960."

The certificates that Ryan has identified are OCSP signing Certificates, 
because they contain the id-kp-OCSPSigning EKU.  However, they have been 
misissued because they don't "contain an extension of type 
id-pkix-ocsp-nocheck".

The fact that these certificates are also CA certificates is unfortunate, 
because revoking a CA certificate tends to have more impact to users than 
revoking a leaf certificate.

Policy-wise, apparently it's OK for a certificate to be both a CA certificate 
and a (correctly issued!) delegated OCSP signing certificate, which is I think 
what Ryan's earlier post was talking about.  So if the affected CAs could go 
back in time and add the id-pkix-ocsp-nocheck extension to these certificates 
then those certificates arguably wouldn't have been misissued(*).

To repeat: the policy violation here is the omission of the 
id-pkix-ocsp-nocheck extension in certificates that contain the 
id-kp-OCSPSigning EKU.

(*) They might still have been "Dangerous" though, even if they hadn't been 
misissued.  Quoting Ryan...
"For example,
consider this certificate https://crt.sh/?id=21606064 . It was issued by
DigiCert to Microsoft, granting Microsoft the ability to provide OCSP
responses for any certificate issued by Digicert's Baltimore CyberTrust
Root. We know from DigiCert's disclosures that this is independently
operated by Microsoft."


From: dev-security-policy  on 
behalf of douglas.beattie--- via dev-security-policy 

Sent: 02 July 2020 12:38
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Re: Question about the issuance of OCSP Responder Certificates by 
technically constrained CAs

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Ryan,

Given the recent announcement "SECURITY RELEVANT FOR CAs: The curious case of 
the Dangerous Delegated Responded Cert", how does you discussion in this thread 
relate to this?  Are your responses here to a different question, because it 
appears (likely my misinterpretation) from this thread it's OK to include 
OCSP-signing into a CA certificate?

https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/XSfw4tZPBwAJ



On Wednesday, September 4, 2019 at 11:01:36 AM UTC-4, Ryan Sleevi wrote:
> On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > My question is the following: is it allowed to issue an OCSP Responder
> > certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA
> > if the "id-kp-OCSPSigning" EKU is not listed in the CA certificate,
>
>
> This will fail, not because of policy reasons, but because of technical
> reasons (not Firefox).
>
> The code (for Firefox) is
> https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888
> ,
> with the most salient logic at
> https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884
> ,
> although the explanation in
> https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#863-869
> explains
> the technical reasons.
>
>
> > in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a
> > possible, mandatory or forbidden option for such CAs?
> >
>
> This is not forbidden by policy. That is, a technically constrained
> subordinate CA certificate can have id-kp-OCSPSigning and id-kp-serverAuth.
>
> As I see in the practice, if a technically constrained CA signs the OCSP
> > response itself, it can be done without the "id-kp-OCSPSigning" EKU but
> > with the "digitalSignature" KU bit in the CA certificate.
> >
>
> Correct, if the id-kp-OCSPSigning EKU is missing from the technically
> constrained intermediate, direct signing still works.

___
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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Rob Stradling via dev-security-policy]

Hi Peter.  The "following CA certificate" (which I'll call Certificate X) is 
not capable of issuing id-kp-serverAuth leaf certificates that will be trusted 
by Mozilla, but that fact is entirely irrelevant to this discussion.  Notice 
that Ryan wrote "issued by a Mozilla-trusted, TLS-capable CA" rather than "is a 
Mozilla-trusted, TLS-capable CA".

Certificate X contains the id-kp-OCSPSigning EKU.  This means that it can be 
used as a delegated OCSP signer, to sign OCSP responses on behalf of its 
issuer.  If its issuer is "a Mozilla-trusted, TLS-capable CA", then all of its 
issuer's delegated OCSP signer certificates are in scope for the BRs and for 
the Mozilla Root Store Policy.

Certificate X is an intermediate CA certificate, which is capable of issuing 
id-kp-timeStamping leaf certificates.  That's all very nice, but it doesn't 
alter the fact that Certificate X is also a (misissued) delegated OCSP signing 
certificate that is in scope for the BRs and the Mozilla Root Store Policy.


From: dev-security-policy  on 
behalf of Peter Mate Erdosi via dev-security-policy 

Sent: 02 July 2020 12:04
To: mozilla-dev-security-policy 
Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous 
Delegated Responder Cert

Just for my better understanding, is the following CA certificate
"TLS-capable"?

X509v3 Basic Constraints critical:
CA:TRUE
X509v3 Key Usage critical:
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
Time Stamping, OCSP Signing


Peter



On Thu, Jul 2, 2020 at 12:14 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> certificates, due to other non-conformities, so I only included a sample.
>
> I just reproduced this result.  I've posted my SQL query and (thanks to
> GitHub) a searchable TSV report of all 293 certificates here:
> https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f
>
> 
> From: dev-security-policy 
> on behalf of Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> Sent: 01 July 2020 22:05
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous
> Delegated Responder Cert
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> I've created a new batch of certificates that violate 4.9.9 of the BRs,
> which was introduced with the first version of the Baseline Requirements as
> a MUST. This is https://misissued.com/batch/138/
>
> A quick inspection among the affected CAs include O fields of: QuoVadis,
> GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
> Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.
>
> Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
> Delegated Responder within Section 4.2.2.2 as indicated by the presence of
> the id-kp-OCSPSigning as an EKU.
>
> These certificates lack the necessary extension, and as such, violate the
> BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
> Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
> could also consider the effective date as 2013-05-15, described later in
> [1] , without changing the results.
>
> This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> certificates, due to other non-conformities, so I only included a sample.
>
> Censys.io is aware of approximately 276 certificates that meet this
> criteria, as you can see at [2]. The differences in perspectives
> underscores the importance of CAs needing to carefully examine the
> certificates they've issued to understand.
>
> It's important for CAs to understand this is Security Relevant. While they
> should proceed with revoking these CAs within seven (7) days, as defined
> under the Baseline Requirements Section 4.9.1.2, the degree of this issue
> likely also justifies requiring witnessed Key Destruction Reports, in order
> to 

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Rob Stradling via dev-security-policy]

> This batch is NOT comprehensive. According to crt.sh, there are approximately 
> 293 certificates that meet the criteria of "issued by a Mozilla-trusted, 
> TLS-capable CA, with the OCSPSigning EKU, and without pkix-nocheck". 
> misissued.com had some issues with parsing some of these certificates, due to 
> other non-conformities, so I only included a sample.

I just reproduced this result.  I've posted my SQL query and (thanks to GitHub) 
a searchable TSV report of all 293 certificates here:
https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f


From: dev-security-policy  on 
behalf of Ryan Sleevi via dev-security-policy 

Sent: 01 July 2020 22:05
To: mozilla-dev-security-policy 
Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated 
Responder Cert

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I've created a new batch of certificates that violate 4.9.9 of the BRs,
which was introduced with the first version of the Baseline Requirements as
a MUST. This is https://misissued.com/batch/138/

A quick inspection among the affected CAs include O fields of: QuoVadis,
GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.

Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
Delegated Responder within Section 4.2.2.2 as indicated by the presence of
the id-kp-OCSPSigning as an EKU.

These certificates lack the necessary extension, and as such, violate the
BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
could also consider the effective date as 2013-05-15, described later in
[1] , without changing the results.

This batch is NOT comprehensive. According to crt.sh, there are
approximately 293 certificates that meet the criteria of "issued by a
Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
pkix-nocheck". misissued.com had some issues with parsing some of these
certificates, due to other non-conformities, so I only included a sample.

Censys.io is aware of approximately 276 certificates that meet this
criteria, as you can see at [2]. The differences in perspectives
underscores the importance of CAs needing to carefully examine the
certificates they've issued to understand.

It's important for CAs to understand this is Security Relevant. While they
should proceed with revoking these CAs within seven (7) days, as defined
under the Baseline Requirements Section 4.9.1.2, the degree of this issue
likely also justifies requiring witnessed Key Destruction Reports, in order
to preserve the integrity of the issuer of these certificates (which may
include the CA's root).

The reason for this is simple: In every case I examined, these are
certificates that appear to nominally be intended as Issuing CAs, not as
OCSP Responder Certificates. It would appear that many CAs were unfamiliar
with RFC 6960 when constructing their certificate profiles, and similarly
ignored discussion of this issue in the past [3], which highlighted the
security impact of this. I've flagged this as a SECURITY matter for CAs to
carefully review, because in the cases where a third-party, other than the
Issuing CA, operates such a certificate, the Issuing CA has delegated the
ability to mint arbitrary OCSP responses to this third-party!

For example, consider a certificate like https://crt.sh/?id=2657658699 .
This certificate, from HARICA, meets Mozilla's definition of "Technically
Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However,
because it includes the OCSP Signing EKU, this certificate can be used to
sign arbitrary OCSP messages for HARICA's Root!

This also applies to non-technically-constrained sub-CAs. For example,
consider this certificate https://crt.sh/?id=21606064 . It was issued by
DigiCert to Microsoft, granting Microsoft the ability to provide OCSP
responses for any certificate issued by Digicert's Baltimore CyberTrust
Root. We know from DigiCert's disclosures that this is independently
operated by Microsoft.

Unfortunately, revocation of this certificate is simply not enough to
protect Mozilla TLS users. This is because this Sub-CA COULD provide OCSP
for itself that would successfully validate, AND provide OCSP for other
revoked sub-CAs, even if it was revoked. That is, if this Sub-CA's key was
maliciously used to sign a GOOD response for itself, it would be accepted.
These security concerns are discussed in Section 4.2.2.2.1 of RFC 6960, and
is tied to a reliance on the CRL. Mozilla users COULD be protected through
the use of OneCRL, although this would not protect other PKI participants
or use cases that don't use OneCRL.

A 

Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

[Rob Stradling via dev-security-policy]

I've just added a "Configure for WebPKI" shortcut to the "Trust Filter", which 
simply links to https://crt.sh/ca-issuers?webpki.

(Ditto for https://crt.sh/ocsp-responders?webpki).


From: dev-security-policy  on 
behalf of Jeremy Rowley via dev-security-policy 

Sent: 17 June 2020 23:13
To: r...@sleevi.com 
Cc: Mozilla 
Subject: Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content 
types)

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Doh - how did I miss that?! Thanks Ryan

From: Ryan Sleevi 
Sent: Wednesday, June 17, 2020 4:11:46 PM
To: Jeremy Rowley 
Cc: Mozilla 
Subject: Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content 
types)

It's right there under "Trust Filter" . Very top of the page ;)

e.g. 
https://crt.sh/ca-issuers?trustedExclude=expired%2Conecrl=Mozilla=Server+Authentication=v=2

On Wed, Jun 17, 2020 at 5:18 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Is there a way to filter out the revoked and non-TLS/SMIME ICAs?

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, June 17, 2020 5:07 AM
To: dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

Inspired by last month's email threads and Bugzilla issues relating to CA 
Issuers misconfigurations, I've just finished adding a new feature to crt.sh...

https://crt.sh/ca-issuers

Sadly, this highlights plenty of misconfigurations and other problems: PEM 
instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, 
non-existent domain names, connection timeouts.  I encourage CAs to take a look 
and see what they can fix.  (Also, comments welcome :-) ).

While I'm here, here's a quick reminder of some other crt.sh features relating 
to CA compliance issues:
https://crt.sh/ocsp-responders
https://crt.sh/test-websites
https://crt.sh/mozilla-disclosures


From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 on behalf of Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
Sent: 22 May 2020 21:52
To: Hanno Böck mailto:ha...@hboeck.de>>
Cc: r...@sleevi.com<mailto:r...@sleevi.com> 
mailto:r...@sleevi.com>>; 
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
 
mailto:dev-security-policy@lists.mozilla.org>>
Subject: Re: CA Issuer AIA URL content types

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I believe you've still implied, even in this reply, that this is something 
serious or important. I see no reason to believe that is the case, and I wasn't 
sure if there was anything more than a "Here's a SHOULD and here's people not 
doing it," which doesn't seem that useful to me.

On Fri, May 22, 2020 at 2:52 PM Hanno Böck 
mailto:ha...@hboeck.de>> wrote:

> Hi,
>
> On Fri, 22 May 2020 09:55:22 -0400
> Ryan Sleevi via dev-security-policy
> mailto:dev-security-policy@lists.mozilla.org>>
>  wrote:
>
> > Could you please cite more specifically what you believe is wrong
> > here? This is only a SHOULD level requirement.
>
> I think I said that more or less:
>
> > > I'm not going to file individual reports for the CAs. Based on
> > > previous threads I don't believe these are strictly speaking rule
> > > violations.
>
> I'm not claiming this is a severe issue or anything people should be
> worried about.
> It's merely that while analyzing some stuff I observed that AIA fields
> aren't as reliable as one might want (see also previous mails) and the
> mime types are one more observation I made where things aren't what
> they probably SHOULD be.
> I thought I'd share this observation with the community.
>
> --
> Hanno Böck
> https://hboeck.de/
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto: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<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozil

crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

[Rob Stradling via dev-security-policy]

Inspired by last month's email threads and Bugzilla issues relating to CA 
Issuers misconfigurations, I've just finished adding a new feature to crt.sh...

https://crt.sh/ca-issuers

Sadly, this highlights plenty of misconfigurations and other problems: PEM 
instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, 
non-existent domain names, connection timeouts.  I encourage CAs to take a look 
and see what they can fix.  (Also, comments welcome :-) ).

While I'm here, here's a quick reminder of some other crt.sh features relating 
to CA compliance issues:
https://crt.sh/ocsp-responders
https://crt.sh/test-websites
https://crt.sh/mozilla-disclosures


From: dev-security-policy  on 
behalf of Ryan Sleevi via dev-security-policy 

Sent: 22 May 2020 21:52
To: Hanno Böck 
Cc: r...@sleevi.com ; dev-security-policy@lists.mozilla.org 

Subject: Re: CA Issuer AIA URL content types

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I believe you’ve still implied, even in this reply, that this is something
serious or important. I see no reason to believe that is the case, and I
wasn’t sure if there was anything more than a “Here’s a SHOULD and here’s
people not doing it,” which doesn’t seem that useful to me.

On Fri, May 22, 2020 at 2:52 PM Hanno Böck  wrote:

> Hi,
>
> On Fri, 22 May 2020 09:55:22 -0400
> Ryan Sleevi via dev-security-policy
>  wrote:
>
> > Could you please cite more specifically what you believe is wrong
> > here? This is only a SHOULD level requirement.
>
> I think I said that more or less:
>
> > > I'm not going to file individual reports for the CAs. Based on
> > > previous threads I don't believe these are strictly speaking rule
> > > violations.
>
> I'm not claiming this is a severe issue or anything people should be
> worried about.
> It's merely that while analyzing some stuff I observed that AIA fields
> aren't as reliable as one might want (see also previous mails) and the
> mime types are one more observation I made where things aren't what they
> probably SHOULD be.
> I thought I'd share this observation with the community.
>
> --
> Hanno Böck
> https://hboeck.de/
>
___
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

Future of Certlint / CABLint (was Re: ZLint 2.1.0-RC1 and announcement list)

[Rob Stradling via dev-security-policy]

In other linter news...

It has become clear that the original certlint/cablint repository 
(https://github.com/awslabs/certlint) is no longer being maintained.  At 
Sectigo we still use cablint as one of our preissuance linters, and 
we've been running into more and more problems with cablint's stale PSL 
data and one or two out-of-date lints.  We think it's useful to have 
multiple, independent certificate linting implementations, and so we 
believe that certlint/cablint still has value.  Consequently, Sectigo 
Management has asked me to maintain a fork of the certlint/cablint 
repository.  Here it is:


https://github.com/certlint/certlint

Collaborators would be very welcome!

BTW, crt.sh is now using this new certlint fork.

On 13/05/2020 17:23, Zakir Durumeric via dev-security-policy wrote:

Hi all,
Earlier this year, we began publishing semantically versioned ZLint releases 
based on several requests from CAs. Yesterday, we tagged 2.1.0-RC1 
(https://github.com/zmap/zlint/releases/tag/v2.1.0-rc1), which includes the 
first batch of Mozilla Root Store Policy lints.

We have created a new minimal-traffic announcement list, which is where we will 
be announcing releases and other major project updates in the future: 
https://groups.google.com/forum/#!forum/zlint-announcements.

Thanks,

Zakir


--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: ssl.com: Certificate with Debian weak key

[Rob Stradling via dev-security-policy]

On 07/03/2020 23:57, Matt Palmer via dev-security-policy wrote:


As further independent confirmation, the crt.sh page for the certificate
shows that crt.sh *also* identifies the certificate as having a Debian weak
key.  My understanding is that crt.sh uses a database of keys that was
independently generated by the operator of the crt.sh service.


For the crt.sh check, I augmented Debian's original blacklists with some 
other blacklists I generated ~12yrs ago for a few less common key sizes 
[1].  See also [2].



[1] https://secure.sectigo.com/debian_weak_keys/

[2] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg10060.html



- Matt


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

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

Re: Acceptable forms of evidence for key compromise

[Rob Stradling via dev-security-policy]

"As an alternative, a standard “revocation request” format could be developed 
that leverages the relative discoverability of each CA’s problem-reporting 
mechanism."

Alternatively, how about we add discoverability to my proposal by asking 
Kathleen to add a "revokeCert API URL" field to the CCADB?


From: Corey Bonnell
Sent: Monday, March 02, 2020 21:38
To: Rob Stradling; Nick Lamb; mozilla-dev-security-policy
Cc: Matt Palmer
Subject: RE: Acceptable forms of evidence for key compromise


Using ACME as the revocation reporting mechanism moves the issue from using a 
bespoke proof-of-possession/revocation request protocol to a known address 
(i.e., the problem-reporting address disclosed in each CA’s CPS/CCADB) to an 
issue of using a known proof-of-possession/revocation protocol to a largely 
non-discoverable address (i.e., the “revoke-cert” endpoint of each CA’s ACME 
server).



There is no central registry of ACME directory URLs, so still significant work 
would be required to make ACME’s “revoke-cert” endpoint useful across CAs.



As an alternative, a standard “revocation request” format could be developed 
that leverages the relative discoverability of each CA’s problem-reporting 
mechanism.



Thanks,

Corey



From: Rob Stradling 
Sent: Monday, March 2, 2020 4:31 PM
To: Nick Lamb ; mozilla-dev-security-policy 
; Corey Bonnell 

Cc: Matt Palmer 
Subject: Re: Acceptable forms of evidence for key compromise



"I do think there's value in developing some standard mechanism to request 
revocation/demonstrate possession of the private key."



Such as 
https://tools.ietf.org/html/rfc8555#section-7.6
 ?



ISTM that any CA could stand up a standalone "revokeCert" API that only accepts 
proofs signed by the private key associated with the certificate, without that 
CA having to implement the rest of RFC8555.  Would this count as a "standard 
mechanism" (given that it's a portion of a Standards Track RFC)?  If so, why 
don't we simply say that this is the "standard mechanism"?



@Matt: I read your tweet 
(https://twitter.com/tobermatt/status/1232779464783695873)
 as proposing this idea, but ISTM that you've stopped slightly short of 
actually proposing it in this list thread.  



@Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI is 
kinda stuck with it now (see RFC8555).





From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 on behalf of Corey Bonnell via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
Sent: 02 March 2020 19:48
To: Nick Lamb mailto:n...@tlrmx.org>>; 
mozilla-dev-security-policy 
mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Cc: Matt Palmer mailto:mpal...@hezmatt.org>>
Subject: RE: Acceptable forms of evidence for key compromise



CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


There was quite a bit of discussion on the development of a standard
revocation request format on LAMPS WG mailing list two years ago in the wake
of the Trustico mass revocation:
https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/.
Nothing was developed in terms of a concrete proposal specifying a revocation
request format/protocol, but the pros/cons of such were hashed out pretty
thoroughly.

I do think there's value in developing some standard mechanism to request
revocation/demonstrate possession of the private key. The use of such a
mechanism would reduce the burden of work for those reporting key compromises,
as the reporter would not need to learn how to demonstrate possession the
private key 15 different ways to 15 different CAs. And CAs would benefit from
such a mechanism, as they wouldn't need to spend support cycles working with
the reporter to arrive at a suitable means to demonstrate possession or have
to learn some exoteric software tooling that the reporter is using to prove
possession.

Thanks,
Corey

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On
Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, March 2, 2020 2:35 PM
To: 
dev-security-policy@lists.mozilla.org
Cc: Matt Palmer mailto:mpal...@hezmatt.org>>
Subject: Re: Acceptable forms of evidence for key compromise

On Mon, 2 Mar 2020 13:48:55 +1100
Matt Palmer 

Re: Acceptable forms of evidence for key compromise

[Rob Stradling via dev-security-policy]

"but ISTM that you've stopped slightly short of actually proposing it in this 
list thread.  "

Or not!  


From: dev-security-policy  on 
behalf of Rob Stradling via dev-security-policy 

Sent: 02 March 2020 21:30
To: Nick Lamb ; mozilla-dev-security-policy 
; Corey Bonnell 

Cc: Matt Palmer 
Subject: Re: Acceptable forms of evidence for key compromise

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


"I do think there's value in developing some standard mechanism to request 
revocation/demonstrate possession of the private key."

Such as https://tools.ietf.org/html/rfc8555#section-7.6 ?

ISTM that any CA could stand up a standalone "revokeCert" API that only accepts 
proofs signed by the private key associated with the certificate, without that 
CA having to implement the rest of RFC8555.  Would this count as a "standard 
mechanism" (given that it's a portion of a Standards Track RFC)?  If so, why 
don't we simply say that this is the "standard mechanism"?

@Matt: I read your tweet 
(https://twitter.com/tobermatt/status/1232779464783695873) as proposing this 
idea, but ISTM that you've stopped slightly short of actually proposing it in 
this list thread.  

@Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI is 
kinda stuck with it now (see RFC8555).


From: dev-security-policy  on 
behalf of Corey Bonnell via dev-security-policy 

Sent: 02 March 2020 19:48
To: Nick Lamb ; mozilla-dev-security-policy 

Cc: Matt Palmer 
Subject: RE: Acceptable forms of evidence for key compromise

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


There was quite a bit of discussion on the development of a standard
revocation request format on LAMPS WG mailing list two years ago in the wake
of the Trustico mass revocation:
https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/.
Nothing was developed in terms of a concrete proposal specifying a revocation
request format/protocol, but the pros/cons of such were hashed out pretty
thoroughly.

I do think there's value in developing some standard mechanism to request
revocation/demonstrate possession of the private key. The use of such a
mechanism would reduce the burden of work for those reporting key compromises,
as the reporter would not need to learn how to demonstrate possession the
private key 15 different ways to 15 different CAs. And CAs would benefit from
such a mechanism, as they wouldn't need to spend support cycles working with
the reporter to arrive at a suitable means to demonstrate possession or have
to learn some exoteric software tooling that the reporter is using to prove
possession.

Thanks,
Corey

-Original Message-
From: dev-security-policy  On
Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, March 2, 2020 2:35 PM
To: dev-security-policy@lists.mozilla.org
Cc: Matt Palmer 
Subject: Re: Acceptable forms of evidence for key compromise

On Mon, 2 Mar 2020 13:48:55 +1100
Matt Palmer via dev-security-policy
 wrote:

> In my specific case, I've been providing a JWS[1] signed by the
> compromised private key, and CAs are telling me that they can't (or
> won't) work with a JWS, and thus no revocation is going to happen.
> Is this a reasonable response?

I don't hate JWS, but I can see Ryan's point of view on this. Not every
"proof" is easy to definitively assess, and a CA doesn't want to get into the
game of doing detailed forensics on (perhaps) random unfounded claims.

Maybe it makes sense for Mozilla to provide in its policy (without limiting
what else might be accepted) an example method of demonstrating Key Compromise
which it considers definitely sufficient ?

I'd also be comfortable with such an example in the BRs, if people think
that's the right place to do this.


Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062=-d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
___
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: Acceptable forms of evidence for key compromise

[Rob Stradling via dev-security-policy]

"I do think there's value in developing some standard mechanism to request 
revocation/demonstrate possession of the private key."

Such as https://tools.ietf.org/html/rfc8555#section-7.6 ?

ISTM that any CA could stand up a standalone "revokeCert" API that only accepts 
proofs signed by the private key associated with the certificate, without that 
CA having to implement the rest of RFC8555.  Would this count as a "standard 
mechanism" (given that it's a portion of a Standards Track RFC)?  If so, why 
don't we simply say that this is the "standard mechanism"?

@Matt: I read your tweet 
(https://twitter.com/tobermatt/status/1232779464783695873) as proposing this 
idea, but ISTM that you've stopped slightly short of actually proposing it in 
this list thread.  

@Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI is 
kinda stuck with it now (see RFC8555).


From: dev-security-policy  on 
behalf of Corey Bonnell via dev-security-policy 

Sent: 02 March 2020 19:48
To: Nick Lamb ; mozilla-dev-security-policy 

Cc: Matt Palmer 
Subject: RE: Acceptable forms of evidence for key compromise

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


There was quite a bit of discussion on the development of a standard
revocation request format on LAMPS WG mailing list two years ago in the wake
of the Trustico mass revocation:
https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/.
Nothing was developed in terms of a concrete proposal specifying a revocation
request format/protocol, but the pros/cons of such were hashed out pretty
thoroughly.

I do think there's value in developing some standard mechanism to request
revocation/demonstrate possession of the private key. The use of such a
mechanism would reduce the burden of work for those reporting key compromises,
as the reporter would not need to learn how to demonstrate possession the
private key 15 different ways to 15 different CAs. And CAs would benefit from
such a mechanism, as they wouldn't need to spend support cycles working with
the reporter to arrive at a suitable means to demonstrate possession or have
to learn some exoteric software tooling that the reporter is using to prove
possession.

Thanks,
Corey

-Original Message-
From: dev-security-policy  On
Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, March 2, 2020 2:35 PM
To: dev-security-policy@lists.mozilla.org
Cc: Matt Palmer 
Subject: Re: Acceptable forms of evidence for key compromise

On Mon, 2 Mar 2020 13:48:55 +1100
Matt Palmer via dev-security-policy
 wrote:

> In my specific case, I've been providing a JWS[1] signed by the
> compromised private key, and CAs are telling me that they can't (or
> won't) work with a JWS, and thus no revocation is going to happen.
> Is this a reasonable response?

I don't hate JWS, but I can see Ryan's point of view on this. Not every
"proof" is easy to definitively assess, and a CA doesn't want to get into the
game of doing detailed forensics on (perhaps) random unfounded claims.

Maybe it makes sense for Mozilla to provide in its policy (without limiting
what else might be accepted) an example method of demonstrating Key Compromise
which it considers definitely sufficient ?

I'd also be comfortable with such an example in the BRs, if people think
that's the right place to do this.


Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062=-d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Rob Stradling via dev-security-policy]

Dimitris,

Since CAs should already be disclosing that an intermediate certificate is 
"externally-operated" by populating the "Subordinate CA Owner" field in the 
CCADB record, what's the benefit of duplicating this information in the 
intermediate certificate itself?

What happens if an intermediate certificate starts life as 
"externally-operated" but later becomes "internally-operated", or vice-versa?  
(e.g., the root CA company acquires the intermediate CA company).

It's possible to update a CCADB record.  It's not possible to update a 
certificate.


From: dev-security-policy  on 
behalf of Dimitris Zacharopoulos via dev-security-policy 

Sent: 04 October 2019 05:43
To: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Adding to Jeremy's post, I believe we need to also define a normative
requirement to mark an unconstrained Intermediate CA Certificate not
operated by the entity that controls the Root Key.
Section 7.1.6.3 of the Baseline Requirements requires an explicit policy
identifier for these subCAs. The anyPolicy identifier is not permitted.
So, I assume that all Intermediate CA Certificates that include the
anyPolicy identifier should be operated by the Issuing CA (or an Affiliate).

Unfortunately -in one sense-, the BRs allow more specific policy
identifiers even for Intermediate CA Certificates that ARE operated by
the Issuing CA, so it is hard to differentiate which subCA is "Internal"
or "External".

I believe this is serious enough to consider the possibility of
requiring a specific policy identifier (assigned by the CABF) to be
included in externally-operated subCA Certificates, in addition to any
other policy identifiers that the Issuing CA has chosen for that CA
Certificate. Of course, other solutions might be available.

Mozilla is also going over a close investigation of unconstrained subCAs
that are missing audits and possibly included in oneCRL. I don't believe
these subCAs should be grandfathered in. However, others that have
supplied audit reports, following Mozilla Policies and indicating
compliance with the BRs, should be grandfathered.


Dimitris.



On 2019-10-04 3:06 π.μ., Jeremy Rowley via dev-security-policy wrote:
> Hey Wayne,
>
> I think there might be confusion on how the notification is supposed to 
> happen. Is notification through CCADB sufficient? We've uploaded all of the 
> Sub CAs to CCADB including the technically constrained ICAs. Each one that is 
> hosted/operated by itself is marked that way using the Subordinate CA Owner 
> field. Section 8 links to emailing certifica...@mozilla.org but 
> operationally, CCADB has become the default means of providing this notice. 
> If you're expecting email, that may be worth clarifying in case CAs missed 
> that an email is required. I know I missed that, and because CCADB is the 
> common method of notification there is a chance that notice was considered 
> sent but not in the expected way.
>
> There's also confusion over the "new to Mozilla" language I think. I 
> interpreted this language as organizations issued cross-signs after the 
> policy. For example, Siemens operated a Sub CA through Quovadis prior to 
> policy date so they aren't "new" to the CA space even if they were 
> re-certified. However, they would be new in the sense you identified - they 
> haven't gone through an extensive review by the community.  If the goal is to 
> ensure the community review happens for each Sub CA, then requiring all 
> recertifications to go through an approval process makes sense instead of 
> making an exception for new. I'm not sure how many exist currently, but if 
> there are not that many organizations, does a grandfathering clause cause 
> unnecessary complexity? I realize this is not in DigiCert's best interest, 
> but the community may benefit the most by simply requiring a review of all 
> Sub CAs instead of trying to grandfather in existing cross-signs.  Do you 
> have an idea on the number that might entail
>   ? At worst, we waste a bunch of time discovering that all of these are 
> perfectly operated and that they could have been grandfathered in the first 
> place. At best, we identify some critical issues and resolve them as a 
> community.
>
> If there are a significant number of unconstrained on-prem CAs, then language 
> that requires a review on re-signing would be helpful.  Perhaps say "As of X 
> date, a CA MUST NOT sign a non-technically constrained certificate where 
> cA=True for keys that are hosted external to the CA's infrastructure or that 
> are not operated in accordance with the issuing CA's policies and procedures 
> unless Mozilla has first granted permission for such certificate"? The 
> wording needs work of course, but the idea is that they go through the 
> discussion and Mozilla signs off. A process for unconstrained Sub CAs that is 
> substantially similar to the root inclusion makes sense, but 

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 02/10/2019 00:51, Wayne Thayer wrote:
> On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
> 
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case
> that the BRs are inconsistent with [4].
> 
> I could simply move [4] to a "recommended practice" (SHOULD) until the 
> ballot comes into force, then move it back to "required". That implies 
> that the bugs which have been opened for this specific issue (responding 
> "unknown" - not to be confused with "returns 1 byte") will be closed as 
> INVALID.
> 
> Are there strong objections to this course of action?

It seems a bit strange to recommend a practice that CAs cannot currently 
adhere to without violating the BRs and some other root programs' 
policies, but at the same time it is helpful to signpost upcoming policy 
changes.

I don't object strongly.

> - Wayne
> 
> [4] 
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
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

[Rob Stradling via dev-security-policy]

On 01/10/2019 00:45, Wayne Thayer via dev-security-policy wrote:
> I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob
> identified.

Thanks Wayne.  I've offered to endorse.

> I also want to acknowledge the feedback from Google on the timing of this.
> I can appreciate the framing of this as a new policy that's been added
> without due process, but I view this as a clarification of existing
> requirements.

I view [4] as new policy that's been added without due process.  I would 
have preferred to see your CABForum ballot [1] resolve this in the BRs 
first, so that CAs weren't faced with conflicting requirements.

> Some CAs have already been held accountable for this requirement [2]
> and some that have been paying close attention adhere to
> it. Others were struggling to determine what to do. Under these
> circumstances, it made no sense to me to roll back the policy, so the only
> reasonable course was to clarify it in favor of the consensus that emerged
> from this thread.

Some CAs (including Sectigo, as I mentioned in an earlier message) are 
currently compliant with (quoting you [1])...
   "During a lengthy discussion on the mozilla.dev.security.policy forum,
it was discovered that BR section 4.9.10 combined with BR
section 7.1.2.5 prevents a CA from responding “good” for a
precertificate." [1]

...but are not compliant with [4].

If/when your CABForum ballot [1] passes and (after the IPR period) takes 
effect, it will become possible for CAs to comply with [4] without 
falling out of compliance with the root program policies of Apple, 
Microsoft, etc, which incorporate the BRs but don't have a BR policy 
override equivalent to [4]).  Until then, what does Mozilla expect CAs 
to do?

> I'm still open to making changes to our "required practice" on
> precertificates, but having caught up on the thread I don't think any
> further changes are necessary.

I propose that you update [4] to say that Mozilla won't treat 
non-compliance with [4] as an "incident" whilst it remains the case that 
the BRs are inconsistent with [4].

> - Wayne
> 
> [1] https://cabforum.org/pipermail/servercert-wg/2019-September/00.html
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ

[4] 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
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

[Rob Stradling via dev-security-policy]

On 19/09/2019 21:01, Ryan Sleevi wrote:

> It would be helpful for one of the relevant documents, or another
> document, or even an errata, to clarify that OCSP services can be
> offered for pre-certificates.  It’s merely a question of clarifying
> the technical requirements about how an OCSP service should operate,
> as those requirements currently can be read to not allow OCSP
> responses for non-certificates.
> 
> 
> I'm still not sure I agree with the conflict, which is the key. In 
> either event, we're arguably discussing a profile / the operational 
> constraints specific to a given CA, and not something general with the 
> protocol. Whether or not a pre-certificate is treated as equivalent 
> issuance is, ultimately, a policy question.

Tim, Ryan,

I just started a thread on the TRANS list about this.  Please could I 
ask you to take this discussion there?

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
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

[Rob Stradling via dev-security-policy]

On 16/09/2019 18:08, Andrew Ayer wrote:
> 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:

Thanks Andrew.  I'll start a thread on the TRANS list to discuss this.

> "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
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: OCSP responder support for SHA256 issuer identifier info

[Rob Stradling via dev-security-policy]

I'm not aware of any requirement that demands that OCSP responders 
support SHA-256 for CertID.hashAlgorithm or of any requirement that 
forbids this.  Therefore, I think 1, 2 and 4 are all acceptable 
responses to an OCSP request whose CertID.hashAlgorithm is SHA-256.

SHA-1 is the defacto requirement for CertID.hashAlgorithm, and I would 
(still [1]) prefer to see SHA-1 required and all other hash algorithms 
forbidden.

Supporting stronger hash algorithms for CertID.hashAlgorithm would not 
lead to any security gain, but it would inflict pain on those CAs that 
need to regularly pregenerate OCSP responses (see [2]) for all unexpired 
leaf certificates.


[1] https://cabforum.org/pipermail/public/2013-November/002453.html

[2] https://tools.ietf.org/html/rfc6960#section-4.4.7.2.2

On 19/09/2019 01:09, Curt Spann via dev-security-policy wrote:
> In the WebPKI ecosystem I have seen a wide range of OCSP responses for OCSP 
> requests using SHA256 for the issuerNameHash and issuerKeyHash. I have 
> observed the following types of OCSP responses:
> 1. “good” response with issuerNameHash and issuerKeyHash using SHA256
> 2. “good” response with issuerNameHash and issuerKeyHash using SHA1
> 3. “unknown” response containing the correct SHA256 issuerNameHash and 
> issuerKeyHash but signed with an incorrect OCSP signing cert (chains to 
> different authority)
> 4. “unauthorized” response
> 5. “malformedrequest” response
> 
> I would like to have a discussion with the community about what is thought to 
> be the correct response. Of the various responses I have observed I think the 
> correct response is number 1. I would also like to know if others have seen 
> other variants of OCSP responses for request using SHA256 for the 
> issuerNameHash and issuerKeyHash.
> 
> Supporting info
> RFC 6960: https://tools.ietf.org/html/rfc6960
> - 4.1.1.  ASN.1 Specification of the OCSP Request
> RFC 2560: https://tools.ietf.org/html/rfc2560
> - 4.1.1  Request Syntax
> 
> - Curt

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
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

[Rob Stradling via dev-security-policy]

On 17/09/2019 08:01, Kurt Roeckx via dev-security-policy wrote:
> On 2019-09-16 14:02, Rob Stradling wrote:
>>
>> ISTM that this "certificate presumed to exist" concept doesn't play
>> nicely with the current wording of BR 4.9.10:
>>     'If the OCSP responder receives a request for status of a certificate
>>  that has not been issued, then the responder SHOULD NOT respond with
>>  a "good" status.'
>>
>> If a certificate (with embedded SCTs and no CT poison extension) is
>> "presumed to exist" but the CA has not actually issued it, then to my
>> mind that's a "certificate that has not been issued"; and therefore, the
>> OCSP 'responder SHOULD NOT respond with a "good" status'.
> 
> The problem of course is that you don't query OCSP about a certificate, 
> you query it about a serial number. And that serial number has been 
> issued. So maybe the BRs should say serial number instead of certificate?

Hi Kurt.  I agree, hence why I proposed:

   "- I would also like to see BR 4.9.10 revised to say something roughly
along these lines:
'If the OCSP responder receives a status request for a serial number
 that has not been allocated by the CA, then the responder SHOULD NOT
 respond with a "good" status.'"

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

___
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

[Rob Stradling via dev-security-policy]

On 16/09/2019 23:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote:

> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in
> question:
>     (1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
>     (2) SHOULD NOT respond "good" (see BR 4.9.10).
> 
> If I'm reading BR 4.9.10 correctly, the situation is worse because it 
> goes on to state "Effective 1 August 2013, OCSP responders for CAs which 
> are not Technically Constrained in line with Section 7.1.5 MUST NOT 
> respond with a "good" status for such certificates." (referring to 
> 'certificates that have not been issued' from the prior paragraph)

Thanks Wayne.  You're right.

(I read the "SHOULD NOT" requirement, forgot it had been superseded, and 
didn't read further.  I wonder if it would be reasonable to remove the 
superseded requirement from the BRs now, given that it was superseded 
over 6 years ago?)

> If the desired outcome is for CAs to respond "good" to a precertificate 
> without a corresponding certificate, we could override the BRs in 
> Mozilla policy, but I'd want to get the BRs updated quickly as Rob 
> suggested to avoid audit findings.

+1

> The other piece of this policy that's still unclear to me relates to the 
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA 
> to provide an "unknown" OCSP response for an issued certificate? If not, 
> should it be? The implication here would be that CAs responding 
> "unknown" to precertificates without corresponding certificates are 
> doing the right thing, despite prior precedent indicating that this is a 
> violation. [1]

This is making my brain hurt.

> - Wayne
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
> 
> Clearly that's impossible, which leads to the question: Which of these
> two conflicting requirements should a CA ignore in order to be as
> un-non-compliant as possible?  Which leads me to BR 7.1.2.5
> :
>     'For purposes of clarification, a Precertificate, as described
> in RFC
>      6962 – Certificate Transparency, shall not be considered to be a
>      “certificate” subject to the requirements of RFC 5280'
> 
> Since the first mention of "certificates" in the OCSP Protocol Overview
> (RFC6960 section 2) cross-references RFC5280, I believe that this
> 'shall
> not be considered to be a "certificate"' declaration can be assumed to
> extend to the OCSP requirements too.  And therefore, the balance tilts
> in favour of implementing 'SHOULD NOT respond "good"' and ignoring
> 'MUST
> respond "good"'.
> 
> I can't say I like this conclusion, but nonetheless it is the
> conclusion
> that my reading of the BRs forces me to reach.  I realize that what the
> BRs actually say may not reflect precisely what was intended by
> CABForum; nonetheless, CAs are measured by what the BRs actually say.
> 
> IDEAS FOR FIXING IT:
> 
> Long-term:
>     - In CT v2 (6962-bis), precertificates are not X.509 certificates,
> which removes Schrödinger from the equation.  :-)
> 
> Short-term:
>     - I think BR 7.1.2.5, as written, is decidedly unhelpful and should
> be revised to have a much smaller scope.  Surely only the serial number
> uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
> not the entirety of RFC5280?
>     - I would also like to see BR 4.9.10 revised to say something
> roughly
> along these lines:
>     'If the OCSP responder receives a status request for a serial number
>      that has not been allocated by the CA, then the responder
> SHOULD NOT
>      respond with a "good" status.'
> 
> P.S. Full disclosure: Sectigo currently provides an (unsigned)
> "unauthorized" OCSP response when a precert exists but the
> corresponding
> cert doesn't, but in all honesty I'm not currently persuaded that an
> Incident Report is warranted.
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com 
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:

> 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.

[Speaking only for myself]

Wayne, Andrew,

Please treat this message as a sincere attempt both to understand what 
the current requirements actually are and to seek to clarify what the 
requirements should be.

ISTM that this "certificate presumed to exist" concept doesn't play 
nicely with the current wording of BR 4.9.10:
   'If the OCSP responder receives a request for status of a certificate
that has not been issued, then the responder SHOULD NOT respond with
a "good" status.'

If a certificate (with embedded SCTs and no CT poison extension) is 
"presumed to exist" but the CA has not actually issued it, then to my 
mind that's a "certificate that has not been issued"; and therefore, the 
OCSP 'responder SHOULD NOT respond with a "good" status'.

However, this is Schrödinger's "certificate that has not been issued", 
because a Precertificate has been issued that has the same serial number 
(as the "certificate presumed to exist" that doesn't actually exist).

And so at this point ISTM that the OCSP responder is expected to 
implement two conflicting requirements for the serial number in question:
   (1) MUST respond "good", because an unrevoked/unexpired 
precertificate exists (and because BR 4.9.9 mandates a signed OCSP 
response).
   (2) SHOULD NOT respond "good" (see BR 4.9.10).

Clearly that's impossible, which leads to the question: Which of these 
two conflicting requirements should a CA ignore in order to be as 
un-non-compliant as possible?  Which leads me to BR 7.1.2.5:
   'For purposes of clarification, a Precertificate, as described in RFC
6962 – Certificate Transparency, shall not be considered to be a
“certificate” subject to the requirements of RFC 5280'

Since the first mention of "certificates" in the OCSP Protocol Overview 
(RFC6960 section 2) cross-references RFC5280, I believe that this 'shall 
not be considered to be a "certificate"' declaration can be assumed to 
extend to the OCSP requirements too.  And therefore, the balance tilts 
in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST 
respond "good"'.

I can't say I like this conclusion, but nonetheless it is the conclusion 
that my reading of the BRs forces me to reach.  I realize that what the 
BRs actually say may not reflect precisely what was intended by 
CABForum; nonetheless, CAs are measured by what the BRs actually say.

IDEAS FOR FIXING IT:

Long-term:
   - In CT v2 (6962-bis), precertificates are not X.509 certificates, 
which removes Schrödinger from the equation.  :-)

Short-term:
   - I think BR 7.1.2.5, as written, is decidedly unhelpful and should 
be revised to have a much smaller scope.  Surely only the serial number 
uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed, 
not the entirety of RFC5280?
   - I would also like to see BR 4.9.10 revised to say something roughly 
along these lines:
   'If the OCSP responder receives a status request for a serial number
that has not been allocated by the CA, then the responder SHOULD NOT
respond with a "good" status.'

P.S. Full disclosure: Sectigo currently provides an (unsigned) 
"unauthorized" OCSP response when a precert exists but the corresponding 
cert doesn't, but in all honesty I'm not currently persuaded that an 
Incident Report is warranted.

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

___
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

[Rob Stradling via dev-security-policy]

On 13/09/2019 19:24, Tim Hollebeek wrote:
> Yes, but I think this clarifies things in the wrong direction.

Hi Tim.  I'm not clear what you mean.

I was talking specifically and only about what IETF could/should do 
regarding this matter.  Which part did you disagree with, and why?

> -Tim
> 
>> -Original Message-
>> From: Rob Stradling 
>> Sent: Friday, September 13, 2019 4:22 AM
>> To: Tim Hollebeek ; Jeremy Rowley
>> ; Alex Cohn 
>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>> 
>> Subject: Re: DigiCert OCSP services returns 1 byte
>>
>> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
>>> So, this is something that would be helpfully clarified via either an
>>> IETF draft,
>>
>> There's already a 6962-bis draft [1] in IESG Last Call, which (when we 
>> finally
>> complete it!) will obsolete RFC6962.  6962-bis redefines precertificates so 
>> that
>> they're not actually X.509 certificates.
>> Therefore, I don't think a "clarify RFC6962" draft is necessary.
>>
>> Thinking aloud...
>> Does anything need to be clarified in 6962-bis though?
>> A (non-X.509) 6962-bis precertificate contains the serial number that will
>> appear in the certificate (if or when that certificate is issued),
>> so: Should the CA be forbidden, permitted or required to operate revocation
>> services for that serial number once the 6962-bis precertificate has been
>> produced but before the certificate has been issued?  (And is this a 
>> technical
>> matter for 6962-bis to address, or a policy matter that's out of scope for 
>> the
>> 6962-bis document?)
>>
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
>>
>>> or clarifications in the BRs.  There are various things in the OCSP RFCs and
>> even the BRs that can be read as precluding good OCSP responses for pre-
>> certificates, although the situation is unclear since the relevant sections 
>> are
>> blissfully ignorant of CT, and the correct behavior here was unfortunately 
>> left
>> out of RFC 6962, which should have clarified this.
>>>
>>> Happy to help draft something.  There are some interesting complexities
>> once you dig deeper.
>>>
>>> -Tim
>>>
 -Original Message-
 From: dev-security-policy
  On Behalf Of Jeremy
 Rowley via dev-security-policy
 Sent: Thursday, September 12, 2019 1:46 PM
 To: Alex Cohn 
 Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
 
 Subject: RE: DigiCert OCSP services returns 1 byte

 The language says you have to provide the response for the cert as if
 it exists, but the reality is that sending a response for the precert
 is the same as calculating the result for the certificate as if it
 exists and sending that. They are the same thing because the precert
 is treated the same as the final cert if the final cert doesn’t exist.

 I believe the intent is that a CT-naïve OCSP checker would work
 normally when presented with a precert or a certificate. Afterall, a
 precert is really just a certificate with a special extension.

 From: Alex Cohn 
 Sent: Thursday, September 12, 2019 9:25 AM
 To: Jeremy Rowley 
 Cc: Wayne Thayer ; mozilla-dev-security-
 pol...@lists.mozilla.org
 Subject: Re: DigiCert OCSP services returns 1 byte

 On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via
 dev-security-policy
 mailto:dev-security-
 pol...@lists.mozilla.org>> wrote:
 This means, for example, that (i) a CA must provide OCSP services and
 responses in accordance with the Mozilla policy for all
 pre-certificates as if corresponding certificate exists and (ii) a CA
 must be able to revoke a pre- certificate if revocation of the
 certificate is required under the Mozilla policy and the
 corresponding certificate doesn't actually exist and therefore cannot be
>> revoked.

 Should a CA using a precertificate signing certificate be required to
 provide OCSP services for their precertificates? Or is it on the
 relying party to calculate the proper OCSP request for the final
 certificate and send that instead? In other words, should we expect a
 CT-naïve OCSP checker to work normally when presented, e.g., with
>> https://crt.sh/?id=1868433277?

 Alex
 ___
 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
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> Email: r...@sectigo.com
>> Bradford, UK
>> Office: +441274024707
>> Sectigo Limited
>>
>> This message and any files associated with it may contain legally privileged,
>> confidential, or proprietary 

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> So, this is something that would be helpfully clarified via either an IETF 
> draft,

There's already a 6962-bis draft [1] in IESG Last Call, which (when we 
finally complete it!) will obsolete RFC6962.  6962-bis redefines 
precertificates so that they're not actually X.509 certificates. 
Therefore, I don't think a "clarify RFC6962" draft is necessary.

Thinking aloud...
Does anything need to be clarified in 6962-bis though?
A (non-X.509) 6962-bis precertificate contains the serial number that 
will appear in the certificate (if or when that certificate is issued), 
so: Should the CA be forbidden, permitted or required to operate 
revocation services for that serial number once the 6962-bis 
precertificate has been produced but before the certificate has been 
issued?  (And is this a technical matter for 6962-bis to address, or a 
policy matter that's out of scope for the 6962-bis document?)


[1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

> or clarifications in the BRs.  There are various things in the OCSP RFCs and 
> even the BRs that can be read as precluding good OCSP responses for 
> pre-certificates, although the situation is unclear since the relevant 
> sections are blissfully ignorant of CT, and the correct behavior here was 
> unfortunately left out of RFC 6962, which should have clarified this.
> 
> Happy to help draft something.  There are some interesting complexities once 
> you dig deeper.
> 
> -Tim
> 
>> -Original Message-
>> From: dev-security-policy  On
>> Behalf Of Jeremy Rowley via dev-security-policy
>> Sent: Thursday, September 12, 2019 1:46 PM
>> To: Alex Cohn 
>> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>> 
>> Subject: RE: DigiCert OCSP services returns 1 byte
>>
>> The language says you have to provide the response for the cert as if it 
>> exists,
>> but the reality is that sending a response for the precert is the same as
>> calculating the result for the certificate as if it exists and sending that. 
>> They are
>> the same thing because the precert is treated the same as the final cert if 
>> the
>> final cert doesn’t exist.
>>
>> I believe the intent is that a CT-naïve OCSP checker would work normally when
>> presented with a precert or a certificate. Afterall, a precert is really 
>> just a
>> certificate with a special extension.
>>
>> From: Alex Cohn 
>> Sent: Thursday, September 12, 2019 9:25 AM
>> To: Jeremy Rowley 
>> Cc: Wayne Thayer ; mozilla-dev-security-
>> pol...@lists.mozilla.org
>> Subject: Re: DigiCert OCSP services returns 1 byte
>>
>> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
>> mailto:dev-security-
>> pol...@lists.mozilla.org>> wrote:
>> This means, for example, that (i) a CA must provide OCSP services and
>> responses in accordance with the Mozilla policy for all pre-certificates as 
>> if
>> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
>> certificate if revocation of the certificate is required under the Mozilla 
>> policy
>> and the corresponding certificate doesn't actually exist and therefore cannot
>> be revoked.
>>
>> Should a CA using a precertificate signing certificate be required to provide
>> OCSP services for their precertificates? Or is it on the relying party to 
>> calculate
>> the proper OCSP request for the final certificate and send that instead? In
>> other words, should we expect a CT-naïve OCSP checker to work normally
>> when presented, e.g., with https://crt.sh/?id=1868433277?
>>
>> Alex
>> ___
>> 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

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
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

[Rob Stradling via dev-security-policy]

On 29/07/2019 21:52, Andrew Ayer via dev-security-policy wrote:
> 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.

crt.sh simply checks whether or not the CP and CPS URLs exactly match 
across all CCADB records for the same Subject CA.  I can't think of any 
good reason why these URLs would ever need to not match.

> 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:

I think this is a reasonable thing to ask for, at least in principle.

It's currently only possible for CAs to update the CP/CPS URLs in their 
CCADB Root Certificate records by opening a "CA Audit Update Request" 
Case.  (Each CCADB Root Certificate page says "CAs cannot modify data 
for the Root Certificate records. It is verified and maintained by root 
store operator.")

Practically, I believe this means that CAs can currently only disclose 
(changes to) CP/CPS URLs to the CCADB on an annual basis.  Given that 
https://www.ccadb.org/policy says (emphasis mine) "The URLs to such CPs, 
CPSes...need to be updated *as new information become available*", ISTM 
that CAs cannot currently use different URLs for different versions of 
their CP/CPS (as some CAs do) unless they restrict themselves to only 
updating their CP/CPS once a year, immediately prior to opening a "CA 
Audit Update Request" Case.

Requiring non-versioned CP/CPS URLs that point directly to the current 
CP/CPS document (rather than a repository page) could work though, I think.

Alternative idea:
Set up a GitHub repository (managed by the CCADB root store operators) 
that will hold CP/CPS documents.  Require CAs to disclose each new 
CP/CPS document by submitting a Pull Request.

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

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
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

[Rob Stradling via dev-security-policy]

Hi Brenda.

https://crt.sh/mozilla-disclosures now shows more information about why 
each intermediate certificate is being flagged as requiring further 
disclosure.

I've also added a "Review this Subject CA's CCADB records" link for each 
entry in the two new buckets.  This searches the CCADB for all records 
that share the same SPKI.  (The expectation is that the Audit and CP/CPS 
details will be consistent across all CCADB records that share the same 
SPKI).

Does that help?

On 27/07/2019 00:49, Brenda Bernal wrote:
> We are curious why our cross-roots are showing up on the list? Can you share 
> the logic on why these are appearing on the report?
> As far as our reviews are concerned, we see that all of these cross-roots are 
> properly disclosed and have covering audits.
>   
> We also see that you have listed CAs where there is a different audit for the 
> issuing CA than the audit that covers the root and the intermediate CA.
> We have reviewed the audits we have posted on CCADB for the non-TLS CAs and 
> we find we have accurately disclosed the division of responsibility between 
> our external CA operators who control the issuing CA under their own 
> qualifying audit, and our audits which cover the Root and the intermediate CA 
> which we operate in an offline manner.
> 
> Thank you,
> Brenda Bernal
> DigiCert
> 
> On 7/24/19, 9:42 AM, "dev-security-policy on behalf of Rob Stradling via 
> dev-security-policy"  of dev-security-policy@lists.mozilla.org> wrote:
> 
>  [Wearing Sectigo hat]
>  
>  Andrew, thanks for filing [1].  Sectigo will provide a full response on
>  that bug, but I'll just note here that we have updated the CCADB records
>  for the cross-certificates such that the Audit and CP/CPS details are
>  now consistent with the Web.com roots.  As it happens, I was already
>  aware of this inconsistency, but I'd delayed fixing it so that I could
>  use it as a test case for...
>  
>  [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.
>  
>  
>  [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1567060
>  
>  On 18/07/2019 21:46, Andrew Ayer via dev-security-policy wrote:
>  > 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
>  
>  --
>  Rob Stradling
>  Senior Research & Development Scientist
>  Sectigo Limited
>  ___
>  dev-security-policy mailing list
>  dev-security-policy@lists.mozilla.org
>  https://lists.mozilla.org/listinfo/dev-security-policy
>  
>  
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
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

[Rob Stradling via dev-security-policy]

[Wearing Sectigo hat]

Andrew, thanks for filing [1].  Sectigo will provide a full response on 
that bug, but I'll just note here that we have updated the CCADB records 
for the cross-certificates such that the Audit and CP/CPS details are 
now consistent with the Web.com roots.  As it happens, I was already 
aware of this inconsistency, but I'd delayed fixing it so that I could 
use it as a test case for...

[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.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1567060

On 18/07/2019 21:46, Andrew Ayer via dev-security-policy wrote:
> 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

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA-issued certificates for publicly-available private keys VU#553544

[Rob Stradling via dev-security-policy]

I've just created a batch for this second list on the Revocation Tracker:

https://misissued.com/batch/49/

On 03/04/2019 15:50, CERT Coordination Center wrote:
> Hi Wayne,
> 
> Sorry about the delay in getting back to you.  This first round of CA
> notifications went out at approximately 10AM Eastern time on March 25, 2019.
> 
> I just sent out a new set of notifications.  This time the notifications
> were limited only currently-valid certificates, as expired-cert
> notification was an oversight in the first batch.  This second list is:
> 
> -
> 
> https://crt.sh/?spkisha256=f2da5b49d3df3ebd9fe910c9972eea948f2d55f2f36c42658462f4b7aabe38a5
> https://crt.sh/?spkisha256=3198c26a22ed9d9602dad91e50dad40d67dcdae8075d2f7fca0c8b025c4a563b
> https://crt.sh/?spkisha256=1dbbd0bf172681ea65ef078865e6f38864e4b40282e9eff72d756383a7b21c51
> https://crt.sh/?spkisha256=ccf794fb078d757d59073173daec5ef7ba34a21ecdaa0f61761a21f5736a0fc7
> https://crt.sh/?spkisha256=8628d8106b72c39d98e8e731fc3b9364940efea0dfbb4816b1382542a979c834
> https://crt.sh/?spkisha256=c108876bca95ab02a0a3d10c7e38981cfc97789922a93bc3fed2a5734e93e97f
> https://crt.sh/?spkisha256=876b1175c135cd388d5b596985129a27967bdbbbe92c615ae9cdc7e33d6dfc62
> https://crt.sh/?spkisha256=71e1d2ce60955944b522ac4d9674e078f98a07e8edaaf1219c4324660e39139a
> https://crt.sh/?q=DC:66:CB:49:F6:DD:A8:13:5C:9D:7A:9E:F0:8A:1F:F7:6B:56:C2:57:88:20:6A:C4:63:F3:76:5B:47:7A:79:C7
> https://crt.sh/?spkisha256=f7e6d9d6a0e18d4ba0526068f9a80e8a7bdbba1191a6bf6e0384545b57edd45c
> https://crt.sh/?spkisha256=98087a0e49cc3f232aa0e79ed84ec26e4ce07e5bca4e2913f2ff986b25ac4f57
> https://crt.sh/?spkisha256=d2e4cf3dbf22f164f2301525a9ba6c2185926717c0a930abf322356bfd75e593
> https://crt.sh/?spkisha256=fa362787ec3d1c185602d45e364fa3aa9049a6d54a15aa58302d123f37de621e
> https://crt.sh/?spkisha256=f5d5f1cdb56cbac9f7306469ca7380f16226b60689d288cc5154962c55bc1605
> https://crt.sh/?spkisha256=a808916ae117cb5ef2c7e73ee11cff0231be1f706106110ca51df4e3914e8b24
> 
> -
> 
> 
> This second batch of notifications went out to the respective CAs at
> approximately 10:30AM Eastern time today (April 3, 2019)
> 
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
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

[Rob Stradling via dev-security-policy]

On 18/03/2019 21:11, Hector Martin 'marcan' wrote:
> On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote:
>> On 18/03/2019 17:05, Kurt Roeckx wrote:
>>> On Mon, Mar 18, 2019 at 03:30:37PM +0000, Rob Stradling via 
>>> dev-security-policy wrote:
>>>>
>>>> When a value in column E is 100%, this is pretty solid evidence of
>>>> noncompliance with BR 7.1.
>>>> When the values in column E and G are both approximately 50%, this
>>>> suggests (but does not prove) that the CA is handling the output from
>>>> their CSPRNG correctly.
>>>
>>> Sould F/G say >= 64, instead of > 64?
>>
>> Yes.  Fixed.  Thanks!
> 
> Perhaps it would make sense to separate out <64, ==64, >64?
> 
> 100% "64-bit" serial numbers would indicate an algorithm using 63 bits
> of entropy and the top bit coerced to 1.

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.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA-issued certificates for publicly-available private keys VU#553544

[Rob Stradling via dev-security-policy]

I've just created a batch for this list on the Revocation Tracker:

https://misissued.com/batch/47/

On 22/03/2019 19:05, CERT Coordination Center via dev-security-policy wrote:
> Hi folks,
> 
> I'm sharing this information with this list per suggestion of Hanno
> Böck.  Some time ago we started looking at private keys that are
> included with Android apps that are publicly available in the Google
> Play store.  Some subset of these keys have been used to obtain
> certificates from CAs participating in the CT project (as visible on
> https://crt.sh)
> 
> The following crt.sh link to keys/certificates that are associated with
> the compromised (released to the public) private keys:
> 
> https://crt.sh/?spkisha256=d31922465b3b7a85718752f1ae9bacb7cd1522996b073cd4da2464cdf84f697d
> https://crt.sh/?spkisha256=a7c10b71f3c0827222573dcc73dac168d91bf3c564b1f5bd43924baf0472576c
> https://crt.sh/?spkisha256=2766f6f5afa36174a08ca27aadaeba6621486960f385bed7ea83173ac2617703
> https://crt.sh/?spkisha256=0cf68ccb3c210c91f742efb4d6091f2467132f33df63b56a8dcb2c84cf9a7502
> https://crt.sh/?spkisha256=84041b5545a35e4bedcb4e1b88e0790dcf70a14abdf5f34d186e3a5656d060b0
> https://crt.sh/?spkisha256=9b4fb504d853e52a1ef4b49a5005d39d4ca5c2e1f98bacedd7befb728d589095
> https://crt.sh/?spkisha256=fddde47bfd018ea5b8b04be6dca332203e776d5249517b8db3acf5fa19abba10
> https://crt.sh/?spkisha256=24184bbe0eadbcfd69b06b0e6f10d07c58413ecdb080cc609469d8a13ad33417
> https://crt.sh/?spkisha256=ebb22a8bd69d1780ec0d74e23c2f83cdd559ef065766dfa80d19be0496ca3e35
> https://crt.sh/?spkisha256=d92b4545299cb1c2426205295a8acc24205bd7a9b7f1ab767c9270d6bed929e9
> https://crt.sh/?spkisha256=7732d4c9781979c2eda1dca14d610f627bf0eb14ad6d9f86c69d8f3a42c39430
> https://crt.sh/?spkisha256=cd6b8f0a1862390bd20dd81e63b266847bf645cdc440f4022fc165e34ff6a7f1
> https://crt.sh/?q=FB:1A:41:67:06:26:2B:99:8A:97:73:9A:FC:C7:E3:77:48:C3:E5:21:47:7E:FD:D5:03:D0:0C:31:C4:95:C5:07
> https://crt.sh/?q=A7:30:9D:E5:1D:44:85:6A:E6:00:74:C3:0F:3E:3E:EA:23:EA:78:2D:84:6C:10:77:0B:1C:8F:24:B3:6D:D4:4D
> https://crt.sh/?spkisha256=79c923c2d644eafef947d40d915b42684d35600a71cea6db22e88d7619a7825c
> https://crt.sh/?spkisha256=45c363fd97c114bdbaa8444d068a0347d18c862e657dd90e2a48ac978f533015
> https://crt.sh/?spkisha256=8206e318193186cace874b77d4b361ec37940e884d6ca10fca430164da663416
> https://crt.sh/?spkisha256=887b1c8bbfb6d54dc47cf4f2397e07e3ccd850ea26bf3bcd8e269bc5b2917266
> https://crt.sh/?spkisha256=d1a0748edb263fdf9fe8370db55b2669e52dec46cc61f7eec607febce66bba70
> https://crt.sh/?spkisha256=b805cc36a8a84d5f462d8230cb6c05fcd13c7f4d81143c4c58692e1c71ac5c66
> https://crt.sh/?spkisha256=f7f5a035038a3f933998ad503fe3535f823355101181ed51e1a942156a178dc2
> https://crt.sh/?spkisha256=493f34228ad3179e2dad25a392acae4d2dcaebcf633240a9df9d7f4413c4e681
> https://crt.sh/?spkisha256=9b40f2df2dc2bbc5d176cfb7b870342678e19cbf1ab14bef6ea22e20d60ec1b9
> https://crt.sh/?spkisha256=cbcbef7bedeb58b1fd36af2bbf32f3269d8a920d7aa77a4d6f7e5beb7c4b656e
> https://crt.sh/?spkisha256=357d37290366067db84ddc291ed15eeb0fef413235101c996a8d6f97e14dfa33
> https://crt.sh/?spkisha256=f8e3776c8f5cd1617faf006e2bfa3b7be3ea11960aa55f7ef72416bde1b7f958
> https://crt.sh/?spkisha256=6e199b309105b8f05f8af089eb9b97d7c4caf2490974c8d4e069a2ca5aca4574
> https://crt.sh/?spkisha256=9b56d3c26284ad6a2faa95ca5f4c13ab69d995abea034bac169146f5401a7a02
> https://crt.sh/?spkisha256=758854a6e58cd778129d56e72617d9312ac4a3bcf9c9b1227a117bb5ea83245e
> https://crt.sh/?spkisha256=0a7b4ca246d82b7b1abe7192be4960a1b9d236f59d056dae3c98bd9c147262f9
> https://crt.sh/?spkisha256=b4a95d9b6d13a38c5e1c5002c69084f4de054e9dc2139afb5fa2454b8042147a
> https://crt.sh/?q=59:A2:F6:05:11:57:A4:11:03:2E:39:45:2B:35:BF:01:E0:04:03:9E:C4:BA:EE:DE:1A:F8:BE:18:B2:4A:85:25
> https://crt.sh/?spkisha256=6e9bc0bd50ea63c19a0e9f04dea75bcca4f18306fea65859cc0676bfeeed87d5
> https://crt.sh/?spkisha256=45ebf9d2308a2b156e50ec13b0a27abc22124d4c167df730dc871773cdbfe66f
> https://crt.sh/?spkisha256=f0a48dd187500284ed98bd9293b3821f60efdf704aed5c14b7c366fc6a02aad9
> https://crt.sh/?spkisha256=07d669c4c024b6e5e1ab0d47e3af705764adb8066ab797ed9be6d690086f0772
> https://crt.sh/?spkisha256=22f6b4e6f9e06687c9df8c9cf4715e7fc58cdf7163d404d2362a4288b7c7e975
> https://crt.sh/?spkisha256=50259dd332075155f9fb4ae2dc23ad193b343941a6efef81d7d2ea2ee1aae1ec
> https://crt.sh/?spkisha256=a1c5cd8e193dffe45230254b62e27f4438414b69b439f835fea54f741c6c6f59
> https://crt.sh/?spkisha256=e3e5c7ff15cd52ce05902b8ae42ae08c3257457136756c89a35f7ee8554c9e59
> https://crt.sh/?spkisha256=d1c40311777bdc363fbe01eda747126efd2de188864cdba4ea5c131e1439da6e
> https://crt.sh/?spkisha256=c327dc1213ae46b0d3d716bced1d2dc588508a66ae1f032c685d18c12b5a226f
> https://crt.sh/?spkisha256=fd1eebe89eb69f45a81eb1fb6bf7216365ff1c138eebad311abcad66c1edf3f9
> https://crt.sh/?spkisha256=1b43aeac546388919f0a08dbbaa76750811d255379b884a19578fd3dc99bf996
> https://crt.sh/?spkisha256=90a3d4ea7c5d74a0ace3ecf8edec3431c2745763b2b01337002f46807d6481fd
> 

Re: Survey of (potentially noncompliant) Serial Number Lengths

[Rob Stradling via dev-security-policy]

On 18/03/2019 17:05, Kurt Roeckx wrote:
> On Mon, Mar 18, 2019 at 03:30:37PM +0000, Rob Stradling via 
> dev-security-policy wrote:
>>
>> When a value in column E is 100%, this is pretty solid evidence of
>> noncompliance with BR 7.1.
>> When the values in column E and G are both approximately 50%, this
>> suggests (but does not prove) that the CA is handling the output from
>> their CSPRNG correctly.
> 
> Sould F/G say >= 64, instead of > 64?

Yes.  Fixed.  Thanks!

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
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

[Rob Stradling via dev-security-policy]

On 18/03/2019 15:43, Rob Stradling via dev-security-policy wrote:
> On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote:
> 
>> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
>>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
>> 
>>>> If any other CA wants to check theirs before someone else does, then now 
>>>> is surely the time to speak up.
>>>
>>> Someone else is in the process of checking...  ;-)
>>
>> The purpose of this survey is to flush out any further CAs that are (or
>> have been) noncompliant with BR 7.1 but have not yet disclosed an
>> incident.

The report now also includes issuing CAs whose certificates have not 
been disclosed to the CCADB, which of course is permitted for 
technically-constrained intermediates.  (Many thanks to the person who 
pointed out this oversight to me).

> Columns A and B are currently empty.  They are intended to hold a
> Bugzilla URL and the date on which the bug was filed.
> 
> Jonathan Rudenberg has offered to review the disclosures that have been
> posted by CAs so far (thanks Jonathan!), so I've given him edit rights
> to the spreadsheet.

Jonathan has finished filling in Columns A & B for all of the 
disclosures he's seen so far.

>> Having scanned the crt.sh database, I have produced the following
>> spreadsheet.  It covers all certificates known to crt.sh where the
>> notBefore date is between 30th September 2016(*) and 22nd February
>> 2019(**), and where the issuing CA...
>>  - is currently trusted by Mozilla to issue serverAuthentication
>> certificates, and
>>  - has issued at least 1 certificate with a <64-bit serial number.
>>
>> https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing
>>
>> When a value in column E is 100%, this is pretty solid evidence of
>> noncompliance with BR 7.1.
>> When the values in column E and G are both approximately 50%, this
>> suggests (but does not prove) that the CA is handling the output from
>> their CSPRNG correctly.
>>
>> For some issuing CAs, the sample sizes are too small to be able to draw
>> any conclusions.
>>
>>
>> (*) This date was chosen because BR 7.1 says:
>> "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."
>>
>> (**) This is when Wayne started the discussion about DarkMatter, which
>> is what prompted the discovery that many CAs were falling short of BR 7.1.
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
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

[Rob Stradling via dev-security-policy]

On 18/03/2019 15:30, Rob Stradling via dev-security-policy wrote:

> On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
>> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
> 
>>> If any other CA wants to check theirs before someone else does, then now is 
>>> surely the time to speak up.
>>
>> Someone else is in the process of checking...  ;-)
> 
> The purpose of this survey is to flush out any further CAs that are (or
> have been) noncompliant with BR 7.1 but have not yet disclosed an
> incident.

Columns A and B are currently empty.  They are intended to hold a 
Bugzilla URL and the date on which the bug was filed.

Jonathan Rudenberg has offered to review the disclosures that have been 
posted by CAs so far (thanks Jonathan!), so I've given him edit rights 
to the spreadsheet.

> Having scanned the crt.sh database, I have produced the following
> spreadsheet.  It covers all certificates known to crt.sh where the
> notBefore date is between 30th September 2016(*) and 22nd February
> 2019(**), and where the issuing CA...
> - is currently trusted by Mozilla to issue serverAuthentication
> certificates, and
> - has issued at least 1 certificate with a <64-bit serial number.
> 
> https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing
> 
> When a value in column E is 100%, this is pretty solid evidence of
> noncompliance with BR 7.1.
> When the values in column E and G are both approximately 50%, this
> suggests (but does not prove) that the CA is handling the output from
> their CSPRNG correctly.
> 
> For some issuing CAs, the sample sizes are too small to be able to draw
> any conclusions.
> 
> 
> (*) This date was chosen because BR 7.1 says:
> "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."
> 
> (**) This is when Wayne started the discussion about DarkMatter, which
> is what prompted the discovery that many CAs were falling short of BR 7.1.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Survey of (potentially noncompliant) Serial Number Lengths

[Rob Stradling via dev-security-policy]

On 14/03/2019 10:59, Rob Stradling via dev-security-policy wrote:
> On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:

>> If any other CA wants to check theirs before someone else does, then now is 
>> surely the time to speak up.
> 
> Someone else is in the process of checking...  ;-)

The purpose of this survey is to flush out any further CAs that are (or 
have been) noncompliant with BR 7.1 but have not yet disclosed an 
incident.

Having scanned the crt.sh database, I have produced the following 
spreadsheet.  It covers all certificates known to crt.sh where the 
notBefore date is between 30th September 2016(*) and 22nd February 
2019(**), and where the issuing CA...
   - is currently trusted by Mozilla to issue serverAuthentication 
certificates, and
   - has issued at least 1 certificate with a <64-bit serial number.

https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing

When a value in column E is 100%, this is pretty solid evidence of 
noncompliance with BR 7.1.
When the values in column E and G are both approximately 50%, this 
suggests (but does not prove) that the CA is handling the output from 
their CSPRNG correctly.

For some issuing CAs, the sample sizes are too small to be able to draw 
any conclusions.


(*) This date was chosen because BR 7.1 says:
"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."

(**) This is when Wayne started the discussion about DarkMatter, which 
is what prompted the discovery that many CAs were falling short of BR 7.1.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Rob Stradling via dev-security-policy]

On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote:

> I'd already asked previously whether any CA wanted to indicate publicly that
> they were compliant with BR 7.1, which zero CAs responded to (I counted them
> twice).

Peter,

Mozilla Root Store Policy section 2.3 [1] requires CAs to conform to the 
latest version of the Baseline Requirements.  So ISTM that until or 
unless a CA publicly states that they are non-compliant with BR 7.1, we 
should act as if that CA has publicly stated that they are compliant 
with BR 7.1.

FWIW though, you can find a public statement from Sectigo at [2].


[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#23-baseline-requirements-conformance

[2] 
https://sectigo.com/blog/all-sectigo-public-certificates-meet-64-bit-serial-number-requirements

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Rob Stradling via dev-security-policy]

On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
> On Tuesday, March 12, 2019 at 11:53:25 PM UTC, Kurt Roeckx wrote:
>>
>> The expected distribution when generating a random 64 bit integer
>> and properly encoding that as DER is that:
>> - about 1/2 integers require 9 bytes
>> - about 1/2 integers require 8 bytes
>> - about 1/512 integers require 7 bytes
>> - about 1/131072 integers require 6 bytes
>> - about 1/33554432 integers require 5 bytes
>> - [...]
>>
>> That a serial is smaller than 8 bytes is not an indication that it
>> doesn't contain enough entropy.
> 
> This is true, but the situation is surely worse - any CA who's serial numbers 
> do not have a significant length variation is almost certainly not providing 
> 64 bits of entropy with the exception of those who are add a prefix to ensure 
> it is positive, and even those are not providing it unless they have lots of 
> serial numbers with a big block of zeros.
> 
> If any other CA wants to check theirs before someone else does, then now is 
> surely the time to speak up.

Someone else is in the process of checking...  ;-)

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

[Rob Stradling via dev-security-policy]

On 13/03/2019 03:04, Peter Gutmann wrote:
> Rob Stradling via dev-security-policy  
> writes:
> 
>> I've been working on an alternative proposal for a serial number generation
>> scheme, for which I intend to write an I-D and propose to the LAMPS WG.
> 
> This seems really, really complicated.

Yes, SNOT adds complexity, but this was necessary to achieve the 
security/transparency properties that I set out to achieve.

Whether or not all of those security/transparency properties are 
desirable enough to warrant (some or all) CAs taking on the burden of 
this added complexity is of course worthy of discussion.

CT, for example, is complicated, and yet the security/transparency 
properties have been deemed desirable enough to warrant burdening the 
ecosystem with the added complexity.

> In all of the endless debate over this, the one thing that hasn't actually 
> come > under question is how to generate the random values themselves. What 
has come up over> and over is how to encapsulate those values as an 
ASN.1 integer.

I'm not sure I agree that dropping 1-bit of entropy falls entirely into 
the "encapsulating those values as an ASN.1 integer" part.

> So I really prefer the
> Modest Proposal version, which directly addresses the bit-bagging problems
> that are the real issue with 7.1.
> 
> Peter.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

[Rob Stradling via dev-security-policy]

On 13/03/2019 03:18, Matthew Hardeman wrote:
> Overall I think it's a neat scheme.
> 
> It does impose some trade-offs beyond the mechanism that I proposed:
> 
> 1.  It leaves the implementing CA with no space within the serial number 
> field to include a CA significant sequence number, timestamp, or other 
> value.  That may not be a bad thing, but it's other than capabilities 
> that they have today.

To comply with today's BRs, SNOT requires that R MUST be 64-bits of 
(fresh and unfiltered!) output from a CSPRNG.

However, if using SNOT in any environment where today's BRs don't apply, 
the purpose of R is simply to act as a disambiguator; so it could be any 
string of 64-bits chosen by the CA (because the TRUNCATE_TO_64BITS(D) 
part of the algorithm is, I believe, sufficient by itself to thwart 
chosen-prefix attacks).

(For clarity: Whilst I can imagine a possible future in which the BRs 
are updated to relax the CSPRNG requirement when SNOT is used, I am *not 
proposing that here* because m.d.s.p is the wrong venue to discuss 
updating the BRs).

> 2.  It necessarily requires that the TBS certificate data be available 
> to the serial number generation routine.  This would seem to lock in 
> some architectural changes  as the system element producing the serial 
> number necessarily has to have all the TBSCertificate data), which may 
> not necessarily be the case today.

Good point.  I think this can be addressed by changing steps 7 and 8 to...

7. Perform a binary search for the first occurrence of H || A || R || D 
in the DER(TBSCertificate) that was produced in step 6, and replace that 
first occurrence with H || A || R || TRUNCATE_TO_64BITS(D).

8. Sign the (modified by step 7) DER(TBSCertificate).

> On Tue, Mar 12, 2019 at 12:10 PM Rob Stradling via dev-security-policy 
>  <mailto:dev-security-policy@lists.mozilla.org>> wrote:
> 
> Hi all.  I've been working on an alternative proposal for a serial
> number generation scheme, for which I intend to write an I-D and
> propose
> to the LAMPS WG.  However, since other folks' proposals are already
> flowing, I will share the gist of mine here.  Comments welcome!
> 
> - Serial Number Origin Transparency (SNOT ;-) ): Generation -
> 1. Let H (meaning "Header"; uint24) be: 0x00DE7E.  The 0x00 is the byte
> that makes the ASN.1 INTEGER a positive value.  0xDE7E signifies
> "DE7Erministic".
> 
> 2. Let A (meaning "Algorithm"; uint8) be a hash algorithm ID from the
> TLS HashAlgorithm registry
> 
> (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18).
> 
> 3. Let R (meaning "Random"; uint64) be 64-bits of (fresh and
> unfiltered!) output from a CSPRNG.
> 
> 4. Let M (meaning "Magic"; uint64) be the magic constant:
>     0x0102030405060708
> 
> 5. Generate the TBSCertificate template with the serial number value
> set to:
>     H || A || R || M
> 
> 6. Let D (meaning "Digest") be the thumbprint of the DER-encoded
> TBSCertificate, calculated using the hash algorithm denoted by A.
>     e.g., D = SHA-256(DER(TBSCertificate))
> 
> 7. Change the serial number value in the TBSCertificate template to:
>     H || A || R || TRUNCATE_TO_64BITS(D).
> 
> 8. Calculate DER(TBSCertificate), then sign it.
> --
> 
> Since this mechanism includes 64-bits of (fresh and unfiltered!) output
> from a CSPRNG, it is compatible with today's BRs.  The randomness also
> ensures that this mechanism doesn't yield multiple certs with the same
> serial number (contrary to RFC5280 §4.1.2.2) if the CA signs the exact
> same TBSCertificate multiple times using a nondeterministic signature
> algorithm.
> 
> In terms of preventing certificate forgery (see [1]), which is the
> thing
> that unpredictable serial numbers are designed to prevent, this
> mechanism gives CAs two chances to not screw up:
>     1) if the CA implements this mechanism wrongly but nonetheless does
> successfully include 64-bits of (fresh and unfiltered!) output from a
> CSPRNG, then the desired level of security is still achieved.
>     2) or, if the CA correctly implements the deterministic parts of
> this
> mechanism but mishandles the output from their CSPRNG, then the desired
> level of security is still achieved (although let me stress that this
> would of course not be compliant with today's BRs).
> 
> Whilst this mechanism does add complexity for the CA (compared to only
> using a CSPRNG to generate serial numbers), I think

Serial Number Origin Transparency proposal (was Re: A modest proposal for a better BR 7.1)

[Rob Stradling via dev-security-policy]

Hi all.  I've been working on an alternative proposal for a serial 
number generation scheme, for which I intend to write an I-D and propose 
to the LAMPS WG.  However, since other folks' proposals are already 
flowing, I will share the gist of mine here.  Comments welcome!

- Serial Number Origin Transparency (SNOT ;-) ): Generation -
1. Let H (meaning "Header"; uint24) be: 0x00DE7E.  The 0x00 is the byte 
that makes the ASN.1 INTEGER a positive value.  0xDE7E signifies 
"DE7Erministic".

2. Let A (meaning "Algorithm"; uint8) be a hash algorithm ID from the 
TLS HashAlgorithm registry 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18).

3. Let R (meaning "Random"; uint64) be 64-bits of (fresh and 
unfiltered!) output from a CSPRNG.

4. Let M (meaning "Magic"; uint64) be the magic constant:
   0x0102030405060708

5. Generate the TBSCertificate template with the serial number value set to:
   H || A || R || M

6. Let D (meaning "Digest") be the thumbprint of the DER-encoded 
TBSCertificate, calculated using the hash algorithm denoted by A.
   e.g., D = SHA-256(DER(TBSCertificate))

7. Change the serial number value in the TBSCertificate template to:
   H || A || R || TRUNCATE_TO_64BITS(D).

8. Calculate DER(TBSCertificate), then sign it.
--

Since this mechanism includes 64-bits of (fresh and unfiltered!) output 
from a CSPRNG, it is compatible with today's BRs.  The randomness also 
ensures that this mechanism doesn't yield multiple certs with the same 
serial number (contrary to RFC5280 §4.1.2.2) if the CA signs the exact 
same TBSCertificate multiple times using a nondeterministic signature 
algorithm.

In terms of preventing certificate forgery (see [1]), which is the thing 
that unpredictable serial numbers are designed to prevent, this 
mechanism gives CAs two chances to not screw up:
   1) if the CA implements this mechanism wrongly but nonetheless does 
successfully include 64-bits of (fresh and unfiltered!) output from a 
CSPRNG, then the desired level of security is still achieved.
   2) or, if the CA correctly implements the deterministic parts of this 
mechanism but mishandles the output from their CSPRNG, then the desired 
level of security is still achieved (although let me stress that this 
would of course not be compliant with today's BRs).

Whilst this mechanism does add complexity for the CA (compared to only 
using a CSPRNG to generate serial numbers), I think that the additional 
operations on the TBSCertificate are less complicated than most CAs have 
already had to deal with to issue CT precertificates and embed SCTs in 
certificates.

*** ADVANTAGES OF THIS MECHANISM ***
When implemented correctly by the CA, this mechanism enables the 
community to programmatically verify(*) that a certificate is not a 
forgery, without having to...
1. trust the CA (to have handled their CSPRNG correctly), or
2. trust the CA's WebTrust/ETSI auditors (to have correctly verified 
that the CA has handled their CSPRNG correctly), or
3. trust the CSPRNG algorithm to actually be unpredictable 
(Dual_EC_DRBG, anyone?)

This mechanism builds on PHB's earlier proposal [2].


[1] https://www.win.tue.nl/hashclash/rogue-ca/

[2] https://cabforum.org/pipermail/public/2016-July/008053.html

(*)
- Serial Number Origin Transparency (SNOT): Verification -
1. Check that the first 3 bytes of the certificate's serial number value 
(including the leading sign byte) are 0x00DE7E.

2. Check that the certificate's serial number value is exactly 20 bytes 
long (including the leading 0x00 sign byte).

3. Let A be the 4th byte of the serial number value (considering the 
leading 0x00 sign byte to be the 1st byte).  Check that A denotes a 
supported hash algorithm.

4. Let D1 be a copy of the last 8 bytes of the certificate's serial number.

5. Let T be a copy of the DER-encoded TBSCertificate component of the 
certificate.

6. Change the last 8 bytes of T's serial number to the magic constant:
   0x0102030405060708
(To avoid having to DER-decode and re-DER-encode T, this step should be 
performed using a binary search-and-replace directly on the first 
occurrence of D1 in T).

7. Let D2 be the thumbprint of T, calculated using the hash algorithm 
denoted by A.
   e.g., D2 = SHA-256(T)

8. Check that D1 exactly matches D2.
--

On 12/03/2019 14:14, Jakob Bohm via dev-security-policy wrote:
> On 09/03/2019 03:43, Matthew Hardeman wrote:
>> I know this isn't the place to bring a BR ballot, but I'm not presently a
>> participant there.
>>
>> I present alternative language along with notes and rationale which, I put
>> forth, would have resulted in a far better outcome for the ecosystem than
>> the issues which have arisen from the present BR 7.1 subsequent to ballot
>> 164.
>>
>> I humbly propose that this would have been a far better starting 

Re: DarkMatter Concerns

[Rob Stradling via dev-security-policy]

On 07/03/2019 05:14, Benjamin Gabriel via dev-security-policy wrote:
> Part 1 of 2:
> 
> Dear Ryan,
> 
> A fair and transparent public discussion requires full disclosure of each 
> participant's motivations and ultimate agenda.  Whether in CABForum, or 
> Mozilla-dev-security-policy, I represent the viewpoints of my employer 
> DarkMatter and passionately believe in our unflagging efforts to provide the 
> citizens, residents and visitors to the United Arab Emirates with the same 
> internet security and privacy protections that are taken for granted in other 
> parts of the world.
> 
> On Wednesday, March 6, 2019 7:51 PM, Ryan Sleevi wrote:
>>   (Writing in a personal capacity)
> 
> Until such time as we have been formally advised by your employer (Google), 
> that you no longer represent their views in CABForum, or in this 
> Mozilla-dev-security-policy forum, we will proceed on the basis that all of 
> your statements are the official viewpoint of your employer (Google).


[Writing in a personal capacity!]

I'd like to remind everyone about the Policy Participants [1] wiki page, 
which is "an optional list of the names, affiliations (if speaking for a 
company) and backgrounds of participants in the 
mozilla.dev.security.policy group".

Since 8th September 2016, this page has included the following text:
"Ryan Sleevi
Peer of the CA Certificates Module; Works for Google; PKI policy for 
Chrome/ChromeOS; Posting in a personal capacity, with posts not 
necessarily representing the views of Google or the Mozilla CA 
Certificate Module, except where otherwise noted."

So Ryan didn't actually need to write "(Writing in a personal 
capacity)", because it would have been implied if he'd omitted it.


I'd also like to remind everyone about the Mozilla Forum Etiquette [2] 
Ground Rules, especially "Be civil" and "Be kind to newcomers".


[1] https://wiki.mozilla.org/CA/Policy_Participants

[2] https://www.mozilla.org/en-US/about/forums/etiquette/

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: DarkMatter Concerns

[Rob Stradling via dev-security-policy]

Hi Scott.  It seems that the m.d.s.p list server stripped the 
attachment, but (for the benefit of everyone reading this) I note that 
you've also attached it to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.

Direct link:
https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699

On 26/02/2019 13:56, Scott Rea via dev-security-policy wrote:
> G’day Folks,
> 
> DarkMatter CEO (Karim Sabbagh), has provided an official response to Mozilla 
> on the recent media article about the UAE that referenced security and 
> intelligence matters. Per Wayne’s request to potentially share this on the 
> list, I am attaching a copy of that letter to this post.
> 
> Regards,
>   
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: DarkMatter Concerns

[Rob Stradling via dev-security-policy]

On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote:
> On Sat, 23 Feb 2019 10:16:27 +0100
> Kurt Roeckx via dev-security-policy
>  wrote:
>> I would also like to have a comment from the current root owner
>> (digicert?) on what they plan to do with it.
> 
> Two other things would be interesting from Digicert on this topic
> 
> 1. To what extent does DarkMatter have practical ability to issue
> independently of Digicert?
> 
> https://crt.sh/?caid=22507
> 
> It would be nice to know where this is on the spectrum of intermediate
> CAs, between the cPanel intermediate (all day-to-day operations
> presumably by Sectigo and nobody from cPanel has the associated RSA
> private keys)

Hi Nick.  I can confirm that all day-to-day operations for the cPanel 
intermediates are performed by Sectigo, and nobody from cPanel has the 
associated RSA private keys.

> and Let's Encrypt X3 (all day-to-day operations by Let's
> Encrypt / ISRG and presumably nobody from IdenTrust has the associated
> RSA private keys)


QuoVadis disclosed [1] that...

"The DarkMatter CAs were previously hosted and operated by QuoVadis, and 
included in the QuoVadis WebTrust audits through 2017. In November 2017, 
the CAs were transitioned to DarkMatter’s own control following 
disclosure to browser root programs."

I take that to mean that DarkMatter are in possession of the RSA private 
key corresponding to https://crt.sh/?caid=22507.


[1] https://www.quovadisglobal.com/QVRepository/ExternalCAs.aspx

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Rob Stradling via dev-security-policy]

On 24/01/2019 14:09, Kurt Roeckx via dev-security-policy wrote:
> On 2019-01-24 12:08, Rob Stradling wrote:
>>
>> Hi Kurt.
>>
>> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
>> address or Fully-Qualified Domain Name that is one of the values
>> contained in the Certificate’s subjectAltName extension (see Section
>> 7.1.4.2.1)."
>>
>> Fitting the U-label into subjectAltName:dNSName (an IA5String, not a
>> UTF8String) would be...hard, so in practice the dNSName has to contain
>> the A-label.
>>
>> So what does "is one of the values" mean?  It's certainly valid to use
>> the A-label in both the CN and SAN:dNSName.  However, it's arguably
>> invalid (or at least it's not obviously valid) to put the A-label in the
>> SAN:dNSName and the corresponding U-label in the CN.  (i.e., the U-label
>> and the A-label are different representations of the same value, but
>> they are not the same value).
> 
> I expect all fields in the subject to be things you can just read, so 
> U-labels. It does not make sense to show users an A-label, they do not 
> understand what that means. The fields in a subject allows writing 
> things in Unicode, there is no reason not to use it.


Here's an example cert containing the A-label in the SAN:dNSName and the 
U-label in the CN.  (It was issued by Sectigo, known back then as Comodo 
CA, before we switched to always putting the A-label in the CN):

https://crt.sh/?id=213062481=cablint,x509lint,zlint

x509lint agrees with your opinion (unsurprisingly!), but both cablint 
and zlint complain.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Rob Stradling via dev-security-policy]

On 24/01/2019 09:04, Kurt Roeckx via dev-security-policy wrote:
> On 2019-01-24 9:47, Buschart, Rufus wrote:
>> Good morning!
>>
>> I would like to sharpen my argument from below a little bit: If a CA 
>> gets a request to issue a certificate for the domain 
>> xn--gau-7ka.siemens.de, how can the CA tell, that xn--gau-7ka is a 
>> punycode string in IDNA2008 and not only a very strange server name? 
>> At least I don't have a glass bowl to read the mind of my customers. 
>> Therefor I would say, it is perfectly okay to issue a certificate for 
>> xn--gau-7ka.siemens.de as long as you perform a successful domain 
>> validation for xn--gau-7ka.siemens.de.
> 
> Will you fill something in in the commonName? I think what is expected 
> in the commonName is what the user would type and expect to see, I don't 
> think the commonName should contain xn--gau-7ka.siemens.de. If you have 
> a commonName, I would expect that it contains gauß.siemens.de.

Hi Kurt.

BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP 
address or Fully-Qualified Domain Name that is one of the values 
contained in the Certificate’s subjectAltName extension (see Section 
7.1.4.2.1)."

Fitting the U-label into subjectAltName:dNSName (an IA5String, not a 
UTF8String) would be...hard, so in practice the dNSName has to contain 
the A-label.

So what does "is one of the values" mean?  It's certainly valid to use 
the A-label in both the CN and SAN:dNSName.  However, it's arguably 
invalid (or at least it's not obviously valid) to put the A-label in the 
SAN:dNSName and the corresponding U-label in the CN.  (i.e., the U-label 
and the A-label are different representations of the same value, but 
they are not the same value).

This issue is one of the things that CABForum ballot 202 sought to 
clarify, and IIRC it was actually the reason why ballot 202 failed.

> And if 
> you create a commonName then, you are required to check that it matches 
> the xn--gau-7ka.siemens.de in the SAN.
> 
> 
> Kurt

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Test website monitor

[Rob Stradling via dev-security-policy]

On 14/01/2019 08:09, westmail24--- via dev-security-policy wrote:
> This URL ( https://crt.sh/test-websites ) does not work (~5 days)

Fixed.  Thanks.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 02/01/2019 14:10, Rob Stradling via dev-security-policy wrote:
> On 02/01/2019 13:44, info--- via dev-security-policy wrote:

>> We're reviewing what happened with this subCA, because it's reported to the 
>> CCADB (like all other subCAs). At the moment we've seen that there are two 
>> different entries in the crt.sh with the same serial number, but different 
>> fingerprints:
>>
>> https://crt.sh/?id=1477430 -> disclosed
>> https://crt.sh/?id=966433897 -> not disclosed
>>
>> This CA is not new, so there wouldn’t be any problem. But we continue 
>> analyzing what happened.
> 
> Thanks Oscar.  You're right: 966433897 is a duplicate of 1477430, and so
> this is *not* a violation of Mozilla's intermediate cert disclosure
> requirement.
> 
> The only difference between the two certs is the encoding of the
> signature parameters in the part of the certificate that is not covered
> by the CA's signature.  Anyone could create any number of "different"
> certs with malformed signature parameters that share the same
> CA-produced signature, and for this we can't blame the CA.  As it
> happens though, 966433897 is slightly less malformed than 1477430.
> 
> It's unfortunate that some CT logs accept, or used to accept, certs with
> malformed signature parameters (in the part of the cert not covered by
> the CA's signature).
> 
> Izenpe did make one related mistake when issuing this cert back in
> (presumably) 2010 though: the signature parameters in the TBSCertificate
> are omitted, whereas they should be an ASN.1 NULL (and so
> https://crt.sh/?id=1477430=cablint reports the error "RSA signatures
> must have a parameter specified").

To deal with this false positive, I've just deleted crt.sh ID 966433897 
and reassigned its log entry records to 1477430.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 02/01/2019 22:40, Wayne Thayer via dev-security-policy wrote:

> Yes, the idea is that CT could remove the need to enforce intermediate
> disclosures via policy.

Hi Wayne.  That seems at odds with (my understanding of) the purpose of 
the disclosure requirement.

The relevant phrase in the Mozilla Root Store Policy is "publicly 
disclosed and audited".  The CCADB captures audit information, whereas 
CT logs do not.

How would Mozilla check that a CT-logged intermediate is covered by an 
appropriate audit, if the CA is no longer required to disclose that 
information to the CCADB?

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 02/01/2019 13:44, info--- via dev-security-policy wrote:
> El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling  escribió:
>> On 09/10/2018 23:53, Wayne Thayer wrote:
>>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
>>>  Wayne, Kathleen:
>>>  Given the number of times that all the CAs in Mozilla's Root Program
>>>  have been reminded about Mozilla's requirements for disclosing
>>>  intermediate certs, I wouldn't blame you if you decided to add these 20
>>>  intermediate certs [5] to OneCRL immediately!
>>>
>>> I think we should give this serious consideration, although it doesn't
>>> help with the majority of these that are trusted for email.
>>
>> Hi Wayne.  Did you give this serious consideration?
>>
>> An Izenpe intermediate cert [1] has been known to crt.sh (see [2]) for
>> well over a month, but hasn't yet been disclosed to the CCADB.
>>
>>
>> [1] https://crt.sh/?id=966433897
>>
>> [2] https://crt.sh/mozilla-disclosures
>>
>> -- 
>> Rob Stradling
>> Senior Research & Development Scientist
>> Sectigo Limited
> 
> We're reviewing what happened with this subCA, because it's reported to the 
> CCADB (like all other subCAs). At the moment we've seen that there are two 
> different entries in the crt.sh with the same serial number, but different 
> fingerprints:
> 
> https://crt.sh/?id=1477430 -> disclosed
> https://crt.sh/?id=966433897 -> not disclosed
> 
> This CA is not new, so there wouldn’t be any problem. But we continue 
> analyzing what happened.

Thanks Oscar.  You're right: 966433897 is a duplicate of 1477430, and so 
this is *not* a violation of Mozilla's intermediate cert disclosure 
requirement.

The only difference between the two certs is the encoding of the 
signature parameters in the part of the certificate that is not covered 
by the CA's signature.  Anyone could create any number of "different" 
certs with malformed signature parameters that share the same 
CA-produced signature, and for this we can't blame the CA.  As it 
happens though, 966433897 is slightly less malformed than 1477430.

It's unfortunate that some CT logs accept, or used to accept, certs with 
malformed signature parameters (in the part of the cert not covered by 
the CA's signature).

Izenpe did make one related mistake when issuing this cert back in 
(presumably) 2010 though: the signature parameters in the TBSCertificate 
are omitted, whereas they should be an ASN.1 NULL (and so 
https://crt.sh/?id=1477430=cablint reports the error "RSA signatures 
must have a parameter specified").

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 09/10/2018 23:53, Wayne Thayer wrote:
> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
> Wayne, Kathleen:
> Given the number of times that all the CAs in Mozilla's Root Program
> have been reminded about Mozilla's requirements for disclosing
> intermediate certs, I wouldn't blame you if you decided to add these 20
> intermediate certs [5] to OneCRL immediately!
> 
> I think we should give this serious consideration, although it doesn't 
> help with the majority of these that are trusted for email.

Hi Wayne.  Did you give this serious consideration?

An Izenpe intermediate cert [1] has been known to crt.sh (see [2]) for 
well over a month, but hasn't yet been disclosed to the CCADB.


[1] https://crt.sh/?id=966433897

[2] https://crt.sh/mozilla-disclosures

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Use cases of publicly-trusted certificates

[Rob Stradling via dev-security-policy]

On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:

> For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
> browserWwwServerAuth" .  WWW is mentioned only in a comment under the
> OID definition.

Hi Jakob.

Are you suggesting that comments in ASN.1 specifications are meaningless 
or that they do not convey intent?

Also, are you suggesting that a canonical OID name must clearly convey 
the full and precise intent of the purpose(s) for which the OID should 
be used?

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Online exposed keys database

[Rob Stradling via dev-security-policy]

On 27/12/2018 10:35, Matt Palmer via dev-security-policy wrote:
> Hmm, Rob's reply never made it to my inbox.  I'll reply to that separately
> now I know it's a thing.

Hi Matt.  I'm consistently receiving "Undelivered Mail Returned to 
Sender" messages from your mailserver, which is presumably why you 
didn't see my reply.  The body of each message is as follows:


This is the mail system at host mail.hezmatt.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

: Command time limit exceeded: "exec 
/usr/bin/procmail -t
 -a "${EXTENSION}""


> On Thu, Dec 27, 2018 at 05:56:08PM +0900, Hector Martin 'marcan' via 
> dev-security-policy wrote:
>> On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote:
>>> I'm wondering how I might add a pwnedkeys check to crt.sh.  I think I'd
>>> prefer to have a table of SHA-256(SPKI) stored locally on the crt.sh DB.
>>
>> Yes, I think the right approach for an upstream source is to provide a big
>> list of hashes. People can then postprocess that into whatever database or
>> filter format they want.
> 
> The reason I haven't provided that (yet) is because, unlike pwnedpasswords,
> the set of pwned keys increases in real-time, as my scrapers go out into the
> world and find more keys.  Thus, a once-off dump of what's in the database
> today isn't going to be very useful tomorrow, or next week, or next month.
> 
> I don't want to put up a dump of everything until I've got a solid mechanism
> for people to retrieve and load updates of the dataset.  The last thing I
> want to do is give people any encouragement to use a stale data set.
> 
> Implementation of an auto-update mechanism is on the todo list, but it's
> quite a bit lower down the priority list than other things, like improving
> key scraping, and implementing a bloom filter of keys, which I feel is more
> useful, because you've got to hit the API anyway to get the attestation of
> compromise, so something with a bit of a false-positive rate isn't a big
> deal.
> 
> - Matt

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Online exposed keys database

[Rob Stradling via dev-security-policy]

Hi Matt.  This is great.  A few comments inline...

On 19/12/2018 09:00, Matt Palmer via dev-security-policy wrote:
> Hi Ryan,
> 
> On Tue, Dec 18, 2018 at 08:24:48PM -0800, Ryan Hurst via dev-security-policy 
> wrote:
>> My first thought is by using SPKI you have limited the service
>> unnecessarily to X.509 related keys, I imagined something like this
>> covering PGP, JWT as well as other formats.  It would be nice to see the
>> scope increased accordingly.
> 
> I had to use *something* to hash to get a fingerprint, and SPKI just
> happened to be the easiest to get out of Ruby's OpenSSL library.  It's also
> been well-defined for a very long time and so, I hope, is fairly widely
> supported.
> 
> Converting keys which happen to be in other formats into SPKI is a Simple
> Matter of Programming (or at least as simple as anything involving ASN.1
> ever is).  They're all the same key parameters underneath, after all (I
> noticed everyone seems to use the EC point encoding format from SEC 1,
> even).
> 
> I've already written code to do SSH public keys
> (https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/lib/openssl/pkey.rb),
> and it wasn't particularly onerous.  Extracting public keys out of PGP or
> JWK wouldn't, I presume, be a Herculean task, either.
> 
> At any rate, if I'd chosen some other format to represent the data to be
> hashed, then I'd have needed to write code to convert from SPKI to *that*
> format to search for keys in certificates, so it's all much of a muchness,
> modulo relative distaste for particular formats.

How do you handle malformed SPKIs?  (e.g., the algorithm parameters 
field for an RSA public key is missing, whereas it should be present and 
should contain an ASN.1 NULL).

Presumably your server/database only deals with correctly encoded SPKIs, 
and it's up to the caller to ensure that they repair an incorrectly 
encoded SPKI before they call your API?

>> It would be ideal if it were possible to download the database also, the
>> latency of the use of a third-party service while issuing certs is
>> potentially too much for a CA to eat at issuance time; something that
>> could optionally be used on-prem wouldn't leak affiliation and address
>> this.
> 
> I don't think the security community would be overly happy if I just dumped
> all the keys in a tarball for world+dog to download, but I *did* consider
> the possibility of providing something like a bloom filter of fingerprints,
> for people who really need to do high-volume, low-latency lookups.  I'd like
> to know that someone actually *wants* to do high-volume, low-latency lookups
> of exposed keys before I go building it (and the infrastructure for updating
> the filter, distributing the updates, etc), though.

I'm wondering how I might add a pwnedkeys check to crt.sh.  I think I'd 
prefer to have a table of SHA-256(SPKI) stored locally on the crt.sh DB.

>> As long as its limited to X.509, or at least as long as it supports it and
>> uses SPKI, it would be interesting to have the website use PKIjs to let
>> you browse to a cert, csr or key and the SPKI calculated for you.  Happy
>> to help with that if your interested.
> 
> My JavaScript skills are even worse than my Golang skills, so yeah, it would
> probably be better for everyone if someone else was willing to build that.
> 
> The command-line querying tool I wrote
> (https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/bin/pwnedkeys-query)
> takes all X.509-key-bearing forms and SSH public keys already, but I never
> expected it to be the primary querying tool for anyone other than the
> hard-core amongst us.  A more user-friendly frontend would, no doubt, be
> appreciated by many.
> 
>> Personally I prefer https://api.pwnedkeys.com/v1/ to
>> https://v1.pwnedkeys.com/.
> 
> I did it that way mostly so I can run future versions of the API on separate
> infrastructure.  The current version is very lightweight and scalable; if a
> future API version required more processing power to run at scale, I'd
> prefer to be able to manage them separately.  Not everyone has Google
> Frontends they can put everything behind...   It's a minor detail,
> though, and one which should impact all of about a dozen people (whoever's
> writing pwnedkeys querying libraries).  If it turns out I was
> being unnecessarily pessimistic, v2 of the API can always move under
> `api.pwnedkeys.com`, because the URL will change anyway for every new
> protocol version, regardless of how it's versioned.
> 
>> I see your using JWS; I had been planning on building mine on top of
>> Trillian (https://github.com/google/trillian) so you could have an
>> auditable low trust mechanism to do this.  Let me know if your interested
>> in that and I would be happy to help there.
> 
> As far as using JWS, I *really* wanted to include a signature in the
> attestation of compromise, so there was iron-clad proof that the key was in
> the control of someone who wanted to say it was pwned (hence why the signed

Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

[Rob Stradling via dev-security-policy]

On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:

> I think it;s worth calling out that Let's Encrypt has implemented what
> appears to be a relatively simple mitigation:
> https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945

Sectigo implemented this same mitigation about a month ago.

> I am also interested to know if other CAs are considering this or other
> mitigations (e.g. multi-perspective validation) for this attack.

Multi-perspective validation is something we've started to think about too.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: DigiCert Assured ID Root CA and Global Root CA EV Request

[Rob Stradling via dev-security-policy]

Hi Jeremy.  Comments inline...

On 14/12/2018 02:23, Jeremy Rowley via dev-security-policy wrote:

> Here’s the breakdown:
> 
> FATAL: x509: RSA modulus is not a positive number
> 
> Bad reading of the BRs. The BRs say the range should be between 2^16+1 and 
> 2^256-1. The team implementing this thought saw SHOULD and thought it was 
> optional. They missed the sentence before which says the public exponent MUST 
> be equal to 3 or more. I’ll file and incident report on this.

No, you've misunderstood the error message.  You're talking about the 
requirements for the public exponent, but this lint issue refers to the 
RSA modulus.

The modulus (n) is the product of two prime numbers (p and q).  AIUI, 
it's not possible for a prime number to be negative, so n=p*q will 
always be positive.

> FATAL: asn1: structure error: integer not minimally-encoded
> 
> I think this one is a false positive? It’s caused by padded zeros which  
> aren’t expressly prohibited. Want us to revoke these?

No, this isn't a false positive.  The ASN.1 Distinguished Encoding Rules 
(DER) expressly prohibit this.

Quoting from X.690 12/97:
"8.3 Encoding of an integer value
...
8.3.2  If the contents octets of an integer value encoding consist of 
more than one octet, then the bits of the first octet and bit 8 of the 
second octet:
   a) shall not all be ones; and
   b) shall not all be zero.
NOTE – These rules ensure that an integer value is always encoded in the 
smallest possible number of octets."

The public exponent (65537) in https://crt.sh/?asn1=628933973 is encoded 
as 02 04 00 01 00 01 (02=INTEGER, 04=length in bytes), whereas the only 
valid encoding is 02 03 01 00 01.

>   ERROR: The common name field in subscriber certificates must include only 
> names from the SAN extension
> 
> This one is a false positive

Yes, I think so.  This must've been due to cached linting results, 
generated by an old linter version.

It's impractical to re-lint every cert known to crt.sh every time a 
linter is updated.  But to facilitate this particular discussion, I've 
relinted all of the certs issued by https://crt.sh/?caid=1191 for which 
lint issues had previously been identified.

> ERROR: DNSNames must have a valid TLD
> 
> This is a false positive

Yes, except for https://crt.sh/?id=845405886=zlint, which has been 
discussed previously:
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg10727.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1500621


> ERROR: CAs MUST NOT issue subscriber certificates with validity periods 
> longer than 39 months regardless of circumstance.
> 
> False positive

How long is a month?

It could be argued that this cert's validity period is 39 months + 12 hours:
https://crt.sh/?id=282328562=zlint,x509lint,cablint

Thankfully the BRs now define maximum validity periods in terms of days 
rather than months.


> ERROR: Subject name fields must not contain '.','-',' ' or any other 
> indication that the field has been omitted
> 
> False positive. The BRs say “All other optional attributes, when present 
> within the subject field, MUST contain information that has  been verified by 
> the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ 
> ‘ (i.e. space)  characters, and/or any other indication that the value is 
> absent, incomplete, or not applicable.” With the strict wording policy that 
> seems in effect, organizationalUnit is not “All other optional attributes”. 
> It’s a defined attribute and thus cannot be “other”.

You're right that Subject:organizationalUnitName doesn't fall under "All 
other optional attributes".

However, the second sentence begins "Optional attributes...".  The 
"other" qualifier is not there, and since Subject:organizationalUnitName 
is an optional attribute, it is in scope for the "MUST NOT contain 
metadata" requirement.

> ERROR: Explicit text has a maximum size of 200 characters
> 
> False positive I think….

Yes, this appears to be a bug in ZLint.

The User Notice string in https://crt.sh/?id=289322499=zlint is 169 
characters long.  It's a BMPString, so each character is encoded in 2 
octets.  Presumably ZLint is counting the number of bytes instead of the 
number of characters.

Note the x509lint warning "explicitText is not using a UTF8String" 
though, which stems from RFC5280 forbidding the use of BMPString in this 
context:
  "Conforming CAs SHOULD use the
   UTF8String encoding for explicitText, but MAY use IA5String.
   Conforming CAs MUST NOT encode explicitText as VisibleString or
   BMPString."

RFC6818 un-forbids it, but AFAICT the BRs don't recognize RFC6818.



-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Test website monitor

[Rob Stradling via dev-security-policy]

Hi Rufus.  I'm not aware of any root program or CABForum requirement 
that supports your interpretation.

On 13/12/2018 12:26, Rufus Buschart wrote:
> Very nice! Are you sure, that this requirement is only valid for "Root 
> CAs"? I was always under the impression, that such a test web site needs 
> to be hosted for every "Issuing CA that chains up to a publicly trusted 
> Root CA".
> 
> /Rufus
> 
> What we do in life, echoes in eternity.
> ===
> Rufus J.W. Buschart
> Anna-Pirson-Weg 1c
> 91052 Erlangen
> Phone: +49 (0)9131 - 530 15 85
> Mobile: +49 (0)152 - 228 94 134
> Web: http://www.buschart.de
> 
> 
> Am Do., 13. Dez. 2018 um 12:18 Uhr schrieb Rob Stradling 
> mailto:r...@sectigo.com>>:
> 
> Thanks to Kathleen for suggesting/requesting this new crt.sh feature...
> 
> To facilitate compliance checking for the 3 test websites that BR 2.2
> [1] requires for each root certificate, I've created this new report:
> 
> https://crt.sh/test-websites
> 
> Anything in red on this page represents either: a
> misconfigured/non-compliant test website, a bug in my code, or an
> interesting edge case worthy of further discussion.
> 
> Each test website is currently rechecked every 10 minutes.  The code
> for
> the checker application is available at [2].
> 
> 
> [1]
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf
> "2.2. PUBLICATION OF INFORMATION
> ...
> The CA SHALL host test Web pages that allow Application Software
> Suppliers to test their software with Subscriber Certificates that
> chain
> up to each publicly trusted Root Certificate. At a minimum, the CA
> SHALL
> host separate Web pages using Subscriber Certificates that are (i)
> valid, (ii) revoked, and (iii) expired."
> 
> [2] https://github.com/crtsh/test_websites_monitor
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "crt.sh" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to crtsh+unsubscr...@googlegroups.com
> .
> To post to this group, send an email to cr...@googlegroups.com
> .
> To view this discussion on the web, visit
> 
> https://groups.google.com/d/msgid/crtsh/2615a68e-9626-8d77-86f4-78dd64c04b3d%40sectigo.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "crt.sh" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to crtsh+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to cr...@googlegroups.com 
> .
> To view this discussion on the web, visit 
> https://groups.google.com/d/msgid/crtsh/CAFnsKvjnAT6RZohgQNUEi5%3Dzxp-qDGxCi_K5jKOjwpvA%3DPZQAA%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Test website monitor

[Rob Stradling via dev-security-policy]

Thanks to Kathleen for suggesting/requesting this new crt.sh feature...

To facilitate compliance checking for the 3 test websites that BR 2.2 
[1] requires for each root certificate, I've created this new report:

https://crt.sh/test-websites

Anything in red on this page represents either: a 
misconfigured/non-compliant test website, a bug in my code, or an 
interesting edge case worthy of further discussion.

Each test website is currently rechecked every 10 minutes.  The code for 
the checker application is available at [2].


[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf
"2.2. PUBLICATION OF INFORMATION
...
The CA SHALL host test Web pages that allow Application Software 
Suppliers to test their software with Subscriber Certificates that chain 
up to each publicly trusted Root Certificate. At a minimum, the CA SHALL 
host separate Web pages using Subscriber Certificates that are (i) 
valid, (ii) revoked, and (iii) expired."

[2] https://github.com/crtsh/test_websites_monitor

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Communication: Underscores in dNSNames

[Rob Stradling via dev-security-policy]

Wayne, many thanks for drawing the attention of the CAs to this matter.

Sectigo (formerly Comodo CA) stopped issuing certificates with 
underscores in dNSNames soon after CABForum ballot 202 failed.  A search 
of our CA database this week found 251 certificates that are in scope 
for the BRs, expire on or after 15th January 2019, and that have at 
least one underscore in a dNSName.

To track Sectigo's progress towards the 15th January 2019 revocation 
deadline, I've created a new batch on Alex Gaynor's excellent Revocation 
Tracker:

https://misissued.com/batch/41/

On 12/11/2018 23:18, Wayne Thayer via dev-security-policy wrote:
> As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> creating a sunset period for TLS certificates containing an underscore
> ("_") character in the SAN. This practice was widespread until a year ago
> when it was pointed out that underscore characters are not permitted in
> dNSName name forms, and ballot 202 was proposed to create an exception to
> RFC 5280 that would allow the practice to continue. When that ballot
> failed, some CAs stopped allowing underscore characters in SANs and others
> continued. Ballot SC12 is intended to resolve this inconsistency and
> provide clear guidance to auditors.
> 
> The sunset period defined by ballot SC12 is very short. Today Mozilla sent
> an email to all CAs in our program informing them of this change and asking
> them to take any steps necessary to comply [2].
> 
> - Wayne
> 
> [1]
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> [2]
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo Rebrand to Sectigo

[Rob Stradling via dev-security-policy]

On 07/11/2018 01:36, RS Tyler Schroder via dev-security-policy wrote:
> Based on a recent visit to crt.sh , Comodo has rebranded to Sectigo 
> 
> 
> (Talked with Wayne off-list to confirm there's no announcement required under 
> BR Sec. 8, so just posting it for general awareness / discussion)

Hi Tyler.  Thanks for posting this.  However, I think your 
(unfortunately inaccurate) statement - "Comodo has rebranded to Sectigo" 
- demonstrates perfectly the confusion between two distinct 
organizations that necessitated this rebrand!

Comodo (https://www.comodo.com/) has not rebranded.  Comodo, which 
continues to offer various cybersecurity products and services, ceased 
being a CA when it sold a majority share in its "Comodo CA" business 
unit to Francisco Partners just over a year ago.

Sectigo (https://sectigo.com/) is the new name for "Comodo CA".

https://sectigo.com/newsroom/comodo-ca-rebrands-as-sectigo

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

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

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 19/10/2018 10:42, Ben Laurie wrote:
> On Fri, 19 Oct 2018 at 10:38, Rob Stradling wrote:


FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever  
signed.>>>

Put it in Trillian? :-)


That had occurred to me.  ;-)

Would it be useful?


To be properly useful you would need to extend CRL protocols to include 
inclusion proofs, but its a step in the right direction. Is there a way 
to add ad-hoc stuff to CRLs?


Yes, CRLs have X.509v3 extensions, just like certificates do.

I suppose "CRL Transparency" would look much the same as CT, except that 
it would operate on X.509v3 CRL blobs instead of X.509v3 Certificate blobs.


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 18/10/2018 22:55, Ben Laurie wrote:

On Fri, 12 Oct 2018 at 19:01, Rob Stradling wrote:

On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
 > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie mailto:b...@google.com>> wrote:

 >> This is one of the reasons we also need revocation transparency.
 >
 > As tempting as the buzzword is, and as much as we love motherhood
and apple
 > pie and must constantly think of the children, slapping
transparency after
 > a word doesn't actually address the needs of the community or
users, nor
 > does it resolve the challenging policy issues that arise. Just
because
 > something is cryptographically verifiable does not mean it actually
 > resolves real world problems, or does not introduce additional ones.
 >
 > A simpler solution, for example, is to maintain an archive of
CRLs signed
 > by the CA. Which would address the need without the distraction, and
 > without having the technical equivalent of Fermat's Last Theorem
being
 > invoked. Let's not let the perfect (and unspecified) be the enemy
of the
 > good and reasonable.

FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever
signed.


Put it in Trillian? :-)


That had occurred to me.  ;-)

Would it be useful?

--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 12/10/18 13:53, Jakob Bohm via dev-security-policy wrote:

On 12/10/2018 14:33, Ben Laurie wrote:



This is one of the reasons we also need revocation transparency.


Or just a crt.sh enhancement to remember the previously collected
revocations.


crt.sh already remembers previously collected CRL entries.

Examples:

1. https://crt.sh/?id=35391481 is a now-expired cert that crt.sh 
observed as revoked-by-CRL whilst it was time-valid.


2. https://crt.sh/mozilla-disclosures#disclosedandunrevokedfromcrl shows 
that https://crt.sh/?id=12724140 was revoked-by-CRL and then "unrevoked" 
(see also https://bugzilla.mozilla.org/show_bug.cgi?id=1442091)


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 09/10/2018 23:53, Wayne Thayer wrote:

>     - DigiCert
> 
> Looks like DigiCert disclosed these within a few hours of your email.

Yes, but I hope that DigiCert will provide an incident report so that we 
can understand why DigiCert's "processes in place to ensure that these 
requirements are met" failed in this case.

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

"ACTION 6" of Mozilla's September 2018 CA Communication [1] reminded CAs 
of the Mozilla Root Store Policy requirement [2] that 
non-technically-constrained intermediate CA certificates...
   "MUST be publicly disclosed in the CCADB by the CA that has their
certificate included in Mozilla's root program. The CA with a
certificate included in Mozilla's root program MUST disclose this
information within a week of certificate creation, and before any
such subordinate CA is allowed to issue certificates."

In their responses to "ACTION 6" [3], most CAs indicated that...
   "We are aware of the requirements for intermediate certificate
disclosure and have processes in place to ensure that these
requirements are met"

There are currently 20 undisclosed non-technically-constrained 
intermediates, belonging to 6 Root Owners, on "Rob's naughty list" [4] 
(snapshot at [5]).  All 20 were undisclosed and listed (on [4]) on the 
day the responses to [1] were due (September 30th), which means that 
they have not been disclosed "within a week of certificate creation".

So, ISTM that the "processes in place to ensure that these requirements 
are met" are insufficient/broken for at least the following Root Owners:
   - Certicámara
   - DigiCert
   - DocuSign (OpenTrust/Keynectis)
   - SECOM Trust Systems CO., LTD.
   - SwissSign AG
   - Telia Company (formerly TeliaSonera)

Wayne, Kathleen:
Given the number of times that all the CAs in Mozilla's Root Program 
have been reminded about Mozilla's requirements for disclosing 
intermediate certs, I wouldn't blame you if you decided to add these 20 
intermediate certs [5] to OneCRL immediately!


[1] 
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3rMGLL

[2] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited

[3] 
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3rMGLL=Q00078,Q00079

[4] https://crt.sh/mozilla-disclosures#undisclosed

[5] https://crt.sh/reports/20181009_MozillaDisclosures.html#undisclosed

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

On 01/10/2018 16:51, Rob Stradling via dev-security-policy wrote:

Hi Iñigo.

I suspect it's because my script that produces the 1 week summary data 
[1] isn't using a consistent view of the underlying linting results 
throughout its processing.  Hopefully this [2] will fix it.


Doh.  [2] was ineffective.  I'll have another look at this sometime.

100% errors from that Comodo issuing CA is because it's issuing SHA-1 
certs that chain to a no-longer-publicly-trusted root.



[1] 
https://github.com/crtsh/certwatch_db/blob/master/lint_update_1week_stats.sql 



[2] 
https://github.com/crtsh/certwatch_db/commit/8ce0c96c9c50bfb51db33c6f44c9c1d1a9f5a96c 



On 01/10/2018 15:35, Inigo Barreira wrote:
And checking this site, how can Comodo have more certs with errors 
(15030) than certs issued (15020).


Regards

From: dev-security-policy 
 on behalf of Adriano 
Santoni via dev-security-policy 

Sent: Monday, October 01, 2018 10:09 PM
To: Rob Stradling; Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Increasing number of Errors found in crt.sh

I also agree.

As I said before, that's a non-trusted certificate. It was issued by a
test CA that does /not/ chain to a public root.


Il 01/10/2018 16:04, Rob Stradling ha scritto:

On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:

Hi Adriano,

First, I didn't mean to call you out specifically, but you happened
to be
first alphabetically, sorry.  I find this link very helpful to list
all CAs
with errors or warnings: https://crt.sh/?cablint=1+week

Second, How do you define a "test CA"?  I thought that any CA that
chains to
a public root was by definition not a test CA,


I agree with that.


and since the issued cert was
in CT logs, I assumed that your root was publicly trusted. Maybe I'm
mistaken on one of these points


Actually, some non-publicly-trusted roots are accepted by some of the
logs that crt.sh monitors.


Doug

-Original Message-
From: dev-security-policy
 On
Behalf Of Adriano Santoni via dev-security-policy
Sent: Monday, October 1, 2018 9:49 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Increasing number of Errors found in crt.sh

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate
in that
list, and it's a non-trusted certificate (it was issued by a test CA).


Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:

Is it possible to filter the list https://crt.sh/?cablint=issues
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that
corresponds to the issuing CA you're interested in.


Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and
asking
for misissuance reports for those that are not compliant? There
are 15
different errors and around 300 individual errors (excluding the
SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, 
are

including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors
like
underscores in CNs or SANs.


Doug






--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

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

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

crt.sh deliberately doesn't monitor any of Google's dedicated test logs 
(Testtube, Crucible, Solera20XX), but it does monitor some multi-purpose 
logs that are sometimes used for testing (e.g., Dodo).


On 01/10/18 20:09, Doug Beattie wrote:

Thanks Wayne.

Rob, Adriano : I had no idea that crt.sh included logs that supported 
test roots or roots that weren’t in some/all root programs.  I assumed 
these were all production level roots that needed to comply with the 
BRs.  Thanks for that tid-bit!


Alex: I’ll keep an eye on https://misissued.com  and use that as a 
better, more filtered report once it returns to life.


Doug

*From:*Wayne Thayer 
*Sent:* Monday, October 1, 2018 2:58 PM
*To:* Doug Beattie 
*Cc:* mozilla-dev-security-policy 


*Subject:* Re: Increasing number of Errors found in crt.sh

Doug,

Responding to your original question, I look at crt.sh and other data 
sources for certificate errors when reviewing inclusion requests or 
doing other sorts of investigations. I am not currently reviewing the 
crt.sh report for misissuance on a regular basis, but maybe I should.


I went through the current list and identified the following problems 
affecting certificates trusted by Mozilla:


* KIR S.A.: Multiple issues - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495497


* Government of Spain FNMT: OU exceeds 64 characters - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495507


* Assecco DS (Certum): Unallowed key usage for EC public key - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495518


* Certinomis: issued & revoked a precertificate containing a SAN of 
'www', didn't report it - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495524


- Wayne

On Mon, Oct 1, 2018 at 8:51 AM Rob Stradling via dev-security-policy 
<mailto:dev-security-policy@lists.mozilla.org>> wrote:


Hi Iñigo.

I suspect it's because my script that produces the 1 week summary data
[1] isn't using a consistent view of the underlying linting results
throughout its processing.  Hopefully this [2] will fix it.

100% errors from that Comodo issuing CA is because it's issuing SHA-1
certs that chain to a no-longer-publicly-trusted root.


[1]

https://github.com/crtsh/certwatch_db/blob/master/lint_update_1week_stats.sql

[2]

https://github.com/crtsh/certwatch_db/commit/8ce0c96c9c50bfb51db33c6f44c9c1d1a9f5a96c

On 01/10/2018 15:35, Inigo Barreira wrote:
 > And checking this site, how can Comodo have more certs with
errors (15030) than certs issued (15020).
 >
 > Regards
 > 
 > From: dev-security-policy
mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf of
Adriano Santoni via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
 > Sent: Monday, October 01, 2018 10:09 PM
 > To: Rob Stradling; Doug Beattie
 > Cc: mozilla-dev-security-policy
 > Subject: Re: Increasing number of Errors found in crt.sh
 >
 > I also agree.
 >
 > As I said before, that's a non-trusted certificate. It was issued
by a
 > test CA that does /not/ chain to a public root.
 >
 >
 > Il 01/10/2018 16:04, Rob Stradling ha scritto:
 >> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
 >>> Hi Adriano,
 >>>
 >>> First, I didn't mean to call you out specifically, but you happened
 >>> to be
 >>> first alphabetically, sorry.  I find this link very helpful to list
 >>> all CAs
 >>> with errors or warnings: https://crt.sh/?cablint=1+week
 >>>
 >>> Second, How do you define a "test CA"?  I thought that any CA that
 >>> chains to
 >>> a public root was by definition not a test CA,
 >>
 >> I agree with that.
 >>
 >>> and since the issued cert was
 >>> in CT logs, I assumed that your root was publicly trusted.
Maybe I'm
 >>> mistaken on one of these points
 >>
 >> Actually, some non-publicly-trusted roots are accepted by some
of the
 >> logs that crt.sh monitors.
 >>
 >>> Doug
 >>>
 >>> -Original Message-
 >>> From: dev-security-policy
 >>> mailto:dev-security-policy-boun...@lists.mozilla.org>> On
 >>> Behalf Of Adriano Santoni via dev-security-policy
 >>> Sent: Monday, October 1, 2018 9:49 AM
 >>> To: dev-security-policy@lists.mozilla.org
<mailto:dev-security-policy@lists.mozilla.org>
 >>> Subject: Re: Increasing number of Errors found in crt.sh
 >>>
 >>> Thank you Rob!
 >>>
 >>> If I am not mistaken, it see

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

Hi Iñigo.

I suspect it's because my script that produces the 1 week summary data 
[1] isn't using a consistent view of the underlying linting results 
throughout its processing.  Hopefully this [2] will fix it.


100% errors from that Comodo issuing CA is because it's issuing SHA-1 
certs that chain to a no-longer-publicly-trusted root.



[1] 
https://github.com/crtsh/certwatch_db/blob/master/lint_update_1week_stats.sql


[2] 
https://github.com/crtsh/certwatch_db/commit/8ce0c96c9c50bfb51db33c6f44c9c1d1a9f5a96c


On 01/10/2018 15:35, Inigo Barreira wrote:

And checking this site, how can Comodo have more certs with errors (15030) than 
certs issued (15020).

Regards

From: dev-security-policy  on behalf 
of Adriano Santoni via dev-security-policy 
Sent: Monday, October 01, 2018 10:09 PM
To: Rob Stradling; Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Increasing number of Errors found in crt.sh

I also agree.

As I said before, that's a non-trusted certificate. It was issued by a
test CA that does /not/ chain to a public root.


Il 01/10/2018 16:04, Rob Stradling ha scritto:

On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:

Hi Adriano,

First, I didn't mean to call you out specifically, but you happened
to be
first alphabetically, sorry.  I find this link very helpful to list
all CAs
with errors or warnings: https://crt.sh/?cablint=1+week

Second, How do you define a "test CA"?  I thought that any CA that
chains to
a public root was by definition not a test CA,


I agree with that.


and since the issued cert was
in CT logs, I assumed that your root was publicly trusted. Maybe I'm
mistaken on one of these points


Actually, some non-publicly-trusted roots are accepted by some of the
logs that crt.sh monitors.


Doug

-Original Message-
From: dev-security-policy
 On
Behalf Of Adriano Santoni via dev-security-policy
Sent: Monday, October 1, 2018 9:49 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Increasing number of Errors found in crt.sh

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate
in that
list, and it's a non-trusted certificate (it was issued by a test CA).


Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:

Is it possible to filter the list https://crt.sh/?cablint=issues
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that
corresponds to the issuing CA you're interested in.


Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and
asking
for misissuance reports for those that are not compliant? There
are 15
different errors and around 300 individual errors (excluding the
SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors
like
underscores in CNs or SANs.


Doug




--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

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

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

Yeah, it would be good to make it possible to filter 
https://crt.sh/?cablint=1+week by trust context.


On 01/10/2018 15:07, Alex Gaynor wrote:
A broader issue is that a lot of the certs listed on these pages are 
publicly-trusted, but not by the Mozilla Root Program, that is to say, 
Microsoft or Apple (or occasionally Adobe) trusts them.


misissued.com <http://misissued.com> (which is currently erroring on all 
requests )  tried to address this by only showing certificates from 
CA's in the Mozilla Root Program, since that's the extent of our 
jurisdiction (and CA's applying for inclusion, which in some cases are 
ones which have a history of non-compliance under other root programs, 
but there's no way to programatically tell if a CA is applying for 
inclusion).


Alex


On Mon, Oct 1, 2018 at 10:05 AM Rob Stradling via dev-security-policy 
<mailto:dev-security-policy@lists.mozilla.org>> wrote:


On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
 > Hi Adriano,
 >
 > First, I didn't mean to call you out specifically, but you
happened to be
 > first alphabetically, sorry.  I find this link very helpful to
list all CAs
 > with errors or warnings: https://crt.sh/?cablint=1+week
 >
 > Second, How do you define a "test CA"?  I thought that any CA
that chains to
 > a public root was by definition not a test CA,

I agree with that.

 > and since the issued cert was
 > in CT logs, I assumed that your root was publicly trusted.  Maybe I'm
 > mistaken on one of these points

Actually, some non-publicly-trusted roots are accepted by some of the
logs that crt.sh monitors.

 > Doug
 >
 > -Original Message-
 > From: dev-security-policy
mailto:dev-security-policy-boun...@lists.mozilla.org>> On
 > Behalf Of Adriano Santoni via dev-security-policy
 > Sent: Monday, October 1, 2018 9:49 AM
 > To: dev-security-policy@lists.mozilla.org
<mailto:dev-security-policy@lists.mozilla.org>
 > Subject: Re: Increasing number of Errors found in crt.sh
 >
 > Thank you Rob!
 >
 > If I am not mistaken, it seems to me that we have just 1
certificate in that
 > list, and it's a non-trusted certificate (it was issued by a test
CA).
 >
 >
 > Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha
scritto:
 >> On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
 >>> Is it possible to filter the list https://crt.sh/?cablint=issues
 >>> based on the issuing CA ?
 >>
 >> Yes.
 >>
 >> First, visit this page:
 >> https://crt.sh/?cablint=1+week
 >>
 >> Next, click on the link in the "Issuer CN, OU or O" column that
 >> corresponds to the issuing CA you're interested in.
 >>
 >>> Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha
scritto:
 >>>> Hi Wayne and all,
 >>>>
 >>>>
 >>>> I've been noticing an increasing number of CA errors,
 >>>> https://crt.sh/?cablint=issues  Is anyone monitoring this list and
 >>>> asking
 >>>> for misissuance reports for those that are not compliant?
There are 15
 >>>> different errors and around 300 individual errors (excluding
the SHA-1
 >>>> "false" errors).  Some CAs are issuing certs to CNs of
localhost, are
 >>>> including RFC822 SANs, not including OCSP links and many more.
 >>>>
 >>>> -  Actalis,
 >>>>
 >>>> -  Digicert,
 >>>>
 >>>> -  Microsoft,
 >>>>
 >>>> -
 >>>>
 >>>>
 >>>> There are also some warning checks that should actually be
errors like
 >>>> underscores in CNs or SANs.
 >>>>
 >>>>
 >>>> Doug

-- 
Rob Stradling

Senior Research & Development Scientist
Email: r...@comodoca.com

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



--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

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

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:

Hi Adriano,

First, I didn't mean to call you out specifically, but you happened to be
first alphabetically, sorry.  I find this link very helpful to list all CAs
with errors or warnings: https://crt.sh/?cablint=1+week

Second, How do you define a "test CA"?  I thought that any CA that chains to
a public root was by definition not a test CA,


I agree with that.


and since the issued cert was
in CT logs, I assumed that your root was publicly trusted.  Maybe I'm
mistaken on one of these points


Actually, some non-publicly-trusted roots are accepted by some of the 
logs that crt.sh monitors.



Doug

-Original Message-
From: dev-security-policy  On
Behalf Of Adriano Santoni via dev-security-policy
Sent: Monday, October 1, 2018 9:49 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Increasing number of Errors found in crt.sh

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate in that
list, and it's a non-trusted certificate (it was issued by a test CA).


Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:

Is it possible to filter the list https://crt.sh/?cablint=issues
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that
corresponds to the issuing CA you're interested in.


Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and
asking
for misissuance reports for those that are not compliant? There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.


Doug


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

On 01/10/2018 14:48, Adriano Santoni via dev-security-policy wrote:

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate in 
that list, and it's a non-trusted certificate (it was issued by a test CA).


For certs issued (and logged) within the last 1 week, yes, that's correct.

The summary page only deals with the past 1 week.  However, once you 
click on a link to (for example) https://crt.sh/?caid=31477=cablint 
("Actalis Domain Validation Server CA G1"), there's an undocumented 
feature...


Add "minNotBefore=-MM-DD" to the URL to view linting info on older 
certs issued by that CA.

e.g., https://crt.sh/?caid=31477=cablint=2018-01-01

(This feature is undocumented because not all historical certs have been 
linted by crt.sh).



Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
Is it possible to filter the list https://crt.sh/?cablint=issues 
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that 
corresponds to the issuing CA you're interested in.



Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and 
asking

for misissuance reports for those that are not compliant? There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.


Doug


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
Is it possible to filter the list https://crt.sh/?cablint=issues based 
on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that 
corresponds to the issuing CA you're interested in.



Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and asking
for misissuance reports for those that are not compliant?  There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.


Doug


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services Root Inclusion Request

[Rob Stradling via dev-security-policy]

Richard,

You might like to familiarize yourself with the Mozilla Forum Etiquette 
Ground Rules:
https://www.mozilla.org/en-US/about/forums/etiquette/

Note this in particular:
"Be civil.
No personal attacks. Do not feel compelled to defend your honor in 
public. Posts containing personal attacks may be removed from the news 
server."

On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote:
> Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer 
> that gave too many pressures to the M.D.S.P community to misleading the 
> Community and to let Mozilla make the decision that Google want.
> 
> There are two facts to support my opinion:
> 
> (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that 
> if we separate StartCom completely from WoSign, then Mozilla don't sanction 
> StartCom that still trust StartCom root. But Google as peer of Mozilla Module 
> don't agree this, and Ryan even found many very very old problems of StartCom 
> to be a "fact" that must be distrusted. Google changed the Mozilla decision!
> 
> (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion 
> from Ryan Sleevi that Google changed the Mozilla initial decision, this also 
> is the fact.
> 
> So, we can see Ryan not just a Mozilla Module Peer, he represents Google 
> browser that affect Mozilla to make the right decision.
> 
> Ryan, don't feel too good about yourself. Peoples patiently look at your long 
> emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, 
> this is because you represent Google Chrome, and Google Chrome seriously 
> affects Mozilla that have the power to kill any CAs. If you leave Google, you 
> will be nothing, no one will care about your existence, and no one will care 
> what you say. So, please don't declare that you don't represent Google before 
> you speak next time, nonsense!
> 
> Your myopic has brought global Internet security to the ditch. Chrome display 
> "Secure" for a website just it has SSL(https). Many fake banking websites and 
> fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it 
> is "Secure", this completely misleads global Internet users, resulting in 
> many users are deceived and lost property. Encryption is not equal to secure. 
> Secure means not only encryption, but also need to tell user the website's 
> true identity. Does a fake bank website encryption mean anything? nothing and 
> more worse.
> 
> Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 
> ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！
> 
> 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets 
> Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。
> 
> 
> Best Regards,
> 
> Richard Wang
> 
>  Original Message 
> From: Ryan Sleevi via dev-security-policy
> Received: Thursday, 27 September 2018 00:53
> To: Jeremy Rowley
> Cc: Ryan Sleevi ; mozilla-dev-security-policy
> Subject: Re: Google Trust Services Root Inclusion Request
> 
> 
> On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley 
> wrote:
> 
>> I also should also emphasize that I’m speaking as Jeremy Rowley, not as
>> DigiCert.
>>
>>
>>
>> Note that I didn’t say Google controlled the policy. However, as a module
>> peer, Google does have significant influence over the policy and what CAs
>> are trusted by Mozilla. Although everyone can participate in Mozilla
>> discussions publicly, it’s a fallacy to state that a general participant
>> has similar sway or authority to a module peer. That’s the whole point of
>> having a separate class for peers compared to us general public.  With
>> Google acting as a CA and module peer, you now have one CA heavily
>> influencing who its competitors are, how its competitors operate, and what
>> its competitors can do.  Although I personally find that you never misuse
>> your power as a module peer, I can see how Jake has concerns that Google
>> (as a CA) has very heavy influence over the platform that has historically
>> been the CA watchdog (Mozilla).
>>
> 
> Jeremy, I think this again deserves calling out, because this is
> misrepresenting what module peership does, as well as the CA relationship.
> 
> I linked you to the definition of Module Ownership, which highlights and
> emphasizes that the module peer is simply a recognized helper. To the
> extent there is any influence, it is through the public discussions here.
> If your concern is that the title confers some special advantage, that's to
> misread what module peer is. If your concern is that the participation -
> which provides solid technical arguments as well as the policy alternatives
> - is influential, then what you're arguing against is public participation.
> 
> You're presenting these as factual, and that's misleading, so I'd like to
> highlight what is actually entailed.
> 
> 
>> The 

Re: Unrevoked/unexpired certificate with Debian Weak Key

[Rob Stradling via dev-security-policy]

On 17/06/18 21:09, Daniel Cater via dev-security-policy wrote:

On Monday, 14 May 2018 15:25:43 UTC+1, Rob Stradling

I'm currently running the check against all of the certs on the crt.sh
DB.  I'll report back once this has completed.


Hi Rob,

Did your checks find anything else in the end?


Hi Daniel.  Thanks for the reminder.  :-)

I found a total of 1,589 certs on the crt.sh DB with Debian weak keys, 
and I did intend to publish a report.  I figured that creating a new 
batch on misissued.com would be the best way to present the data, but 
that gives me an HTTP 500 response whenever I try to submit the list of 
crt.sh IDs.


Until misissued.com lets me submit the list, you can find the list of 
affected certs in a table on the crt.sh DB called "has_debian_weak_key".


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Re: Unrevoked/unexpired certificate with Debian Weak Key

[Rob Stradling via dev-security-policy]

On 14/05/18 11:39, Jakob Bohm via dev-security-policy wrote:

On 14/05/2018 10:42, Hanno Böck wrote:

Hi,

Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.

A few days ago I did a re-check of the CT logs for vulnerable keys.

I found one unexpired, unrevoked certificate issued by a CA called
"QuoVadis". I reported it and it's been revoked, they told me they'll
check their systems why this certificate issuance wasn't blocked.

https://crt.sh/?id=308235142

I also found an unrevoked Wosign cert that I had already reported last
year. The abuse contact of wosign bounces mails.

(My check was semi-thorough, I didn't have access to all the possible
key combinations that could be generated with the Debian bug. There may
be more certs in the logs.)



You could try the openssl-blacklist package distributed by Debian in
both source and prepackaged form.  If you use the packaged form, be sure
to include the openssl-blacklist-extra package which contains the lists
of RSA-4096 and RSA-512 keys.

Their included checking program (in the .diff file) is in Python.

URL: http://ftp.de.debian.org/debian/pool/main/o/openssl-blacklist/


Today I've added a Debian weak key check feature to crt.sh.  I augmented 
Debian's original blacklists with some other blacklists I generated 
~10yrs ago for a few less common key sizes [1].


I'm currently running the check against all of the certs on the crt.sh 
DB.  I'll report back once this has completed.



[1] https://secure.comodo.com/debian_weak_keys/


--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

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

Re: Mis-issuance of certificate with https in CN/SAN

[Rob Stradling via dev-security-policy]

On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote:

On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:


Please see https://crt.sh/?id=353098570=cablint



Note: This is the CT precertificate.

Note 2: According to crt.sh, the OCSP response for this precertificate
is not correct.  (error message: "OCSP response contains bad number of
certificates").


The crt.sh feature relies on Go's crypto/ocsp library, which currently 
"is just a bit limited and doesn't have support for more complex 
responses" [1].


The Go x/crypto/ocsp library was recently updated.  I've just deployed 
the update to crt.sh, and as a result https://crt.sh/ocsp-responders no 
longer shows any instances of the "bad number of certificates" error.


It's not "incorrect" for an OCSP response to contain superfluous CA 
certificates.  However, it is suboptimal (in terms of bytes on the wire).



[1] https://github.com/golang/go/issues/21527


--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

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

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

[Rob Stradling via dev-security-policy]

On 22/04/18 21:04, Eric Mill via dev-security-policy wrote:

On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


First of all, it's important to distinguish between the BR r
But even if you accept my premise there, then you have to ask "in what
timezone?"  March 1 00:00:00 2018 GMT in North America is February 28.  So
I could see someone making the argument that issuance at that moment in
time is fine if the CA is in North America but it's mis-issuance if the CA
is in Europe, since the requirements don't state that the measurement is
UTC.  This is why I'm not a fan of such precise enforcements of
date-related compliance.  There are a lot of different ways to interpret
dates/times, but none of the readings materially change the net effect of
the rule.  That is, all readings change the max validity period to ~825
days (which itself is subject to debate as to its precise meaning in terms
of seconds) within a day or two of each other.  So, enforcing the date as
Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value and leads to
confusion like this.


I'm just going to double down on Matt's comment that the problem here
doesn't seem to be in strictness of enforcement, but rather CAs leaving
themselves no buffer zone.


The problem here, IMHO, is that the BR requirement was poorly written.


Whatever business advantage there is of giving
customers that one last day to get 3-year certs, seems likely not as
valuable as the certainty of avoiding giving those customers errors when
the certs are used in major browsers.


The certainty?  Hindsight is a wonderful thing.  When I wrote Comodo 
CA's code to enforce the "after 1 March 2018" rule, this "certainty" did 
no occur to me.  I simply read the BR requirement and then implemented 
code to enforce it.



-- Eric




On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti
via dev-security-policy"  wrote:

 Hello,

 I'm investigating an issue on behalf of a customer. Our customer
requested a multi-year certificate that was issued on March 1st by Comodo.

 Here's the certificate:
 https://crt.sh?id=354042595

 Validity
 Not Before: Mar  1 00:00:00 2018 GMT
 Not After : May 29 23:59:59 2021 GMT

 The certificate is currently considered invalid at least by Google
Chrome.

 It's my understanding that Google Chrome uses a >= comparison, which
effectively means certificates issued on March 1st are already subject to
Ballot 193.

 However, it looks like the interpretation of Comodo of Ballot 193 here
is based on a > comparison, since the certificate was issued with a 3y
validity.

 BR 6.3.2 says:

 > Subscriber Certificates issued after 1 March 2018 MUST have a
Validity Period no greater than 825 days.
 > Subscriber Certificates issued after 1 July 2016 but prior to 1
March 2018 MUST have a Validity Period no greater than 39 months.

 I'd appreciate some hints about whether a certificate issued on March
1st should be considered subject to Ballot 193 or not.

 Best,
 -- Simone


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

[Rob Stradling via dev-security-policy]

On 20/04/18 14:30, Tim Shirley via dev-security-policy wrote:

First of all, it's important to distinguish between the BR requirement, which is defined in terms 
of certificate *issuance* dates, and the value in the "Not Before" field.  I'm guessing 
the "Not Before" value in this certificate is not the actual issuance timestamp, since 
it's unlikely it was issued right at the stroke of midnight.  The CA is probably rounding, but we 
don't know if they're rounding up or down.  But it would only be mis-issuance if the issuance 
occurred outside of the allowed time window.  There's nothing I can see to show when the 
certificate was actually issued; it first showed up in CT logs on March 13, so we know it was 
issued on or before that, but that's all we know for sure about the issuance time.

So what is the allowed time window according to the BRs?  I'd argue that the intent was that it be >=.  If 
you read the first bullet's "after" as >, then you have to also read the second bullet's 
"prior to" as <.  So what rule applies to certificates issued ON March 1, 2018?  Apparently none.  
Certainly that wasn't the intent, which is why I interpret the requirement as >=.


Indeed, I'm sure that wasn't the intent.  However, if the BRs don't say 
what the BRs intend to say, then the fault is with the BRs rather than 
with the CA that adheres to what the BRs actually say.  What the BRs 
actually say is what matters, because that's what auditors will audit 
against.


"after" is not the same thing as "on or after".  "on or after" is used 
elsewhere in the document to me >=, so TBH I think that reading "after" 
as > is the only correct interpretation.


BTW, over in linting-land, we've already had this same discussion...

https://github.com/awslabs/certlint/pull/58

https://github.com/zmap/zlint/pull/195


 That is, the dividing line is the moment in time when we moved from February 
into March, such that one rule or the other is always in effect.

But even if you accept my premise there, then you have to ask "in what 
timezone?"  March 1 00:00:00 2018 GMT in North America is February 28.  So I could 
see someone making the argument that issuance at that moment in time is fine if the CA is 
in North America but it's mis-issuance if the CA is in Europe, since the requirements 
don't state that the measurement is UTC.  This is why I'm not a fan of such precise 
enforcements of date-related compliance.  There are a lot of different ways to interpret 
dates/times, but none of the readings materially change the net effect of the rule.  That 
is, all readings change the max validity period to ~825 days (which itself is subject to 
debate as to its precise meaning in terms of seconds) within a day or two of each other.  
So, enforcing the date as Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value 
and leads to confusion like this.

On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti via 
dev-security-policy" 
 wrote:

 Hello,
 
 I'm investigating an issue on behalf of a customer. Our customer requested a multi-year certificate that was issued on March 1st by Comodo.
 
 Here's the certificate:

 https://crt.sh?id=354042595
 
 Validity

 Not Before: Mar  1 00:00:00 2018 GMT
 Not After : May 29 23:59:59 2021 GMT
 
 The certificate is currently considered invalid at least by Google Chrome.
 
 It's my understanding that Google Chrome uses a >= comparison, which effectively means certificates issued on March 1st are already subject to Ballot 193.
 
 However, it looks like the interpretation of Comodo of Ballot 193 here is based on a > comparison, since the certificate was issued with a 3y validity.
 
 BR 6.3.2 says:
 
 > Subscriber Certificates issued after 1 March 2018 MUST have a Validity Period no greater than 825 days.

 > Subscriber Certificates issued after 1 July 2016 but prior to 1 March 
2018 MUST have a Validity Period no greater than 39 months.
 
 I'd appreciate some hints about whether a certificate issued on March 1st should be considered subject to Ballot 193 or not.
 
 Best,

 -- Simone
 ___
 dev-security-policy mailing list
 dev-security-policy@lists.mozilla.org
 
https://scanmail.trustwave.com/?c=4062=p8zZ2rF2lZEEgQKoVUUviom_gMvUa93578dYFlK0UQ=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
 


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



--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it 

Re: Mis-issuance of certificate with https in CN/SAN

[Rob Stradling via dev-security-policy]

On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:


Please see https://crt.sh/?id=353098570=cablint



Note: This is the CT precertificate.

Note 2: According to crt.sh, the OCSP response for this precertificate
is not correct.  (error message: "OCSP response contains bad number of
certificates").


The crt.sh feature relies on Go's crypto/ocsp library, which currently 
"is just a bit limited and doesn't have support for more complex 
responses" [1].


It's not "incorrect" for an OCSP response to contain superfluous CA 
certificates.  However, it is suboptimal (in terms of bytes on the wire).



[1] https://github.com/golang/go/issues/21527

--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

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

Re: Trustico code injection

[Rob Stradling via dev-security-policy]

We also asked Trustico to cease offering any tools to generate and/or 
retain customer private keys.  They have complied with this request and 
have confirmed that they do not intend to offer any such tools again in 
the future.


Trustico have also confirmed to us that they were not, and are not, in 
possession of the private keys that correspond to any of the 
certificates that they have requested for their customers through Comodo CA.


On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:

Comodo CA has investigated the reports posted to this list relating to the
suspected compromise of the private key corresponding to
https://crt.sh/?id=206535041.  Trustico have assured us that the private key
could not have been compromised.  However, since it will be hard to convince
everyone that this is the case, Trustico have agreed to obtain a replacement
certificate with a new keypair.  Once that new certificate has been
installed, Comodo CA will revoke https://crt.sh/?id=206535041.

Regards,
Rich Smith
Sr. Compliance Manager
Comodo CA

--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

[Rob Stradling via dev-security-policy]

On 01/03/18 10:51, Ben Laurie via dev-security-policy wrote:

On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Wed, 28 Feb 2018 20:03:51 +
Jeremy Rowley via dev-security-policy
 wrote:


The keys were emailed to me. I'm trying to get a project together
where we self-sign a cert with each of the keys and publish them.
That way there's evidence to the community of the compromise without
simply listing 23k private keys. Someone on Reddit suggested that,
which I really appreciated.


That's probably me (tialaramex).

Anyway, if it is me you're referring to, I suggested using the private
keys to issue a bogus CSR. CSRs are signed, proving that whoever made
them had the corresponding private key but they avoid the confusion
that comes from DigiCert (or its employees) issuing bogus certs.
Everybody reading m.d.s.policy can still see that a self-signed cert is
harmless and not an attack, but it may be harder to explain in a
soundbite. Maybe more technically able contributors disagree ?



Seems to me that signing something that has nothing to do with certs is a
safer option - e.g. sign random string+Subject DN.


And also throw in some transparency...

https://mailarchive.ietf.org/arch/msg/trans/WLFmIyaH4BJo77ZJDinKJcylOcg

--
Rob Stradling
Senior Research & Development Scientist
Email: rob.stradl...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

[Rob Stradling via dev-security-policy]

On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:

On 08/02/18 13:47, Hanno Böck wrote:

Is a revoked intermediate cert a license for operating a yolo CA that
signs everything? Given the fragility of revocation checking I'd find
that a problematic precedent.


In this case, the certificates are revoked in Firefox via OneCRL and
Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
noticed.


The OCSP seems operational and replies with "Good" and the issuance
happened before it's being added to OneCRL.


If the cert itself has not been revoked by its issuer, "Good" is an
entirely reasonably response...


I don't find a reference why this intermediate had been added to
OneCRL, but I think this deserves more clarification what's going on
here.


OneCRL additions normally have an associated bug but I can't see one for
this...


https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed) 
suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467.


--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Rob Stradling via dev-security-policy]

On 23/01/18 22:55, Jonathan Rudenberg via dev-security-policy wrote:


https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date

This incident makes me think that two changes should be made:

1) The Root Store Policy should explicitly ban forward and back-dating the 
notBefore date.


I think it would be reasonable and sensible to permit back-dating 
insofar as it is deemed necessary to accommodate client-side clock-skew.



2) Firefox should implement a technical check to enforce the validity period so 
that issuance practices like this do not impact users (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Jonathan


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

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

Re: Camerfirma's misissued certificate

[Rob Stradling via dev-security-policy]

Hi Juan.  Is there a particular technical reason why you feel the need 
to include "all the certs chaining up to the roots" in your OCSP responses?


When an OCSP response is signed directly by the CA that issued the 
corresponding certificate, the OCSP response does not need to contain 
any certificates at all.


When a CA uses an Authorized Responder, the OCSP response needs to 
contain 1 certificate (i.e., the leaf cert, issued directly by the CA, 
that contains the id-kp-ocspSigning EKU OID).


I don't see any circumstance in which including >1 certificate in an 
OCSP response provides any benefit.  All it does is bloat the OCSP 
response unnecessarily.


The TLS client's certificate path validation algorithm validates the 
issuing CA.  Therefore, the OCSP response validation algorithm only 
needs to validate the OCSP response up to that issuing CA, not all the 
way up to the root.


On 18/01/18 07:34, Juan Angel Martin (AC Camerfirma) via 
dev-security-policy wrote:

Hello Wayne,

  


I’ve investigated the OCSP’s issue time ago, I can tell you that it’s related 
with https://github.com/golang/go/issues/21527 cause we send all the certs 
chaining up to the roots.

  


BR

Juan Angel

  


De: Wayne Thayer [mailto:wtha...@mozilla.com]
Enviado el: miércoles, 17 de enero de 2018 19:14
Para: martin...@camerfirma.com
CC: mozilla-dev-security-policy 
Asunto: Re: Camerfirma's misissued certificate

  


Thank you for reporting this misissuance. Since this is a different issue than 
described in bug 1390977, I have created a new bug to track this problem and 
your response: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 Please also 
post your incident report here.

  


Also, the crt.sh link above is reporting the following OCSP error for this certificate: 
"OCSP response contains bad number of certificates" Please investigate.

  


- Wayne

  

  


On Wed, Jan 17, 2018 at 9:27 AM, Juan Angel Martin via dev-security-policy 
 > wrote:

Hello,

I have to inform you about a SSL certificate misissued. OU contains 
non-printable control characters.

https://crt.sh/?id=305441195

It has already been revoked.

Regards

Juan Angel Martin Gomez
AC Camerfirma
___
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



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

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

Re: Add Wayne Thayer as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

[Rob Stradling via dev-security-policy]

+1

ISTM that Wayne is already doing an excellent job!

On 16/01/18 22:03, Kathleen Wilson via dev-security-policy wrote:

All,

I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates 
Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I 
are distributing the job of running Mozilla's CA Program between us, so 
he will be actively working on both of these Modules.


Thanks,
Kathleen

[1] https://wiki.mozilla.org/Modules
[2] https://wiki.mozilla.org/Modules/All#CA_Certificates
[3] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB disclosure of id-kp-emailProtection intermediates

[Rob Stradling via dev-security-policy]

On 17/01/18 09:21, Ryan Sleevi via dev-security-policy wrote:

Specifically,
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7


Ben, Ryan,

Hmm, you're right.  (I must've skipped over that disclosure deadline 
change because I'd already disclosed Comodo's id-kp-emailProtection 
intermediates to the CCADB well ahead of the original deadline).  The 
November 2017 CA Communication does indeed say 15th April 2018, and, in 
fact, so does the latest draft of the Mozilla Root Store Policy [1].


However, the Stable version of the Mozilla Root Store Policy [2] still 
says 15th January 2018.


Surely the Stable version of the Policy is in force and the Draft 
version is not yet in force?


Perhaps Mozilla could consider publishing a v2.5.1 of the Policy that 
(compared to v2.5) simply updates this disclosure deadline?



[1] https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md

[2] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/



On Tue, Jan 16, 2018 at 6:06 PM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


What about the Mozilla CA communication that said that CAs had until 15
April 2018?

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Tuesday, January 16, 2018 2:29 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: CCADB disclosure of id-kp-emailProtection intermediates

[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents
Mozilla's policy and/or current expectations.  Thanks!]

Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the
non-disclosure (and, IINM, non-audit) of certain
non-technically-constrained
id-kp-emailProtection intermediate certificates...until yesterday:
"Instead of complying with the above paragraph, intermediate certificates
issued before 22nd June 2017 may, until 15th January 2018..."

According to [2], there are currently 223 non-technically-constrained
intermediate certificates known to crt.sh that chain to an NSS built-in
root
(that has the Email trust bit set) and are capable of issuing
id-kp-emailProtection certificates but not id-kp-serverAuthentication
certificates.

IIUC, the Mozilla policy now requires these intermediate certificates to
have already been disclosed to the CCADB and to be audited.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy