SHA-1 serverAuth cert issued by Trustis in November 2016

[Rob Stradling via dev-security-policy]

This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth 
EKU and CN=hmrcset.trustis.com:

https://crt.sh/?id=50773741=cablint

It lacks the SAN extension, but that doesn't excuse it from the ban on 
SHA-1!


Its issuer is trusted for serverAuth by Mozilla:
https://crt.sh/?caid=920=mozilladisclosure

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

SHA-1 serverAuth cert issued by HydrantID (QuoVadis) in January 2017

[Rob Stradling via dev-security-policy]

This currently unrevoked cert has the serverAuth EKU and 
dNSName=qvsslrca3-v.quovadisglobal.com:

https://crt.sh/?id=83114602

Its issuer is trusted for serverAuth by Mozilla:
https://crt.sh/?caid=1333

--
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: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:

On 27/03/17 23:12, Andrew Ayer wrote:

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

I think this is bad.


Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?


Increased attack surface.  An undisclosed dormant sub-CA most likely has 
its private key in an online HSM, and so I think it's prudent to assume 
that it's more vulnerable (to being compromised by an attacker, or to 
being accidentally used to misissue a cert) than an offline root key.


IINM, the purpose (so far) of Mozilla's intermediate cert disclosure 
policy is to map the attack surface.  Right?


--
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: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 28/03/17 13:32, Jakob Bohm via dev-security-policy wrote:


On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:



Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?



Actually, I think it is about ensuring that there are no non-compliant
issuers of Mozilla-trusted certificates, that might be issuing
improperly validated certificates.


We're talking about the policy's requirement for disclosing "dormant" 
sub-CAs, not sub-CAs "that might be issuing".


By the time a sub-CA issues its first cert, that sub-CA MUST have 
already been disclosed.  The policy is already clear on this point.


--
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: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 30/03/17 13:11, Gervase Markham via dev-security-policy wrote:

On 28/03/17 12:21, Rob Stradling wrote:

Increased attack surface.  An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being compromised by an attacker, or to
being accidentally used to misissue a cert) than an offline root key.


If it's dormant, there's no particular reason the HSM will be online.
But it might be, and it doesn't make much sense to make a distinction in
the policy.


IINM, the purpose (so far) of Mozilla's intermediate cert disclosure
policy is to map the attack surface.  Right?


That's certainly one goal :-)

Does a week sound about right?


SGTM.

Presumably that week begins at either 1) the moment the intermediate is 
issued or 2) the moment the CA is first granted access to the CCADB, 
whichever is the latter?


--
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: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Rob Stradling via dev-security-policy]

On 12/04/17 10:47, Gervase Markham via dev-security-policy wrote:

Section 5.3.1 of policy 2.4.1 defines what it means to be technically
constrained for email sub-CAs (those with id-kp-emailProtection). It says:

"If the certificate includes the id-kp-emailProtection extended key
usage, then all end-entity certificates MUST only include e-mail
addresses or mailboxes that the issuing CA has confirmed (via technical
and/or business controls) that the subordinate CA is authorized to use."

This is bogus.



Gerv, FYI what you're proposing here 
(https://github.com/mozilla/pkipolicy/issues/69) was slated to appear in 
v2.1 of the policy, but it was vetoed by Symantec.


Here's why...

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/l1BAEHjKe8Q/mey4WREKpooJ 



--
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: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 04/04/17 12:17, Gervase Markham via dev-security-policy wrote:

On 27/03/17 22:12, Andrew Ayer wrote:

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


This has now been added to the policy 2.5 draft with a one-week deadline.

Gerv


Gerv,
Mozilla also requires CAs to disclose intermediate cert revocations to 
CCADB.  Should there be a corresponding time limit in the policy 
regarding how soon after revocation this disclosure must occur?


https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2 
GlobalSign EV intermediates that were revoked by Google Trust Services 5 
days ago, but which are still unrevoked according to CCADB.  By when 
must GTS notify CCADB of these 2 revocations?


--
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: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 13/04/17 14:50, Gervase Markham wrote:

On 12/04/17 21:21, Rob Stradling wrote:

Mozilla also requires CAs to disclose intermediate cert revocations to
CCADB.  Should there be a corresponding time limit in the policy
regarding how soon after revocation this disclosure must occur?


There is:

"If a non-exempt intermediate certificate is revoked, the CCADB must be
updated to mark it as revoked, giving the reason why, within 24 hours
for a security incident, and within 7 days for any other reason."
https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md


Ah, thanks Gerv.  I hadn't looked in that doc.


https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2
GlobalSign EV intermediates that were revoked by Google Trust Services 5
days ago, but which are still unrevoked according to CCADB.  By when
must GTS notify CCADB of these 2 revocations?


Assuming they weren't revoked because of a security incident, some time
in the next two days :-)

Gerv


--
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: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Rob Stradling via dev-security-policy]

Thanks Gerv.  :-)

On 13/04/17 14:46, Gervase Markham via dev-security-policy wrote:

Hi Rob,

You either have a great memory or good search-fu; well done for digging
this out!

On 12/04/17 22:14, Rob Stradling wrote:

Gerv, FYI what you're proposing here
(https://github.com/mozilla/pkipolicy/issues/69) was slated to appear in
v2.1 of the policy, but it was vetoed by Symantec.

Here's why...

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/l1BAEHjKe8Q/mey4WREKpooJ


Hmm. I note we didn't end up using Symantec's proposed text either.

I'm not sure I entirely understand their objection. They wanted to
confirm via "business controls" that the customer was authorized to
issue email certs for the domain. What sort of thing might that be, and
how is it different to a technical control? Does it just involve the
customer pinky-swearing that it's OK for them to issue such certs?

I can see that CAs might want to issue email certs for almost any
domain, if the controller of an email address comes and asks for one.
But in that sort of case, I wouldn't expect them to be using a TCSC.
TCSCs are for "Hi, I'm Company X, and have 100,000 employees with
@companyx.com email addresses, and want to issue them publicly-trusted
email certs. Give me a TCSC for @companyx.com." Whereupon the CA would
get them to prove they own that domain, then provide them with such a
certificate.

Gerv


--
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: Email sub-CAs

[Rob Stradling via dev-security-policy]

On 15/04/17 17:05, Peter Bowen via dev-security-policy wrote:

On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via
dev-security-policy  wrote:

On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote:

On 13/04/17 14:23, Doug Beattie wrote:

There is no statement back to scope or corresponding audits.  Were
secure email capable CAs supposed to be disclosed and audited to
Mozilla under 2.3?


If they did not include id-kp-serverAuth, I would not have faulted a CA
for not disclosing them if they met the exclusion criteria for email
certs as written.


OK.


and how it applies to Secure email, I don't see how TCSCs with secure
email EKU fall within the scope of the Mozilla Policy 2.3.  Can you
help clarify?


I think this is basically issue #69.
https://github.com/mozilla/pkipolicy/issues/69


OK, I look forward to a conclusion on that.  I hope that name constraining a 
secure email CA (either technically in the CA certificate or via business 
controls) is sufficient to avoid WebTrust Audits.  If Public disclosure helps 
get us there then that would be acceptable.


Should the Mozilla policy change to require disclosure of all CA
certificates issued by an unconstrained CA (but not necessarily
require audits, CP/CPS, etc)? This would help identify unintentional
gaps in policy.


+1

--
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: Bad characters in dNSNames

[Rob Stradling via dev-security-policy]

On 15/08/17 13:29, Gervase Markham via dev-security-policy wrote:

Hi Rob,

On 26/07/17 11:21, Rob Stradling wrote:

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


Thanks for this. Any chance of saving me a bit of time by
cross-referencing each line with the "CA owner" from the CCADB? If
that's too much work, no problem, let me know and I can do it myself by
hand.


Hi Gerv.  I've just added the "CA Owner" field to both tabs on this 
spreadsheet.  See also https://misissued.com/batch/3/, which reports on 
the same set of certificates.


BTW, I've just asked Alex to look at adding the "CA Owner" field to the 
misissued.com reports.  :-)


--
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: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

[Rob Stradling via dev-security-policy]

On 11/08/17 16:40, Nick Lamb via dev-security-policy wrote:

On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor  wrote:

Given that these were all caught by cablint, has Let's Encrypt considered
integrating it into your issuance pipeline, or automatically monitoring
crt.sh (which runs cablint) for these issues so they don't need to be
caught manually by researchers?


The former has the risk of being unexpectedly fragile, the latter puts a bunch 
of work on crt.sh which (even if Rob says it's OK) is a bit out of order.

I would suggest that Let's Encrypt could automatically run cablint on some fraction of 
just issued certificates (where "some fraction" might be 100% if they've got 
the resources) and summarise the output for internal review. They're obliged to keep all 
the certificates they've just issued online by their own system design (ACME offers to 
deliver the certificate again if you ask for it) anyway.

This way: If cablint breaks, or won't complete in a timely fashion during high 
volume issuance, it doesn't break the CA itself. But on the other hand it also 
doesn't wail on Comodo's generously offered public service crt.sh.

Also, while on the subject I commend to any researchers at least as interested 
in the contents of the CT logs as myself the building of an actual Log Monitor 
of their own rather than relying on crt.sh. This is for several reasons, off 
the top of my head:

1. The Logs have anti-tamper features, but if only Comodo (and Google) look at 
the Logs themselves then we miss out on much real benefit from those features 
because we will never actually detect any tampering, we'd have to be told about 
it by someone we trust.


+1.  I trust me, but it bothers me that everyone else has to trust me 
too.  :-)


Also, crt.sh doesn't yet verify the Merkle Tree stuff when fetching 
entries from the logs.



2. The Logs are obliged to achieve reasonable performance to hit Google's 
targets and will accordingly have been built to be robust, Rob has put lots of 
effort into crt.sh but it definitely has... off days.


Such as today, during which Comodo has been the target of a DoS attack 
that's affected many of our services (including crt.sh and our CT logs 
:-( ).


--
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: Bad characters in dNSNames

[Rob Stradling via dev-security-policy]

On 16/08/17 22:57, alex.gaynor--- via dev-security-policy wrote:

On Wednesday, August 16, 2017 at 11:22:01 AM UTC-4, Rob Stradling wrote:

BTW, I've just asked Alex to look at adding the "CA Owner" field to the
misissued.com reports.  :-)


It does this now :-)


Excellent.  Thanks Alex.  :-)

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

Disclosing unconstrained emailProtection intermediates to CCADB

[Rob Stradling via dev-security-policy]

CAs,

Version 2.5 of the Mozilla Root Store Policy classifies 
EKU=emailProtection intermediates as unconstrained when suitable name 
constraints aren't present.  As a result, such intermediates need to be 
disclosed to the CCADB (although not until 15th January 2018 for those 
intermediates issued before 22nd June 2017).


I've updated https://crt.sh/mozilla-disclosures to implement the new 
disclosure rules.



P.S. Note that the CCADB's definition of technically constrained hasn't 
yet been similarly updated, so you may still see this warning:
"This certificate is considered to be technically-constrained as per 
Mozilla policy, so it does not need to be added to the CA Community in 
Salesforce. All data that you enter into Salesforce will be publicly 
available, so please make sure you do not enter sensitive information 
that should not be published."


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

Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

[Rob Stradling via dev-security-policy]

On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:

This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which 
chains up to a Baltimore CyberTrust root, contains an invalid dnsName of 
“www.intesasanpaolovita..biz” (note the two dots):

https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint

This raises some questions about the technical controls in place for issuance 
from this CA.


Yesterday evening Jonathan privately made me aware of a leaf certificate 
(https://crt.sh/?id=73190674) with two SAN:dNSNames that contain 
consecutive dots, which was issued by a Comodo intermediate.  He found 
this cert using the crt.sh DB's lint records.


This morning Robin and I have investigated this bug in our code and 
we've taken the following actions:
  - We've deployed a hotfix to our CA system to prevent any further 
"double dot" mis-issuances.
  - We've confirmed that the bug only affected labels to the left of 
the registrable domain.  (e.g., dNSNames of the form www..domain.com 
were not always rejected, but those of the form www.domain..com were 
always rejected).
  - We've performed an exhaustive search of our certificate database 
and found 2 further unexpired leaf certificates that exhibit this 
"double dot" problem.  I've submitted both of them to some CT logs:

https://crt.sh/?id=174668364
https://crt.sh/?id=174668366

We will revoke all 3 of these leaf certificates ASAP.

--
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: Certificates with invalid "double dot" dnsNames issued from Comodo intermediates

[Rob Stradling via dev-security-policy]

On 18/07/17 15:31, Jakob Bohm via dev-security-policy wrote:

On 18/07/2017 16:19, Rob Stradling wrote:

On 17/07/17 16:14, Jonathan Rudenberg via dev-security-policy wrote:
This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni 
Enhanced” which chains up to a Baltimore CyberTrust root, contains an 
invalid dnsName of “www.intesasanpaolovita..biz” (note the two dots):


https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint 



This raises some questions about the technical controls in place for 
issuance from this CA.


Yesterday evening Jonathan privately made me aware of a leaf 
certificate (https://crt.sh/?id=73190674) with two SAN:dNSNames that 
contain consecutive dots, which was issued by a Comodo intermediate.  
He found this cert using the crt.sh DB's lint records.


This morning Robin and I have investigated this bug in our code and 
we've taken the following actions:
   - We've deployed a hotfix to our CA system to prevent any further 
"double dot" mis-issuances.


   - We've confirmed that the bug only affected labels to the left of 
the registrable domain.  (e.g., dNSNames of the form www..domain.com 
were not always rejected, but those of the form www.domain..com were 
always rejected).


This doesn't match the one reported by Ben Wilson, which also exhibits 
various Microsoft related oddities:


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


Hi Jakob.  Why would you expect it to?

Jonathan found certs containing "double dots" in dNSNames in leaf certs 
that chain to both DigiCert roots and Comodo roots.


Note that DigiCert != Comodo.

--
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: How long to resolve unaudited unconstrained intermediates?

[Rob Stradling via dev-security-policy]

On 20/07/17 15:24, Gervase Markham via dev-security-policy wrote:

On 12/07/17 21:18, Ben Wilson wrote:

For CAs with emailProtection and proper name constraints, where would such CAs 
appear in https://crt.sh/mozilla-disclosures?  
https://crt.sh/mozilla-disclosures#constrainedother?  Or a new section of the 
list, yet to be determined?


I believe Rob has now split the list into two.


Ben, these intermediate certs should appear in 
https://crt.sh/mozilla-disclosures#constrained (if they've not been 
disclosed to CCADB).


https://crt.sh/mozilla-disclosures#constrainedother is for intermediate 
certs for which there is a signature chain up to a root that is trusted 
by Mozilla, but which are trusted for neither Server Authentication nor 
Secure Email.  (Mostly they're Code Signing intermediates, it seems).



And for CAs where EKU contains emailProtection, what are the programmatic 
criteria that determine whether the CA will be in such list as properly name 
constrained, since the Baseline Requirements don’t cover email certificates?  
(Presumably, a properly name-constrained email CA would not require any audit.)


Rob would be able to say. But the criteria for whether an email
intermediate is properly name constrained are in Mozilla policy 2.5.


The purpose of the https://crt.sh/mozilla-disclosures page is to track 
compliance with the Mozilla Root Store Policy.  BRs, or the lack of 
them, are only relevant to this page insofar as the Mozilla Root Store 
Policy says they're relevant.


So yes, this page uses the criteria from Mozilla Root Store Policy v2.5.

--
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: Bad characters in dNSNames

[Rob Stradling via dev-security-policy]

On 26/07/17 11:44, Kurt Roeckx via dev-security-policy wrote:

On 2017-07-26 12:21, Rob Stradling wrote:
At Jonathan's suggestion, I've used the crt.sh DB to produce this 
report of certs that have SAN:dNSName(s) that contain non-permitted 
characters:


The report says "CN or dNSName". It's my understanding that in the CN 
you can have international characters but that in the SAN you can't. Can 
you clarify that it's really only the SAN that you checked?


It's really only the SAN I checked.  I've updated that heading in the 
report.


Thanks.

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

Bad characters in dNSNames

[Rob Stradling via dev-security-policy]

At Jonathan's suggestion, I've used the crt.sh DB to produce this report 
of certs that have SAN:dNSName(s) that contain non-permitted characters:


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

I've only looked at certs for which there's a chain up to a root trusted 
by Mozilla, and I've only looked at certs with notBefore dates after 1st 
November 2015 (so there's no chance that any of these are "legitimate" 
internal server names, per the BRs).


The characters I've treated as permitted are:
A-Z
a-z
0-9
-_.*

So that Symantec's "redacted" precertificates didn't make up 99%+ of the 
report, I've also permitted dNSNames to begin with 0 or more instances 
of "?.".


--
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Rob Stradling via dev-security-policy]

On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:


(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)


Here's a report of all "double dot" certs known to crt.sh that are 
useable for server authentication and chain to a root trusted by Mozilla:


https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhNQVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to 
produce this report:


SELECT c.ID, x509_notBefore(c.CERTIFICATE), 
x509_notAfter(c.CERTIFICATE), array_to_string(array_agg(DISTINCT 
ci.NAME_VALUE), CHR(10)), ca.NAME

  FROM certificate_identity ci, ca, certificate c
  WHERE ci.NAME_VALUE LIKE '%..%'
AND ci.NAME_TYPE IN ('dNSName', 'commonName')
AND ci.ISSUER_CA_ID = ca.ID
AND ci.CERTIFICATE_ID = c.ID
AND EXISTS (
  SELECT 1
FROM ca_trust_purpose ctp
WHERE ci.ISSUER_CA_ID = ctp.CA_ID
  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
)
AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE), 
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME

  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;

--
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Rob Stradling via dev-security-policy]

On 19/07/17 15:31, Jeremy Rowley via dev-security-policy wrote:

You should also filter out expired certs as they aren't usable.


I've added a 2nd tab that just shows unexpired certs.  I'll also add a 
column to track the revocation status of each of these certs.


I've left the expired certs in the 1st tab, since they show historical 
issuance problems.  Perhaps some of those CAs still have code bugs that 
need to be fixed.



On Jul 19, 2017, at 8:30 AM, Alex Gaynor via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:



(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



Here's a report of all "double dot" certs known to crt.sh that are useable
for server authentication and chain to a root trusted by Mozilla:

https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to
produce this report:

SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
  FROM certificate_identity ci, ca, certificate c
  WHERE ci.NAME_VALUE LIKE '%..%'
AND ci.NAME_TYPE IN ('dNSName', 'commonName')
AND ci.ISSUER_CA_ID = ca.ID
AND ci.CERTIFICATE_ID = c.ID
AND EXISTS (
  SELECT 1
FROM ca_trust_purpose ctp
WHERE ci.ISSUER_CA_ID = ctp.CA_ID
  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
)
AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;


--
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Rob Stradling via dev-security-policy]

Hi Alex.  This is about issuance (mal)practices, so therefore I didn't 
omit certs that are already revoked.


On 19/07/17 15:29, Alex Gaynor via dev-security-policy wrote:

I think there might be a bug in your SQL, one of the offending certs is
issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.

Alex

On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:



(Due to limitations in the search methodology - scraping crt.sh
search results and looping through tlds - I only searched for ..tld. It
would certainly be valuable to search further.)



Here's a report of all "double dot" certs known to crt.sh that are useable
for server authentication and chain to a root trusted by Mozilla:

https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing


P.S.
For anyone interested, here's the SQL I executed on the crt.sh DB to
produce this report:

SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
   FROM certificate_identity ci, ca, certificate c
   WHERE ci.NAME_VALUE LIKE '%..%'
 AND ci.NAME_TYPE IN ('dNSName', 'commonName')
 AND ci.ISSUER_CA_ID = ca.ID
 AND ci.CERTIFICATE_ID = c.ID
 AND EXISTS (
   SELECT 1
 FROM ca_trust_purpose ctp
 WHERE ci.ISSUER_CA_ID = ctp.CA_ID
   AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
   AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
 )
 AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
   GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
   ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;

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


--
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: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Rob Stradling via dev-security-policy]

Hi Jeremy.  I'm not aware of any formal definition in any RFC of the 
phrase "transitively chains".


My recollection (and Hanno's [1]) is that this terminology dates back to 
the 2010 write-up of the EFF SSL Observatory [2], in which the word 
"transvalid" was coined.



[1] 
https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html


[2] 
https://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse-a-safe-place.pdf

Slide 29

On 03/07/17 21:59, Jeremy Rowley wrote:

Link please to a formal definition? As your email alleges a policy violation by 
one a cross-signed CAs, we take the investigation and response very seriously. 
I'd like to know the basis for the definition before formulating an official 
report and potentially penalizing the Sub CA for non-compliance.

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com]
Sent: Monday, July 3, 2017 2:14 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of 
https://crt.sh/?id=160110886

On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote:

I am surprised you decided to fork the thread from here 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM 
where this was already being discussed. Seems unnecessary.


Hi Jeremy.  That thread discusses a collection of intermediate certs that Tavis 
Ormandy found (when "crawling the pkcs7 blobs in public pdf
files") that were not at the time known to any CT logs.  Most of those 
intermediates did not need to be disclosed to Mozilla.

https://crt.sh/?id=160110886 was not in Tavis's collection and has not AFAICT 
been previously discussed on this list.


I don't agree this is a policy violation, and I doubt any CA not involved in 
the previously mentioned thread would even register that Mozilla may be 
requiring disclosure of self-signed CAs.


See this post (from another recent thread) in which Ryan Sleevi explained why 
it makes sense to require disclosure of self-signed CA certs (for which the 
subject public key also exists in one or more trusted cross-certificates):
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg07049.html


The only disclosure requirement this root may fall under is the weird 
"transitive" trust phrase in the policy. Note, this phrase is not defined in 
5280 or the Mozilla policy. Can you please link me to the definition in an RFC? If there 
isn't one, until Mozilla clarifies what this means, the definition of transitive trust is 
vague, meaning any third interpretation is as good as the one you propose.


I think the meaning of "transitive" trust is actually quite simple.

A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a root (R) if it is 
issued by an intermediate CA whose cert (IC2) chains to R.  The trust for L / IC1 is 
"transitive" because a relying party will only be able to verify that trust under certain 
circumstances - i.e., the RP needs to have been made aware of, and received a copy of, the IC2 cert.

If IC1 is issued directly by R, trust is "direct".  The RP is able to verify 
that trust under all circumstances, because R is built into the application / shipped 
with the trust store that the RP is using.


Regardless, we will log the cert in the database pending resolution of the 
dispute on what this means in the Mozilla policy to avoid the debate over this 
particular root.

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
<dev-security-policy@lists.mozilla.org>
Subject: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

https://crt.sh/mozilla-disclosures#undisclosed has listed
https://crt.sh/?id=160110886 for over 1 week.

This is a violation of section 5.3.2 of the Mozilla Root Store Policy
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new certificates, that are 
not technically constrained, and that directly or transitively chain to a certificate 
included in Mozilla’s root program MUST be audited in accordance with Mozilla’s Root 
Store Policy and 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."

It's a self-signed root certificate, but nonetheless there exists a signature 
chain up to an included root and so disclosure is required.


[1]
https://w

Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Rob Stradling via dev-security-policy]

On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote:

I am surprised you decided to fork the thread from here 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM 
where this was already being discussed. Seems unnecessary.


Hi Jeremy.  That thread discusses a collection of intermediate certs 
that Tavis Ormandy found (when "crawling the pkcs7 blobs in public pdf 
files") that were not at the time known to any CT logs.  Most of those 
intermediates did not need to be disclosed to Mozilla.


https://crt.sh/?id=160110886 was not in Tavis's collection and has not 
AFAICT been previously discussed on this list.



I don't agree this is a policy violation, and I doubt any CA not involved in 
the previously mentioned thread would even register that Mozilla may be 
requiring disclosure of self-signed CAs.


See this post (from another recent thread) in which Ryan Sleevi 
explained why it makes sense to require disclosure of self-signed CA 
certs (for which the subject public key also exists in one or more 
trusted cross-certificates):

https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg07049.html


The only disclosure requirement this root may fall under is the weird 
"transitive" trust phrase in the policy. Note, this phrase is not defined in 
5280 or the Mozilla policy. Can you please link me to the definition in an RFC? If there 
isn't one, until Mozilla clarifies what this means, the definition of transitive trust is 
vague, meaning any third interpretation is as good as the one you propose.


I think the meaning of "transitive" trust is actually quite simple.

A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a 
root (R) if it is issued by an intermediate CA whose cert (IC2) chains 
to R.  The trust for L / IC1 is "transitive" because a relying party 
will only be able to verify that trust under certain circumstances - 
i.e., the RP needs to have been made aware of, and received a copy of, 
the IC2 cert.


If IC1 is issued directly by R, trust is "direct".  The RP is able to 
verify that trust under all circumstances, because R is built into the 
application / shipped with the trust store that the RP is using.



Regardless, we will log the cert in the database pending resolution of the 
dispute on what this means in the Mozilla policy to avoid the debate over this 
particular root.

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<dev-security-policy@lists.mozilla.org>
Subject: DigiCert policy violation - non-disclosure of 
https://crt.sh/?id=160110886

https://crt.sh/mozilla-disclosures#undisclosed has listed
https://crt.sh/?id=160110886 for over 1 week.

This is a violation of section 5.3.2 of the Mozilla Root Store Policy
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new certificates, that are 
not technically constrained, and that directly or transitively chain to a certificate 
included in Mozilla’s root program MUST be audited in accordance with Mozilla’s Root 
Store Policy and 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."

It's a self-signed root certificate, but nonetheless there exists a signature 
chain up to an included root and so disclosure is required.


[1]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/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.

_

DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Rob Stradling via dev-security-policy]

https://crt.sh/mozilla-disclosures#undisclosed has listed 
https://crt.sh/?id=160110886 for over 1 week.


This is a violation of section 5.3.2 of the Mozilla Root Store Policy 
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new 
certificates, that are not technically constrained, and that directly or 
transitively chain to a certificate included in Mozilla’s root program 
MUST be audited in accordance with Mozilla’s Root Store Policy and 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."


It's a self-signed root certificate, but nonetheless there exists a 
signature chain up to an included root and so disclosure is required.



[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/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: Machine- and human-readable format for root store information?

[Rob Stradling via dev-security-policy]

On 05/07/17 18:08, Ryan Sleevi wrote:

On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham wrote:



That is, the difference between, say:
"label": "Verisign/RSA Secure Server CA"
And
CKA_LABEL "Verisign/RSA Secure Server CA"

I would argue there isn't a meaningful difference for "human readability",
and it's more a subjective preference. Before we fixate on those, I'm
hoping we should get objective use cases nailed down. That's why I'm trying
to understand how you're evaluating that spectrum. Is it because it's
something you'd like to maintain, because you think it should be "readable"
on a webpage, etc?


How it is sans-comments is irrelevant, because it has comments. :-)


It isn't, because JSON can't.


Unless...

{"label":"Verisign/RSA Secure Server CA","comments":"These are some 
comments"}


--
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: Symantec Conclusions and Next Steps

[Rob Stradling via dev-security-policy]

On 25/04/17 23:50, Ryan Sleevi via dev-security-policy wrote:

Continuing to look through the audits, I happened to notice a few other
things that stood out, some more pressing than others.

More pressing:
I can find no disclosure with Salesforce or crt.sh of at least two CAs that
are listed 'in scope' of the audit report, as part of
https://www.symantec.com/content/en/us/about/media/
repository/Symantec-NFSSP-WTCA_11-30-2016.pdf


Hi Ryan.  Today I went hunting for missing intermediate certificates.  I 
produced a list of all the AIA:caIssuers URLs from all certs known to 
crt.sh.  Then I downloaded and parsed all of them, attempting to decode 
each file as DER cert, PEM cert, DER PKCS#7 and PEM PKCS#7.  Then I 
submitted the previously unseen certs to CT.



This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
CA2" as within scope for this audit. It would be useful to understand their
lack of disclosure, relative to the audits and to Section 5.3.2 of the
inclusion policy.


Those two now appear here:
https://crt.sh/?id=129400172
https://crt.sh/?id=129400151

https://crt.sh/mozilla-disclosures#undisclosed currently lists these two 
SureID intermediates plus a further VeriSign intermediate 
(https://crt.sh/?id=129148836) that should've been disclosed to CCADB 
some time ago.


(Note: A few of the non-Symantec entries currently listed by 
https://crt.sh/mozilla-disclosures#undisclosed are false positives, I 
think.  It looks like Kathleen has marked some roots as "Removed" on 
CCADB ahead of the corresponding certdata.txt update on mozilla-central).


--
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: Symantec Conclusions and Next Steps

[Rob Stradling via dev-security-policy]

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:


(Note: A few of the non-Symantec entries currently listed by
https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
think.  It looks like Kathleen has marked some roots as "Removed" on
CCADB ahead of the corresponding certdata.txt update on mozilla-central).


Ah, I take that back.  The March certdata.txt update did hit 
mozilla-central on 11th April, but I missed an alert.  I've just pushed 
that update to crt.sh.


https://crt.sh/mozilla-disclosures#undisclosed is currently free of 
false positives.  It shows that DigiCert, StartCom and Symantec are 
currently out-of-compliance with Mozilla's disclosure requirement.


--
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: Symantec Conclusions and Next Steps

[Rob Stradling via dev-security-policy]

On 27/04/17 11:56, Inigo Barreira wrote:

Good to know that our new certs are there :-)
Regarding StartCom, these are the new certs we´ve generated and will be used
to apply for inclusion in the Mozilla root program. Nothing to disclose at
the moment I guess. We´ve not been audited yet nor applied.



Hi Iñigo.  The old StartCom roots still have the SSL trust bit enabled 
in NSS, and you've used one of those old roots to cross-sign the new 
StartCom roots.  AFAICT, that means that these new StartCom 
intermediates do need to be disclosed to the CCADB.


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

TBSCertificate / Certificate Linting APIs

[Rob Stradling via dev-security-policy]

In response to the many BR compliance issues [1] that have been reported 
here this month, there's been renewed interest in certificate linting. 
Various CAs have said that they're considering plugging one or more 
certificate linters into their certificate issuance processes.


Some CAs, such as those with high certificate issuance rates, will 
probably prefer to run their own local installations of their chosen 
linter(s).  However, other CAs may prefer to use an external linting 
service.


One current problem is that neither certlint/cablint nor x509lint is 
suitable for use prior to certificate issuance - that is, they're only 
currently capable of operating on certificates, not TBSCertificates.


With all of the above in mind, I've created a new crt.sh API that can be 
used to lint TBSCertificates.  It uses crt.sh's existing linting 
capabilities, which are provided by cablint and x509lint.  To workaround 
the limitation described in the previous paragraph, it wraps the 
TBSCertificate into a certificate structure by appending a dummy signature.


I'm planning to integrate this crt.sh API into Comodo's issuance 
processes ASAP.  Other CAs are also welcome to use it (although please 
chat to me first if you're a high-volume issuer!)


API URL: https://crt.sh/linttbscert

To use it, either (1) browse to that URL, paste a base64-encoded 
TBSCertificate, then click "Lint TBSCertificate", or (2) simulate that 
button click by POSTing a URL-encoded "b64tbscert" parameter to the same 
URL.


The API response is tab-separated text, with one line per "issue".  Each 
line contains three items:

  LinterSeverityDescription


P.S. I've also created an equivalent linting API for certificates: 
https://crt.sh/lintcert



[1] https://wiki.mozilla.org/CA/Incident_Dashboard#Open_CA_Compliance_Bugs

--
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: Guang Dong Certificate Authority (GDCA) root inclusion request

[Rob Stradling via dev-security-policy]

On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:


* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh - it would be great to get them
CT logged.


Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be 
done for the other two ROOTs as we have not yet applied for the inclusion of 
these two.


Hi.

Would you like me to add your other two roots to the list of roots that 
are accepted by the Comodo Dodo log?


If so, please either submit a pull request on GitHub (see 
https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two 
root certs.


The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh.

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

Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

Yesterday I knocked together a script that: scrapes a URL (or a list of 
URLs) for certificate files; then attempts to build a trust chain (using 
https://crt.sh/gen-add-chain) for each certificate found; then submits 
to some CT logs any trust chains that crt.sh hasn't previously seen.


I've thrown the code up on GitHub [1].

Overnight I left certscraper to scrape the following lists of URLs:
  - the disclosure URLs that CAs provided in response to Mozilla's May 
2014 CA Communication [2].
  - the CP/CPS URLs currently listed in the CCADB (some of which appear 
to be repository pages).

  - the Belgian Government eID repository pages [3].

certscraper found...

  - 8 DigiCert intermediates (found on [4]) that should've been already 
disclosed to CCADB, but weren't:

https://crt.sh/?id=135966905
https://crt.sh/?id=135966906
https://crt.sh/?id=135966907
https://crt.sh/?id=135966908
https://crt.sh/?id=135970325
https://crt.sh/?id=135970327
https://crt.sh/?id=135970329
https://crt.sh/?id=135970332

  - 10 Belgian eID intermediates:
https://crt.sh/?id=135626971
https://crt.sh/?id=135626972
https://crt.sh/?id=135626973
https://crt.sh/?id=135626974
https://crt.sh/?id=135626975
https://crt.sh/?id=135626980
https://crt.sh/?id=135626981
https://crt.sh/?id=135626982
https://crt.sh/?id=135626983
https://crt.sh/?id=135626984

Another 1 undisclosed Belgian eID intermediate 
(https://crt.sh/?id=135002620) had appeared in crt.sh a couple of days 
earlier.


It would seem that DigiCert noticed these 19 intermediates appear on 
https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, 
because they've all now been disclosed to the CCADB.


They should've been disclosed some time ago, however.


[1] https://github.com/robstradling/certscraper

[2] 
https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml


[3] 
https://github.com/robstradling/certscraper/blob/master/url_lists/belgian_eid.txt


[4] https://www.digicert.com/digicert-root-certificates.htm?show=all

--
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: Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote:

On 2017-05-11 13:07, Rob Stradling wrote:

It would seem that DigiCert noticed these 19 intermediates appear on
https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep,
because they've all now been disclosed to the CCADB.

They should've been disclosed some time ago, however.


Does the CCADB keep track of when something was disclosed? A history?


There's a "Created by" field (Username, Timestamp) and a "Last Modified 
By" field (Username, Timestamp) in the CCADB, but neither of these 
fields are currently provided in the public CSV reports that Mozilla 
publishes.


--
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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:

Ryan,

If you look at the wide range of user agents accessing google.com today you'd 
see many legacy applications and older versions of browsers and custom browsers 
built from variants of the commercial browsers.  By the time all/most users 
upgraded to new browsers, it would be time to change the roots out again and 
this will impact the ability for web site operators to enable TLS for all 
visitors.

Before we can implement a short Root usage policy we'd need to convince all 
browsers to follow a process for rapid updates of root stores.


Hi Doug.

Imagine a root cert A, valid for a short duration; and a root cert B, 
valid for a long duration.


Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas 
other less agile root stores would contain B.


A doesn't have to be in every root store, because B can cross-certify A. 
 (Let's call the cross-certificate A').


A widely compatible cert chain would therefore look like this:
B -> A' -> Intermediate -> Leaf

If you're already cross-certifying from an older root C, then an even 
more widely compatible cert chain would look like this:

C -> B' -> A' -> Intermediate -> Leaf

--
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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:


The important point in this is that there should not be a non-linear path
of trust (which is implied, I think, by the reading of "group of
cross-certs"). But yes, there would be a linearized path.


If you *rely* on AIA, then why not set the AIA->caIssuers content to be 
a PKCS#7 "group of cross-certs" ?



Unquestionably, this means that performance gets worse for sites who
support clients that do not support AIA and who serve the extra
(potentially unnecessary) chains. This does put a certain pressure on these
clients _to_ support AIA, and the performance implications would only
become worse the longer the legacy clients exist. However, if/when 'enough'
clients support AIA (or automatic updates), the performance costs
evaporate. This helps create a virtuous cycle in which site operators are
incentivized to support clients that support AIA/automatic updates, and
software developers are incentivized to provide clients that support
AIA/automatic updates :)


--
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: Guang Dong Certificate Authority (GDCA) root inclusion request

[Rob Stradling via dev-security-policy]

On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote:

在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道：

On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:


* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh - it would be great to get them
CT logged.


Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be 
done for the other two ROOTs as we have not yet applied for the inclusion of 
these two.


Hi.

Would you like me to add your other two roots to the list of roots that
are accepted by the Comodo Dodo log?

If so, please either submit a pull request on GitHub (see
https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two
root certs.

The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh.


Hi Rob,

Thanks for your kind assistance, we have e-mailed our roots to you for this 
purpose.


Our Dodo log now accepts the "GDCA TrustAUTH E5 ROOT" and "数安时代 R5 根 CA" 
root certificates, and I've submitted both of them to Dodo.  You can see 
them here:


https://crt.sh/?id=139646527
https://crt.sh/?id=139646529

--
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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

On 16/05/17 16:11, Ryan Sleevi via dev-security-policy wrote:

On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:



The important point in this is that there should not be a non-linear path
of trust (which is implied, I think, by the reading of "group of
cross-certs"). But yes, there would be a linearized path.



If you *rely* on AIA, then why not set the AIA->caIssuers content to be a
PKCS#7 "group of cross-certs" ?



1) Clients don't widely support PKCS#7


Regarding AIA->caIssuers, RFC5280 says:
  'Conforming applications that support HTTP or FTP for accessing
   certificates MUST be able to accept individual DER encoded
   certificates and SHOULD be able to accept "certs-only" CMS messages.'

Out of interest, which particular clients chase AIA->caIssuers HTTP URLs 
but ignore that "SHOULD"?
(I know CryptoAPI has accepted "certs-only" CMS messages since XP, but 
I've not checked any other implementations).



2) LOL PKCS#7 is a tirefire
3) Because that's an added/unnecessarily complexity to the PKI which is
pretty detrimental compared to a linearized path.


Sure, it's certainly added complexity.


I presume, but perhaps you can clarify, that the 'group of cross-certs' is
meant to cover the case where you have roots A, B, C, where A was created a
T-6, B at T-3, and C at T0, with an intermediate I issuing leaf L

I presume that your goal is that rather than expressing:
L -> I -> C -> B -> A

That you want to express

L -> I -> C
  -> C2 (via AIA) -> B
  -> C3 (via AIA) -> A
> Is that correct?


That's what my question was about, yes.


What is the advantage of that, given that PKCS#7 involves
BER, it introduces C/C2/C3, and you're still supplying the same number of
certs?

I don't think there is any notable advantage.

I asked the question because I thought it would be useful to enumerate 
the reasons why "there should not be a non-linear path" rather than just 
assume it to be fact.  ;-)


--
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: Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

On 11/05/17 18:05, Gervase Markham via dev-security-policy wrote:

On 11/05/17 12:46, Rob Stradling wrote:

There's a "Created by" field (Username, Timestamp) and a "Last Modified
By" field (Username, Timestamp) in the CCADB, but neither of these
fields are currently provided in the public CSV reports that Mozilla
publishes.


Rob: do you think you could enhance
https://crt.sh/mozilla-disclosures#undisclosed to give the number of
days a certificate has been on the list?


Hi Gerv.

I've just added two columns to 
https://crt.sh/mozilla-disclosures#undisclosed:

  - "Earliest SCT".
  - "Listed Here Since".

Note that if an intermediate cert goes out of scope for disclosure 
(i.e., all trust paths become revoked) but then comes back into scope 
for disclosure (i.e., a new trust path is discovered), then its "Listed 
Here Since" timestamp will be reset.


--
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: Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

On 17/05/17 15:12, Gervase Markham via dev-security-policy wrote:

On 17/05/17 13:32, Rob Stradling wrote:

I've just added two columns to
https://crt.sh/mozilla-disclosures#undisclosed:
   - "Earliest SCT".
   - "Listed Here Since".


Lovely! Now we just need a cert to be on the list so we can see what it
looks like ;-)


Shall I add the same two fields to 
https://crt.sh/mozilla-disclosures#disclosureincomplete as well?


--
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: Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

On 17/05/17 14:43, Kurt Roeckx via dev-security-policy wrote:

On 2017-05-17 14:40, Rob Stradling wrote:

On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote:

On 2017-05-11 19:05, Gervase Markham wrote:

On 11/05/17 12:46, Rob Stradling wrote:
There's a "Created by" field (Username, Timestamp) and a "Last 
Modified

By" field (Username, Timestamp) in the CCADB, but neither of these
fields are currently provided in the public CSV reports that Mozilla
publishes.


Rob: do you think you could enhance
https://crt.sh/mozilla-disclosures#undisclosed to give the number of
days a certificate has been on the list?


Rob,


Hi Kurt.


Could you also split the "Technically Constrained", into those that
are really technically constrained, and those that are out of scope
for the CCADB?


What's your definition of "really technically constrained"?


For instance https://crt.sh/?id=12729339 is out of scope because it's
code signing. https://crt.sh/?id=8951039 because it's client / email.


They're out of scope because they're Technically Constrained in
accordance with Section 5.3.1 of the Mozilla Root Store Policy v2.4.1 [1]


Or maybe it just needs to be renamed?


I'm really not sure what "it" you'd like to see categorized differently.


I seem to have been confused. For some reason I was under the impression 
that only those that can be used for server auth were required to be 
disclosed when I was reading it last week. It didn't really make sense 
to me at the time, and now I can't find anything that suggests that.


The impression you were under is correct.

Any intermediate that is EKU-constrained to not permit serverAuth, or 
that permits serverAuth but is appropriately name-constrained, is 
considered to be "Technically Constrained" and is therefore not subject 
to the current disclosure requirement.


And it seem that only an EKU is needed with the current policy for email 
and code signing to be considered constrained.


Correct.

But you could argue that 
for email you can't say for sure that it's constrained or not, which I 
guess is why we have https://github.com/mozilla/pkipolicy/issues/69


Correct.

See also https://github.com/mozilla/pkipolicy/issues/73, which proposes 
that even Technically Constrained intermediates should fall under the 
disclosure requirement.


I guess with code signing we have the situation that Mozilla doesn't 
care about it, but requires you to disclose them anyway.


Where does it say that code signing intermediates need to be disclosed?

That's not my understanding of section 5.3.1 of 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/


Incidentally, it's true that Mozilla have said that they don't care 
about the Code Signing trust bit any more, but the 
CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt.  Bug?


--
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: Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

On 17/05/17 15:21, Gervase Markham via dev-security-policy wrote:

On 17/05/17 15:15, Rob Stradling wrote:

Shall I add the same two fields to
https://crt.sh/mozilla-disclosures#disclosureincomplete as well?


Yes, why not? :-)

Gerv


Done.

The "Listed Here Since" timestamps for the 24 intermediates currently in 
this category are set to today, because I don't have a time machine to 
go back and find out how long they've actually been listed in this 
category.  ;-)


--
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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:


Just spitballing ideas here, but in Alex's case, part of me would be
tempted to see if X509 could be extended with a new "CanIssueUntil"
field. Basically, it would act as an off switch for CA:TRUE after a
given date, but certificates signed before that would still be valid for
that root, and then can be wound down beyond that point.


That sounds like the "Private Key Usage Period" extension, which was 
present in RFC3280 but removed in RFC5280.


https://tools.ietf.org/html/rfc3280#section-4.2.1.4

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

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

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

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


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


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


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


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


Fixed.

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


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


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



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


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


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

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


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

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

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote:

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy  wrote:



On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
 wrote:

I don't believe that disclosure of root certificates is the responsibility
of a CA that has cross-certified a key.  For instance, the CCADB interface
talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
browsers to upload.  I don't even have access to upload a "root"
certificate.


I think the Mozilla Root Store policy is pretty clear on this point:


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.


The self-signed certificates in the present set are all in scope for the 
disclosure policy because they are capable of being used to issue new 
certificates and chain to a certificate included in Mozilla’s CA Certificate 
Program. From the perspective of the Mozilla root store they look like 
intermediates because they can be used as intermediates in a valid path to a 
root certificate trusted by Mozilla.


There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different
restrictions.  Self-issued certificates do not provide alternative
paths that may have fewer constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the
"child" CA can issue self-issued certificates all day long.  If they
are self-signed there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are
out of scope.


There's a signature chain, so they're clearly in scope (as far as the 
current policy is concerned).


The policy would need to be updated before we could say that they "*are* 
out of scope".


(FWIW, I agree that it's pointless for them to be in scope.  However, 
the policy trumps my opinion).


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

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

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:


What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?

And would someone please post those alleged certificate chains 
*explicitly* here, not just say they saw it "somehow".


Hi Jakob.  Let me run through one of them as an example:

https://crt.sh/?id=12977063 is a self-signed root certificate that is 
also an NSS built-in trust anchor.


https://crt.sh/?id=149444544 is a self-signed root certificate that is 
_not_ an NSS built-in trust anchor.


These two certs share the same Name and Key.  Therefore, the signature 
on the first can be verified by the public key in the second; and vice 
versa.  And clearly the Subject Name in each one matches the Issuer Name 
in the other.  This means that the first chains to the second, and also 
that the second chains to the first.


The policy says:
"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."


--
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: When are public applications embedding certificates pointing to 127.0.0.1 OK?

[Rob Stradling via dev-security-policy]

[CC'ing rev...@digicert.com, as per 
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028]


Annie,

"but these have been known about and deemed acceptable for years"

Known about by whom?  Deemed acceptable by whom?  Until the CA becomes 
aware of a key compromise, the CA will not know that the corresponding 
certificate(s) needs to be revoked.


Thanks for providing the Spotify example.  I've just found the 
corresponding certificate (issued by DigiCert) and submitted it to some 
CT logs.  It's not yet revoked:

https://crt.sh/?id=158082729

https://gist.github.com/venoms/d2d558b1da2794b9be6f57c5e81334f0 does 
appear to be the corresponding private key.


On 20/06/17 15:57, annie nguyen via dev-security-policy wrote:

Hi!

I'm not sure if this is the correct place to ask (I'm not sure where
else I would ask). I'm so sorry if this message is unwanted.

Earlier this week, a certificate for a domain resolving to 127.0.0.1 in
a Cisco application was revoked, because it was deemed to have been
compromised.

Dropbox, GitHub, Spotify and Discord (among others) have done the same
thing for years: they embed SSL certificates and private keys into their
applications so that, for example, open.spotify.com can talk to a local
instance of Spotify (which must be served over https because
open.spotify.com is also delivered over https).

This has happened for years, and these applications have certificates
issued by DigiCert and Comodo all pointing to 127.0.0.1 whose private
keys are trivially retrievable, since they're embedded in publicly
distributed binaries.

- GitHub: ghconduit.com
- Discord: discordapp.io
- Dropbox: www.dropboxlocalhost.com
- Spotify: *.spotilocal.com

Here is Spotify's, for example:
https://gist.github.com/venoms/d2d558b1da2794b9be6f57c5e81334f0



What I want to know is: how does this differ to Cisco's situation? Why
was Cisco's key revoked and considered compromised, but these have been
known about and deemed acceptable for years - what makes the situation
different?

It's been an on-going question for me, since the use case (as a software
developer) is quite real: if you serve a site over HTTPS and it needs to
communicate with a local client application then you need this (or, you
need to manage your own CA, and ask every person to install a
certificate on all their devices)

Thank you so much,
Annie
___
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: Unknown Intermediates

[Rob Stradling via dev-security-policy]

On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:

Thanks Alex, I took a look, it looks like the check pings crt.sh - is doing
that for a large number of certificates acceptable Rob?


Hi Tavis.  Yes, Alex's tool uses https://crt.sh/gen-add-chain to find a 
suitable cert chain and build the JSON that can then be submitted to a 
log's /ct/v1/add-chain.  It should be fine to do that for a large number 
of certs.  crt.sh exists to be used.  ;-)



I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
Purpose : Yes', there were only a few thousand that verified, so I just
checked those and found 551 not in crt.sh.

(The *vast* majority are code signing certificates, many are individual
apple developer certificates)

Is this useful? if not, what key usage is interesting?

https://lock.cmpxchg8b.com/ServerOrAny.zip


Thanks for this, Tavis.  I pointed my certscraper 
(https://github.com/robstradling/certscraper) at this URL a couple of 
days ago.  This submitted many of the certs to the Dodo and Rocketeer logs.


However, it didn't manage to build chains for all of them.  I haven't 
yet had a chance to investigate why.



Tavis.

On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor <agay...@mozilla.com> wrote:


If you're interested in playing around with submitting them yourself, or
checking if they're already submitted, I've got some random tools for
working with CT: https://github.com/alex/ct-tools

Specifically ct-tools check <cert1.pem, cert2.pem, ...> will get what you
want. It's all serial, so for 8M certs you probably want to Bring Your Own
Parallelism (I should fix this...)

Alex

On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:


On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:





Is there an easy way to check which certificates from my set you're

missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
for fuzzing).

I collected these from public sources, so can just give you my whole
set if you already have tools for importing them and don't mind
processing them, I have around ~8M (mostly leaf) certificates, the
set with isCa will be much smaller.



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

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

Thanks a bunch for this!



+1

Tavis, please do post the whole set.  And thanks!


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

[Rob Stradling via dev-security-policy]

On 23/06/17 14:49, Peter Bowen via dev-security-policy wrote:

On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:


On 2017-06-23 14:59, Rob Stradling wrote:


Reasons:
- Some are only trusted by the old Adobe CDS program.
- Some are only trusted for Microsoft Kernel Mode Code Signing.
- Some are very old roots that are no longer trusted.



I wonder if Google's daedalus would like to see some of those.



Daedalus only accepts expired certs.  Most of these haven't expired.

If there's interest, I could add these to our Dodo log.


For those three, I would be interested in seeing them.  I wonder if
any match submariner as well.


We've just added the Adobe Root CA and Microsoft Code Verification Root 
to the list of roots accepted by our Dodo log.


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

[Rob Stradling via dev-security-policy]

On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:

On 2017-06-23 14:59, Rob Stradling wrote:

Reasons:
   - Some are only trusted by the old Adobe CDS program.
   - Some are only trusted for Microsoft Kernel Mode Code Signing.
   - Some are very old roots that are no longer trusted.


I wonder if Google's daedalus would like to see some of those.


Daedalus only accepts expired certs.  Most of these haven't expired.

If there's interest, I could add these to our Dodo log.

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

[Rob Stradling via dev-security-policy]

On 22/06/17 10:51, Rob Stradling via dev-security-policy wrote:

On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:



Is this useful? if not, what key usage is interesting?

https://lock.cmpxchg8b.com/ServerOrAny.zip


Thanks for this, Tavis.  I pointed my certscraper 
(https://github.com/robstradling/certscraper) at this URL a couple of 
days ago.  This submitted many of the certs to the Dodo and Rocketeer logs.


However, it didn't manage to build chains for all of them.  I haven't 
yet had a chance to investigate why.


There are ~130 CA certificates in 
https://lock.cmpxchg8b.com/ServerOrAny.zip that I've not yet been able 
to submit to any CT logs.


Reasons:
  - Some are only trusted by the old Adobe CDS program.
  - Some are only trusted for Microsoft Kernel Mode Code Signing.
  - Some are very old roots that are no longer trusted.
  - Some are corrupted.
  - Some seem to be from private PKIs.

--
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: Hunting for intermediates that still haven't been disclosed to CCADB

[Rob Stradling via dev-security-policy]

On 17/05/17 15:12, Gervase Markham wrote:

On 17/05/17 15:08, Rob Stradling wrote:

Incidentally, it's true that Mozilla have said that they don't care
about the Code Signing trust bit any more, but the
CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt.  Bug?


Yes, but a low priority one. Feel free to file :-)


Filed.

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

--
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: Google Plan for Symantec posted

[Rob Stradling via dev-security-policy]

On 19/05/17 21:04, Kathleen Wilson via dev-security-policy wrote:


Hi Kathleen.  I'm not quite sure how to interpret this part...


- I'm not sold on the idea of requiring Symantec to use third-party CAs to 
perform validation/issuance on Symantec's behalf. The most serious concerns 
that I have with Symantec's old PKI is with their third-party subCAs and 
third-party RAs. I don't have particular concern about Symantec doing the 
validation/issuance in-house. So, I think it would be better/safer for Symantec 
to staff up to do the validation/re-validation in-house rather than using third 
parties. If the concern is about regaining trust, then add auditing to this.


Are you saying that Symantec would be a Delegated Third Party that can 
perform all of the validation and can trigger certificate issuance, but 
that it would actually be a third-party CA that handles the new Symantec 
PKI and issues certs (when triggered to do so by Symantec)?


Or, are you saying that Symantec would be permitted to operate their new 
PKI in-house from day 1?


--
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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

On 16/05/17 19:53, Ryan Sleevi via dev-security-policy wrote:


What is the advantage of that, given that PKCS#7 involves

BER, it introduces C/C2/C3, and you're still supplying the same number of
certs?


I don't think there is any notable advantage.

I asked the question because I thought it would be useful to enumerate the
reasons why "there should not be a non-linear path" rather than just assume
it to be fact.  ;-)


You mean I can't just spout opinion here without substantiating it? ;)


You can do that if you want, but I tend to find well-reasoned arguments 
to be more persuasive.  ;-)


--
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: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Rob Stradling via dev-security-policy]

On 06/06/17 22:26, Jakob Bohm wrote:

On 06/06/2017 22:08, Ryan Sleevi wrote:



Signing data is heavily reliant on CA competency, and that's in
unfortunately short supply, as the economics of the CA market make it 
easy to fire all the engineers, while keeping the sales team, and

outsourcing the rest.


Ryan, thankfully at least some CAs have some engineers.  :-)


Which is why I am heavily focused on allowing new technology to be be
developed by competent non-CA staff (such as IETF),


Jakob, if I interpret that literally it seems you're objecting to CA 
staff contributing to IETF efforts.  If so, may I advise you to beware 
of TLS Feature (aka Must Staple), CAA, CT v1 (RFC6962) and especially CT 
v2 (6962-bis)?


;-)

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

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

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 08/06/17 12:57, Kurt Roeckx via dev-security-policy wrote:

On 2017-06-08 13:31, richmoor...@gmail.com wrote:
This one is interesting since the domain name of the CRL resolves to 
an RFC 1918 IP address. Surely that is a violation of the baseline 
requirements.


https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca 



That seems to be a root CA. It does not mention any CRL. I don't expect 
a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
CRL URL.


crt.sh collates revocation information from all known CRL Distribution 
Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by the 
same CA:


https://crt.sh/?Identity=%25=241

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

[Rob Stradling via dev-security-policy]

On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:

Hello, I was crawling the pkcs7 blobs in public pdf files and found some
intermediate certificates that don't appear in crt.sh.

I forwarded them to Rob, I don't know if this is useful to anyone else, but
they're available here.

https://lock.cmpxchg8b.com/intermediates.zip

Tavis.


Thanks Tavis.  I've just submitted all of these intermediates to some CT 
logs.


This list just grew considerably...
https://crt.sh/mozilla-disclosures#undisclosed


(I have a larger collection if anyone wants them, but many have unknown
critical extensions, or are name or usage constrained, etc)


Yes please.  :-)

--
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: Changing CCADB domains

[Rob Stradling via dev-security-policy]

On 06/05/17 10:25, Jesper Kristensen via dev-security-policy wrote:


Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.

Is that what you meant, Peter?


You cannot set up a CNAME without configuring Salesforce, since they
would not know your Host/SNI header, and they would not serve a cert
that is valid for your domain.


Ah.


You can set up a new domain in Salesforce while keeping the old
mozillacacommunity.force.com without premium support, as long as the new
domain is a custom domain and not a force.com domain.


Or Mozilla could setup https://login.ccadb.org to simply return an HTTP 
temporary redirect to .force.com.


--
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: Symantec: Draft Proposal

[Rob Stradling via dev-security-policy]

On 01/05/17 18:33, Alex Gaynor via dev-security-policy wrote:

Hi Gerv,

One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
less than some period, perhaps 3 days. This would ensure rapid visibility
into important changes to the WebPKI.


Hi Alex.  Mandatory timely CCADB submission is already planned (for the 
next version of the Mozilla Root Store Policy, I presume):


https://github.com/mozilla/pkipolicy/commit/b7d1b6c04458114fbe73fa3f146ad401235c2a1b

I keep an eye on https://crt.sh/mozilla-disclosures#unknown (which shows 
intermediates known to CCADB but not yet known to CT/crt.sh).  When an 
intermediate appears in that list, I'll grab the PEM data from CCADB, 
paste it onto https://crt.sh/gen-add-chain, and then submit it to some 
CT logs.  However, it would be great if the CAs would do this 
themselves.  :-)


--
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: Changing CCADB domains

[Rob Stradling via dev-security-policy]

On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:

On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
dev-security-policy  wrote:

All,

I think it is time for us to change the domains that we are using for the CCADB 
as follows.

Change the links for...

1)  CAs to login to the CCADB
from
https://mozillacacommunity.force.com/
to
https://ccadb.force.com/

2) all published reports
from
https://mozillacaprogram.secure.force.com/
to
https://ccadb.secure.force.com/


We asked Salesforce for a temporary redirect from the old to the new URLs, but 
that was declined because we're not paying for premium support for the CCADB. 
(Other than this change, I do not currently see the need for us to pay for 
premium support.)


Is it also a "premium" feature to use custom domain names?  I think it
would probably make sense to use ccadb.org (which seems to belong to
Mozilla) rather than force.com.


Mozilla could CNAME from ccadb.org to .force.com, and then 
declare that the ccadb.org URLs are the official ones.


Is that what you meant, Peter?

--
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: Changing CCADB domains

[Rob Stradling via dev-security-policy]

On 05/05/17 16:08, Gervase Markham via dev-security-policy wrote:

On 05/05/17 10:22, Rob Stradling wrote:

Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.


It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an introductory website for the CCADB, once Mozilla IT
configures things correctly ;-)


How about...

login.ccadb.org => mozillacacommunity.force.com
(to be changed on May 19th to => ccadb.force.com)

reports.ccadb.org => mozillacaprogram.secure.force.com
(to be changed on May 19th to => ccadb.secure.force.com)

?

--
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: CA Validation quality is failing

[Rob Stradling via dev-security-policy]

On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:

I know several CAs are using certlint (https://github.com/awslabs/certlint)
as a pre-issuance check that the cert they're about to issue doesn't have
any programmatically detectable deficiencies; if it doesn't already cover
some of these cases, it'd be great to add them as a technical means for
ensuring that this doesn't regress -- things like N/A should be an easy
enough check to add I'd think.


Simple project idea (perhaps for https://github.com/cabforum):

A CSV file that contains 2 items per line:
1. An optional comma-separated list of Subject attribute shortnames.
2. A string that a CA should probably not encode as a complete Subject 
attribute.


e.g.,
"OU,ST,L","N/A"
,"."
"O","Internet Widgits Pty Ltd"

Anyone (CA representatives, industry researchers, etc, etc) would be 
able to submit PRs, CAs would be invited to consult this list when 
evaluating certificate requests, and certlint would be able to report on 
"violations".



Cheers,
Alex

On Tue, May 2, 2017 at 11:07 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


(Still wearing Google Hat in this context)

I think sharing a list (in CT) of the certs is good and can help verify the
assertions made here :)

But overall, I think this sounds right and the risk is minimal to our
users, so not revoking still sounds good :)

On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley 
*Cc:* Gervase Markham ; mozilla-dev-security-policy@
lists.mozilla.org
*Subject:* Re: CA Validation quality is failing







On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

There isn't anything in our CPS directly. However, we state that we

follow

the baseline requirements in the CPS. The baseline requirements give a
profile for the state field. We weren't sure this was strictly followed.

We finished our validation review over the weekend.   There are about

3000

older certs with information indicating a field was not applicable (such

as

a "-", "N/A", etc). On top of this, we issued about 1000 certificates

with

mismatched validation information. The mismatched information can be
divided into about 850 certificates with numbers in the state field.

These

numbers indicate a location code that was provided by the auto-populator.
The remaining 150 are certificates with "Select", a state, or a postal

code

improperly included in the certificate.  The root issue was a combination
of the auto-populator inserting incorrect data into the cert request and
our validation staff not properly updating the certificate information
after completing the validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate
order generators.
2. We already blocked this information on the CA side from included in
signed SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct the
certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850
certificates because the information isn't misleading, the information is
accurate, and there isn't a risk posed to Mozilla's users by inclusion of
the numeric location code or not applicable indicator. Any thoughts?



(With a Google hat on)



Jeremy,



I think with the information you've shared so far, that sounds like a
reasonable plan from Google's perspective for the 3000 certificates. I
think there's at least a little concern about the EV nature for the 850
side, but just trying to understand more here what the implications would
be. Is this exclusively the state, or does it also extend to the
jurisdiction* fields? Or is this only for EV?



Would you be able to share a spreadsheet or details for those, in the
spirit of transparency? I think if you can share those details, it's
reasonable to avoid revoking, and anything specific that might represent

a

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 06/06/17 14:22, Alex Gaynor via dev-security-policy wrote:

On Tue, Jun 6, 2017 at 9:05 AM, Ryan Sleevi via dev-security-policy <



Alex, do you have the specific list of CAs at the time of your posting?



Yes, it was:

* QuoVadis
* AC Camerfirma, S.A.
* Chunghwa Telecom Corporation
* Start Commercial (StartCom) Ltd.

QuoVadis disclosed their intermediate within a few hours of my email, the
others still have not.


"QuoVadis Grid ICA G2"
https://crt.sh/?q=74CE8C1631EF9F38E7A4197DA3F5474DBC34F001F2967C25B5999562BCC8C9D4

First seen by Censys just over a month ago:
https://censys.io/certificates/74ce8c1631ef9f38e7a4197da3f5474dbc34f001f2967c25b5999562bcc8c9d4

--
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: Machine- and human-readable format for root store information?

[Rob Stradling via dev-security-policy]

On 27/06/17 01:36, Ryan Sleevi via dev-security-policy wrote:

On Mon, Jun 26, 2017 at 9:50 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


A few root store operators at the recent CAB Forum meeting informally
discussed the idea of a common format for root store information, and
that this would be a good idea. More and more innovative services find
it useful to download and consume trust store data from multiple
parties, and at the moment there are various hacky solutions and
conversion scripts in use.



Gerv,

Do you anticipate this being used to build trust decisions in other
products, or simply inform what CAs are trusted (roughly)?

My understanding from the discussions is that this is targeted at the
latter - that is, informative, and not to be used for trust decision
capability - rather than being a full expression of the policies and
capabilities of the root store.

The reason I raise this is that you quickly get into the problem of
inventing a domain-specific language (or vendor-extensible, aka
'non-format') if you're trying to express what the root store does or what
constraints it applies. And that seems a significant amount of work, for
what is an unclear consumption / use case.

I'm hoping you can clarify with the concrete intended users you see Mozilla
wanting to support, and if you could share what the feedback these other
store providers offered.

FWIW, Microsoft's (non-JSON, non-XML) machine readable format is
http://unmitigatedrisk.com/?p=259


Hi Gerv.  crt.sh consumes the various trust store data, so I may be 
interested in helping to write a spec.  However, it depends very much on 
how the end product would be used.


If the aim is to replace certdata.txt, authroot.stl, etc, with this new 
format, then I'm more interested.


If the aim is to offer yet another mechanism for obtaining trust store 
data (which may fall out of sync with the "official" data), then I'm 
less interested.


--
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: CAs not compliant with CAA CP/CPS requirement

[Rob Stradling via dev-security-policy]

On 21/09/17 22:56, richmoore44--- via dev-security-policy wrote:

On Thursday, September 21, 2017 at 10:13:56 AM UTC+1, Rob Stradling wrote:

Our CPS has now been updated.


Will you be ensuring that CAs like Gandi who are chaining back to your roots 
also update their CPS?


Gandi are a managed CA.  We are chasing them up and will get them to 
link through to Comodo's legal repository.


https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf 
is a deprecated document.  A different CPS URL (that takes you to 
Comodo's CPS) is being included in new certificates.  See 
https://crt.sh/?Identity=%25=1593 and 
https://crt.sh/?Identity=%25=1575 for examples.


--
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: CAs not compliant with CAA CP/CPS requirement

[Rob Stradling via dev-security-policy]

On 22/09/17 17:07, Richard Moore via dev-security-policy wrote:

I see, the one I saw in the wild was issued from the intermediate below and
linked to the Gandi document however it was from 2014. That said, I don't
see the intermediate in crt.sh though that could just be me failing to use
the site properly!



That intermediate is https://crt.sh/?id=931

--
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: CAs not compliant with CAA CP/CPS requirement

[Rob Stradling via dev-security-policy]

On 08/09/17 20:24, Andrew Ayer via dev-security-policy wrote:

The BRs state:

"Effective as of 8 September 2017, section 4.2 of a CA's Certificate
Policy and/or Certification Practice Statement (section 4.1 for CAs
still conforming to RFC 2527) SHALL state the CA's policy or practice
on processing CAA Records for Fully Qualified Domain Names; that policy
shall be consistent with these Requirements. It shall clearly specify
the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
'issuewild' records as permitting it to issue. The CA SHALL log all
actions taken, if any, consistent with its processing practice."

Since it is now 8 September 2017, I decided to spot check the CP/CPSes
of some CAs.

At time of writing, the latest published CP/CPSes of the following CAs
are not compliant with the above provision of the BRs:



Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
specify issuer domain names


Andrew, thanks for bringing this to our attention.

Our CPS has now been updated.

--
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: Doppelganger/tripleganger intermediate certificates

[Rob Stradling via dev-security-policy]

On 03/10/17 17:50, Kathleen Wilson via dev-security-policy wrote:

On Friday, September 29, 2017 at 1:29:26 PM UTC-7, Rob Stradling wrote:

Several CAs have issued intermediate CA certificates with duplicate
serial numbers.  This is a clear violation of the serial number
uniqueness requirement of the BRs and RFC5280 4.1.2.2.  Below is a list
of all those known to crt.sh that chain to at least 1 NSS built-in root:




Thanks, Rob. I plan to file Bugzilla Bugs for these (for those not already 
filed), and request that these CAs scan their databases for all certs with same 
issuer/serial and provide an incident report.

But before doing so, I compared your finding with what I see in the CCADB...



  Issuer: https://crt.sh/?caid=1450
Issuer O: WoSign CA Limited
   Issuer CN: CA 沃通根证书
Subject CN: 中国湖南 EV 服务器证书
Serial #: 44:80:7b:20:7c:f2:05:2e:8d:34:11:77:02:66:d2:95
   Certs: https://crt.sh/?id=7841622
  https://crt.sh/?id=9318242
Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
still in NSS)
Subject CN: CA 沃通 EV 代码签名证书
Serial #: 3a:de:c4:02:27:0b:f4:ee:9e:89:2c:c6:5e:0a:da:21
   Certs: https://crt.sh/?id=12728869
  https://crt.sh/?id=12729072
Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots
still in NSS)


I don't plan to file a bug for these WoSign doppelganger certs, since we've 
already disabled and are removing the WoSign roots (bug #1387260).


That seems reasonable.  I realize the old WoSign and StartCom roots are 
already (semi-)disabled in Firefox, but since they've not yet been 
removed from NSS I considered them to be in scope for this report (for 
the benefit of any other consumers of the NSS trust list).



Also, I see another set of dobbelganger certs in the CCADB. Not sure why they 
didn't show up in your script output...

Issuer commonName: Belgium Root CA4
Subject commonName: Belgium Root CA4
Serial Number: 4f33208cc594bf38
https://crt.sh/?id=26311649
https://crt.sh/?id=160110886
Revoked? No


My query did find those two "Belgium Root CA4" certs, but (rightly or 
wrongly) I decided to omit them from my report.  They're both 
self-signed root certs rather than intermediates, although there are 
other trust paths from the "Belgium Root CA4" CA up to a root that's 
included in NSS.


FWIW, I also found one other pair of self-signed root certs that share a 
serial number, although there are no longer any known unrevoked trust 
paths from this CA up to a root that's included in NSS:


 Issuer commonName: Common Policy
Subject commonName: Common Policy
 Serial Number: 29:36:47:aa:e3:8a:ac:86:4a:23:56:f2:ca:b7:61:af
 Certs: https://crt.sh/?id=20444
https://crt.sh/?id=26310636

--
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: Doppelganger/tripleganger intermediate certificates

[Rob Stradling via dev-security-policy]

On 04/10/17 13:18, Adriano Santoni via dev-security-policy wrote:

Are these "temporary unconstrained SubCA certificate"s publicly 
trusted?  That is, do they have valid signatures from your "Actalis 
Authentication Root CA" (https://crt.sh/?caid=935) ?

If yes, can you confirm that you have disclosed them all to the CCADB?


No. The temporary unconstrained SubCA certificate is not trusted, 
because it is post-processed when it still is a tbsCertificate. When it 
comes into existence as a signed object, it already is a technically 
constrained certificate. As such, it is not required to disclose it to 
the CCADB.


Great.  Thanks for clarifying that, Adriano.

--
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: Doppelganger/tripleganger intermediate certificates

[Rob Stradling via dev-security-policy]

Hi Adriano.

It was pointed out to me that the doppelganger intermediate certificates 
that Actalis issued to Unicredit (https://crt.sh/?id=47081615 and 
https://crt.sh/?id=147626411) don't quite meet Mozilla's current 
"technically constrained" criteria.


Since v2.3, the Mozilla Root Store Policy has referenced BR 7.1.5, which 
says (emphasis mine):
"If the Subordinate CA Certificate includes the id‐kp‐serverAuth 
extended key usage, then the Subordinate CA Certificate MUST include the 
Name Constraints X.509v3 extension with constraints on dNSName, 
iPAddress *and DirectoryName*".


(In v2.2, "technically constrained" was defined within the Mozilla 
policy itself, and that definition did not require a DirectoryName 
constraint).


I suspect that the DirectoryName constraint requirement was added to the 
BRs due to Windows XP's weird behaviour when processing a Name 
Constraints extension that lacks a DirectoryName constraint (see 
https://unmitigatedrisk.com/?p=201).


I've just adjusted my crt.sh code to enforce the DirectoryName 
constraint requirement, and so the two Unicredit intermediates now 
appear under https://crt.sh/mozilla-disclosures#undisclosed


On 04/10/17 13:33, Adriano Santoni via dev-security-policy wrote:

Nick,

I think I have addressed this in my reply to Rob Stradling a few minutes 
ago.


In short: no, the "temporary unconstrained subCA" does never exist as a 
signed document, only the final (constrained) subCA is signed.


Adriano


Il 02/10/2017 20:57, Nick Lamb via dev-security-policy ha scritto:
The "post-processing" element is confusing, and could do with a bit 
more explanation unless perhaps I'm the fool here and everybody else 
(m.d.s.policy regulars) understands how this works


Since the name constraints are part of the signed document, altering 
them after it's signed would invalidate the signature. So surely that 
can't be what happens.


On the other hand, if the thing being "post-processed" is a 
tbsCertificate rather than a signed certificate surely that can be 
created using whatever processes are convenient entirely outside the 
protected physical environment and prior to the ceremony commencing? 
At most it may be appropriate for the serial number to be chosen 
during the protected process, to assure auditors that this was random 
rather than chosen by a third party.


I guess the thing I'm seeking clarity on is whether a "temporary 
unconstrained subCA" actually exists as a signed document, even 
momentarily within the protected physical environment, and if so, how 
that could possibly be necessary. Regardless of whether that's the 
case, the proposed remedial actions are appropriate, but if there are 
sketchy "temporary" unconstrained subCAs being created (and hopefully 
destroyed) then it seems important to emphasise to other CAs that this 
is not an acceptable practice.

--
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: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

[Rob Stradling via dev-security-policy]

On 16/10/17 20:01, Matthew Hardeman via dev-security-policy wrote:

The authors of the paper on the weak RSA keys generated by Infineon TPMs and 
smart cards have published code in multiple languages / platforms that provide 
for an efficient test for weakness by way of the Infineon TPM bug.

Perhaps this should be a category of issue identified by the crt.sh engine, etc?


Hi Matt.  Yeah, I'm working on adding the ROCA check to crt.sh.


Should someone put together a ballot for incorporating this category of weak 
keys as a mandatory check before issuing certs?
 
Code for testing keys is at: https://github.com/crocs-muni/roca


It looks like the test is exceptionally easy math against the modulus of the 
public key.


--
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: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

[Rob Stradling via dev-security-policy]

On 16/10/17 23:15, Jakob Bohm via dev-security-policy wrote:


Unfortunately, as of right now, their github repository still doesn't
include the promised C/C++ implementation,


Hi Jakob.  Today I ended up rewriting the ROCA fingerprint checker in C 
(using OpenSSL BIGNUM calls) to get it working in crt.sh.  In case it's 
useful, here's a Gist:


https://gist.github.com/robstradling/f525d423c79690b72e650e2ad38a161d

Build it with -lcrypto and pipe a DER cert to STDIN.

--
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: Lack of CAA checking at Comodo

[Rob Stradling via dev-security-policy]

Hi Hanno.  Thanks for reporting this to us.  We acknowledge the problem, 
and as I mentioned at [1], we took steps to address it this morning.


We will follow-up with an incident report ASAP.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1398545#c3

On 11/09/17 15:18, Hanno Böck via dev-security-policy wrote:

Hi,

On saturday I was able to receive a certificate from comodo depsite the
subdomain having a CAA record only allowing Let's Encrypt as the CA.
Here's the cert:
https://crt.sh/?id=207082245

I have by now heard from multiple other people that confirmed the same.
Seems right now Comodo isn't checking CAA at all. There's also a bug in
the Mozilla bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398545

I was originally informed about the lack of CAA checking at Comodo by
Michael Kliewe from the mail provider mail.de. However that was before
CAA became mandatory. But even back then the Comodo webpage claimed that
Comodo would check CAA since at least 12 months:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/1204/1/caa-record---certification-authority-authorization

I have covered this also today in a news article for Golem.de [1]


[1]
https://www.golem.de/news/tls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html
google translate:
https://translate.google.de/translate?sl=de=en=y=_t=de=UTF-8==url=https%3A%2F%2Fwww.golem.de%2Fnews%2Ftls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html



--
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: Incident Certificate signed with SHA1 Violation BR 7.3.1

[Rob Stradling via dev-security-policy]

Hi Conny.  Are you able to post those 2 certificates to some CT logs and 
provide crt.sh links?


You've said that both certs have the same SHA-1 Fingerprint.  Are you 
sure about that?


On 06/09/17 20:38, cornelia.enke66--- via dev-security-policy wrote:

SwissSign has identified the following incident:
two Certificate signed with SHA1: Violation BR 7.3.1

1)
During an internal audit on 05.09.2017 we found out that there are two 
certificates issued after 16.01.2015 and signed with a SHA1 hash.
After the discovery of two certificates, the following actions where taken 
05.09.2017
a) a security incident was opend
b) contact the customers to revoke the two certificates
c) identify the reason for the error
d) the source of the error has been eliminated

2)
On 06.09.2017 the Icident including a description of the treatment was reported 
to the community.

3)
By identifying the error, the configuration of the software has been changed in 
such a way that the issuing of certificates with a SHA1 signature is no longer 
possible.

4)  
The following certificates were concerned:
a) CN=v05dua. pnet. ch/Email=betriebit...@post.ch/OU=IT2/O=Post CH 
AG/L=Bern/ST=BE/C=CH
Certificate Identifier: CEC009CA9554D878F118F9582749B3
SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: 
A4:9D: 05: EE
Issued: 16.01.2015
Revoked: 2017-09-05 15:37:10
b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik 
AG/L=Herisau/ST=AR/C=CH
Certificate Identifier: 743DDD4855841D256DAFBD0448D957A439DEA593D
SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: E1:96: 
A4:9D: 05: EE
Issued 02/02/2017
Revoked 2017-09-06 08:42:42:42

5)
The following reasons for misissunace have been identified:
a) the correct configuration of the customer account to prevent the issuance of 
SHA1 certificates was activated delayed.
b) a new functionality was introduced in the CA software in January 2017, which 
made it possible to reissue the certificate signed with SHA1.

6)
The additional functionality introduced in January 2017 had a weak point.
This vulnerability was only found because of the detailed error analysis 
performed by finding the certificate that was misissued.
The misissued certificates where detected by the improved quality control. No 
further measures are currently planned.

7)  
The error has been fixed. Configurative measures ensured that no more 
certificates can be signed using SHA1.

Best Regards Conny Enke


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

Incident Report - CAA misissuance (was Re: Lack of CAA checking at Comodo)

[Rob Stradling via dev-security-policy]

On 11/09/17 15:30, Rob Stradling via dev-security-policy wrote:
Hi Hanno.  Thanks for reporting this to us.  We acknowledge the problem, 
and as I mentioned at [1], we took steps to address it this morning.


We will follow-up with an incident report ASAP.


INCIDENT REPORT

We received two Problem Reports - from Hanno Böck on 9th September at 
20:10 UTC, and from Jonathan Rudenberg on 10th September at 00:08 UTC - 
each of which reported that we had misissued a certificate contrary to a 
published CAA RRset.
Jonathan reported this problem at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1398545, and in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1398545#c2 Quirin Scheitle 
provided a further misissuance report.


TRIAGING
Some Comodo staff saw these reports late on Friday 9th and began to 
discuss them over the weekend, but they were unable to confirm their 
accuracy.  Indeed, the reports appeared to them to be erroneous, because 
the logs at their disposal showed that the relevant CAA checks had been 
performed but the RRsets were empty.  Therefore, the only action taken 
at that point was to escalate the reports to the original developer of 
our CAA checking code to look at first thing Monday morning.


BACKGROUND
As you'd expect from the authors of RFC6844, we were an early adopter, 
deploying our initial CAA checking implementation 2.5 years ago.  It 
executes `dig CAA +dnssec +sigchase +trusted-key=dnssec_trusted.keys` to 
perform the DNS queries.  We chose this approach after concluding that, 
at that time, it was the least worst option available to us for checking 
DNSSEC signatures.  We deployed a specific version of BIND (9.10.1-P2) 
because testing had shown that `dig` in the next release of BIND would 
crash when trying to do DNSSEC validation.


WHAT WENT WRONG
Our ops team upgraded the servers that our CAA checking code was running 
on.  This included a very-long-awaited transition from a 32-bit to 
64-bit OS.  Rather than recompile 9.10.1-P2 for 64-bit, our ops 
engineers upgraded BIND to 9.10.5-P1.
Yesterday morning (Monday 11th), when investigating the Problem Reports, 
the original developer discovered that as a result of that BIND upgrade 
all of our calls to `dig` were returning the following response:


`Invalid option: +sigchase
Usage:  dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]

Use "dig -h" (or "dig -h | more") for complete list of options`

Unfortunately, this `dig` response was being interpreted by our CAA 
checking code as a CAA response that contained: no "issue" property, no 
"issuewild" property, no unrecognized critical properties, etc.


This problem had gone undetected due to a combination of reasons: the 
developer did not ask for BIND to be upgraded and so did not expect any 
behaviour to have changed; the ops engineers did not realize that 
upgrading BIND might cause a problem; there wasn't an automated test 
that would've detected this problem and raised an alarm; CAA RRsets are 
still fairly uncommon, so nobody noticed that we'd dropped from finding 
hardly any RRsets to finding zero RRsets; our validation staff only see 
the results of our CAA processing rather than the complete output from 
`dig`.


ACTION TAKEN TO ADDRESS THE PROBLEM
Upon discovery of the failing `dig` calls, we immediately downgraded to 
BIND 9.10.1-P2 and verified that our CAA checks were then working 
correctly.  We also purged our local cache (of recent `dig` responses) 
to ensure that the misissuance vector was completely closed.


PROBLEM CERTIFICATES
The following certificates have all been revoked:
Reported by Hanno:
https://crt.sh/?id=207082245
Reported by Jonathan:
https://crt.sh/?id=207224651
Reported by Quirin:
https://crt.sh/?id=208456003
https://crt.sh/?id=208486480
https://crt.sh/?id=208486489
https://crt.sh/?id=208486485
https://crt.sh/?id=208486495

NEW CAA CHECKING IMPLEMENTATION
Our initial CAA checking implementation, while functional, was not 
designed with our current certificate issuance volumes in mind. 
Consequently, we had been working on a new, much more scalable CAA 
checking implementation, written in Go.  We had expected to deploy this 
new implementation during Q2 2017, but work on this project was paused 
due to the uncertainties of CNAME processing that have now been resolved 
at IETF (see https://www.rfc-editor.org/errata/eid5065) and that will 
hopefully soon also be resolved at CABForum (see 
https://cabforum.org/pipermail/public/2017-August/011972.html).


DEPLOYING OUR NEW CAA CHECKING IMPLEMENTATION
Having fixed our `dig` calls we found that our system was struggling to 
process the queue of CAA checks quickly enough, and so we accelerated 
our plans to deploy our new CAA checking implementation.  This morning 
(Tuesday 12th) we verified that our new implementation does a reasonable 
job

Re: Doppelganger/tripleganger intermediate certificates

[Rob Stradling via dev-security-policy]

Hi Adriano.  Thanks for providing your incident report so promptly.

Some questions inline...

On 02/10/17 15:26, Adriano Santoni via dev-security-policy wrote:

6) Explanation about how and why the mistakes were made or bugs 
introduced, and how they avoided detection until now.


In the particular case of the generation of technically constrained 
SubCA certificates, and only in that particular case, we use a special 
procedure that operates in two phases: first, we generate a temporary 
unconstrained SubCA certificate using our core Root CA software;


Are these "temporary unconstrained SubCA certificate"s publicly trusted? 
 That is, do they have valid signatures from your "Actalis 
Authentication Root CA" (https://crt.sh/?caid=935) ?


If yes, can you confirm that you have disclosed them all to the CCADB?


Since it had been Unicredit itself to ask for regeneration of their 
SubCA certificate, on the very same day, our staff assumed that the 
first SubCA certificate would have been discarded; but apparently, due 
to some misunderstanding within Unicredit, it was mistakenly installed 
on some sites and then removed, but it probably remained online long 
enough for some crawler to detect it.


Are you suggesting that "discarding" a certificate makes it acceptable 
to reuse the same serial number in another certificate?



- revocation of the affected SubCA certificate is scheduled for Oct 4th, 
EOB.


Nit: revocation of *both* affected SubCA certificates, since they share 
the same serial number.


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

Doppelganger/tripleganger intermediate certificates

[Rob Stradling via dev-security-policy]

Several CAs have issued intermediate CA certificates with duplicate 
serial numbers.  This is a clear violation of the serial number 
uniqueness requirement of the BRs and RFC5280 4.1.2.2.  Below is a list 
of all those known to crt.sh that chain to at least 1 NSS built-in root:



Issuer: https://crt.sh/?caid=140
  Issuer O: AC Camerfirma SA CIF A82743287
 Issuer CN: Chambers of Commerce Root
Subject CN: (id=1252) AC CAMERFIRMA AAPP
(id=12625404) AC Camerfirma Express Corporate Server
  Serial #: 0d
 Certs: https://crt.sh/?id=1252
https://crt.sh/?id=12625404
  Revoked?: No


Issuer: https://crt.sh/?caid=935
  Issuer O: Actalis S.p.A./03358520967
 Issuer CN: Actalis Authentication Root CA
Subject CN: UniCredit Subordinate External
  Serial #: 3e:5d:be:44:e7:51:5a:5a
 Certs: https://crt.sh/?id=47081615
https://crt.sh/?id=147626411
  Revoked?: No


Issuer: https://crt.sh/?caid=941
  Issuer O: Atos
 Issuer CN: Atos TrustedRoot 2011
Subject CN: Atos TrustedRoot Client-CA 2011
  Serial #: 5b:6a:8e:8d:5a:86:71:8f
 Certs: https://crt.sh/?id=12725513
https://crt.sh/?id=12725727
https://crt.sh/?id=12728899
  Revoked?: No
Subject CN: Atos TrustedRoot CodeSigning-CA 2011
  Serial #: 33:45:52:39:ec:16:dd:62
 Certs: https://crt.sh/?id=18068233
https://crt.sh/?id=49643406
  Revoked?: Yes
Subject CN: Atos TrustedRoot Server-CA 2011
  Serial #: 6b:5d:91:bc:13:61:ce:75
 Certs: https://crt.sh/?id=705899
https://crt.sh/?id=18068212
  Revoked?: Yes


Issuer: https://crt.sh/?caid=138
  Issuer O: SwissSign AG
 Issuer CN: SwissSign Gold CA - G2
Subject CN: AffirmTrust Networking
  Serial #: 84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9
 Certs: https://crt.sh/?id=3386
https://crt.sh/?id=1991456
  Revoked?: No
Subject CN: Trend Micro Gold CA
  Serial #: 49:e1:33:6e:94:e5:b6:a5:2d:a9:6e:d4:8a:e2:76
 Certs: https://crt.sh/?id=12629343
https://crt.sh/?id=198226194
  Revoked?: Yes


Issuer: https://crt.sh/?caid=656
  Issuer O: Trustwave Holdings, Inc.
 Issuer CN: Trustwave Organization Issuing CA, Level 2
Subject CN: Trustwave Enterprise CA
  Serial #: 6b:49:d2:04
 Certs: https://crt.sh/?id=12624965
https://crt.sh/?id=12629351
  Revoked?: Issuer cert revoked (https://crt.sh/?id=95565)

Issuer: https://crt.sh/?caid=12391
  Issuer O: Trustwave Holdings, Inc.
 Issuer CN: Trustwave Enterprise CA
Subject CN: Trustwave Enterprise VPN CA
  Serial #: 41:90:ae:5d
 Certs: https://crt.sh/?id=12625419
https://crt.sh/?id=12629788
  Revoked?: Issuer's issuer cert revoked (https://crt.sh/?id=95565)


Issuer: https://crt.sh/?caid=1450
  Issuer O: WoSign CA Limited
 Issuer CN: CA 沃通根证书
Subject CN: 中国湖南 EV 服务器证书
  Serial #: 44:80:7b:20:7c:f2:05:2e:8d:34:11:77:02:66:d2:95
 Certs: https://crt.sh/?id=7841622
https://crt.sh/?id=9318242
  Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots 
still in NSS)

Subject CN: CA 沃通 EV 代码签名证书
  Serial #: 3a:de:c4:02:27:0b:f4:ee:9e:89:2c:c6:5e:0a:da:21
 Certs: https://crt.sh/?id=12728869
https://crt.sh/?id=12729072
  Revoked?: No (x-certs from StartCom not yet in OneCRL; StartCom roots 
still in NSS)



P.S. Here's the query I ran on crt.sh to find these certs:

select count(*), min(c.id), max(c.id), c.issuer_ca_id, 
encode(x509_serialNumber(c.certificate), 'hex') from certificate c, 
ca_certificate cac where c.id=cac.certificate_id and exists (select 1 
from ca_trust_purpose ctp where ctp.ca_id = c.issuer_ca_id and 
ctp.trust_context_id=5) group by c.issuer_ca_id, 
x509_serialNumber(c.certificate) having count(*) > 1 order by count(*) desc;


--
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: TBSCertificate / Certificate Linting APIs

[Rob Stradling via dev-security-policy]

Anyone who's using or planning to use these crt.sh APIs might like to 
know that I've enhanced them to also run the ZLint certificate linter 
(from https://github.com/zmap/zlint).


On 18/08/17 17:39, Rob Stradling via dev-security-policy wrote:
In response to the many BR compliance issues [1] that have been reported 
here this month, there's been renewed interest in certificate linting. 
Various CAs have said that they're considering plugging one or more 
certificate linters into their certificate issuance processes.


Some CAs, such as those with high certificate issuance rates, will 
probably prefer to run their own local installations of their chosen 
linter(s).  However, other CAs may prefer to use an external linting 
service.


One current problem is that neither certlint/cablint nor x509lint is 
suitable for use prior to certificate issuance - that is, they're only 
currently capable of operating on certificates, not TBSCertificates.


With all of the above in mind, I've created a new crt.sh API that can be 
used to lint TBSCertificates.  It uses crt.sh's existing linting 
capabilities, which are provided by cablint and x509lint.  To workaround 
the limitation described in the previous paragraph, it wraps the 
TBSCertificate into a certificate structure by appending a dummy signature.


I'm planning to integrate this crt.sh API into Comodo's issuance 
processes ASAP.  Other CAs are also welcome to use it (although please 
chat to me first if you're a high-volume issuer!)


API URL: https://crt.sh/linttbscert

To use it, either (1) browse to that URL, paste a base64-encoded 
TBSCertificate, then click "Lint TBSCertificate", or (2) simulate that 
button click by POSTing a URL-encoded "b64tbscert" parameter to the same 
URL.


The API response is tab-separated text, with one line per "issue".  Each 
line contains three items:

   LinterSeverityDescription


P.S. I've also created an equivalent linting API for certificates: 
https://crt.sh/lintcert



[1] https://wiki.mozilla.org/CA/Incident_Dashboard#Open_CA_Compliance_Bugs


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

ROCA fingerprints found on crt.sh (was Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards)

[Rob Stradling via dev-security-policy]

I've completed a full scan of the crt.sh DB, which found 171 certs with 
ROCA fingerprints.


The list is at https://misissued.com/batch/28/

Many of these are Qualified/EUTL certs rather than anything to do with 
the WebPKI.  Only about half of them chain to roots that are trusted by NSS.


On 17/10/17 14:49, Rob Stradling via dev-security-policy wrote:

On 16/10/17 23:15, Jakob Bohm via dev-security-policy wrote:


Unfortunately, as of right now, their github repository still doesn't
include the promised C/C++ implementation,


Hi Jakob.  Today I ended up rewriting the ROCA fingerprint checker in C 
(using OpenSSL BIGNUM calls) to get it working in crt.sh.  In case it's 
useful, here's a Gist:


https://gist.github.com/robstradling/f525d423c79690b72e650e2ad38a161d

Build it with -lcrypto and pipe a DER cert to STDIN.


--
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: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names

[Rob Stradling via dev-security-policy]

On 24/11/17 12:25, Gervase Markham via dev-security-policy wrote:

On 24/11/17 11:37, Rob Stradling wrote:

When issuing a "single domain" certificate to (for example)
www.example.com or *.example.com, it's fairly common practice for CAs to
also include in the certificate a SAN.dNSName for the "base domain"
(e.g., example.com).  (Similarly, if the certificate request is for
example.com, some CAs will add a SAN.dNSName for www.example.com).


IMO these two processes are not at all "similar".


The similarity I was talking about is that, in both cases, the CA 
includes a dNSName in the cert that the subscriber did not explicitly 
request.



Validate example.com -> add "www.example.com": seems fine to me, and a
reasonable accommodation to a common customer desire.

Validate www.example.com -> add "example.com": not at all fine.

Validate *.example.com -> add "example.com": still dodgy IMO.


I agree.  However, my previous message in this thread concerned a 
deficiency (since fixed) in Comodo's CAA checks, not Comodo's domain 
validation checks.



I seem to remember we have come across this before, and I thought we
said it was not to be done. But perhaps that didn't make it into our
policy.


Yes, this has come up before.  It was formerly Comodo's practice to...
  "consider proof of control of 'www.' as also proving
   control of '' (except where '' is a public
   suffix)" [1]


Do we need to add it?


Now that only the "Ten Blessed Methods" of domain validation are 
permitted, I think it's clear that it's "not to be done".  (But feel 
free to "add it" if you think it would be useful).



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


--
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: On the value of EV

[Rob Stradling via dev-security-policy]

On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote:

If you look at where the HTTPS phishing certificates come from, they come
almost entirely from Let's Encrypt and Comodo.

This is perhaps the best argument in favor of distinguishing between CAs
that care about phishing and those that don't.


Tim,

We reject certificate requests for sites that are already known to 
engage in phishing, and we revoke (for all the good that does) 
certificates for sites that are subsequently discovered to have engaged 
in phishing.


IIUC, you're saying that "CAs that care about phishing" are ~100% 
successful at avoiding issuing certs to phishing sites.  If so, that's 
great!  Perhaps you could help us to become one of the "CAs that care 
about phishing" by sharing your crystal ball technology with us, so that 
we too can avoid issuing certs to sites that subsequently engage in 
phishing?


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

Fox-IT hack (was Re: On the value of EV)

[Rob Stradling via dev-security-policy]

On 15/12/17 00:18, Matthew Hardeman via dev-security-policy wrote:

On Thursday, December 14, 2017 at 5:50:40 PM UTC-6, Matthew Hardeman wrote:


Route hijacking your way to what would appear as a proper domain validation is 
practical for even a modestly resourceful adversary.  I suspect that the only 
reason more spectacular demonstration of certs issuing pursuant to such hijacks 
haven't arisen owes to ethical considerations, poor overlap of those with the 
network interconnection experience and the CA DV practices knowledge, and that 
doing it effectively means doing it in a well documented way -- ringing a bell 
you can not unring.


So when I wrote the above, I had not yet seen this (just published):

https://twitter.com/matthew_d_green/status/941460537724080128


FWIW, this is the cert for clientportal.fox-it.com that was used in this 
attack:

https://crt.sh/?id=278968925

We issued this cert in accordance with the BRs, the Mozilla Root Store 
Policy, our CPS, etc.  Domain control was validated via an email 
challenge with hostmas...@fox-it.com.  We revoked this certificate as 
soon as we were informed that the DNS records had been compromised.



I have lots of ideas on how to help make DV more resilient against this, though 
they have various costs of complexity, infrastructure, and time.


--
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: Incident report - ROCA fingerprints in certificates issued by Comodo CA (was Re: RSA key generation vulnerability in Infineon firmware)

[Rob Stradling via dev-security-policy]

On 09/11/17 13:09, Rob Stradling via dev-security-policy wrote:

On 06/11/17 22:26, Rob Stradling via dev-security-policy wrote:

On Monday 6th November, we scanned the certificates that we'd issued 
between 20th October and 5th November.  8 further server 
authentication certificates were found, all for subdomains of the same 
registered domain.  We will get these revoked and then post the details.


The 8 further certs have been revoked and submitted to some CT logs. 
They're all related to the same registered domain (kindermorgan.com). 
There's yet another SCADA reference ("OU=IT SCADA").


https://crt.id/?id=250561714
https://crt.id/?id=250561721
https://crt.id/?id=250561722
https://crt.id/?id=250561723
https://crt.id/?id=250561724
https://crt.id/?id=250561725
https://crt.id/?id=250561728
https://crt.id/?id=250561731


Sorry for the URL construction fail.  The correct URLs are:

https://crt.sh/?id=250561714
https://crt.sh/?id=250561721
https://crt.sh/?id=250561722
https://crt.sh/?id=250561723
https://crt.sh/?id=250561724
https://crt.sh/?id=250561725
https://crt.sh/?id=250561728
https://crt.sh/?id=250561731

--
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: Incident report - ROCA fingerprints in certificates issued by Comodo CA (was Re: RSA key generation vulnerability in Infineon firmware)

[Rob Stradling via dev-security-policy]

On 06/11/17 22:26, Rob Stradling via dev-security-policy wrote:

On Monday 6th November, we scanned the certificates that we'd issued 
between 20th October and 5th November.  8 further server authentication 
certificates were found, all for subdomains of the same registered 
domain.  We will get these revoked and then post the details.


The 8 further certs have been revoked and submitted to some CT logs. 
They're all related to the same registered domain (kindermorgan.com). 
There's yet another SCADA reference ("OU=IT SCADA").


https://crt.id/?id=250561714
https://crt.id/?id=250561721
https://crt.id/?id=250561722
https://crt.id/?id=250561723
https://crt.id/?id=250561724
https://crt.id/?id=250561725
https://crt.id/?id=250561728
https://crt.id/?id=250561731

--
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: DigiCert ROCA fingerprint incident report

[Rob Stradling via dev-security-policy]

I see all 7 of the certs identified in this thread in crt.sh:

Serial number: 4a907fbfc90eb043c50c9c8ace6305a1
SAN->dNSName: [www.]asik-portal.com
https://crt.sh/?id=13734110

Serial number: 8008c178d0d4cd3d79acc09f6ac132c
SAN->dNSName: *.Thameswater.co.uk
https://crt.sh/?id=249452540

Serial number: 2dab9a2d40a2f55c5d705551cf7cafe5
SAN->dNSName: *.thameswater.co.uk
https://crt.sh/?id=249452542

Serial number: 306b67f5c25ee0fd495d2be88979eb72
SAN->dNSName: *.thameswater.co.uk
https://crt.sh/?id=249452543

Serial number: 7c7b826b183093ba1e5b9850ac31d806
SAN->dNSName: *.thameswater.co.uk
https://crt.sh/?id=249452544

Serial number: 4c834767e44ecbd0cdef8e60c04dcf32
SAN->dNSName: r02s06.nex.yahoo.com
https://crt.sh/?id=153622290

Serial number: a18e9
Domain name: [www.]vwiscada.com
https://crt.sh/?id=42223834

On 07/11/17 18:27, Jeremy Rowley via dev-security-policy wrote:

I believe so – I asked that they all be logged, but I’ll need to double check 
whether it got done.

  


From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Tuesday, November 7, 2017 11:23 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert ROCA fingerprint incident report

  


Hi Jeremy,

  


Have all these certificates been submitted to CT?

  


Thanks!

Alex

  


On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy 
 > wrote:

Hey everyone,



Here's the DigiCert incident report about the ROCA fingerprints. Note that
these were all issued by Symantec (ie, before the transaction closed).



We became aware of the issue when it was posted to the mailing list.
However, at that time, the certs were not operated by DigiCert. We became
aware that DigiCert needed to take action on close (Nov 1).  At that time,
the new combined team launched an investigation to determine the impacted
certs. Six certs were identified and revoked:




4a907fbfc90eb043c50c9c8ace6305a1


8008c178d0d4cd3d79acc09f6ac132c


2dab9a2d40a2f55c5d705551cf7cafe5


306b67f5c25ee0fd495d2be88979eb72


7c7b826b183093ba1e5b9850ac31d806


4c834767e44ecbd0cdef8e60c04dcf32



These certs were all revoked around Nov 3, within 24 hours of identifying
the impacted certs at DigiCert.



Jeremy


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

OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

[Rob Stradling via dev-security-policy]

Inspired by Paul Kehrer's research a few months ago, I've added a 
continuous OCSP Monitoring feature to crt.sh:


https://crt.sh/ocsp-responders

This page shows the latest results of 3 OCSP checks (performed hourly) 
against each CA / Responder URL that crt.sh has ever encountered:

  1. a GET request for an unexpired certificate.
  2. a POST request for an unexpired certificate.
  3. a POST request for a randomly-generated serial number.

The results can be sorted and filtered in various ways: try editing the 
form at the top of the page and then clicking "Update"; or try clicking 
a value in any of the "Response" columns.


The "B" (for "Bytes") column lists the size of each HTTP response. 
Click on any of these values and you'll see the actual OCSP response 
that crt.sh saw; each OCSP response can be viewed as a hex dump, ASN.1 
dump, or in the text form used by "openssl ocsp -resp_text".


There are many well behaved Responders, but there's also a wealth of 
interesting misbehaviours to explore!


Some example reports:

1. CAs / Responder URLs that are in scope for, but violate, the BR 
prohibition on returning a signed a "Good" response for a random serial 
number, and are also in scope for Mozilla's consideration:

https://crt.sh/ocsp-responders?trustedExclude=constrained%2Cexpired%2Conecrl=Mozilla=Server+Authentication=Good

2. All CAs / Responder URLs, sorted by GET response size (largest first):
https://crt.sh/ocsp-responders?dir=^=6

3. All CAs / Responder URLs, sorted by GET response time (fastest first):
https://crt.sh/ocsp-responders?dir=v=10
(No surprise that Comodo's OCSP Responders are fastest from this 
particular network perspective ;-) ).


4. All CAs / Responder URLs where 'comodo' is a substring of the 
Responder URL:

https://crt.sh/ocsp-responders?url=%25comodo%25

On 15/11/17 00:19, Paul Kehrer via dev-security-policy wrote:

Hi Ben,

DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação
Electrónica do Estado, C=PT

Downloading the issuer (https://crt.sh/?id=8949008) and then running:

openssl ocsp -issuer 8949008.crt -serial 101010101010101101010101010
-no_nonce -url http://ocsp.root.cartaodecidadao.pt/publico/ocsp -noverify

gives this response:

101010101010101101010101010: good
This Update: Nov 14 23:59:47 2017 GMT

So this does not appear to be resolved.


DN: C=PT, O=SCEE, CN=ECRaizEstado

The SCEE root for the Government of Portugal is now responding with
unknown/revoked statuses.


DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Accredited Certification Authority, CN=MULTICERT Certification Authority
002

Download https://crt.sh/?id=8642581 and run:

openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010
-no_nonce -url http://ocsp.multicert.com/ocsp -noverify

and

openssl ocsp -issuer 8642581.crt -serial 101010101010101101010101010
-no_nonce -url http://ocsp.multicert.com/procsp -noverify

and the responses are:

101010101010101101010101010: good
This Update: Nov 15 00:03:40 2017 GMT
Next Update: Nov 15 00:03:40 2017 GMT

101010101010101101010101010: good
This Update: Nov 15 00:03:58 2017 GMT
Next Update: Nov 15 00:03:58 2017 GMT

Not fixed.


DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de
Certificação 001

(Issuer: https://crt.sh/?id=128496365)

openssl ocsp -issuer 128496365.crt -serial 1010101010101010101002101010
-no_nonce -noverify -url http://ocsp.multicert.com/ocsp

1010101010101010101002101010: good
This Update: Nov 15 00:15:45 2017 GMT
Next Update: Nov 15 00:15:45 2017 GMT

Also not fixed.

I believe Kathleen has opened bugzilla issues for these so it would
probably be good to copy this correspondence there as well.

-Paul

On November 15, 2017 at 6:50:43 AM, Ben Wilson (ben.wil...@digicert.com)
wrote:

Could someone re-check Multicert and SCEE? (See below.)  They have
indicated to us that they have now patched their OCSP responder systems.



DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação
Electrónica do Estado, C=PT

Example cert: https://crt.sh/?id=12729446

OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp



DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Accredited Certification Authority, CN=MULTICERT Certification Authority
002

Example cert: https://crt.sh/?id=117934576

OCSP URI: http://ocsp.multicert.com/ocsp

OCSP URI: http://ocsp.multicert.com/procsp



DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A.,
OU=Entidade de Certificação Credenciada, CN=MULTICERT - Entidade de
Certificação 001

Example cert: https://crt.sh/?id=11653177

OCSP URI: http://ocsp.multicert.com/ocsp



DigiCert/Government of Portugal, Sistema de Certificação Electrónica do
Estado (SCEE) / Electronic Certification System of the State:



DN: C=PT, O=SCEE, CN=ECRaizEstado

Example cert: https://crt.sh/?id=8322256

OCSP URI: http://ocsp.ecee.gov.pt


--
Rob 

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

CCADB disclosure of id-kp-emailProtection intermediates

[Rob Stradling via dev-security-policy]

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



[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained


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

[3] https://crt.sh/mozilla-disclosures#undisclosedsummary

--
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: 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: Compromised certificate for localhost.cmdm.comodo.net / Comodo ITSM

[Rob Stradling via dev-security-policy]

Hanno, thanks for reporting this to us earlier today.

Mozilla, please consider adding https://crt.sh/?id=245397620 to OneCRL. 
Thanks.


On 12/01/18 15:33, Hanno Böck via dev-security-policy wrote:

Hi,

Comodo ITSM (IT Service Management Software) runs an HTTPS server on
localhost and port 21185. The domain localhost.cmdm.comodo.net pointed
to localhost.

It is obvious that with this setup the private key is part of the
application and thus compromised. With advanced next generation key
extraction software (strings and grep) I was able to extract the
private key from the software executable.

There exist two certificates that use the same key plus two
precertificates. Only one of the certificates is still valid, the other
is expired. List:
https://crt.sh/?spkisha256=accbb60afe2d28949e21d76f298a2f20c0a24488ad0980ea31b4c0e04b952879

I reported this to Comodo earlier today and the certificate got revoked
very quickly. It was pointed out to me that Comodo ITSM was developed
by Comodo Security Solutions and that Comodo CA played no part in the
development of that software.



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

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