Re: SHA1 certs issued this year chaining to included roots
On 01/19/16 01:49, Charles Reiss wrote: > Via censys.io, I found a couple SHA-1 certs with notBefore dates from this > year > which chain to root CAs in Mozilla's program: [snip] and even more, from different subCAs than have come up yet: - https://crt.sh/?id=12501241&opt=cablint -- Baltimore CyberTrust Root [DigiCert] via Verizon Public SureServer CA G14-SHA1 - https://crt.sh/?id=12309564&opt=cablint -- Baltimore CyberTrust Root [DigiCert] via TI Trust Technologies Global CA - https://crt.sh/?id=12501254&opt=cablint -- RSA Security 2048 V3 via RSA Corporate CA v2 via RSA Corporate Server CA v2 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 certs issued this year chaining to included roots
On 01/26/16 20:33, Ben Wilson wrote: > The SHA1 certificate issued by Postecom.it with serial number > 35:6c:f3:ee:ae:90:77:cd:11:aa:11:ec:1d:62:fd:e5:16:b7:ef:09 has been revoked. > > Here is the corresponding CRL: > http://postecert.poste.it/postecomcs3/crl.crl How about this one? https://crt.sh/?id=12501194&opt=cablint Has/Will PosteCom scanned their logs for other misissued certificates? > Ben > > -Original Message- > From: Marco Bongiovanni [mailto:marco.bongiova...@postecom.it] > Sent: Tuesday, January 26, 2016 6:05 AM > > we communicate that we have revoked the certificate referred to > https://crt.sh/?id= > > -Original Message- > From: Ben Wilson > Sent: Monday, January 25, 2016 10:08 AM > To: 'Charles Reiss' ; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: RE: SHA1 certs issued this year chaining to included roots > > Thanks for spotting this Charles. We've reached out to Postecom.it for an > explanation and with a request that they revoke the certificate immediately > and reissue it with the proper contents. > Ben Wilson > DigiCert VP of Compliance > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On > Behalf Of Charles Reiss > Sent: Monday, January 25, 2016 1:23 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: SHA1 certs issued this year chaining to included roots > > On 01/19/16 01:49, Charles Reiss wrote: >> Via censys.io, I found a couple SHA-1 certs with notBefore dates from >> this year which chain to root CAs in Mozilla's program: > [snip] > > And here are a couple more, from different subCAs: > > - https://crt.sh/?id=12131821 -- chaining to Deutsche Telekom Root CA 2 > [T-Systems] via subCA "Shared Business CA 3" > > > - https://crt.sh/?id=12203339 -- chaining to Baltimore CyberTrust Root > (again) this time via (presumably external) subCA "Postecom CS3" > > Also, the OCSP responder for this certificate appears to use an OCSP > responder certificate for some subCA with CN=Postecom CA3 (instead of CS3). > > Even SHA-256 certificates from this subCA (e.g. > https://crt.sh/?id=12138276) appear to have an Authority Key Identifier > extension that specifies the serial number of the subCA cert instead of the > keyid: > > X509v3 Authority Key Identifier: > DirName:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > serial:07:27:52:62 > > Does this mean they couldn't be used with a SHA-256 version of the subCA > certificate? > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: HARICA Root Renewal Request
Thank you, Dimitris, for your helpful response! I appreciate the clarifications you provided. I do like that there are fairly tight controls in place as I think it will serve everyone (both HARICA CA subscribers and the wider Internet population) well.I did review version 3.3 (which is much better than the previous version!) and the clarifications you mention below all sound reasonable to me. I have no further comments on them if you will be updating the CPS accordingly. For some of the more technical points, I will provide some commentary but in a separate email. I'll try to get my comments to you soon since as I'm sure you want to move forward in this process without too much delay. Thanks again.From: Dimitris ZacharopoulosSent: Tuesday, January 26, 2016 5:58 AM Hello Peter and thank you for reviewing this request. I hope you have reviewed the DRAFT CP/CPS available from the bug 1201423 since we have done some changes after the original bug report. On 25/1/2016 6:16 μμ, Peter Kurrasch wrote: I've reviewed the CPS/CP and in general I like it but I do have some concerns. My frame of reference is two-fold: First, how large is the attack surface through which I as a bad guy might obtain a cert to use for nefarious purposes? I would rate that as "moderate". Second, how much damage can I cause with a fraudulently obtained cert and private key? I rate this as "significant" based on my understanding and interpretation of this doc. As my understanding improves I'll probably change my mind, though. One general problem I had was trying to figure out the right context, roles, and such for some of the policies stated in the doc. For example, the terms HARICA, HARICA PKI, HARI PKI, HARICA member of organization, HARICA root, subCAs and such appeared in ways that seemed confusing but maybe I am the one who's confused. In particular it wasn't always clear to me which roles would be performed by a "member organization" vs "the main" CA--and under which circumstances and how many there are likely to be. Knowing this helps me better judge the attack surface and damage potential. We will try to make these terms clearer in a future revision. For this review, please consider the following which might make things more clear: "HARICA" is the "organization" that runs, administers, manages, oversees the "HARICA PKI". HARICA Root and all subCAs are centrally managed. We searched for the term "HARI PKI" in our CP/CPS but did not get a hit. HARICA members are Greek Academic and Research Institutions signing a certain MoU, which is available at http://www.harica.gr/procedures. You may consider this as an "affiliation", as defined in section 1.6.1. HARICA members (as Institutions) have physical persons (students, faculty, staff, researchers and so on) under their "supervision". We did not find the term "the main" referring to a CA. We do have a "Central RA" that verifies identity, email ownership and control over domains. ...snip... ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: More SHA-1 certs
Same with DigiCert. This is a sub CA issued by Verizon. We've reached out to the customer to investigate why they had the issue and what they are doing to remediate. We will provide details once we receive them. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Rick Andrews Sent: Monday, February 1, 2016 11:34 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: More SHA-1 certs On Sunday, January 31, 2016 at 9:47:53 AM UTC-8, Peter Bowen wrote: > These are all in the last week > > Sub-CA under SHECA (which has applied to be in the Mozilla program) > https://crt.sh/?id=12367776&opt=cablint > > Sub-CA under DigiCert > https://crt.sh/?id=12460684&opt=cablint > > Sub-CA under Symantec > https://crt.sh/?id=12456194&opt=cablint > https://crt.sh/?id=12434313&opt=cablint The Sub-CA under Symantec is managed by one of our customers. We've reached out to them and we're investigating. More detail to follow. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: More SHA-1 certs
On Sunday, January 31, 2016 at 9:47:53 AM UTC-8, Peter Bowen wrote: > These are all in the last week > > Sub-CA under SHECA (which has applied to be in the Mozilla program) > https://crt.sh/?id=12367776&opt=cablint > > Sub-CA under DigiCert > https://crt.sh/?id=12460684&opt=cablint > > Sub-CA under Symantec > https://crt.sh/?id=12456194&opt=cablint > https://crt.sh/?id=12434313&opt=cablint The Sub-CA under Symantec is managed by one of our customers. We've reached out to them and we're investigating. More detail to follow. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Bonjour, Le jeudi 10 décembre 2015 21:01:39 UTC+1, Kathleen Wilson a écrit : > This request is to include the "ComSign Global Root CA" root > certificate, and enable the Websites and Email trust bits. This root > will eventually replace the "ComSign CA" root certificate that is > currently included in NSS, and was approved in bug #420705. [...] > * OCSP URL: http://ocsp1.comsign.co.il When sending a request to validate intermediate CA certificates (both Organizational and EV SSL) to this responder, the responder certificate signing the response is issued by Organizational CA instead of the Global Root CA. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
