Re: Pre-Incident Report - GoDaddy Serial Number Entropy

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

On Wednesday, March 13, 2019 at 9:09:35 PM UTC-4, Peter Gutmann wrote:
> Richard Moore via dev-security-policy  
> writes:
> 
> >If any other CA wants to check theirs before someone else does, then now is
> >surely the time to speak up.
> 
> I'd already asked previously whether any CA wanted to indicate publicly that
> they were compliant with BR 7.1, which zero CAs responded to (I counted them
> twice).  This means either there are very few CAs bothering with dev-security-
> policy, or they're all hunkering down and hoping it'll blow over, which given
> that they're going to be forced to potentially carry out mass revocations
> would be the game-theoretically sensible approach to take:
> 
> Option 1: Keep quiet case 1 (very likely): -> No-one notices, nothing happens.
>   Keep quite case 2 (less likely): -> Someone notices, revocation 
> issues.
> Option 2: Say something -> Revocation issues.
> 
> So keeping your head down would be the sensible/best policy.
> 
> Peter.

IdenTrust confirms compliance: We do not run EJBCA, and our certificate serial 
number entropy is greater than what is required from BR 7.1.

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

Re: Discrepancy on Address

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

On Friday, February 8, 2019 at 4:20:14 AM UTC-5, Kurt Roeckx wrote:
> On 2019-02-08 1:04, identr...@gmail.com wrote:
> > On Thursday, February 7, 2019 at 6:47:03 PM UTC-5, iden...@gmail.com wrote:
> >> On 04/04/2018 we found a discrepancy in the address values for some SSL 
> >> certificates. A formal incident Report was just posted:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1526099
> > 
> > CORRECTION: This issue was found last Monday 4/4/2019 and it this date is 
> > properly reflected in the logged bug.Sorry about this typo.
> 
> I guess the 4th of February ...
Yes, the discrepancy was on February 4, 2019.
> 
> 
> Kurt

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

Re: Discrepancy on Address

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

On Thursday, February 7, 2019 at 6:47:03 PM UTC-5, iden...@gmail.com wrote:
> On 04/04/2018 we found a discrepancy in the address values for some SSL 
> certificates. A formal incident Report was just posted: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1526099

CORRECTION: This issue was found last Monday 4/4/2019 and it this date is 
properly reflected in the logged big.Sorry about this typo.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Discrepancy on Address

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

On 04/04/2018 we found a discrepancy in the address values for some SSL 
certificates. A formal incident Report was just posted: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1526099
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

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

On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote:
> I am recommending denial of this request.
> 
> It was not uncommon for CAs to treat the .int TLD as an Internal Name, so
> I'm not going to argue this point and claim that these certificates were
> misissued because 'identrust.int' and 'identrus.int' were not registered
> domain names.
> 
> Under the assumption that these are Internal Names, none of these
> certificates were issued after the BR deadline of 1-November 2015. From
> this I would infer that Identrust was aware of the requirements. Three of
> the disclosed certificates were not expired or revoked prior to the BR
> Internal Name deadline of 1-October 2016:
> https://crt.sh/?id=7852280
> https://crt.sh/?id=882509134
> https://crt.sh/?id=882509077
> 
> This happened in spite of well documented incidents in which other CAs
> failed to revoke certificates containing Internal Names [1]. One of these
> three certificates was revoked on 22-February 2018, corresponding with the
> date Nick Hatch reported it to Identrust. Identrust did not disclose the
> incident, nor - given that the other two were never revoked - did they
> apparently perform a scan of their certificates to identify any others.
> This calls into question Identrust's ability to adhere to the BRs, their
> remediation practices, and their willingness to publicly disclose incidents.
> 
> Identrust has requested that Mozilla grant EV indication to the Commercial
> Root CA 1 - the same root involved in this incident. Identrust's actions in
> this incident are troubling and provide justification for denying the
> higher level of trust implied by EV.
> 
> - Wayne
> 
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/00gci6NII9Y/AsQHXkltDgAJ
> 
> On Mon, Oct 22, 2018 at 2:14 PM identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> > > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via
> > dev-security-policy wrote:
> > > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via
> > dev-security-policy wrote:
> > > > > > 5.Explanation about how and why the mistakes were made, and not
> > caught and
> > > > > > fixed earlier.
> > > > > >
> > > > > > IdenTrust:
> > The certificate was generated for a server within IdenTrust.
> > > > > > The certificate contained internal domain names which were not
> > reachable
> > > > > > externally.  Two domain names in the SAN (
> > Autodiscover.identrus.int and
> > > > > > Mercury.identrus.int) were included at that time.  When the
> > certificate
> > > > > > was generated, these domains were internally hosted domains.
> > > > >
> > > > > This doesn't explain why the mistakes were made, nor does it explain
> > why
> > > > > they were not caught and fixed earlier.
> > > >
> > > > IdenTrust:IdenTrust has strict procedures regarding issuance of
> > publicly
> > > > trusted website certificates.  However at the time of this certificate
> > > > issuance (2015) the procedures did allow ability to request exceptions
> > for
> > > > IdenTrust internal deployments that were not accessible externally.
> > >
> > > On what date was this exception-requesting element added to IdenTrust's
> > > procedures?
> > IdenTrust:
> > At this point we are unable to ascertain the exact date the
> > exception-requesting element was added.  We can confirm the that the
> > exception-requesting element pre-dates 2012.
> >
> > > Please share the criteria which were used to evaluate exception requests.
> > IdenTrust:
> > The criteria for the exception is  that Registration desk, upon request of
> > IdenTrust IT Staff, can request to risk management an exception to complete
> > an attempted Verification of Domain through external registrars for domain
> > name that is IdenTrust owned domain equivalent for servers that will not be
> > accessible externally.
> >
> > > How many times has the procedure for requesting an exception been used?
> > How
> > > many times has the exception been granted?  I think it would be best if
> > all
> > > certificates issued under this exception process were made public, to
> > ensure
> > > that there is full transparency around the extent to which this

Re: Identrust Commercial Root CA 1 EV Request

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

On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via 
> dev-security-policy wrote:
> > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via 
> > > dev-security-policy wrote:
> > > > 5.Explanation about how and why the mistakes were made, and not caught 
> > > > and
> > > > fixed earlier.
> > > >
> > > > IdenTrust: 
The certificate was generated for a server within IdenTrust. 
> > > > The certificate contained internal domain names which were not reachable
> > > > externally.  Two domain names in the SAN (Autodiscover.identrus.int and
> > > > Mercury.identrus.int) were included at that time.  When the certificate
> > > > was generated, these domains were internally hosted domains.
> > > 
> > > This doesn't explain why the mistakes were made, nor does it explain why
> > > they were not caught and fixed earlier.
> >
> > IdenTrust:IdenTrust has strict procedures regarding issuance of publicly
> > trusted website certificates.  However at the time of this certificate
> > issuance (2015) the procedures did allow ability to request exceptions for
> > IdenTrust internal deployments that were not accessible externally.
> 
> On what date was this exception-requesting element added to IdenTrust's
> procedures?
IdenTrust: 
At this point we are unable to ascertain the exact date the 
exception-requesting element was added.  We can confirm the that the 
exception-requesting element pre-dates 2012.

> Please share the criteria which were used to evaluate exception requests.
IdenTrust:
The criteria for the exception is  that Registration desk, upon request of 
IdenTrust IT Staff, can request to risk management an exception to complete an 
attempted Verification of Domain through external registrars for domain name 
that is IdenTrust owned domain equivalent for servers that will not be 
accessible externally.

> How many times has the procedure for requesting an exception been used?  How
> many times has the exception been granted?  I think it would be best if all
> certificates issued under this exception process were made public, to ensure
> that there is full transparency around the extent to which this exception
> process was used.
IdenTrust:
The exception request has been used on the issuance of the 13 certificates 
listed below, now in CT logs.  Please note that majority of the certificates 
listed were issued pre-2012.
https://crt.sh/?id=514746
https://crt.sh/?id=7852280
https://crt.sh/?id=882509134
https://crt.sh/?id=882509077
https://crt.sh/?id=882509158
https://crt.sh/?id=882509159
https://crt.sh/?id=882597656
https://crt.sh/?id=882509100
https://crt.sh/?id=882509154
https://crt.sh/?id=882509101
https://crt.sh/?id=882597659
https://crt.sh/?id=882509103
https://crt.sh/?id=882509147

> Finally, can you speak to why the BR requirements around internal names and
> certificate expiry dates wasn't followed in this case?
IdenTrust:
As noted the exception request procedure pre-dates 2012.  Our best 
determination is that the procedure was not updated correctly to remove the 
ability to allow the exception for internal names for IdenTrust owned domains 
on at the time BR  v1 was adopted in 2012 as it should have been.
> > However due to human error in implementation the server was made available
> > external to our network.  Also due to human error, the IT staff failed to
> > request certificate revocation when the certificate was no longer needed.
> 
> Speaking of revocation, can you explain why this certificate wasn't caught
> by the requirement to revoke all certificates containing internal names by
> 2016-10-01?
IdenTrust:
This was due to human error in interpreting the exception granted to 
certificates issued to internal names of IdenTrust owned domain equivalents on 
servers that were not supposed to be accessible externally. The following 
certificates containing internal names were not revoked as of 2016-10-01:
https://crt.sh/?id=514746
https://crt.sh/?id=7852280
https://crt.sh/?id=882509134
https://crt.sh/?id=882509077


> > Upon discovering of this misissuance on 02/22/2018, IdenTrust updated the
> > website certificate approval procedures to eliminate the ability to
> > request exceptions to the standard domain validation\verification
> > procedures.  Please note that these website issuance procedures apply to
> > all applications regardless of the TLD(s) requested in the certificate
> > application.
> 
> Correct me if I'm wrong, but does this mean that until the date you
> specified above, it was procedurally possible for IdenTrust to issu

Re: Identrust Commercial Root CA 1 EV Request

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

On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote:
> On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via 
> dev-security-policy wrote:
> > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via 
> > > dev-security-policy wrote:
> > > > 5.Explanation about how and why the mistakes were made, and not caught 
> > > > and
> > > > fixed earlier.
> > > >
> > > > IdenTrust: The certificate was generated for a server within IdenTrust. 
> > > > The certificate contained internal domain names which were not reachable
> > > > externally.  Two domain names in the SAN (Autodiscover.identrus.int and
> > > > Mercury.identrus.int) were included at that time.  When the certificate
> > > > was generated, these domains were internally hosted domains.
> > > 
> > > This doesn't explain why the mistakes were made, nor does it explain why
> > > they were not caught and fixed earlier.
> >
> > IdenTrust:IdenTrust has strict procedures regarding issuance of publicly
> > trusted website certificates.  However at the time of this certificate
> > issuance (2015) the procedures did allow ability to request exceptions for
> > IdenTrust internal deployments that were not accessible externally.
> 
> On what date was this exception-requesting element added to IdenTrust's
> procedures?
> 
> Please share the criteria which were used to evaluate exception requests.
> 
> How many times has the procedure for requesting an exception been used?  How
> many times has the exception been granted?  I think it would be best if all
> certificates issued under this exception process were made public, to ensure
> that there is full transparency around the extent to which this exception
> process was used.
> 
> Finally, can you speak to why the BR requirements around internal names and
> certificate expiry dates wasn't followed in this case?
> 
> > However due to human error in implementation the server was made available
> > external to our network.  Also due to human error, the IT staff failed to
> > request certificate revocation when the certificate was no longer needed.
> 
> Speaking of revocation, can you explain why this certificate wasn't caught
> by the requirement to revoke all certificates containing internal names by
> 2016-10-01?
> 
> > Upon discovering of this misissuance on 02/22/2018, IdenTrust updated the
> > website certificate approval procedures to eliminate the ability to
> > request exceptions to the standard domain validation\verification
> > procedures.  Please note that these website issuance procedures apply to
> > all applications regardless of the TLD(s) requested in the certificate
> > application.
> 
> Correct me if I'm wrong, but does this mean that until the date you
> specified above, it was procedurally possible for IdenTrust to issue a
> certificate for *any* domain based on the invocation of this exception? 
> Under which subsection of BR section 3.2.2.4 does IdenTrust believe this
> procedure was permitted as of the date of the procedure update?
> 
> - Matt
IdenTrust: We acknowledge the request for more information and are actively 
working on getting the necessary details to accurately respond.   We will 
respond as soon as we can.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

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

On Wednesday, October 17, 2018 at 2:02:34 PM UTC-4, Jakob Bohm wrote:
> On 17/10/2018 01:18, Matt Palmer wrote:
> > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via 
> > dev-security-policy wrote:
> >> 5.Explanation about how and why the mistakes were made, and not caught and
> >> fixed earlier.
> >>
> >> IdenTrust: The certificate was generated for a server within IdenTrust.
> >> The certificate contained internal domain names which were not reachable
> >> externally.  Two domain names in the SAN (Autodiscover.identrus.int and
> >> Mercury.identrus.int) were included at that time.  When the certificate
> >> was generated, these domains were internally hosted domains.
> > 
> > This doesn't explain why the mistakes were made, nor does it explain why
> > they were not caught and fixed earlier.
> > 
> >> 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: Post 02/22/2018, IdenTrust implemented a change in the
> >> certificate approval processes that will prevent the domain names with the
> >> .int TLD from being approved.
> > 
> > What about other non-existent TLDs?
> > 
> > - Matt
> > 
> 
> And what about real domains in the very existant .int domain (in case
> one of those requests an Identrust certificate).
> 
> ..int contains almost exclusively high value domains such as un.int,
> nato.int etc.
> 
> IndenTrust:  request with a ‘.int’ and all other TLDs, including “high value” 
> domains, are processed through our website certificate issuance procedures 
> including domain validation\verification and procedures for handling High 
> Risk Certificate Requests. 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: Identrust Commercial Root CA 1 EV Request

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

On Wednesday, October 17, 2018 at 2:02:34 PM UTC-4, Jakob Bohm wrote:
> On 17/10/2018 01:18, Matt Palmer wrote:
> > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via 
> > dev-security-policy wrote:
> >> 5.Explanation about how and why the mistakes were made, and not caught and
> >> fixed earlier.
> >>
> >> IdenTrust: The certificate was generated for a server within IdenTrust.
> >> The certificate contained internal domain names which were not reachable
> >> externally.  Two domain names in the SAN (Autodiscover.identrus.int and
> >> Mercury.identrus.int) were included at that time.  When the certificate
> >> was generated, these domains were internally hosted domains.
> > 
> > This doesn't explain why the mistakes were made, nor does it explain why
> > they were not caught and fixed earlier.
> > 
> >> 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: Post 02/22/2018, IdenTrust implemented a change in the
> >> certificate approval processes that will prevent the domain names with the
> >> .int TLD from being approved.
> > 
> > What about other non-existent TLDs?
> > 
> > - Matt
> > 
> 
> And what about real domains in the very existant .int domain (in case
> one of those requests an Identrust certificate).
> 
> ..int contains almost exclusively high value domains such as un.int,
> nato.int etc.
> 
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

IdenTrust: A request with a ‘.int’ and all other TLDs, including “high value” 
domains, are processed through our website certificate issuance procedures 
including domain validation\verification and procedures for handling High Risk 
Certificate Requests.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

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

On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer wrote:
> On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via 
> dev-security-policy wrote:
> > 5.Explanation about how and why the mistakes were made, and not caught and
> > fixed earlier.
> >
> > IdenTrust: The certificate was generated for a server within IdenTrust. 
> > The certificate contained internal domain names which were not reachable
> > externally.  Two domain names in the SAN (Autodiscover.identrus.int and
> > Mercury.identrus.int) were included at that time.  When the certificate
> > was generated, these domains were internally hosted domains.
> 
> This doesn't explain why the mistakes were made, nor does it explain why
> they were not caught and fixed earlier.
IdenTrust:IdenTrust has strict procedures regarding issuance of publicly 
trusted website certificates.  However at the time of this certificate issuance 
(2015) the procedures did allow ability to request exceptions for IdenTrust 
internal deployments that were not accessible externally.In this particular 
case, there was an exception requested by IT staff to our registration desk and 
was escalated and granted through a risk management process as the certificate 
and associated server in question was not expected to be accessible externally 
and the server was to be operational only for short duration.  However due to 
human error in implementation the server was made available external to our 
network.  Also due to human error, the IT staff failed to request certificate 
revocation when the certificate was no longer needed.
Upon discovering of this misissuance on 02/22/2018, IdenTrust updated the 
website certificate approval procedures to eliminate the ability to request 
exceptions to the standard domain validation\verification procedures.  Please 
note that these website issuance procedures apply to all applications 
regardless of the TLD(s) requested in the certificate application.  
> 
> > 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: Post 02/22/2018, IdenTrust implemented a change in the
> > certificate approval processes that will prevent the domain names with the
> > .int TLD from being approved. 
> 
> What about other non-existent TLDs?
> > - Matt
IdenTrust: Our website certificate issuance procedures (including domain 
validation\verification and procedures for handling High Risk Certificate 
Requests) apply to all requests containing any TLDs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

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

On Monday, October 15, 2018 at 7:15:26 PM UTC-4, Nick Hatch wrote:
> On February 21 2018, I reported an unexpired certificate to Identrust which 
> contained SAN entries for several invalid .INT domains: 
> 
> https://crt.sh/?id=7852280
> 
> They acknowledged and revoked the certificate in a timely manner. However, I 
> find this event particularly bothersome:
> 
> - This certificate was created for Identrust's own internal use.
> - The issue of .int being a valid TLD has been communicated and well-known 
> since 2009 [1]  
> - I don't believe Identrust has disclosed this misissuance as required.
> 
> -Nick
> 
> [1] 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/L9A67IryHu0/RzeaEgIjt48J
Mr. Hatch is correct and although IdenTrust worked to resolve this issue 
immediately and responded to him accordingly, there was an oversight on our 
part not to file the formal misissuance report more broadly to the public 
forum. With our apologies, here is that report:
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: We were made aware of this issue on 02/22/2018 from Nicholas Hatch 
via an email message to IdenTrust customer support. 

2.Prompt confirmation that your CA has stopped issuing TLS/SSL certificates 
with the problems listed below.
IdenTrust: The certificate in question was revoked on the same date, 02/22/2018

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: Only one certificate was found to have SAN containing ‘.int’ domain. 
  This certificate was issued on 5/21/2015 with cert.sh ID: 
https://crt.sh/?id=7852280. As noted in #2, this certificate was revoked on 
2/22/2018.

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:  Problematic certificates consists of only one certificate issued on 
5/21/2015 and installed on IdenTrust server.  As noted in #2, this certificate 
was revoked on 2/22/2018.

5.Explanation about how and why the mistakes were made, and not caught and 
fixed earlier.
IdenTrust: The certificate was generated for a server within IdenTrust. The 
certificate contained internal domain names which were not reachable 
externally. Two domain names in the SAN (Autodiscover.identrus.int and 
Mercury.identrus.int) were included at that time. When the certificate was 
generated, these domains were internally hosted domains. 

When the problem was identified, IdenTrust revoked the certificate and issued a 
new certificate without the Autodiscover.identrus.int and Mercury.identrus.int.

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: Post 02/22/2018, IdenTrust implemented a change in the certificate 
approval processes that will prevent the domain names with the .int TLD from 
being approved.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Identrust Commercial Root CA 1 EV Request

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

On Tuesday, September 18, 2018 at 8:53:58 PM UTC-4, Wayne Thayer wrote:
> This request is to enable EV treatment for the Identrust Commercial Root CA
> 1 as documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1339292
> 
> * BR Self Assessment is here:
> https://bugzilla.mozilla.org/attachment.cgi?id=8964414
> 
> * Summary of Information Gathered and Verified:
> https://bug1339292.bmoattachments.org/attachment.cgi?id=8965525
> 
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8473319
> 
> CP/CPS:
> ** CP:
> https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Policy_V4.1_08172018.pdf
> ** CPS:
> https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Practices_Statement_V4.1_08172018.pdf
> 
> * This root is already included with Websites and Email trust bits. EV
> treatment is requested.
> ** EV Policy OID: 2.23.140.1.1
> ** Original inclusion request:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1037590
> 
> * Test Websites:
> ** Valid: https://ev-valid.identrustssl.com/
> ** Expired: https://ev-expired.identrustssl.com/
> ** Revoked: https://ev-revoked.identrustssl.com/
> 
> * CRL URL: http://validation.identrust.com/trustidcaa52.crl
> * OCSP URL: http://commercial.ocsp.identrust.com/
> 
> * Audit: Annual audits are performed by Schellman according to the WebTrust
> for CA, BR, and EV audit criteria.
> ** WebTrust: https://cert.webtrust.org/ViewSeal?id=2331
> ** BR: https://www.cpacanada.ca/webtrustseal?sealid=2334
> ** EV: https://www.cpacanada.ca/webtrustseal?sealid=2335
> 
> I’ve reviewed the CPS, BR Self Assessment, and related information for the
> Identrust Commercial Root CA 1 EV request that is being tracked in this bug
> and have the following comments:
> 
> ==Good==
> * Identrust’s audits prior to 2016 don’t list specific roots, but this root
> appears to have been audited back to its creation in 2014.
> * In their latest BR audit statement [1], Identrust’s auditor includes an
> “Emphasis on Matters” section in which they list four BR violations
> disclosed by Identrust. All of these issues were previously known and are
> included in comments below.
> * CPS section 1.4.2 expressly prohibits the use of Identrust certificates
> for MitM.
> 
> ==Meh==
> * There are a few misissued certs documented under this root [2][3]. All
> appear to be expired or revoked.
> * Identrust was the subject of two compliance bugs last year [4][5]. Both
> have been resolved, but it was noted that Identrust was slow to respond to
> Mozilla’s questions.
> * Three intermediate certificates have been disclosed under this root, but
> the EV audit explicitly lists only the TrustID Server CA A52 as in-scope.
> The A12 intermediate is constrained by EKU to emailProtection, but the Booz
> Allen Hamilton BA CA 01 is not. The Booz Allen Hamilton BA CA 01 does
> contain a set of policy OIDs that exclude Identrust’s EV policy, but that
> does not satisfy section 3.1.2 of Mozilla policy. However, Firefox will not
> display an EV indication if the intermediate certificate’s
> certificatePolicies extension does not include either anyPolicy or the CAs
> or CABF EV policy OID, so I believe this is a problem with our policy.
> * Identrust’s CPS section 1.3.2 allow delegation of the RA function but
> doesn’t explicitly state that domain validation must be performed by
> Identrust. The CPS does state that it complies with the BRs which forbid
> delegation of domain validation.
[IdenTrust:]Agree with this comment and confirm that IdenTrust as issuing CA is 
responsible for and does handle domain name validation prior the issuance of 
any server certificate. CPS Section 1.3.2 will be updated accordingly.

> * CPS section 2.3 states that the PMA updates the CPS on an annual basis to
> include the most recent CAB Forum requirements, but Mozilla expects CPS
> updates to happen whenever required by changes to either CAB Forum
> requirements or Mozilla policy. However, both the CP and CPS have been
> updated more frequently in the past year.
[IdenTrust:]
Agree with this comment and confirm that policy documents have been updated and 
published more than once a year.  CPS section 2.3 will be updated accordingly.
> * Typo in CPS section 6.9 heading: “ENGINREERING”
[IdenTrust:]Thanks for pointing out this typo; it will be corrected in the next 
CPS version.
> ==Bad==
> * Identrust had an open compliance bug for improper encoding of 6 wildcard
> certificates [6]. Remediation for this bug included the implementation of
> pre-issuance linting by the end of Q3, more than 6 months after the issue
> was reported. Identrust also chose to wait a week before revoking all of
> the misissued certificates. This could be considered another example of
> Identrust being slow to respond, but they did confirm that pre-issuance
> linting was deployed in August, well ahead of their goal.
> * The version of the CPS that I initially reviewed 

Re: Identrust Commercial Root CA 1 EV Request

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

On Monday, September 24, 2018 at 1:09:07 PM UTC-4, Wayne Thayer wrote:
> Good point Nick. Can someone from Identrust provide more details on
> Identrust's use and implementation of validation method 3.2.2.4.10?

[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this 
method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as 
we were exploring the possibility to use it in the future but have decided to 
discard that option. This validation method will be removed for the CPS.   We 
also confirm that we have not used this validation method for any certificate 
issuance.

> - Wayne
> 
> On Sat, Sep 22, 2018 at 3:43 AM Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Tue, 18 Sep 2018 17:53:34 -0700
> > Wayne Thayer via dev-security-policy
> >  wrote:
> >
> > > * The version of the CPS that I initially reviewed (4.0) describes a
> > > number of methods of domain name validation in section 3.2.10.5 that
> > > do not appear to fully comply with the BRs. This was corrected in the
> > > current version, but one of the methods listed is BR 3.2.2.4.10,
> > > which contains a known vulnerability.
[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this 
method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as 
we were exploring the possibility to use it in the future but have decided to 
discard that option. This validation method will be removed for the CPS.   We 
also confirm that we have not used this validation method for any certificate 
issuance.

> > Since the time of the post about 3.2.2.4.10 the Let's Encrypt team (and
> > others via the relevant IETF working group?) have developed a new
> > realisation of 3.2.2.4.10 that is not vulnerable.
> >
> > Specifically tls-sni-01 and tls-sni-02 are replaced by tls-alpn-01
> > which as its name might suggest uses an ALPN TLS feature to ask a
> > remote server to show the certificate. This involves a brand new ALPN
> > sub-protocol with no other purpose. Suppliers who aren't trying to help
> > their customers get certificates have no reason to develop/
> > enable/ configure such a feature. So it becomes reasonable (unlike with
> > SNI) to assume that if the check passes, it was intended to pass by the
> > name's real owner or by their agent.
> >
> > Section 3.2.10.5 doesn't specify how Identrust's checks work, and it
> > would be desirable to have better descriptions for methods like
> > 3.2.2.4.10 that are a bit vague, but it's definitely not true that all
> > realisations of 3.2.2.4.10 are broken.
> >
> > Nick.
[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this 
method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as 
we were exploring the possibility to use it in the future but have decided to 
discard that option. This validation method will be removed for the CPS.   We 
also confirm that we have not used this validation method for any certificate 
issuance.
Marco S.
> > ___
> > 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: CAs not compliant with CAA CP/CPS requirement

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

On Friday, September 8, 2017 at 3:25:20 PM UTC-4, Andrew Ayer wrote:
> The BRs state:
> 
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or practice
> on processing CAA Records for Fully Qualified Domain Names; that policy
> shall be consistent with these Requirements. It shall clearly specify
> the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
> 'issuewild' records as permitting it to issue. The CA SHALL log all
> actions taken, if any, consistent with its processing practice."
> 
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes
> of some CAs.
> 
> At time of writing, the latest published CP/CPSes of the following CAs
> are not compliant with the above provision of the BRs:
> 
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
> 
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
> 
> DigiCert (https://www.digicert.com/legal-repository/) - Does not
> specify issuer domain names, and processing is not compliant with BRs
> ("If a CAA record exists that does not list DigiCert as an authorized
> CA, DigiCert verifies that the applicant has authorized issuance,
> despite the CAA record.")
> 
> Google Trust Services (https://pki.goog/) - Does not check CAA
> 
> Identrust (https://secure.identrust.com/certificates/policy/ts/) -
> Does not check CAA
> 
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml)
> - Does not specify issuer domain names
> 
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
> 
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
> 
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) -
> No mention of CAA
> 
> Visa (http://www.visa.com/pki/) - Does not check CAA
> 
> 
> These CAs have compliant CP/CPSes:
> 
> Entrust
> 
> GlobalSign
> 
> GoDaddy
> 
> Let's Encrypt
> 
> QuoVadis
> 
> Trustwave
> 
> 
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
> 
> Regards,
> Andrew

Updated IdenTrust TrustID CPS covering CAA record check can be found at 
https://secure.identrust.com/certificates/policy/ts/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

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

On Friday, September 8, 2017 at 5:57:44 PM UTC-4, Jeremy Rowley wrote:
> Hi Andrew, 
> 
> I'm not certain how to update the previous Mozilla response with respect to
> CAA, but we added the following as authorized CAA records:
> Digicert.com
> *.digicert
> Digicert.net.jp
> Cybertrust.net.jp
> 
> I wasn't sure if adding a wildcard to the CAA record is kosher, but I didn't
> seem anything prohibiting use of wildcard characters in CAA records.  We saw
> quite a few records similar to CAA.digiert.com during the testing and added
> this to the list.
> 
> Jeremy
> 
> 
> Jeremy
> 
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
> .org] On Behalf Of Andrew Ayer via dev-security-policy
> Sent: Friday, September 8, 2017 1:25 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: CAs not compliant with CAA CP/CPS requirement
> 
> The BRs state:
> 
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy
> and/or Certification Practice Statement (section 4.1 for CAs still
> conforming to RFC 2527) SHALL state the CA's policy or practice on
> processing CAA Records for Fully Qualified Domain Names; that policy shall
> be consistent with these Requirements. It shall clearly specify the set of
> Issuer Domain Names that the CA recognises in CAA 'issue' or 'issuewild'
> records as permitting it to issue. The CA SHALL log all actions taken, if
> any, consistent with its processing practice."
> 
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes of
> some CAs.
> 
> At time of writing, the latest published CP/CPSes of the following CAs are
> not compliant with the above provision of the BRs:
> 
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
> 
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
> 
> DigiCert (https://www.digicert.com/legal-repository/) - Does not specify
> issuer domain names, and processing is not compliant with BRs ("If a CAA
> record exists that does not list DigiCert as an authorized CA, DigiCert
> verifies that the applicant has authorized issuance, despite the CAA
> record.")
> 
> Google Trust Services (https://pki.goog/) - Does not check CAA
> 
> Identrust (https://secure.identrust.com/certificates/policy/ts/) - Does not
> check CAA
> 
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certif
> icados/es_url/index.shtml)
> - Does not specify issuer domain names
> 
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
> 
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
> 
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - No
> mention of CAA
> 
> Visa (http://www.visa.com/pki/) - Does not check CAA
> 
> 
> These CAs have compliant CP/CPSes:
> 
> Entrust
> 
> GlobalSign
> 
> GoDaddy
> 
> Let's Encrypt
> 
> QuoVadis
> 
> Trustwave
> 
> 
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
> 
> Regards,
> Andrew
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

IdenTrust confirms CAA record check has been implemented for every SSL 
certificate prior to issuance, effective September 8, 2017.
We will post updated CPS as soon as possible. Currently it is under PMA review 
and approval.
___
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 Thursday, August 31, 2017 at 11:31:48 PM UTC-4, Eric Mill wrote:
> Thank you for the continued updates, and for relaying the deadline by which
> these will be revoked.
> 
> On Thu, Aug 31, 2017 at 9:35 PM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> > > On Friday, August 18, 2017 at 7:22:06 PM UTC-4, iden...@gmail.com wrote:
> > > > On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg
> > wrote:
> > > > > > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> 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
> > > >
> > > > As an update to the reported issue of misclassification of client
> > certificates as server certificates, based on our continuing internal
> > investigations, feedback from our user community, and also taking into
> > account the feedback posted in this forum, we plan to proceed as follows:
> > > > 1.Nolater than August 31, 2017 we will discontinue new or reissuance
> > of human certificate with the anyExtendedKeyUsage extension from all
> > IdenTrust ACES CAs.
> > > > 2.We will allow continued use of the current certificates and replace
> > or let them expire through natural lifecycle because:
> > > > a. These certificates are not sever certificates
> > > > b. All certificates issued are from audited CA(s) with public
> > disclosure of audit result
> > > > c. The legacy application usage requires anyExtendedKeyUsage extension
> > at the present time though we are phasing out support of such application.
> > > > d. These certificates do not pose a security concern meriting
> > immediate revocation
> > > > e.  Replacement of these certificates will result in significant
> > negative impact on our customers.
> > >
> > > Effective August 28, 2017, IdenTrust has discontinued new issuance or
> > reissuance of human certificates with the anyExtendedKeyUsage extension
> > from all IdenTrust ACES CAs.
> >
> >
> > IdenTrust continues to work our customers in revoking/replacing ACES SSL
> > certificates with these reported issues:
> > - https for OCSP validation instead of http in AIA extension;
> > - Invalid “US Government” as o= in the SDN;
> > - Invalid OtherName in the SAN extension.
> > For those customers that have not replaced their certificates by September
> > 15, 2017, we will revoke their them.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone <https://twitter.com/konklone>

Effective Aug-31-2017 at 7:00PM MT, IdenTrust have revoked the remaining ACES 
SSL certificates with the issues reported. As of today September 1st. 2017, the 
remediation process is completed.
___
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 Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> On Friday, August 18, 2017 at 7:22:06 PM UTC-4, iden...@gmail.com wrote:
> > On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote:
> > > > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy 
> > > > <dev-security-policy@lists.mozilla.org> 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
> > 
> > As an update to the reported issue of misclassification of client 
> > certificates as server certificates, based on our continuing internal 
> > investigations, feedback from our user community, and also taking into 
> > account the feedback posted in this forum, we plan to proceed as follows:
> > 1.Nolater than August 31, 2017 we will discontinue new or reissuance of 
> > human certificate with the anyExtendedKeyUsage extension from all IdenTrust 
> > ACES CAs. 
> > 2.We will allow continued use of the current certificates and replace or 
> > let them expire through natural lifecycle because: 
> > a. These certificates are not sever certificates
> > b. All certificates issued are from audited CA(s) with public disclosure of 
> > audit result
> > c. The legacy application usage requires anyExtendedKeyUsage extension at 
> > the present time though we are phasing out support of such application.
> > d. These certificates do not pose a security concern meriting immediate 
> > revocation
> > e.  Replacement of these certificates will result in significant negative 
> > impact on our customers.
> 
> Effective August 28, 2017, IdenTrust has discontinued new issuance or 
> reissuance of human certificates with the anyExtendedKeyUsage extension from 
> all IdenTrust ACES CAs.


IdenTrust continues to work our customers in revoking/replacing ACES SSL 
certificates with these reported issues: 
- https for OCSP validation instead of http in AIA extension;
- Invalid “US Government” as o= in the SDN;
- Invalid OtherName in the SAN extension.
For those customers that have not replaced their certificates by September 15, 
2017, we will revoke their them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violations of Baseline Requirements 4.9.10

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

On Tuesday, August 29, 2017 at 9:41:07 AM UTC-4, Paul Kehrer wrote:
> I've recently completed a scan of OCSP responders with a focus on checking
> whether they are compliant with BR section 4.9.10's requirement: "Effective
> 1 August 2013, OCSP responders for CAs which are not Technically
> Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD"
> status for such certificates." This rule was put in place in the wake of
> the DigiNotar incident as an additional method of ensuring the CA is aware
> of all issuances in its infrastructure and has been a requirement for over
> 4 years now.
> 
> The scan was performed by taking the list of responders (and valid issuer
> name hash/issuer key hashes) that Andrew Ayer has aggregated and making an
> OCSP request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef".
> This serial is extremely unlikely to have been issued legitimately.
> 
> The following OCSP responders appear to be non-compliant with the BRs (they
> respond GOOD and are not listed as technically constrained by crt.sh) but
> are embedded in certificates issued in paths that chain up to trusted roots
> in the Mozilla store. I have grouped them by owner where possible and put
> notes about whether they've been contacted:
> 
> AS Sertifitseerimiskeskuse (SK)
> 
> CCADB does not list an email address. Not CC'd.
> 
> DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA,
> emailAddress=p...@sk.ee
> Example cert:
> https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f
> OCSP URI: http://ocsp.sk.ee/CA
> 
> Autoridad de Certificacion Firmaprofesional
> 
> Email sent to i...@firmaprofesional.com
> 
> DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
> Example cert:
> https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35
> OCSP URI: http://ocsp.firmaprofesional.com
> 
> DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244
> Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de
> Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068,
> CN=AC Firmaprofesional - CA1
> Example cert:
> https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796
> OCSP URI: http://ocsp.firmaprofesional.com
> 
> DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la
> Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional -
> AAPP
> Example cert:
> https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7
> OCSP URI: http://ocsp.firmaprofesional.com
> 
> CA Disig a.s.
> 
> Email sent to tspnot...@disig.sk
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service
> Example cert:
> https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2
> OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service
> Example cert:
> https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417
> OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1
> Example cert:
> https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947
> OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> 
> DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2
> Example cert:
> https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341
> OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> 
> certSIGN
> 
> Email sent to off...@certsign.ro
> 
> DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN
> Enterprise CA Class 3 G2
> Example cert:
> https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355
> OCSP URI: http://ocsp.certsign.ro
> 
> DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA
> Example cert:
> https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c
> OCSP URI: http://ocsp.certsign.ro
> 
> Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
> 
> CCADB does not list an email address. Not CC'd.
> 
> DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
> de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
> ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
> Locals de Catalunya, CN=EC-AL
> Example cert:
> https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4
> OCSP URI: http://ocsp.catcert.net
> 
> DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
> de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
> ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
> Locals de Catalunya, CN=EC-AL
> Example cert:
> https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208
> OCSP URI: http://ocsp.catcert.net
> 
> DN: 

Re: Violations of Baseline Requirements 4.9.10

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

On Tuesday, August 29, 2017 at 12:51:05 PM UTC-4, Ryan Sleevi wrote:
> On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > Symantec / GeoTrust
> >
> > CCADB does not list an email address. Not CC'd.
> >
> > DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External
> > Example cert:
> > https://crt.sh/?q=049462100743d2bcb10780e7c4eb2c
> > e1197a3f8bea7fad5ef9141f008eb1e6ca
> > OCSP URI: http://ocsp.unicredit.eu/ocsp
> 
> 
> Note: There are 7 associated certificates for this CA (
> https://crt.sh/?caid=294 )
> 
> Of those:
> 5 are issued by Symantec / GeoTrust:
>   - 1 is expired ( https://crt.sh/?id=9219 )
>   - 4 are revoked ( https://crt.sh/?id=12722071 / https://crt.sh/?id=6941850
> / https://crt.sh/?id=47086214 / https://crt.sh/?id=12165934)
> 2 are issued by Actalis
>   - 2 are technically constrained sub-CAs ( https://crt.sh/?id=147626411 /
> https://crt.sh/?id=47081615 )
> 
> As they are technically-constrained subordinate CAs, they are (presently)
> exempted from that MUST requirement.

IdenTrust acknowledge this post and will begin reviewing.
___
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 Friday, August 18, 2017 at 7:22:06 PM UTC-4, iden...@gmail.com wrote:
> On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote:
> > > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy 
> > > <dev-security-policy@lists.mozilla.org> 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
> 
> As an update to the reported issue of misclassification of client 
> certificates as server certificates, based on our continuing internal 
> investigations, feedback from our user community, and also taking into 
> account the feedback posted in this forum, we plan to proceed as follows:
> 1.Nolater than August 31, 2017 we will discontinue new or reissuance of human 
> certificate with the anyExtendedKeyUsage extension from all IdenTrust ACES 
> CAs. 
> 2.We will allow continued use of the current certificates and replace or let 
> them expire through natural lifecycle because: 
> a. These certificates are not sever certificates
> b. All certificates issued are from audited CA(s) with public disclosure of 
> audit result
> c. The legacy application usage requires anyExtendedKeyUsage extension at the 
> present time though we are phasing out support of such application.
> d. These certificates do not pose a security concern meriting immediate 
> revocation
> e.  Replacement of these certificates will result in significant negative 
> impact on our customers.

Effective August 28, 2017, IdenTrust has discontinued new issuance or 
reissuance of human certificates with the anyExtendedKeyUsage extension from 
all IdenTrust ACES CAs.
___
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 Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy 
> > <dev-security-policy@lists.mozilla.org> 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

As an update to the reported issue of misclassification of client certificates 
as server certificates, based on our continuing internal investigations, 
feedback from our user community, and also taking into account the feedback 
posted in this forum, we plan to proceed as follows:
1.Nolater than August 31, 2017 we will discontinue new or reissuance of human 
certificate with the anyExtendedKeyUsage extension from all IdenTrust ACES CAs. 
2.We will allow continued use of the current certificates and replace or let 
them expire through natural lifecycle because: 
a. These certificates are not sever certificates
b. All certificates issued are from audited CA(s) with public disclosure of 
audit result
c. The legacy application usage requires anyExtendedKeyUsage extension at the 
present time though we are phasing out support of such application.
d. These certificates do not pose a security concern meriting immediate 
revocation
e.  Replacement of these certificates will result in significant negative 
impact on our customers.
___
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

In ref to "2) Certificates with otherName SANs  above", we have identified 30 
certificates with this issue that are also part of the same population of 
certificates with the https and o=US government issue.

As indicated in the previous reports addressing the HTTP and o=US Government, 
we have corrected the ACES certificate profile and have been proactively 
contacting clients via email notifications and phone calls inviting them to 
replace those certificates. On August 31, 2017 at the latest, we will be making 
a decision regarding any outstanding certificates with this or with the other 2 
issues and posting  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)

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

[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: 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: 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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Tuesday, August 15, 2017 at 4:42:06 PM UTC-4, Eric Mill wrote:
> On Tue, Aug 15, 2017 at 2:47 PM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > We have been moderately successful in replacing the five (5)
> > certificates.  One (1) has been voluntarily replaced, we have a commitment
> > from our client to initiate a replacement for one (1) tomorrow and three
> > (3) have been revoked by IdenTrust.
> >
> 
> Thank you for this -- this information is very helpful to the community in
> evaluating ongoing impact to clients, and in how specific issues are being
> handled beyond the expected 24-hour timespan.
> 
> -- Eric
> 
> 
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone <https://twitter.com/konklone>
IdenTrust has revoked the identified certificates: 
https://misissued.com/batch/4/.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote:
> On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote:
> > IdenTrust is fully aware of the situation and has consulted with internal 
> > and external parties to ensure that our course of action is appropriate and 
> > commensurate with our business practices and accommodates our customer’s 
> > needs.
> > When IdenTrust initially established the ACES SSL profile, 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.  Later, 
> > when non-agencies applied, IdenTrust reasoned at that time that this static 
> > value continued to be acceptable as these entities must identify themselves 
> > as organizations that act as relying parties, accepting certificates issued 
> > under the ACES program, and are in some capacity associated with the U.S. 
> > Government.  We have discussed internally and taken a fresh look at this 
> > decision.   As a result, IdenTrust has updated the ACES SSL profile to use 
> > the applicant Organization name in the Subject DN organization field.  This 
> > change will accommodate all applications for ACES SSL certificates, both 
> > U.S. agencies and non-agencies.  At the same time, we have modified the 
> > OCSP validation URL from HTTPS to HTTP.  
> > It is important to note that all certificates that are impacted by this 
> > situation have been appropriately vetted by the IdenTrust Registration team 
> > according to Identity Validation requirements stated in the ACES CP, 
> > therefore the need to revoke affected certificates immediately is less 
> > critical.  Our key objective is to revoke all incorrect certificates as 
> > quickly as possible, while minimizing the impact to our customers and 
> > avoiding disruption to critical business processes.  As such, IdenTrust is 
> > working directly with these customers to initiate a replacement for the 
> > offending certificates.  The replacement process allows the client to use 
> > an online mechanism to request a new certificate with the correct 
> > attributes and immediately download the new certificate.  The replacement 
> > process also automatically revokes the certificate being replaced.  This 
> > will enable our clients to receive a newly vetted certificate and they will 
> > not be inconvenienced by a forced revocation, which would likely adversely 
> > impact their business processes. IdenTrust will ultimately force a 
> > revocation, in the event that the clients do not initiate a certificate 
> > replacement in response to our communications.
> >  
> > Thank you for the opportunity to represent our position.
> 
> Is it Identrust's contention that the revocation rules required under the 
> requirements they are audited under do not apply to these certificates 
> because it would inconvenience their customers? This is a clear violation of 
> the baseline requirements and I'd like some clarity on why Identrust believes 
> it's permissible to pick and choose what their revocation timelines will be.
> 
> -Paul
No, IdenTrust is not insinuating that the revocation rules do not apply here.  
IdenTrust, upon notification, immediately started reviewing our historical 
understanding of our ACES SSL program and how it complied with both the ACES CP 
and CA/B CP. This review involving internal and external resources began in 
earnest. As previously stipulated, all certificates impacted were appropriately 
vetted by the IdenTrust Registration team according to Identity Validation 
requirements stated in the ACES CP.  IdenTrust worked to bridge the gap between 
historical definitions and CA/B forum compliance while balancing the needs of 
the community and IdenTrust customers alike. Concurrently, IdenTrust reviewed, 
implemented and validated programmatic controls prohibiting the population of 
the "U.S. Government" for ACES non-agency entities. Once our technical fix was 
verified, our priority objective has been to revoke all non-compliant 
certificates as quickly as possible, while minimizing the impact to our 
customers and avoiding disruption to critical business processes.   IdenTrust 
has been working with the certificate sponsors to initiate a replacement for 
these identified certificates.  One certificate has been successfully replaced. 
 For one certificate, the customer has requested an extension until Wednesday 
(tomorrow) to replace--we have granted this extension, but will revoke if the 
replacement in not completed by 5 p.m. MT on Wednesday.  For the three 
certificates where we were not successful in facilitating a replacement, we 
have completed a revocation.  We will confirm replacement or revocation of the 
last remaining certificate after 5 p.m. MT tomorrow.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Tuesday, August 15, 2017 at 1:51:36 AM UTC-4, Eric Mill wrote:
> On Fri, Aug 11, 2017 at 4:43 PM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote:
> > > On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > > >
> > > > We acknowledge seeing this issue and are looking into it.
> > > > Details will be supplied as soon we can but not later that today’s end
> > of
> > > > business day.
> > > >
> > >
> > > Thanks for looking into it. It's coming up on the end of the day - do you
> > > have an update?
> > >
> > > -- Eric
> > >
> > >
> > > > ___
> > > > dev-security-policy mailing list
> > > > dev-security-policy@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-security-policy
> > > >
> > >
> > >
> > >
> > > --
> > > konklone.com | @konklone <https://twitter.com/konklone>
> >
> > IdenTrust is fully aware of the situation and has consulted with internal
> > and external parties to ensure that our course of action is appropriate and
> > commensurate with our business practices and accommodates our customer’s
> > needs.
> > When IdenTrust initially established the ACES SSL profile, 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.  Later,
> > when non-agencies applied, IdenTrust reasoned at that time that this static
> > value continued to be acceptable as these entities must identify themselves
> > as organizations that act as relying parties, accepting certificates issued
> > under the ACES program, and are in some capacity associated with the U.S.
> > Government.  We have discussed internally and taken a fresh look at this
> > decision.   As a result, IdenTrust has updated the ACES SSL profile to use
> > the applicant Organization name in the Subject DN organization field.  This
> > change will accommodate all applications for ACES SSL certificates, both
> > U.S. agencies and non-agencies.  At the same time, we have modified the
> > OCSP validation URL from HTTPS to HTTP.
> > It is important to note that all certificates that are impacted by this
> > situation have been appropriately vetted by the IdenTrust Registration team
> > according to Identity Validation requirements stated in the ACES CP,
> > therefore the need to revoke affected certificates immediately is less
> > critical.  Our key objective is to revoke all incorrect certificates as
> > quickly as possible, while minimizing the impact to our customers and
> > avoiding disruption to critical business processes.  As such, IdenTrust is
> > working directly with these customers to initiate a replacement for the
> > offending certificates.  The replacement process allows the client to use
> > an online mechanism to request a new certificate with the correct
> > attributes and immediately download the new certificate.  The replacement
> > process also automatically revokes the certificate being replaced.  This
> > will enable our clients to receive a newly vetted certificate and they will
> > not be inconvenienced by a forced revocation, which would likely adversely
> > impact their business processes. IdenTrust will ultimately force a
> > revocation, in the event that the clients do not initiate a certificate
> > replacement in response to our communications.
> >
> 
> Thanks for the background and the detail. Given that you're intentionally
> ignoring the 24-hour revocation rule, could you at least provide an
> estimate of when Identrust will force revocations to be done by? Have
> clients initiated prompt replacements?
> 
> -- Eric
> 
> 
> >
> > Thank you for the opportunity to represent our position.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone <https://twitter.com/konklone>
We have been moderately successful in replacing the five (5) certificates.  One 
(1) has been voluntarily replaced, we have a commitment from our client to 
initiate a replacement for one (1) tomorrow and three (3) have been revoked by 
IdenTrust.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote:
> On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > We acknowledge seeing this issue and are looking into it.
> > Details will be supplied as soon we can but not later that today’s end of
> > business day.
> >
> 
> Thanks for looking into it. It's coming up on the end of the day - do you
> have an update?
> 
> -- Eric
> 
> 
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone <https://twitter.com/konklone>

IdenTrust is fully aware of the situation and has consulted with internal and 
external parties to ensure that our course of action is appropriate and 
commensurate with our business practices and accommodates our customer’s needs.
When IdenTrust initially established the ACES SSL profile, 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.  Later, when 
non-agencies applied, IdenTrust reasoned at that time that this static value 
continued to be acceptable as these entities must identify themselves as 
organizations that act as relying parties, accepting certificates issued under 
the ACES program, and are in some capacity associated with the U.S. Government. 
 We have discussed internally and taken a fresh look at this decision.   As a 
result, IdenTrust has updated the ACES SSL profile to use the applicant 
Organization name in the Subject DN organization field.  This change will 
accommodate all applications for ACES SSL certificates, both U.S. agencies and 
non-agencies.  At the same time, we have modified the OCSP validation URL from 
HTTPS to HTTP.  
It is important to note that all certificates that are impacted by this 
situation have been appropriately vetted by the IdenTrust Registration team 
according to Identity Validation requirements stated in the ACES CP, therefore 
the need to revoke affected certificates immediately is less critical.  Our key 
objective is to revoke all incorrect certificates as quickly as possible, while 
minimizing the impact to our customers and avoiding disruption to critical 
business processes.  As such, IdenTrust is working directly with these 
customers to initiate a replacement for the offending certificates.  The 
replacement process allows the client to use an online mechanism to request a 
new certificate with the correct attributes and immediately download the new 
certificate.  The replacement process also automatically revokes the 
certificate being replaced.  This will enable our clients to receive a newly 
vetted certificate and they will not be inconvenienced by a forced revocation, 
which would likely adversely impact their business processes. IdenTrust will 
ultimately force a revocation, in the event that the clients do not initiate a 
certificate replacement in response to our communications.
 
Thank you for the opportunity to represent our position.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

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

On Thursday, August 10, 2017 at 12:21:18 PM UTC-4, Ryan Sleevi wrote:
> On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > > What's it going to take for mozilla to set up near real-time
> > > monitoring/auditing of certs showing up in ct logs?
> > >
> > > Lee
> > >
> > > On 8/9/17, Alex Gaynor via dev-security-policy
> > > <dev-security-policy@lists.mozilla.org> 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
> > > > ___
> > > > dev-security-policy mailing list
> > > > dev-security-policy@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-security-policy
> > > >
> > We aware of this situation and had previously introduced logic into our
> > certificate authority that a pathLengthConstraint will never be set for a
> > certificate other than a CA.  We have confirmed that only the stated
> > five (5)
> > certificates contain the issue.  Three (3) of these are real certificates;
> > however, one has expired. We have revoked the other two certificates. The
> > remaining two (2) are pre-certificates.
> 
> 
> It might be helpful if you can share more details regarding this situation,
> to better help the community understand the procedures Identrust has in
> place.
> 
> 1) Were you aware of this issue before it was reported? It's unclear, based
> on this reply, whether this was something you were previously aware of,
> given the logic you mentioning having introduced.
> 2) Given this issue, have you examined other Identrust-issued certificates
> for issues - for example, running the corpus of issued certificates over
> the past year (whether from your own DB or logged in CT) - for other forms
> of violations, such as by using tools as certlint or cablint?
> 3) What processes and procedures are in place at Identrust to help ensure
> certificates properly adhere to RFC 5280? Why did these not detect the
> issue? What steps are being taken in the future to provide greater
> assurance of future conformance?
> 
> While it's useful to hear that you've revoked those certificates, it's
> equally useful to help the community understand what, if any, changes that
> Identrust is making. If the answer is "There was a bug, we fixed it," then
> it's useful to understand what, if any, changes are being made to detect
> and/or prevent such bugs in the future.
> 
> Cheers

Your questions are reasonable.  Here is additional information to address your 
follow up comments.  IdenTrust did identify this situation during a routine 
audit in March of 2017.  The fix mentioned previously was put into place at 
that time.  The certificates (which are all internal to IdenTrust) were 
reissued and those that were incorrect were intended to be revoked; 
unfortunately the revocation did not occur.  

Additional information that might be useful:

These certif

Re: Misissued certificates

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

On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> What's it going to take for mozilla to set up near real-time
> monitoring/auditing of certs showing up in ct logs?
> 
> Lee
> 
> On 8/9/17, Alex Gaynor via dev-security-policy
>  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
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
We aware of this situation and had previously introduced logic into our
certificate authority that a pathLengthConstraint will never be set for a
certificate other than a CA.  We have confirmed that only the stated 
five (5)
certificates contain the issue.  Three (3) of these are real certificates;
however, one has expired. We have revoked the other two certificates. The
remaining two (2) are pre-certificates.
 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Wednesday, August 9, 2017 at 11:59:42 PM UTC-4, Lee wrote:
> On 8/9/17, Eric Mill <e...@konklone.com> wrote:
> > On Wed, Aug 9, 2017 at 4:28 PM, Lee <ler...@gmail.com> wrote:
> >
> >> On 8/9/17, Eric Mill via dev-security-policy
> >> <dev-security-policy@lists.mozilla.org> wrote:
> >> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
> >> > dev-security-policy@lists.mozilla.org> wrote:
> >> >
> >> >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg
> >> wrote:
> >> >> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
> >> >> dev-security-policy@lists.mozilla.org> wrote:
> >> >> > >
> >> >> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
> >> >> wrote:
> >> >> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
> >> >> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
> >> >> responder URI is required to have the plaintext HTTP scheme according
> >> >> to
> >> >> Baseline Requirements section 7.1.2.2(c).
> >> >> > >>
> >> >> > >> Here’s the list of certificates: https://misissued.com/batch/4/
> >> >> > >>
> >> >> > >> Jonathan
> >> >> > >
> >> >> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS
> >> in
> >> >> this
> >> >> > > context.  That being said, we have altered our profiles for
> >> >> certificates
> >> >> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
> >> >> certificates
> >> >> > > issued going forward will contain an HTTP OCSP URL.  We will also
> >> >> examine all
> >> >> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank
> >> >> > > you
> >> >> for giving
> >> >> > > us an opportunity to address this with the community
> >> >> >
> >> >> > Thanks for the update.
> >> >> >
> >> >> > Can you also clarify why the subject organizationName is "U.S.
> >> >> Government” for all of these certificates, despite the other subject
> >> >> fields
> >> >> indicating organizations that are not a component of the US
> >> >> Government?
> >> >> >
> >> >> > Jonathan
> >> >>
> >> >> Yes,
> >> >> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
> >> >> certificate policy defined by U.S. General Service Administration (
> >> >> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
> >> >> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust
> >> CPS
> >> >> (https://secure.identrust.com/certificates/policy/aces/IdenT
> >> >> rust_ACES_CPS_v5.1_20161110.pdf)
> >> >> These ACES SSL certificates are issued to either U.S. Government
> >> agencies
> >> >> and/or their sub-contractors in support of government
> >> >> programs\projects.
> >> >> The
> >> >> CP requires an approved CA, such as IdenTrust, to identify U.S.
> >> Government
> >> >> in
> >> >> subject organizationName along with other applicable organizations
> >> >> (e.g.
> >> >> sub-contractors, or local government agency, etc...).
> >> >>
> >> >
> >> > If that's the case, I would expect each certificate to be
> >> > authenticating
> >> > hostnames that are used solely to provide such services to the U.S.
> >> > Government. That doesn't appear to be the case with these.
> >> >
> >> > For example, one of them is for the homepage for a service provider:
> >> > www.mudiaminc.com
> >>
> >> What am I doing wrong?  goto https://www.mudiaminc.com/
> >> check the cert and it says
> >> Issued To
> >> Common Name (CN)*.opentransfer.com
> >> Organization (O)ECOMMERCE, INC.
> >>
> >
> > You're not doing anything wrong, that hostname is just not using that
> > certificate at this time, at least not to public users. But issuance is
> > what matters he

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
> that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
> required to have the plaintext HTTP scheme according to Baseline Requirements 
> section 7.1.2.2(c).
> 
> Here’s the list of certificates: https://misissued.com/batch/4/
> 
> Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy 
> > <dev-security-policy@lists.mozilla.org> wrote:
> > 
> > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
> >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
> >> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
> >> is required to have the plaintext HTTP scheme according to Baseline 
> >> Requirements section 7.1.2.2(c).
> >> 
> >> Here’s the list of certificates: https://misissued.com/batch/4/
> >> 
> >> Jonathan
> > 
> > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in this 
> > context.  That being said, we have altered our profiles for certificates 
> > issued under this Sub CA to include only HTTP OCSP URLs.  All certificates 
> > issued going forward will contain an HTTP OCSP URL.  We will also examine 
> > all 
> > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you for 
> > giving 
> > us an opportunity to address this with the community
> 
> Thanks for the update.
> 
> Can you also clarify why the subject organizationName is "U.S. Government” 
> for all of these certificates, despite the other subject fields indicating 
> organizations that are not a component of the US Government?
> 
> Jonathan

Yes,
IdenTrust ACES SSL Certificates are issued 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)
These ACES SSL certificates are issued to either U.S. Government agencies
and/or their sub-contractors in support of government programs\projects.  The
CP requires an approved CA, such as IdenTrust, to identify U.S. Government in
subject organizationName along with other applicable organizations (e.g.
sub-contractors, or local government agency, etc...).
Marco Schambach
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

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

On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy 
> > <dev-security-policy@lists.mozilla.org> wrote:
> > 
> > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:
> >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
> >> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
> >> is required to have the plaintext HTTP scheme according to Baseline 
> >> Requirements section 7.1.2.2(c).
> >> 
> >> Here’s the list of certificates: https://misissued.com/batch/4/
> >> 
> >> Jonathan
> > 
> > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in this 
> > context.  That being said, we have altered our profiles for certificates 
> > issued under this Sub CA to include only HTTP OCSP URLs.  All certificates 
> > issued going forward will contain an HTTP OCSP URL.  We will also examine 
> > all 
> > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you for 
> > giving 
> > us an opportunity to address this with the community
> 
> Thanks for the update.
> 
> Can you also clarify why the subject organizationName is "U.S. Government” 
> for all of these certificates, despite the other subject fields indicating 
> organizations that are not a component of the US Government?
> 
> Jonathan

Yes,
IdenTrust ACES SSL Certificates are issued 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)
 
These ACES SSL certificates are issued to either U.S. Government agencies 
and/or their sub-contractors in support of government programs\projects.  The 
CP requires an approved CA, such as IdenTrust, to identify U.S. Government in 
subject organizationName along with other applicable organizations (e.g. 
sub-contractors, or local government agency, etc...).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy