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 

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)

[Eric Mill via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

Doesn't RFC 5280 clearly indicate that already, through its normative
description of the EKU?

That is, I can understand there being confusion or misinterpretation, but
I'm not sure that the problem itself is rooted in the documents, and thus,
may not be something the documents need to address. :)

On Fri, Aug 18, 2017 at 10:49 AM, Jeremy Rowley 
wrote:

> I don't (as these are the exact type of cert I've been trying to kill for
> years), but Identrust did based on their response. Looking at it from their
> POV, the language could probably be clarified to state thar any cert with
> no equipment, sever Auth,  or anyEKU is considered a BR cert regardless of
> other content.
>
> On Aug 18, 2017, at 8:26 AM, Ryan Sleevi vb wrote:
>
> Do you believe https://github.com/mozilla/pkipolicy/blob/master/
> rootstore/policy.md#11-scope is ambiguous in this context? That is what
> is referenced in the text.
>
> It sounds as if you're suggesting they're in scope, via 1.1, but that
> they're out of scope, because the policy does not state that (id-kp-anyEKU
> || id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU ||
> id-kp-emailProtection) are email certificates, even though this would
> logically flow (from RFC 5280 https://tools.ietf.org/
> html/rfc5280#section-4.2.1.12) stating that anyEKU places no restrictions
> on the subject key as to its purpose. Is that correct?
>
> On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Right, but can you call these SSL certs without an FQDN?
>>
>>
>>   *   Insofar as the Baseline Requirements attempt to define their own
>> scope, the scope of this policy (section 1.1) overrides that. Mozilla thus
>> requires CA operations relating to issuance of all SSL certificates in the
>> scope of this policy to conform to the Baseline Requirements.
>>
>> Is SSL certificate defined?
>>
>> On Aug 18, 2017, at 7:33 AM, Gervase Markham  g...@mozilla.org>> wrote:
>>
>> On 17/08/17 20:31, Jeremy Rowley wrote:
>> Without an FQDN, I doubt they are in scope for the baseline requirements.
>>
>> Not according to the BRs themselves. However, the Mozilla Policy 2.5
>> specifically says:
>>
>> "Insofar as the Baseline Requirements attempt to define their own scope,
>> the scope of this policy (section 1.1) overrides that. Mozilla thus
>> requires CA operations relating to issuance of all SSL certificates in
>> the scope of this policy to conform to the Baseline Requirements."
>>
>> Now, whether we are right to include anyEKU in scope, given that it
>> pulls in certs such as those in question, is still something I am unsure
>> about :-) But the current policy says what it says.
>>
>> They are in scope for the Mozilla policy. The BRs require the cert to
>> be intended for web tls. These are not.
>>
>> But the Mozilla Policy re-scopes the BRs to remove the ambiguous
>> language about "intent".
>>
>> The Mozilla policy covers client certs as well as tls.
>>
>> Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
>> policy covers server certs and email certs.
>>
>> Gerv
>> ___
>> 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: O=U.S. Government for non-USG entity (IdenTrust)

[Jeremy Rowley via dev-security-policy]

I don't (as these are the exact type of cert I've been trying to kill for 
years), but Identrust did based on their response. Looking at it from their 
POV, the language could probably be clarified to state thar any cert with no 
equipment, sever Auth,  or anyEKU is considered a BR cert regardless of other 
content.

On Aug 18, 2017, at 8:26 AM, Ryan Sleevi 
vb> wrote:

Do you believe 
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope 
is ambiguous in this context? That is what is referenced in the text.

It sounds as if you're suggesting they're in scope, via 1.1, but that they're 
out of scope, because the policy does not state that (id-kp-anyEKU || 
id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU || 
id-kp-emailProtection) are email certificates, even though this would logically 
flow (from RFC 5280 https://tools.ietf.org/html/rfc5280#section-4.2.1.12) 
stating that anyEKU places no restrictions on the subject key as to its 
purpose. Is that correct?

On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy 
>
 wrote:
Right, but can you call these SSL certs without an FQDN?


  *   Insofar as the Baseline Requirements attempt to define their own scope, 
the scope of this policy (section 1.1) overrides that. Mozilla thus requires CA 
operations relating to issuance of all SSL certificates in the scope of this 
policy to conform to the Baseline Requirements.

Is SSL certificate defined?

On Aug 18, 2017, at 7:33 AM, Gervase Markham 
>>
 wrote:

On 17/08/17 20:31, Jeremy Rowley wrote:
Without an FQDN, I doubt they are in scope for the baseline requirements.

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

They are in scope for the Mozilla policy. The BRs require the cert to
be intended for web tls. These are not.

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

Gerv
___
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: O=U.S. Government for non-USG entity (IdenTrust)

[Ryan Sleevi via dev-security-policy]

Do you believe
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope
is ambiguous in this context? That is what is referenced in the text.

It sounds as if you're suggesting they're in scope, via 1.1, but that
they're out of scope, because the policy does not state that (id-kp-anyEKU
|| id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU ||
id-kp-emailProtection) are email certificates, even though this would
logically flow (from RFC 5280
https://tools.ietf.org/html/rfc5280#section-4.2.1.12) stating that anyEKU
places no restrictions on the subject key as to its purpose. Is that
correct?

On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Right, but can you call these SSL certs without an FQDN?
>
>
>   *   Insofar as the Baseline Requirements attempt to define their own
> scope, the scope of this policy (section 1.1) overrides that. Mozilla thus
> requires CA operations relating to issuance of all SSL certificates in the
> scope of this policy to conform to the Baseline Requirements.
>
> Is SSL certificate defined?
>
> On Aug 18, 2017, at 7:33 AM, Gervase Markham > wrote:
>
> On 17/08/17 20:31, Jeremy Rowley wrote:
> Without an FQDN, I doubt they are in scope for the baseline requirements.
>
> Not according to the BRs themselves. However, the Mozilla Policy 2.5
> specifically says:
>
> "Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla thus
> requires CA operations relating to issuance of all SSL certificates in
> the scope of this policy to conform to the Baseline Requirements."
>
> Now, whether we are right to include anyEKU in scope, given that it
> pulls in certs such as those in question, is still something I am unsure
> about :-) But the current policy says what it says.
>
> They are in scope for the Mozilla policy. The BRs require the cert to
> be intended for web tls. These are not.
>
> But the Mozilla Policy re-scopes the BRs to remove the ambiguous
> language about "intent".
>
> The Mozilla policy covers client certs as well as tls.
>
> Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
> policy covers server certs and email certs.
>
> Gerv
> ___
> 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: O=U.S. Government for non-USG entity (IdenTrust)

[Jeremy Rowley via dev-security-policy]

Right, but can you call these SSL certs without an FQDN?


  *   Insofar as the Baseline Requirements attempt to define their own scope, 
the scope of this policy (section 1.1) overrides that. Mozilla thus requires CA 
operations relating to issuance of all SSL certificates in the scope of this 
policy to conform to the Baseline Requirements.

Is SSL certificate defined?

On Aug 18, 2017, at 7:33 AM, Gervase Markham 
> wrote:

On 17/08/17 20:31, Jeremy Rowley wrote:
Without an FQDN, I doubt they are in scope for the baseline requirements.

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

They are in scope for the Mozilla policy. The BRs require the cert to
be intended for web tls. These are not.

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Gervase Markham via dev-security-policy]

On 17/08/17 20:31, Jeremy Rowley wrote:
> Without an FQDN, I doubt they are in scope for the baseline requirements. 

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

> They are in scope for the Mozilla policy. The BRs require the cert to 
> be intended for web tls. These are not. 

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

> The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jeremy Rowley via dev-security-policy]

Without an FQDN, I doubt they are in scope for the baseline requirements. They 
are in scope for the Mozilla policy. The BRs require the cert to be intended 
for web tls. These are not. The Mozilla policy covers client certs as well as 
tls.

> On Aug 17, 2017, at 12:27 PM, identrust--- via dev-security-policy 
>  wrote:
> 
> On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
>>> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
>>>  wrote:
>>> 
>>> I looked through the CT logs and found 15 more unexpired unrevoked 
>>> certificates that are trusted by NSS and appear to have the same inaccurate 
>>> organizationName of “U.S. Government” for a non-USG entity.
>>> 
>>> The list is here: https://misissued.com/batch/10/
>>> 
>>> Can you explain why your review missed these? Are there any more in 
>>> addition to these 15 and previous 5?
>>> 
>>> Jonathan
>> 
>> After looking into this more, I’ve found that the majority of certificates 
>> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
>> are not BR-compliant.
>> 
>> The issues fall into three categories:
>> 
>> 1) Certificates with HTTPS OCSP URLs
>> 2) Certificates with otherName SANs
>> 3) Certificates that appear to be intended as client certificates, but have 
>> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root 
>> Policy.
>> 
>> I’ve found 33 certificates that have one or more of these issues that are 
>> unexpired and unrevoked.
>> 
>> Here is the full list: https://misissued.com/batch/11/ (note that it is a 
>> superset of the batch I posted earlier today)
>> 
>> Jonathan
> and also in reference to number 1 but regarding non US Government issue 
> certificates, here is the reply in the expected format:
> Issue: Non US Government Certificates issued with o=US Government (IdenTrust) 
>
> 1.How your CA first became aware of the problems listed below (e.g. via a 
> Problem Report, via the discussion in mozilla.dev.security.policy, or via 
> this Bugzilla Bug), and the date.
> IdenTrust: Problem Reported to IdenTrust  via the Mozilla Dev Security Policy 
> Forum on August 8, 2017
> 2.Prompt confirmation that your CA has stopped issuing TLS/SSL 
> certificates with the problems listed below.
> IdenTrust: on August 9, IdenTrust acknowledged the issue and offered a formal 
> reply before the end of the business day. A formal reply was supplied to the 
> forum the following day August 10, 2017:
> 3.Complete list of certificates that your CA finds with each of the 
> listed issues during the remediation process. The recommended way to handle 
> this is to ensure each certificate is logged to CT and then attach a CSV 
> file/spreadsheet of the fingerprints or crt.sh IDs, with one list per 
> distinct problem.
> IdenTrust: On August 16, 2017 we have identified a total of 164 ACES 
> certificates reflecting o=US Government for non-US government entities. 
> 4.Summary of the problematic certificates. For each problem listed below:
> number of certs, date first and last certs with that problem were issued.
> IdenTrust: The date range of the ACES certificates with issue is from 
> 08/21/2015 to 05/12/2017
> 5.Explanation about how and why the mistakes were made, and not caught 
> and fixed earlier. 
> IdenTrust: When IdenTrust initially established the ACES SSL certificate 
> profile (around 2002), it was intended to apply only to US government 
> entities.  At that time, the Organization was defined as a static value of 
> “U.S. Government” in our profiles.  Subsequently around 2007, when 
> non-agencies were identified to require ACES SSL certificates under the ACES 
> policy, IdenTrust interpreted the policy at that time that this static value 
> continued to be acceptable as these entities must identify themselves as 
> organizations that act as relying parties affiliated with a government 
> program, accepting client certificates issued under the ACES program, and are 
> in some capacity associated with the U.S. Government programs.  Once we were 
> notified of the problem, we consulted internally and with GSA (owner of the 
> ACES policy) and have determined that this interpretation needs to be updated 
> to align  with BR requirements.  As such we updated our processes and 
> profiles to include the Organization as the non-agencies when the FQDN owner 
> is not directly U.S. Government agency. 
> 6.List of steps your CA is taking to resolve the situation and ensure 
> such issuance will not be repeated in the future, accompanied with a timeline 
> of when your CA expects to accomplish these things.
> IdenTrust:
> 1.Effective August 7, 2017 the ACES SSL profile and process has been 
> updated to use the applicant Organization name in the Subject DN organization 
> field include only HTTP OCSP URLs. 
> 2.Other IdenTrust SSL Sub-CA’s have been 

Re: O=U.S. Government for non-USG entity (IdenTrust)

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

On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
> >  wrote:
> > 
> > I looked through the CT logs and found 15 more unexpired unrevoked 
> > certificates that are trusted by NSS and appear to have the same inaccurate 
> > organizationName of “U.S. Government” for a non-USG entity.
> > 
> > The list is here: https://misissued.com/batch/10/
> > 
> > Can you explain why your review missed these? Are there any more in 
> > addition to these 15 and previous 5?
> > 
> > Jonathan
> 
> After looking into this more, I’ve found that the majority of certificates 
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
> are not BR-compliant.
> 
> The issues fall into three categories:
> 
> 1) Certificates with HTTPS OCSP URLs
> 2) Certificates with otherName SANs
> 3) Certificates that appear to be intended as client certificates, but have 
> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root 
> Policy.
> 
> I’ve found 33 certificates that have one or more of these issues that are 
> unexpired and unrevoked.
> 
> Here is the full list: https://misissued.com/batch/11/ (note that it is a 
> superset of the batch I posted earlier today)
> 
> Jonathan
and also in reference to number 1 but regarding non US Government issue 
certificates, here is the reply in the expected format:
Issue: Non US Government Certificates issued with o=US Government (IdenTrust)   
1.  How your CA first became aware of the problems listed below (e.g. via a 
Problem Report, via the discussion in mozilla.dev.security.policy, or via this 
Bugzilla Bug), and the date.
IdenTrust: Problem Reported to IdenTrust  via the Mozilla Dev Security Policy 
Forum on August 8, 2017
2.  Prompt confirmation that your CA has stopped issuing TLS/SSL 
certificates with the problems listed below.
IdenTrust: on August 9, IdenTrust acknowledged the issue and offered a formal 
reply before the end of the business day. A formal reply was supplied to the 
forum the following day August 10, 2017:
3.  Complete list of certificates that your CA finds with each of the 
listed issues during the remediation process. The recommended way to handle 
this is to ensure each certificate is logged to CT and then attach a CSV 
file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct 
problem.
IdenTrust: On August 16, 2017 we have identified a total of 164 ACES 
certificates reflecting o=US Government for non-US government entities. 
4.  Summary of the problematic certificates. For each problem listed below:
number of certs, date first and last certs with that problem were issued.
IdenTrust: The date range of the ACES certificates with issue is from 
08/21/2015 to 05/12/2017
5.  Explanation about how and why the mistakes were made, and not caught 
and fixed earlier. 
IdenTrust: When IdenTrust initially established the ACES SSL certificate 
profile (around 2002), it was intended to apply only to US government entities. 
 At that time, the Organization was defined as a static value of “U.S. 
Government” in our profiles.  Subsequently around 2007, when non-agencies were 
identified to require ACES SSL certificates under the ACES policy, IdenTrust 
interpreted the policy at that time that this static value continued to be 
acceptable as these entities must identify themselves as organizations that act 
as relying parties affiliated with a government program, accepting client 
certificates issued under the ACES program, and are in some capacity associated 
with the U.S. Government programs.  Once we were notified of the problem, we 
consulted internally and with GSA (owner of the ACES policy) and have 
determined that this interpretation needs to be updated to align  with BR 
requirements.  As such we updated our processes and profiles to include the 
Organization as the non-agencies when the FQDN owner is not directly U.S. 
Government agency. 
6.  List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future, accompanied with a timeline 
of when your CA expects to accomplish these things.
IdenTrust:
1.  Effective August 7, 2017 the ACES SSL profile and process has been 
updated to use the applicant Organization name in the Subject DN organization 
field include only HTTP OCSP URLs. 
2.  Other IdenTrust SSL Sub-CA’s have been examined and confirmed that this 
issue does not exist. 
3.  We have been proactively contacting clients via email notifications and 
phone calls inviting them to replace those certificates. As of August 17 2017 
AM we have 153 ACES SSL certificates with this issue. On August 31, 2017 at the 
latest, we will be making a decision regarding any outstanding certificates 
with this issue and will post an update to the forum. 
 
___

Re: O=U.S. Government for non-USG entity (IdenTrust)

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

On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
> >  wrote:
> > 
> > I looked through the CT logs and found 15 more unexpired unrevoked 
> > certificates that are trusted by NSS and appear to have the same inaccurate 
> > organizationName of “U.S. Government” for a non-USG entity.
> > 
> > The list is here: https://misissued.com/batch/10/
> > 
> > Can you explain why your review missed these? Are there any more in 
> > addition to these 15 and previous 5?
> > 
> > Jonathan
> 
> After looking into this more, I’ve found that the majority of certificates 
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
> are not BR-compliant.
> 
> The issues fall into three categories:
> 
> 1) Certificates with HTTPS OCSP URLs
> 2) Certificates with otherName SANs
> 3) Certificates that appear to be intended as client certificates, but have 
> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root 
> Policy.
> 
> I’ve found 33 certificates that have one or more of these issues that are 
> unexpired and unrevoked.
> 
> Here is the full list: https://misissued.com/batch/11/ (note that it is a 
> superset of the batch I posted earlier today)
> 
> Jonathan

In reference to number 1)"Certificates with HTTPS OCSP URLs"
Here is IdenTust reply in the recommended format:
Issue: Certificates issued with HTTPS OCSP responder URL (IdenTrust)
1.  How your CA first became aware of the problems listed below (e.g. via a 
Problem Report, via the discussion in mozilla.dev.security.policy, or via this 
Bugzilla Bug), and the date.
IdenTrust: Problem Reported to IdenTrust  via the Mozilla Dev Security Policy 
Forum on August 7, 2017
2.  Prompt confirmation that your CA has stopped issuing TLS/SSL 
certificates with the problems listed below.
IdenTrust: IdenTrust immediately began researching the issue.  In parallel, we 
consulted with the ACES certificate policy owners to ensure we had the right 
interpretation of policy requirements.  Upon confirmation of the problem, we 
updated the relevant the certificate profile on August 7, 2017 so that future 
issuance of TLS/SSL certificates is free of the identified problem.
3.  Complete list of certificates that your CA finds with each of the 
listed issues during the remediation process. The recommended way to handle 
this is to ensure each certificate is logged to CT and then attach a CSV 
file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct 
problem.
IdenTrust: Besides the 5 reported certificates, on August 16, 2017 we have 
identified another 309 ACES certificates with this issue. 
4.  Summary of the problematic certificates. For each problem listed below:
number of certs, date first and last certs with that problem were issued.
IdenTrust: The date range of the ACES certificates with this issue is from 
08/21/2015 to 07/26/2017
5.  Explanation about how and why the mistakes were made, and not caught 
and fixed earlier. 
IdenTrust: IdenTrust ACES SSL Certificates have been issued by IdenTrust in 
accordance with the ACES 
certificate policy defined by U.S. General Service Administration 
(http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/documents/ACES-CP-v3-2_signed_05122017.pdf)
  and the GSA approved IdenTrust CPS 
(https://secure.identrust.com/certificates/policy/aces/IdenTrust_ACES_CPS_v5.1_20161110.pdf)
 
IdenTrust started issuing ACES SSL Certificates since 2006 using the above 
reference guidelines which accept either http or https as acceptable values in 
the AIA extension for the OCSP validation.
The issue reported was not caught earlier as none of ACES SSL certificate 
clients or relevant Relying party(s) have reported issues validating their 
certificates.
6.  List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future, accompanied with a timeline 
of when your CA expects to accomplish these things.
IdenTrust:
1.  Effective August 7, 2017 the ACES SSL profiles have been updated to 
include only HTTP OCSP URLs. 
2.  Other IdenTrust SSL Sub-CA’s have been examined and confirmed that this 
issue does not exist.
3.   We have been proactively contacting clients via email notifications 
and phone calls inviting them to replace those certificates. As of August 17 
2017 AM we have a 242 ACES SSL certificates with this issue and we are seeing a 
positive trend from clients coming forward for replacement/revocation. On 
August 31, 2017 at the latest, we will be making a decision regarding any 
outstanding certificates with this issue and will post an update to the forum.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy 
>  wrote:
> 
> Hello, In reference to 3)"Certificates that appear to be intended as client 
> certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for 
> the Mozilla Root Policy."
> The following 6 client certificates that have been identified as server 
> certificates and have been flagged as non-compliant.  However, these 
> certificates do not contain FQDN, IP Address, nor ‘TLS Web Server 
> Authentication’ EKU.  As such in order for us to proceed with our analysis 
> and determine if any remediation is required, we need clarification in the 
> exact nature of non-compliance as it relates to Mozilla Root Policy or CAB 
> Forum Baseline Requirement (ideally with pointer to the specific requirement 
> in the corresponding documents).

The Mozilla Root Store Policy section 1.1 (Scope) says:

> This policy applies, as appropriate, to certificates matching any of the 
> following (and the CAs which control or issue them):
> …
> 3. End-entity certificates which have at least one valid, unrevoked chain up 
> to such a CA certificate through intermediate certificates which are all in 
> scope, such end-entity certificates having either:
>   - an Extended Key Usage (EKU) extension which contains one or more of 
> these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, 
> id-kp-emailProtection; or: …

The six certificates linked contain the anyExtendedKeyUsage KeyPurposeId and 
were issued by an intermediate that is also in scope, so they are in scope for 
the Mozilla Root Policy and by extension the Baseline Requirements.

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

Re: O=U.S. Government for non-USG entity (IdenTrust)

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

On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
> > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
> >  wrote:
> > 
> > I looked through the CT logs and found 15 more unexpired unrevoked 
> > certificates that are trusted by NSS and appear to have the same inaccurate 
> > organizationName of “U.S. Government” for a non-USG entity.
> > 
> > The list is here: https://misissued.com/batch/10/
> > 
> > Can you explain why your review missed these? Are there any more in 
> > addition to these 15 and previous 5?
> > 
> > Jonathan
> 
> After looking into this more, I’ve found that the majority of certificates 
> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
> are not BR-compliant.
> 
> The issues fall into three categories:
> 
> 1) Certificates with HTTPS OCSP URLs
> 2) Certificates with otherName SANs
> 3) Certificates that appear to be intended as client certificates, but have 
> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root 
> Policy.
> 
> I’ve found 33 certificates that have one or more of these issues that are 
> unexpired and unrevoked.
> 
> Here is the full list: https://misissued.com/batch/11/ (note that it is a 
> superset of the batch I posted earlier today)
> 
> Jonathan
Hello, In reference to 3)"Certificates that appear to be intended as client 
certificates, but have the anyExtendedKeyUsage EKU, putting them in scope for 
the Mozilla Root Policy."
The following 6 client certificates that have been identified as server 
certificates and have been flagged as non-compliant.  However, these 
certificates do not contain FQDN, IP Address, nor ‘TLS Web Server 
Authentication’ EKU.  As such in order for us to proceed with our analysis and 
determine if any remediation is required, we need clarification in the exact 
nature of non-compliance as it relates to Mozilla Root Policy or CAB Forum 
Baseline Requirement (ideally with pointer to the specific requirement in the 
corresponding documents).  

https://crt.sh/?id=157944459
https://crt.sh/?id=157944592
https://crt.sh/?id=157944616
https://crt.sh/?id=157944549
https://crt.sh/?id=157944611
https://crt.sh/?id=157944466

Thanks

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

Re: 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: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: O=U.S. Government for non-USG entity (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 15, 2017, at 14:53, identrust--- via dev-security-policy 
>  wrote:
> 
> 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