Re: Certificates with less than 64 bits of entropy
Since QuoVadis has not yet responded, let me point to a few (partial) answers already known from previous messages from QuoVadis or others: On 15/08/2017 14:53, Ryan Sleevi wrote: On Tue, Aug 15, 2017 at 4:53 AM, Stephen Davidson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Update on Siemens - Certificates with less than 64 bits of entropy The following is regarding the topic https://groups.google.com/ forum/#!topic/mozilla.dev.security.policy/vl5eq0PoJxY regarding the “Siemens Issuing CA Internet Server 2016” that is root signed by QuoVadis and independently audited and disclosed. At the time the issue was reported, Siemens agreed to immediately take the CA offline, and it remains offline pending resolution. This was reported to the listserv by me on 7/20. Siemens confirmed a bug in their internally-developed CA software which meant it was issuing TLS/SSL with 32bit serial numbers, although the serial numbers were non sequential. Siemens informed their external auditors of the situation. It was found that 1201 currently valid certificates chained to the QuoVadis root were affected. An additional 137 currently valid certificates were issued under the previous "Siemens Issuing CA Internet 2013" chained to a Digicert root, noted in an email from Ben Wilson of Digicert yesterday. In the case of the QuoVadis-chained certificates, the certificates are virtually all of one year validity with expirations balanced across the calendar months (there are a handful of two and three year certificates, similar to the Digicert-chained population). The remaining Digicert-chained certificates all expire by end of November 2017. All certificates were issued to Siemens entities and Siemens-controlled domains. Next steps Siemens has moved to accelerate the previously planned replacement of their existing inhouse CA platform with a well-known open source CA with which QuoVadis is well familiar. QuoVadis and Siemens' auditors are coordinating with Siemens to confirm that the new CA configuration meets Baseline Requirements. It is worth noting that some BR controls, particularly related to vetting, are imposed by the Siemens certificate lifecycle system which will continue to be used with the new CA. Siemens will not recommence their inhouse SSL issuance until the new CA is active and confirmed compliant. The new CA is expected to come online in the second week of September. Siemens commits to logging new SSL from that CA in Certificate Transparency. Replacement Although the Siemens PKI is centralised, the certificates are issued to a wide variety of Siemens group companies around the world and are used on both infrastructure and high traffic websites. A rushed revocation and replacement of these certificates would have a negative business impact on Siemens that they believe outweighs the risk of the lower serials entropy (particularly given that they are nonsequential). We propose that Siemens begin the early replacement of the affected certificates as soon as the new CA infrastructure is approved, with the goal of completing the task by January 31, 2018. This will include all the affected certificates (ie those chained from both the QuoVadis and Digicert roots). While Siemens acknowledges that the affected certificates should not have occurred, we point out that they will all be replaced far in advance of the September 2019 date when industry-wide the last certificates issued before the BR change (to larger serial numbers) are scheduled to expire. We request that Siemens be allowed this expanded scope to conduct an orderly replacement of the affected certificates. Many thanks, Stephen Davidson QuoVadis Stephen, Thanks for posting your update regarding Siemens. Unfortunately, however, it's lacking in many critical details necessary to take appropriate next steps. On the positive side, it is good to see that QuoVadis immediately took (and kept) the Siemens CA offline. This represents a minimum necessary step when faced with misissuance from a subordinate, and is a step expected of all CAs while they investigate the issue and its causes, to prevent future misissuance. Note that it was (obviously) Siemens that took the SubCA offline, at the request of QuoVadis. However, the assessment of what went wrong, what steps are being taken, and the risk are all deficient and, at worse, potentially demonstrate a misunderstanding of both the risk of these certificates and the purposes of these discussions. To understand an appropriate level of detail, and the set of questions that both QuoVadis and Siemens should be asking, I think a postmortem to the level of detail provided by PKIoverheid, in https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ , is a _minimum_ necessary step to take. In particular, it's useful to understand 1) Siemens has maintained it was a "bug" that caused 32-bit serial numbers. However, it's unclear from the community
Re: TrustCor root inclusion request
Thank you to everyone who has reviewed and commented on this request from TrustCor to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits. I believe that all of the questions and concerns have been addressed and resolved. Therefore, if no further concerns are raised, I intend to close this discussion and recommend approval in the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issuing certificates with non-random serial numbers
Just from the posted serial numbers, it looks almost like the high order bits may represent 32 bits of random, which is still far short of the requirement. Perhaps they intended a 48 bit sequential counter after a 32 bit random, or intended a 64 bit random followed by a 16 bit sequential counter, but failed at filling the second half of the 64 bit random space. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
Filed bug for GoDaddy: https://bugzilla.mozilla.org/show_bug.cgi?id=1391429 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
> On Aug 16, 2017, at 19:18, Kathleen Wilson via dev-security-policy >wrote: > > Bugs filed... Hi Kathleen, It looks like a bug was not created for GoDaddy about these certificates with invalid dnsNames, containing a space at the beginning of the eTLD+1: https://crt.sh/?id=93578583=cablint https://crt.sh/?id=110219638=cablint https://crt.sh/?id=20950698=cablint https://crt.sh/?id=25047430=cablint https://crt.sh/?id=108417123=cablint Additionally, I don’t believe that any communication was received from the following CAs about “double-dot” certificates[0][1] which they revoked after Rob found them and posted here (they are technically a subset of “invalid dnsNames” but the certificates were not listed in any of the threads linked in the bugs). - GoDaddy - GlobalSign - T-Systems - Symantec I will post comments on the bugs that are already open for the last three. Jonathan [0] https://misissued.com/batch/13/ [1] https://groups.google.com/d/topic/mozilla.dev.security.policy/5bpr9yBgaYo/discussion ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: O=U.S. Government for non-USG entity (IdenTrust)
Without an FQDN, I doubt they are in scope for the baseline requirements. They are in scope for the Mozilla policy. The BRs require the cert to be intended for web tls. These are not. The Mozilla policy covers client certs as well as tls. > On Aug 17, 2017, at 12:27 PM, identrust--- via dev-security-policy >wrote: > > On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote: >>> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy >>> wrote: >>> >>> I looked through the CT logs and found 15 more unexpired unrevoked >>> certificates that are trusted by NSS and appear to have the same inaccurate >>> organizationName of “U.S. Government” for a non-USG entity. >>> >>> The list is here: https://misissued.com/batch/10/ >>> >>> Can you explain why your review missed these? Are there any more in >>> addition to these 15 and previous 5? >>> >>> Jonathan >> >> After looking into this more, I’ve found that the majority of certificates >> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates >> are not BR-compliant. >> >> The issues fall into three categories: >> >> 1) Certificates with HTTPS OCSP URLs >> 2) Certificates with otherName SANs >> 3) Certificates that appear to be intended as client certificates, but have >> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root >> Policy. >> >> I’ve found 33 certificates that have one or more of these issues that are >> unexpired and unrevoked. >> >> Here is the full list: https://misissued.com/batch/11/ (note that it is a >> superset of the batch I posted earlier today) >> >> Jonathan > and also in reference to number 1 but regarding non US Government issue > certificates, here is the reply in the expected format: > Issue: Non US Government Certificates issued with o=US Government (IdenTrust) > > 1.How your CA first became aware of the problems listed below (e.g. via a > Problem Report, via the discussion in mozilla.dev.security.policy, or via > this Bugzilla Bug), and the date. > IdenTrust: Problem Reported to IdenTrust via the Mozilla Dev Security Policy > Forum on August 8, 2017 > 2.Prompt confirmation that your CA has stopped issuing TLS/SSL > certificates with the problems listed below. > IdenTrust: on August 9, IdenTrust acknowledged the issue and offered a formal > reply before the end of the business day. A formal reply was supplied to the > forum the following day August 10, 2017: > 3.Complete list of certificates that your CA finds with each of the > listed issues during the remediation process. The recommended way to handle > this is to ensure each certificate is logged to CT and then attach a CSV > file/spreadsheet of the fingerprints or crt.sh IDs, with one list per > distinct problem. > IdenTrust: On August 16, 2017 we have identified a total of 164 ACES > certificates reflecting o=US Government for non-US government entities. > 4.Summary of the problematic certificates. For each problem listed below: > number of certs, date first and last certs with that problem were issued. > IdenTrust: The date range of the ACES certificates with issue is from > 08/21/2015 to 05/12/2017 > 5.Explanation about how and why the mistakes were made, and not caught > and fixed earlier. > IdenTrust: When IdenTrust initially established the ACES SSL certificate > profile (around 2002), it was intended to apply only to US government > entities. At that time, the Organization was defined as a static value of > “U.S. Government” in our profiles. Subsequently around 2007, when > non-agencies were identified to require ACES SSL certificates under the ACES > policy, IdenTrust interpreted the policy at that time that this static value > continued to be acceptable as these entities must identify themselves as > organizations that act as relying parties affiliated with a government > program, accepting client certificates issued under the ACES program, and are > in some capacity associated with the U.S. Government programs. Once we were > notified of the problem, we consulted internally and with GSA (owner of the > ACES policy) and have determined that this interpretation needs to be updated > to align with BR requirements. As such we updated our processes and > profiles to include the Organization as the non-agencies when the FQDN owner > is not directly U.S. Government agency. > 6.List of steps your CA is taking to resolve the situation and ensure > such issuance will not be repeated in the future, accompanied with a timeline > of when your CA expects to accomplish these things. > IdenTrust: > 1.Effective August 7, 2017 the ACES SSL profile and process has been > updated to use the applicant Organization name in the Subject DN organization > field include only HTTP OCSP URLs. > 2.Other IdenTrust SSL Sub-CA’s have been
Re: O=U.S. Government for non-USG entity (IdenTrust)
On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy > >wrote: > > > > I looked through the CT logs and found 15 more unexpired unrevoked > > certificates that are trusted by NSS and appear to have the same inaccurate > > organizationName of “U.S. Government” for a non-USG entity. > > > > The list is here: https://misissued.com/batch/10/ > > > > Can you explain why your review missed these? Are there any more in > > addition to these 15 and previous 5? > > > > Jonathan > > After looking into this more, I’ve found that the majority of certificates > issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates > are not BR-compliant. > > The issues fall into three categories: > > 1) Certificates with HTTPS OCSP URLs > 2) Certificates with otherName SANs > 3) Certificates that appear to be intended as client certificates, but have > the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root > Policy. > > I’ve found 33 certificates that have one or more of these issues that are > unexpired and unrevoked. > > Here is the full list: https://misissued.com/batch/11/ (note that it is a > superset of the batch I posted earlier today) > > Jonathan and also in reference to number 1 but regarding non US Government issue certificates, here is the reply in the expected format: Issue: Non US Government Certificates issued with o=US Government (IdenTrust) 1. How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date. IdenTrust: Problem Reported to IdenTrust via the Mozilla Dev Security Policy Forum on August 8, 2017 2. Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. IdenTrust: on August 9, IdenTrust acknowledged the issue and offered a formal reply before the end of the business day. A formal reply was supplied to the forum the following day August 10, 2017: 3. Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem. IdenTrust: On August 16, 2017 we have identified a total of 164 ACES certificates reflecting o=US Government for non-US government entities. 4. Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued. IdenTrust: The date range of the ACES certificates with issue is from 08/21/2015 to 05/12/2017 5. Explanation about how and why the mistakes were made, and not caught and fixed earlier. IdenTrust: When IdenTrust initially established the ACES SSL certificate profile (around 2002), it was intended to apply only to US government entities. At that time, the Organization was defined as a static value of “U.S. Government” in our profiles. Subsequently around 2007, when non-agencies were identified to require ACES SSL certificates under the ACES policy, IdenTrust interpreted the policy at that time that this static value continued to be acceptable as these entities must identify themselves as organizations that act as relying parties affiliated with a government program, accepting client certificates issued under the ACES program, and are in some capacity associated with the U.S. Government programs. Once we were notified of the problem, we consulted internally and with GSA (owner of the ACES policy) and have determined that this interpretation needs to be updated to align with BR requirements. As such we updated our processes and profiles to include the Organization as the non-agencies when the FQDN owner is not directly U.S. Government agency. 6. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. IdenTrust: 1. Effective August 7, 2017 the ACES SSL profile and process has been updated to use the applicant Organization name in the Subject DN organization field include only HTTP OCSP URLs. 2. Other IdenTrust SSL Sub-CA’s have been examined and confirmed that this issue does not exist. 3. We have been proactively contacting clients via email notifications and phone calls inviting them to replace those certificates. As of August 17 2017 AM we have 153 ACES SSL certificates with this issue. On August 31, 2017 at the latest, we will be making a decision regarding any outstanding certificates with this issue and will post an update to the forum. ___
Re: O=U.S. Government for non-USG entity (IdenTrust)
On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy > >wrote: > > > > I looked through the CT logs and found 15 more unexpired unrevoked > > certificates that are trusted by NSS and appear to have the same inaccurate > > organizationName of “U.S. Government” for a non-USG entity. > > > > The list is here: https://misissued.com/batch/10/ > > > > Can you explain why your review missed these? Are there any more in > > addition to these 15 and previous 5? > > > > Jonathan > > After looking into this more, I’ve found that the majority of certificates > issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates > are not BR-compliant. > > The issues fall into three categories: > > 1) Certificates with HTTPS OCSP URLs > 2) Certificates with otherName SANs > 3) Certificates that appear to be intended as client certificates, but have > the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root > Policy. > > I’ve found 33 certificates that have one or more of these issues that are > unexpired and unrevoked. > > Here is the full list: https://misissued.com/batch/11/ (note that it is a > superset of the batch I posted earlier today) > > Jonathan In reference to number 1)"Certificates with HTTPS OCSP URLs" Here is IdenTust reply in the recommended format: Issue: Certificates issued with HTTPS OCSP responder URL (IdenTrust) 1. How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date. IdenTrust: Problem Reported to IdenTrust via the Mozilla Dev Security Policy Forum on August 7, 2017 2. Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. IdenTrust: IdenTrust immediately began researching the issue. In parallel, we consulted with the ACES certificate policy owners to ensure we had the right interpretation of policy requirements. Upon confirmation of the problem, we updated the relevant the certificate profile on August 7, 2017 so that future issuance of TLS/SSL certificates is free of the identified problem. 3. Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem. IdenTrust: Besides the 5 reported certificates, on August 16, 2017 we have identified another 309 ACES certificates with this issue. 4. Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued. IdenTrust: The date range of the ACES certificates with this issue is from 08/21/2015 to 07/26/2017 5. Explanation about how and why the mistakes were made, and not caught and fixed earlier. IdenTrust: IdenTrust ACES SSL Certificates have been issued by IdenTrust in accordance with the ACES certificate policy defined by U.S. General Service Administration (http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/documents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust CPS (https://secure.identrust.com/certificates/policy/aces/IdenTrust_ACES_CPS_v5.1_20161110.pdf) IdenTrust started issuing ACES SSL Certificates since 2006 using the above reference guidelines which accept either http or https as acceptable values in the AIA extension for the OCSP validation. The issue reported was not caught earlier as none of ACES SSL certificate clients or relevant Relying party(s) have reported issues validating their certificates. 6. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. IdenTrust: 1. Effective August 7, 2017 the ACES SSL profiles have been updated to include only HTTP OCSP URLs. 2. Other IdenTrust SSL Sub-CA’s have been examined and confirmed that this issue does not exist. 3. We have been proactively contacting clients via email notifications and phone calls inviting them to replace those certificates. As of August 17 2017 AM we have a 242 ACES SSL certificates with this issue and we are seeing a positive trend from clients coming forward for replacement/revocation. On August 31, 2017 at the latest, we will be making a decision regarding any outstanding certificates with this issue and will post an update to the forum. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: O=U.S. Government for non-USG entity (IdenTrust)
> On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy >wrote: > > Hello, In reference to 3)"Certificates that appear to be intended as client > certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for > the Mozilla Root Policy." > The following 6 client certificates that have been identified as server > certificates and have been flagged as non-compliant. However, these > certificates do not contain FQDN, IP Address, nor ‘TLS Web Server > Authentication’ EKU. As such in order for us to proceed with our analysis > and determine if any remediation is required, we need clarification in the > exact nature of non-compliance as it relates to Mozilla Root Policy or CAB > Forum Baseline Requirement (ideally with pointer to the specific requirement > in the corresponding documents). The Mozilla Root Store Policy section 1.1 (Scope) says: > This policy applies, as appropriate, to certificates matching any of the > following (and the CAs which control or issue them): > … > 3. End-entity certificates which have at least one valid, unrevoked chain up > to such a CA certificate through intermediate certificates which are all in > scope, such end-entity certificates having either: > - an Extended Key Usage (EKU) extension which contains one or more of > these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, > id-kp-emailProtection; or: … The six certificates linked contain the anyExtendedKeyUsage KeyPurposeId and were issued by an intermediate that is also in scope, so they are in scope for the Mozilla Root Policy and by extension the Baseline Requirements. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: O=U.S. Government for non-USG entity (IdenTrust)
On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy > >wrote: > > > > I looked through the CT logs and found 15 more unexpired unrevoked > > certificates that are trusted by NSS and appear to have the same inaccurate > > organizationName of “U.S. Government” for a non-USG entity. > > > > The list is here: https://misissued.com/batch/10/ > > > > Can you explain why your review missed these? Are there any more in > > addition to these 15 and previous 5? > > > > Jonathan > > After looking into this more, I’ve found that the majority of certificates > issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates > are not BR-compliant. > > The issues fall into three categories: > > 1) Certificates with HTTPS OCSP URLs > 2) Certificates with otherName SANs > 3) Certificates that appear to be intended as client certificates, but have > the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root > Policy. > > I’ve found 33 certificates that have one or more of these issues that are > unexpired and unrevoked. > > Here is the full list: https://misissued.com/batch/11/ (note that it is a > superset of the batch I posted earlier today) > > Jonathan Hello, In reference to 3)"Certificates that appear to be intended as client certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root Policy." The following 6 client certificates that have been identified as server certificates and have been flagged as non-compliant. However, these certificates do not contain FQDN, IP Address, nor ‘TLS Web Server Authentication’ EKU. As such in order for us to proceed with our analysis and determine if any remediation is required, we need clarification in the exact nature of non-compliance as it relates to Mozilla Root Policy or CAB Forum Baseline Requirement (ideally with pointer to the specific requirement in the corresponding documents). https://crt.sh/?id=157944459 https://crt.sh/?id=157944592 https://crt.sh/?id=157944616 https://crt.sh/?id=157944549 https://crt.sh/?id=157944611 https://crt.sh/?id=157944466 Thanks ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
> On Aug 17, 2017, at 07:19, ramirommunoz--- via dev-security-policy >wrote: > > https://crt.sh/?id=112929021=cablint > is a precertificate. You can see the CT Precertificate Poison critical > extention. The serial number of this certificate should still be added to the relevant CRL, as it is not possible to prove the non-existance of a corresponding certificate without the CT Poison extension. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued certificates - pathLenConstraint with CA:FALSE
On Wednesday, August 9, 2017 at 9:53:14 PM UTC-4, Alex Gaynor wrote: > (Whoops, accidentally originally CC'd to m.d.s originally! Original mail > was to IdenTrust) > > Hi, > > The following certificates appear to be misissued: > > https://crt.sh/?id=77893170=cablint > https://crt.sh/?id=77947625=cablint > https://crt.sh/?id=78102129=cablint > https://crt.sh/?id=92235995=cablint > https://crt.sh/?id=92235998=cablint > > All of these certificates have a pathLenConstraint value with CA:FALSE, > this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the > pathLenConstraint field unless the cA boolean is asserted and the key usage > extension asserts the keyCertSign bit. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: D1B3 ADC0 E023 8CA6 > > > > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: D1B3 ADC0 E023 8CA6 Formal reply addressing the questionnaire format: Issue pathLenConstraint with CA:False (IdenTrust) 1. How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date. IdenTrust: Problem Reported to IdenTrust via the Mozilla Dev Security Policy Forum on August 9, 2017 2. Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. IdenTrust: The issue was addressed immediately and a formal reply was supplied on to forum on August 10, 2017 3. Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem. IdenTrust: There were 5 certificates reported with this issue: https://crt.sh/?id=77893170=cablint https://crt.sh/?id=77947625=cablint https://crt.sh/?id=78102129=cablint https://crt.sh/?id=92235995=cablint https://crt.sh/?id=92235998=cablint 4. Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued. IdenTrust: Those 5 certificates were issued between Jan-16 and Feb 14, 2017. 2 of them were pre-certificates. 5. Explanation about how and why the mistakes were made, and not caught and fixed earlier. IdenTrust: IdenTrust identified this situation during a routine audit in March of 2017. The certificates (which are all internal to IdenTrust) were reissued and these that were incorrect were intended to be revoked; unfortunately the revocation did not occur. These certificates were created during the process of building a new product, which has not yet been officially launched and no additional certificates have been issued under this profile. Quarterly audits, comprised of evaluating a sampling of certificates, have been conducted; however, due to the fact that a revocation order had been issued for these certificates and we have no active production certificates for this program, no sampling was warranted. With respect to lack of follow through on the revocation in March 2017, because these certificates were not production certificates issued to actual subscribers, our standard revocation process for certificates does not appear to have been followed; rather, an informal internal emailed request was initiated and was apparently overlooked. We have addressed this internally and put remediation steps into place that will alleviate this possibility in the future. 6. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. IdenTrust: 1. The 5 certificates were revoked on August 10, 2017 2. Since March 2017 we have corrected the profiles to prevent recurrence of this issue ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New undisclosed Camerfirma intermediates
> On Aug 16, 2017, at 23:35, Aaron Wu via dev-security-policy >wrote: > > Hi Jonathan, > > Thanks for reminding! I've sent mail to POC of AC Camerfirma and these two > intermediate certs has been disclosed in CCADB now. One of these intermediates is missing audit details: https://crt.sh/?sha256=247a6d807ff164031e0eb22ca85de329a3a4e6603dbc6203f0c6e282a9c9ea84=mozilladisclosure ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TrustCor root inclusion request
Thanks Neil, I've looked over the updated CP and CPS documents and have no further comments or questions. Cheers, Andrew On Tue, Aug 15, 2017 at 12:18 PM, Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Andrew, > > SHA-1 has been removed from the TrustCor OCSP list of acceptable hash > algorithms for responder signatures. > > The minimum hash deemed acceptable now is SHA-256. We have updated the > CP/CPS in section 6.1.5 to clarify that SHA-1 will no longer be honoured as > a signature algorithm. > > Best regards, > > Neil Dunbar > TrustCor CA Administrator > > > > On 14 Aug 2017, at 20:48, Andrew Ayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > On Mon, 14 Aug 2017 20:27:05 +0100 > > Neil Dunbar via dev-security-policy > >wrote: > > > >> Note that TrustCor is capable of removing SHA-1 as a signature hash on > >> OCSP responses, if the community determines it presents risk to the > >> relying parties. However, this does raise the risk to some clients > >> that would fail to understand the signature on the response. We > >> should prefer to service as many clients as faithfully as we can while > >> remaining true to the security principles of this community. > > > > Yes, OCSP responses signed with SHA-1 do present a risk, since a > > chosen prefix attack can be performed to forge OCSP responses and even > > certificates: > > https://www.mail-archive.com/dev-security-policy@lists. > mozilla.org/msg02999.html > > > > Even if you technically constrain your OCSP responder certificates as > > required by Mozilla policy section 5.1.1, forged OCSP responses are > > still possible if you use SHA-1. That would allow attackers to use > > revoked certificates. So it would be better if you didn't use SHA-1 at > > all for OCSP responses. > > > > Thanks for your consideration of security feedback from the community. > > > > Regards, > > Andrew > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
On 15/08/17 21:24, Kathleen Wilson wrote: > Mozilla's Root Store policy says: "CAs MUST follow and be aware of > discussions in the mozilla.dev.security.policy forum, where Mozilla's > root program is coordinated." > > There is no indication about how frequently a representative of the > CA must check the m.d.s.policy discussions. And what about when a > CA's representative is on vacation? (e.g. the month of August for > many CAs) Do we really expect them to monitor m.d.s.policy while on > vacation? (I don't even monitor it myself while I'm on vacation.) Yes, indeed. That stipulation was more to prevent CAs claiming lack of awareness of issues which had been discussed at length, rather than making it so people can report issues here and count them as properly reported to the CA. There are no SLAs for CAs reviewing m.d.s.policy, although ignoring it entirely for a month would suggest to me that the absent employee should have delegated. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: O=U.S. Government for non-USG entity (IdenTrust)
On Wednesday, August 16, 2017 at 2:06:21 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 16, 2017, at 13:44, Jonathan Rudenberg via dev-security-policy > >wrote: > > > > After looking into this more, I’ve found that the majority of certificates > > issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates > > are not BR-compliant. > > If anyone is interested in looking through the expired/revoked certificates > issued by these intermediates, these two links will show all of the > certificates that are known to CT: > > https://crt.sh/?Identity=%25=718 > https://crt.sh/?Identity=%25=5738 > > After clicking on a certificate ID, you can click the “Run cablint” link on > the left to see the cablint output. > > Jonathan IdenTrust acknowledges receipt of this bug report and are working to provide the requested information ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
CA Disig revoked listed non-conforming certificate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber
Hi Arno, Tools like https://github.com/alex/ct-tools or https://github.com/grahamedgecombe/ct-submit can be used to manually submit specific certificates to CT logs. Alex On Thu, Aug 17, 2017 at 9:07 AM, Arno Fiedler via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Am Montag, 14. August 2017 18:44:59 UTC+2 schrieb Jonathan Rudenberg: > > Hi Arno and Martin, > > > > > On Aug 14, 2017, at 11:44, Arno Fiedler> wrote: > > > > > > Dear Forum, > > > > > > since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at > least 64 bits of entropy in the serial number. > > > > > > Since 01-12-2016 D-TRUST TLS certificates requested via our enterprise > platform have a serial number which includes at least 64 bits of entropy. > We informed the CA-Program Manager about the 3 Month delay in moving the > entropy from the "DNqualifier” to the “SerialNumber” via eMail on 27-10-16. > > > > Does this mean that you knew you would not be complying with Ballot 164 > / BRs 1.3.7 by the effective date of 2016-09-30? When did you realize this? > Did you receive permission for this non-compliance from the relevant > Application Software Suppliers, including Mozilla? > Answer: > We realized that there were problems with the implementation of Ballot 164 > in September 2016 and we informed the Rootstore/Browser Provider via email > on 2016-10-27 that we would be delayed until December 2016. > We believed ourselves to be compliant with Ballot 164 from 2016-12-01 when > we implemented it into our enterprise platform. However, on 2017-08-07, we > received knowledge about the case. > > > > Between 2012 and 06-07-2017 we still produced a smaller number of > certificates using our retail platform with additional entropy in the > “DNqualifier” field instead of the serial number field, because our > certified third party software was not able to handle long serial numbers > earlier. We defined this issue as minor nonconformity, because the > requirement for entropy in the certificate was fulfilled. > > > > What other issues have you defined as a "minor nonconformity"? > Answer: > We didn´t detect any other minor nonconformity. In general we work with an > accreditation scheme based on ISO 27 and EN 319 403 to implement the > requirements from Root-Policies, CA/B-Forum Guidelines, eIDAS-Regulation > and ETSI Policies, there are defined audit procedures to recognize, control > and remediate nonconformities under the supervision of the certification > audit body > > > > > On 20-07-17 Mozilla asked D-TRUST for clarification, due to the > holiday period this message reached us on 07-08-17, AF answered on 08-08-17 > and 10-08-17: “the certificate has 64 bits of entropy in the "DNqualifier" > field instead of the serial number field. Since 2012 we used this way of > adding random bits to certificates to mitigate preimage attacks. From a > security perspective the amount of Entropy in the certificate should be > reasonable”. > > > > > > On 10-08-2017 we got the information, that we issued in the Individual > Certificate Registration process a certificate with less entropy than 64 > bit, Jonathan reported “The DNqualifier appears to have a 33-bit number, > not a 64-bit number”. > > > > > > On the 11-08-2017 we defined this case as a major issue, because our > internal examinations confirmed, that just using numeric characters causes > entropy less than 64 bit. > > > > > > The review with our tool “PKI-watcher” gave the following result of > effected certificates: > > > D-TRUST SSL Class 3 CA 1 2009 (607) > > > D-TRUST SSL Class 3 CA 1 EV 2009 (63) > > > > To provide transparency, can you please add all of these certificates to > at least one CT log and post the serial numbers, certificate fingerprints, > or crt.sh IDs? > Answer: > We have implemented the CT logs into our EV production process and are > currently unaware about how to manually export specific certificates to a > log; we will publish the affected certificate serial numbers immediately > via *.csv. Please advise us about the receiver. > A new certificate – instead of “www.lbv-gis.brandenburg.de/lbvagszit” – > has been issued, the old one is revoked. > Arno > > > > > Jonathan > > ___ > 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: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber
Am Montag, 14. August 2017 18:44:59 UTC+2 schrieb Jonathan Rudenberg: > Hi Arno and Martin, > > > On Aug 14, 2017, at 11:44, Arno Fiedlerwrote: > > > > Dear Forum, > > > > since the 07-07-2017, all new issued D-TRUST TLS-Certificates have at least > > 64 bits of entropy in the serial number. > > > > Since 01-12-2016 D-TRUST TLS certificates requested via our enterprise > > platform have a serial number which includes at least 64 bits of entropy. > > We informed the CA-Program Manager about the 3 Month delay in moving the > > entropy from the "DNqualifier” to the “SerialNumber” via eMail on 27-10-16. > > Does this mean that you knew you would not be complying with Ballot 164 / BRs > 1.3.7 by the effective date of 2016-09-30? When did you realize this? Did you > receive permission for this non-compliance from the relevant Application > Software Suppliers, including Mozilla? Answer: We realized that there were problems with the implementation of Ballot 164 in September 2016 and we informed the Rootstore/Browser Provider via email on 2016-10-27 that we would be delayed until December 2016. We believed ourselves to be compliant with Ballot 164 from 2016-12-01 when we implemented it into our enterprise platform. However, on 2017-08-07, we received knowledge about the case. > > Between 2012 and 06-07-2017 we still produced a smaller number of > > certificates using our retail platform with additional entropy in the > > “DNqualifier” field instead of the serial number field, because our > > certified third party software was not able to handle long serial numbers > > earlier. We defined this issue as minor nonconformity, because the > > requirement for entropy in the certificate was fulfilled. > > What other issues have you defined as a "minor nonconformity"? Answer: We didn´t detect any other minor nonconformity. In general we work with an accreditation scheme based on ISO 27 and EN 319 403 to implement the requirements from Root-Policies, CA/B-Forum Guidelines, eIDAS-Regulation and ETSI Policies, there are defined audit procedures to recognize, control and remediate nonconformities under the supervision of the certification audit body > > > On 20-07-17 Mozilla asked D-TRUST for clarification, due to the holiday > > period this message reached us on 07-08-17, AF answered on 08-08-17 and > > 10-08-17: “the certificate has 64 bits of entropy in the "DNqualifier" > > field instead of the serial number field. Since 2012 we used this way of > > adding random bits to certificates to mitigate preimage attacks. From a > > security perspective the amount of Entropy in the certificate should be > > reasonable”. > > > > On 10-08-2017 we got the information, that we issued in the Individual > > Certificate Registration process a certificate with less entropy than 64 > > bit, Jonathan reported “The DNqualifier appears to have a 33-bit number, > > not a 64-bit number”. > > > > On the 11-08-2017 we defined this case as a major issue, because our > > internal examinations confirmed, that just using numeric characters causes > > entropy less than 64 bit. > > > > The review with our tool “PKI-watcher” gave the following result of > > effected certificates: > > D-TRUST SSL Class 3 CA 1 2009 (607) > > D-TRUST SSL Class 3 CA 1 EV 2009 (63) > > To provide transparency, can you please add all of these certificates to at > least one CT log and post the serial numbers, certificate fingerprints, or > crt.sh IDs? Answer: We have implemented the CT logs into our EV production process and are currently unaware about how to manually export specific certificates to a log; we will publish the affected certificate serial numbers immediately via *.csv. Please advise us about the receiver. A new certificate – instead of “www.lbv-gis.brandenburg.de/lbvagszit” – has been issued, the old one is revoked. Arno > > Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
El jueves, 17 de agosto de 2017, 12:26:05 (UTC+2), ramiro...@gmail.com escribió: > El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham escribió: > > On 08/08/17 14:33, Alex Gaynor wrote: > > > Following up on this thread, 8 days ago I emailed Camerfirma, I have not > > > heard back from them, nor have they taken any action. What is the > > > appropriate next step here? > > > > I have emailed the primary Point of Contact at Camerfirma to enquire as > > to what is going on. > > > > Gerv > Hi Gev and Alex > > We have been trying to contact with our customer to replace the wrong > certificate otherwise we could block our customers services. We found > difficulties to reach the right person due to the holidays period. > > We have already revoke > - https://crt.sh/?id=5129200=cablint > - https://crt.sh/?id=42531587=cablint > and we are working on > - https://crt.sh/?id=112929021=cablint > We expect to be revoked along this day > > All of then are mistakes from the request form that are not been detected by > the AR operator. > > placing "http://; or "https://; in the domain name. > > We are going to improve control over the domain name entry form and report to > the AR operators. > > Best regards https://crt.sh/?id=112929021=cablint is a precertificate. You can see the CT Precertificate Poison critical extention. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
El martes, 15 de agosto de 2017, 15:13:04 (UTC+2), Gervase Markham escribió: > On 08/08/17 14:33, Alex Gaynor wrote: > > Following up on this thread, 8 days ago I emailed Camerfirma, I have not > > heard back from them, nor have they taken any action. What is the > > appropriate next step here? > > I have emailed the primary Point of Contact at Camerfirma to enquire as > to what is going on. > > Gerv Hi Gev and Alex We have been trying to contact with our customer to replace the wrong certificate otherwise we could block our customers services. We found difficulties to reach the right person due to the holidays period. We have already revoke - https://crt.sh/?id=5129200=cablint - https://crt.sh/?id=42531587=cablint and we are working on - https://crt.sh/?id=112929021=cablint We expect to be revoked along this day All of then are mistakes from the request form that are not been detected by the AR operator. placing "http://; or "https://; in the domain name. We are going to improve control over the domain name entry form and report to the AR operators. Best regards ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bad characters in dNSNames
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