On 26/08/14 16:52, [email protected] wrote:
I should have included the dates. Validity period is November 2010 to
2015. Anyone at Comodo care to comment?
A colleague tried to post the following message a few days ago, but for
some reason it didn't reach the list...
"Peter has passed on details of the certificate to us at Comodo, and we
have investigated.
The certificate was issued back in November of 2010, and indeed was
issued from a root CA without an intermediate.
Comodo discontinued the practice in Q1 of 2011, and any requests to
re-issue certificates such as this will only be performed where the
certificate is reissued in a manner in-line with the CABF Baseline
Requirements.
Peter also informed us he had no reason to believe the certificate was
being misused or used fraudulently."
*From: *Jeremy Rowley
*Sent: *Tuesday, August 26, 2014 10:26 AM
If the cert was issued directly from a 2048-bit root and the issuance
date is after the effective date of the BRs, then the cert violates the
BRs and there should be an explanation.
Although notBefore != issuance date, if the notBefore date is earlier
than Feb 2013 and the root is 2048, then then there is a strong
indication that the cert was improperly issued. You could also reach
out to Comodo directly to alert them to the possibly mis-issued certificate.
Jeremy
*From:*dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org]
*On Behalf Of *[email protected]
*Sent:* Tuesday, August 26, 2014 9:10 AM
*To:* [email protected]
*Cc:* [email protected]; Peter Bowen
*Subject:* Re: Wildcard cert, no intermediate
In your rush to judgment you arrived at the wrong conclusions, Ryan. No
problem, though, as I'll recap my points in a bit. But first:
The cert in question has as its root the utn-userfirst-hardware
certificate. That appears to be a 2048-bit cert. If the wildcard cert
should not have been issued directly under the 2048-bit root should we
ask the folks at UTN (Comodo?) to explain what happened here? Are there
any controls which are missing? Just curious how other people feel about
this.
The broader purpose behind my previous email was to raise awareness
within the forum for how certain risks and vulnerabilities get combined
to attack the Internet populace. I don't think it hurts to share
different perspectives.
The salient points I hoped to get across:
* The inability to revoke endpoint certs is a major hole in Internet
security. In the case of wildcard certs the hole is that much larger
because of the damage that can be done when they get compromised. Also,
having the same cert installed on multiple servers increases the risk.
* When an admin account is compromised a lot of things can go south,
especially if the account has access to DNS, server configs, private
keys. If the account credentials can be used in some way to issue new
certs, that can be a concern.
* The scenario described is functionally similar to the NSA program
QUANTUMINSERT. If you don't have the funding nor equipment of a nation
state to back you up you might try this.
For those who are interested I would encourage you to read up on network
injection as this style of attack goes well beyond simple MITM. For
starters here's a good article, though Wired and The Intercept (and
others) have good stuff too.
https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/
I hope this perspective is helpful to people. I would like to know how
anyone feels about the cert issue, too.
*From: *Ryan Sleevi
*Sent: *Wednesday, August 20, 2014 5:43 PM
This doesn't add any useful data to the debate, nor is it accurate.
Your original complaint is about a certificate with no intermediate. This
is permitted (pre-BR), and not (post-BR).
Your examples of "doom" that would be caused by this cert apply to all
wildcard certs. If you wish to complain about wildcard certs, you're
certainly entitled to, but it's entirely orthogonal.
_______________________________________________
dev-security-policy mailing list
[email protected]
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
