Re: Certificates with less than 64 bits of entropy

[Jakob Bohm via dev-security-policy]

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

[Kathleen Wilson via dev-security-policy]

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

[Matthew Hardeman via dev-security-policy]

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

[Kathleen Wilson via dev-security-policy]

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

[Jonathan Rudenberg via dev-security-policy]

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

[Jeremy Rowley via dev-security-policy]

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)

[identrust--- via dev-security-policy]

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)

[identrust--- via dev-security-policy]

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)

[Jonathan Rudenberg via dev-security-policy]

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

[identrust--- via dev-security-policy]

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

[Jonathan Rudenberg via dev-security-policy]

> 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

[identrust--- via dev-security-policy]

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

[Jonathan Rudenberg via dev-security-policy]

> 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

[Andrew R. Whalley via dev-security-policy]

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

[Gervase Markham via dev-security-policy]

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)

[identrust--- via dev-security-policy]

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

[Peter Miskovic via dev-security-policy]

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

[Alex Gaynor via dev-security-policy]

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

[Arno Fiedler via dev-security-policy]

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

Re: Miss-issuance: URI in dNSName SAN

[ramirommunoz--- via dev-security-policy]

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

[ramirommunoz--- via dev-security-policy]

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

[Rob Stradling via dev-security-policy]

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

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

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


It does this now :-)


Excellent.  Thanks Alex.  :-)

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

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