Re: StartCom cross-signs disclosed by Certinomis
On Thursday, 3 August 2017 02:12:18 UTC+2, Matt Palmer wrote: > On Wed, Aug 02, 2017 at 06:38:44PM -0400, Jonathan Rudenberg via > dev-security-policy wrote: > > I think the correct response is to add both intermediates to OneCRL > > immediately, especially given the historic issues with StartCom. > > +1. Also a strongly worded letter of "are you f%*king kidding me?!?" to > Certinomis. Everyone even ephemerally involved in the WebPKI should know by > now that StartCom/WoSign are viewed with deep suspicion, and blithely > signing an intermediate for them is not a smart move. > > - Matt It just means Certinomis now has to answer for the misissuance, doesn't it? I don't see the problem. They can choose to risk their own webtrust if they want to. ;-) CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
Peter Bowen writes: >Gerv's email was clear that sale to DigiCert will not impact the plan, >saying: "any change of control of some or all of Symantec's roots would not >be grounds for a renegotiation of these dates." > >So the sanctions are still intact. Ah, I phrased my question a bit unclearly, what I meant was that the existing certs, which now chain up to to-be-untrusted Symantec roots, can be moved across to trusted DigiCert roots and continue as before. I'm assuming that was the intent of exercise, that it's business as usual, just the name has changed. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
On Wed, Aug 2, 2017 at 8:10 PM, Peter Gutmann via dev-security-policy wrote: > Jeremy Rowley via dev-security-policy > writes: > >>Today, DigiCert and Symantec announced that DigiCert is acquiring the >>Symantec CA assets, including the infrastructure, personnel, roots, and >>platforms. > > I realise this is a bit off-topic for the list but someone has to bring up the > elephant in the room: How does this affect the Google vs. Symantec situation? > Is it pure coincidence that Symantec now re-emerges as DigiCert, presumably > avoiding the sanctions since now things will chain up to DigiCert roots? Peter, On topic for this list is Mozilla policy. Gerv's email was clear that sale to DigiCert will not impact the plan, saying: "any change of control of some or all of Symantec's roots would not be grounds for a renegotiation of these dates." So the sanctions are still intact. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
Jeremy Rowley via dev-security-policy writes: >Today, DigiCert and Symantec announced that DigiCert is acquiring the >Symantec CA assets, including the infrastructure, personnel, roots, and >platforms. I realise this is a bit off-topic for the list but someone has to bring up the elephant in the room: How does this affect the Google vs. Symantec situation? Is it pure coincidence that Symantec now re-emerges as DigiCert, presumably avoiding the sanctions since now things will chain up to DigiCert roots? Just curious here, this seems like a bit too much of a coincidence. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert-Symantec Announcement
* Will there be other players in Symantec's SubCA plan or is DigiCert the only one? [DC] Only DigiCert. * Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase certs that chain up through the new "DigiCert SubCA" to any of the Symantec roots? I hope that, for issues that may arise under the new system, there is sufficient time to identify and resolve them prior to the 2017-12-01 deadline. [DC] Not yet. That’s an ongoing discussion. * I think the idea of a smart segregation plan for the roots and intermediates is a must-have. Such a plan should factor in the clientele who are using the different roots and the environments in which they operate. Given how important the "ubiquitous roots" are, I would hope to see community involvement and "sign-off", if you will. [DC] Okay. We plan to update the community as things solidify. * I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks. [DC] I’ll leave that open to the community discussion, although anything sooner than the current deadlines might not have as satisfactory results as the current proposal. Finally, when I went to read the DigiCert blog post, I noticed that John Merrill's link for the agreement announcement was a dud. I don't know why but I really don't care either. I think it serves as a reminder that mistakes are going to be made during this process so it's best to make allowances for that in the plans going forward. That, and attention to detail is important. [DC] Egg on my face there. Thanks for finding that. We’re getting it updated. 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: DigiCert-Symantec Announcement
This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the way.Some thoughts:* Will there be other players in Symantec's SubCA plan or is DigiCert the only one?* Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase certs that chain up through the new "DigiCert SubCA" to any of the Symantec roots? I hope that, for issues that may arise under the new system, there is sufficient time to identify and resolve them prior to the 2017-12-01 deadline.* I think the idea of a smart segregation plan for the roots and intermediates is a must-have. Such a plan should factor in the clientele who are using the different roots and the environments in which they operate. Given how important the "ubiquitous roots" are, I would hope to see community involvement and "sign-off", if you will.* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.Finally, when I went to read the DigiCert blog post, I noticed that John Merrill's link for the agreement announcement was a dud. I don't know why but I really don't care either. I think it serves as a reminder that mistakes are going to be made during this process so it's best to make allowances for that in the plans going forward. That, and attention to detail is important.Thanks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy wrote: > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, and > platforms. At the same time, DigiCert signed a Sub CA agreement wherein we > will validate and issue all Symantec certs as of Dec 1, 2017. We are > committed to meeting the Mozilla and Google plans in transitioning away from > the Symantec infrastructure. The deal is expected to close near the end of > the year, after which we will be solely responsible for operation of the CA. > From there, we will migrate customers and systems as necessary to > consolidate platforms and operations while continuing to run all issuance > and validation through DigiCert. We will post updates and plans to the > community as things change and progress. > > Thanks a ton for any thoughts you offer. Jeremy, A while ago I put together a list of all the certificates that are or were included in trust stores that were known to be owned by Symantec or companies that Symantec acquired. The list is in Google Sheets at https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdRDGFuGehdzcvo8/edit?usp=sharing Can you confirm that DigiCert will be "solely responsible for operation" of all of these CAs once the deal closes? Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
On Wed, Aug 02, 2017 at 06:38:44PM -0400, Jonathan Rudenberg via dev-security-policy wrote: > I think the correct response is to add both intermediates to OneCRL > immediately, especially given the historic issues with StartCom. +1. Also a strongly worded letter of "are you f%*king kidding me?!?" to Certinomis. Everyone even ephemerally involved in the WebPKI should know by now that StartCom/WoSign are viewed with deep suspicion, and blithely signing an intermediate for them is not a smart move. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
Jonathan, Thank you for bringing this to our attention. I have filed two bugs... 1) https://bugzilla.mozilla.org/show_bug.cgi?id=1386891 Certinomis: Cross-signing of StartCom intermediate certs, and delay in reporting it in CCADB 2) https://bugzilla.mozilla.org/show_bug.cgi?id=1386894 Add "StartCom BR SSL ICA” and "StartCom EV SSL ICA” intermediate certs to OneCRL We will look into this further, and will appreciate any further relevant information. I will also appreciate explanation from Certinomis and StartCom. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert-Symantec Announcement
Hey Nick - I plan to include all relevant OIDs in the cert. I figured that way relying parties understand the total risk associated with verification of the certificate, even if they don't know exactly the methods tied to each listed domain. If a method is eventually deemed less desirable (*cough* domain authorization letters *cough*), then the entire cert would need to be replaced anyway to reflect deprecation of that method. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Nick Lamb via dev-security-policy Sent: Wednesday, August 2, 2017 4:57 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On the use of OIDs to signify the Blessed Method used for validation I thought it can't hurt to mention the first obstacle for this idea which occurred to me in respect of Let's Encrypt (and more generally any CA importing ACME I think) Suppose an applicant asks for www.example.com, images.example.com and www.example.org. They demonstrate control over www.example.com using files in .well-known/ (sorry I'm writing this on my phone in a hotel room, don't have BR section numbers in front of me) but use DNS to show control over www.example.org... Which OID goes in this certificate? Both of them? There are arbitrarily more complicated examples along these lines, all worth a bit of thought before setting off I think. ___ 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: DigiCert-Symantec Announcement
Thanks Kathleen. We already offer short-lived certs (anywhere from 8 hours up), but they are not issued off a dedicated intermediate. It's a great suggestion, and we'll add it to the DigiCert plan. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson via dev-security-policy Sent: Wednesday, August 2, 2017 4:07 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote: > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, > and platforms. At the same time, DigiCert signed a Sub CA agreement > wherein we will validate and issue all Symantec certs as of Dec 1, 2017. Thanks for posting this information here. Pointer to DigiCert's blog: https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security- business/ > Two things I can say we plan on doing (following closing) to address > concerns are: > > a.We plan to segregate certs by type on each root. Going forward, we > will issue all SSL certs from a root while client and email come from > different roots. I would like to see all CAs move in this direction. > We also plan on limiting the number of organizations on each issuing > CA. We hope this will help address the "too big to fail" issue seen > with Symantec. By segregating end entities into roots and sub CAs, > the browsers can add affected Sub CAs to their CRL lists quickly and > without impacting the entire ecosystem. This plan is very much in > flux, and we'd love to hear additional recommendations. I greatly appreciate your consideration in this area! Perhaps there can be different subCAs for large organizations versus smaller/individual site operators (that might be covered as different brands). Of course, I'm always in favor of technically-constrained subCAs for the large organizations. And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL certs, similar to Let's Encrypt? > b.Another thing we are doing is adding a validation OID to all of our > certificates that identifies which of the BR methods were used to > issue the cert. This way the entire community can readily identify > which method was used when issuing a cert and take action if a method > is deemed weak or insufficient. We think this is a huge improvement > over the existing landscape, and I'm very excited to see that OID rolled out. I would like to see all CAs move in this direction as well. Looks like you are going to be very busy! :-) Thanks, and good luck! Kathleen ___ 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: DigiCert-Symantec Announcement
On the use of OIDs to signify the Blessed Method used for validation I thought it can't hurt to mention the first obstacle for this idea which occurred to me in respect of Let's Encrypt (and more generally any CA importing ACME I think) Suppose an applicant asks for www.example.com, images.example.com and www.example.org. They demonstrate control over www.example.com using files in .well-known/ (sorry I'm writing this on my phone in a hotel room, don't have BR section numbers in front of me) but use DNS to show control over www.example.org... Which OID goes in this certificate? Both of them? There are arbitrarily more complicated examples along these lines, all worth a bit of thought before setting off I think. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
StartCom cross-signs disclosed by Certinomis
Two certificates were disclosed by Certinomis in the CCADB today: - https://crt.sh/?q=F6044A7B147C26BABAB17C5189A09BE781919E95E26F8014D6A8B9880A6BABED - https://crt.sh/?q=6D9A258172F5CD1BDFF447EF64F9A9593070F4ACCBFD07465E4A7CBD205A5CFC These certificates are cross-signs of StartCom’s "StartCom BR SSL ICA” and "StartCom EV SSL ICA” intermediates. The two intermediates have issued many certificates that do not comply with the Baseline Requirements. I’ve included links to 46 of these misissued certificates at the end of this email. Additionally, the intermediates issued by Certinomis have a notBefore date of 2017-04-13, six days after the notBefore dates on the corresponding intermediates issued by "StartCom Certification Authority G3”. It is deeply concerning that these intermediates were not disclosed until 111 days after issuance, as the Mozilla policy is very clear that intermediate certificates must be disclosed within one week of creation and before any leaf or subordinate certificates are issued from the intermediate. I think the correct response is to add both intermediates to OneCRL immediately, especially given the historic issues with StartCom. Jonathan — https://crt.sh/?opt=cablint&id=135182815 https://crt.sh/?opt=cablint&id=134843670 https://crt.sh/?opt=cablint&id=134843674 https://crt.sh/?opt=cablint&id=134843685 https://crt.sh/?opt=cablint&id=134869886 https://crt.sh/?opt=cablint&id=134843694 https://crt.sh/?opt=cablint&id=134843703 https://crt.sh/?opt=cablint&id=134843707 https://crt.sh/?opt=cablint&id=138327705 https://crt.sh/?opt=cablint&id=140047773 https://crt.sh/?opt=cablint&id=137248474 https://crt.sh/?opt=cablint&id=140623429 https://crt.sh/?opt=cablint&id=139640371 https://crt.sh/?opt=cablint&id=139701126 https://crt.sh/?opt=cablint&id=140087378 https://crt.sh/?opt=cablint&id=140087671 https://crt.sh/?opt=cablint&id=146517428 https://crt.sh/?opt=cablint&id=134843674 https://crt.sh/?opt=cablint&id=157917796 https://crt.sh/?opt=cablint&id=134869886 https://crt.sh/?opt=cablint&id=179453898 https://crt.sh/?opt=cablint&id=156959581 https://crt.sh/?opt=cablint&id=139640371 https://crt.sh/?opt=cablint&id=137248474 https://crt.sh/?opt=cablint&id=153410888 https://crt.sh/?opt=cablint&id=155895466 https://crt.sh/?opt=cablint&id=155066805 https://crt.sh/?opt=cablint&id=155035575 https://crt.sh/?opt=cablint&id=134843670 https://crt.sh/?opt=cablint&id=146484676 https://crt.sh/?opt=cablint&id=153370547 https://crt.sh/?opt=cablint&id=150133570 https://crt.sh/?opt=cablint&id=155077521 https://crt.sh/?opt=cablint&id=155358674 https://crt.sh/?opt=cablint&id=134843703 https://crt.sh/?opt=cablint&id=154267215 https://crt.sh/?opt=cablint&id=179437157 https://crt.sh/?opt=cablint&id=149445010 https://crt.sh/?opt=cablint&id=134843694 https://crt.sh/?opt=cablint&id=160150786 https://crt.sh/?opt=cablint&id=146437172 https://crt.sh/?opt=cablint&id=146437565 https://crt.sh/?opt=cablint&id=153404034 https://crt.sh/?opt=cablint&id=179425684 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote: > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, and > platforms. At the same time, DigiCert signed a Sub CA agreement wherein we > will validate and issue all Symantec certs as of Dec 1, 2017. Thanks for posting this information here. Pointer to DigiCert's blog: https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-business/ > Two things I can say we plan on doing (following closing) to address > concerns are: > > a.We plan to segregate certs by type on each root. Going forward, we > will issue all SSL certs from a root while client and email come from > different roots. I would like to see all CAs move in this direction. > We also plan on limiting the number of organizations on > each issuing CA. We hope this will help address the "too big to fail" issue > seen with Symantec. By segregating end entities into roots and sub CAs, the > browsers can add affected Sub CAs to their CRL lists quickly and without > impacting the entire ecosystem. This plan is very much in flux, and we'd > love to hear additional recommendations. I greatly appreciate your consideration in this area! Perhaps there can be different subCAs for large organizations versus smaller/individual site operators (that might be covered as different brands). Of course, I'm always in favor of technically-constrained subCAs for the large organizations. And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL certs, similar to Let's Encrypt? > b.Another thing we are doing is adding a validation OID to all of our > certificates that identifies which of the BR methods were used to issue the > cert. This way the entire community can readily identify which method was > used when issuing a cert and take action if a method is deemed weak or > insufficient. We think this is a huge improvement over the existing > landscape, and I'm very excited to see that OID rolled out. I would like to see all CAs move in this direction as well. Looks like you are going to be very busy! :-) Thanks, and good luck! Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
DigiCert-Symantec Announcement
Hi everyone, Today, DigiCert and Symantec announced that DigiCert is acquiring the Symantec CA assets, including the infrastructure, personnel, roots, and platforms. At the same time, DigiCert signed a Sub CA agreement wherein we will validate and issue all Symantec certs as of Dec 1, 2017. We are committed to meeting the Mozilla and Google plans in transitioning away from the Symantec infrastructure. The deal is expected to close near the end of the year, after which we will be solely responsible for operation of the CA. >From there, we will migrate customers and systems as necessary to consolidate platforms and operations while continuing to run all issuance and validation through DigiCert. We will post updates and plans to the community as things change and progress. I wanted to post to the Mozilla dev list to: 1. Inform the public, 2. Get community feedback about the transition and concerns, and 3. Get an update from the browsers on what this means for the plan, noting that we fully commit to the stated deadlines. We're hoping that any changes Two things I can say we plan on doing (following closing) to address concerns are: a. We plan to segregate certs by type on each root. Going forward, we will issue all SSL certs from a root while client and email come from different roots. We also plan on limiting the number of organizations on each issuing CA. We hope this will help address the "too big to fail" issue seen with Symantec. By segregating end entities into roots and sub CAs, the browsers can add affected Sub CAs to their CRL lists quickly and without impacting the entire ecosystem. This plan is very much in flux, and we'd love to hear additional recommendations. b. Another thing we are doing is adding a validation OID to all of our certificates that identifies which of the BR methods were used to issue the cert. This way the entire community can readily identify which method was used when issuing a cert and take action if a method is deemed weak or insufficient. We think this is a huge improvement over the existing landscape, and I'm very excited to see that OID rolled out. Thanks a ton for any thoughts you offer. Jeremy 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: Certificate with invalid CN and dnsName issued by certSIGN
> On Aug 2, 2017, at 12:28, Jonathan Rudenberg via dev-security-policy > wrote: > > This certificate, issued on July 27 by certSIGN, has an invalid common name > of “todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading > space): > > https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96&opt=cablint The above is not the first certificate issued by certSIGN with a leading space in a dnsName, which points to a failure in technical controls. Here is another one: https://crt.sh/?q=91782A8F1182E239D49FABA796CFDF17AFC22A0D035838FD77FDD633FC72C416&opt=cablint ___ 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
On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson wrote: > Nick, > We are in discussions with Intesa Sanpaolo about implementing/pursuing > OneCRL or a similar approach (e.g. outright revocation of the CAs). > Thanks, > Ben Is there any progress on this? To be honest I was more meaning that Mozilla (Gerv?) should just add this subCA to OneCRL and be done with it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Certificate with invalid CN and dnsName issued by certSIGN
This certificate, issued on July 27 by certSIGN, has an invalid common name of “todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading space): https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96&opt=cablint ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intermediates missing audit disclosures (Firmaprofesional)
> On Aug 2, 2017, at 12:02, Jonathan Rudenberg via dev-security-policy > wrote: > > There are still three intermediates (one issued by Firmaprofesional and two > issued by Swisscom) that are missing audit disclosures in the CCADB and do > not have a pending OneCRL revocation: > > - > https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b > (see https://bugzilla.mozilla.org/show_bug.cgi?id=1368171) > Actually it looks like I missed that the two Swisscom intermediates are only trusted for email by Mozilla, so it’s just the Firmaprofesional intermediate that is currently in scope. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Intermediates missing audit disclosures (Firmaprofesional and Swisscom)
There are still three intermediates (one issued by Firmaprofesional and two issued by Swisscom) that are missing audit disclosures in the CCADB and do not have a pending OneCRL revocation: - https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b (see https://bugzilla.mozilla.org/show_bug.cgi?id=1368171) - https://crt.sh/?sha256=5299ea42b7ee3d4422be47d0bfc64217426b57ee55a8e5465836a741c97e628a - https://crt.sh/?sha256=801c82cbc298c07f082b9d2d22a0f23427e638f94f75dee4d0e081abc9046e52 Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Undisclosed Taiwan GRCA intermediates
Two intermediates were issued by the Taiwan Government Root Certification Authority two weeks ago and have not been disclosed in CCADB: - https://crt.sh/?sha256=a423a33493b31953226df96477627dbd056756704211001b6161fb5f8299dc3a - https://crt.sh/?sha256=dd9c545d6b645c2bfbe1b6ecb60376006464e97bb1304b7978cfe83a4099b227 Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Found something I can't understand in these cerificates.
On 02/08/2017 04:28, Han Yuwei wrote: 在 2017年8月1日星期二 UTC+8下午8:47:57,Nick Lamb写道: On Tuesday, 1 August 2017 08:39:28 UTC+1, Han Yuwei wrote: 1. the CN of two cerificates are same. So it is not necessary to issue two certificates in just 2 minutes. I think the most likely explanation is the difference in signature algorithm, but it is also not uncommon for subscribers to have more than one certificate fo the same name for operational reasons, this is not prohibited although it can be useful to watch for the rate at which this happens to an issuing system as a possible sign of trouble. 2. second one used SHA1, though is consistent with BR, but first one used SHA256. It is possible that a customer ordered a certificate and then, very quickly but alas after issuance they realised they had more specific needs, the SHA-256 algorithm and the longer expiry date. Or maybe even they simply asked for the longer expiry and WoSign correctly pointed out that it would silly to use SHA-1 with the longer expiry as it was to be (and has been) distrusted by that date. 3. first one has 39 month period of validity which is very rare. Although rare this is permissible, and even, if the subscriber had a previous certificate for roughly the same name, a common business practice in order to secure customer loyalty. 4. Since they are issued so close they should be logged at CT same time but second one are too late. CT logging was not mandatory at the time, and WoSign subsequently volunteered to upload all the extant certificates in mid-2016 during Mozilla's investigation of other (serious) problems. I think these certificates are, though perhaps not entirely regular, not a sign of any problem at WoSign. Thanks for your explanation. So maybe some devices require SHA1 certificate to operate normally? This certificate was issued during the SHA-1 transition, and many website operators probably wanted to have an SHA-1 certificate in case some clients (web browsers etc.) were not yet ready. This often involved getting matching SHA-256 and SHA-1 certificates before the BR deadline, then keeping the SHA-1 certificate "in stock" in case it was needed during 2016 (when new SHA-1 web certs could no longer be issued, but could still be valid if requested in 2015). No/Little way of knowing if they ever deployed that SHA-1 certificate, either generally (for all visitors), or behind some special logic to only use it for some known-broken client types. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy