Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg]

“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

[Jonathan Rudenberg]

> On Aug 7, 2017, at 16:47, Jonathan Rudenberg via dev-security-policy <dev-secur...@lists.mozilla.org> 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/

I also note that these certificates all have an organizationName of "U.S. Government”, but the rest of the subject details indicate organizations that are not components of the US Government.

[Jakob Bohm]

Why are you so obsessed with the least significant BR requirements?

The original prohibition on https revocation URLs was based on the risk
that CAs might misconfigure this in a way that causes infinite recursion
in clients checking that particular https certificate for revocation.

This was before mass-surveillance became such a big issue, and might
have been decided otherwise today.

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

[Vincent Lynch]

Jakob,

I don't see what is wrong with Jonathan reporting these issues. The authors
and ratifiers of the BRs made the choice to specify these small details.
While a minor encoding error is certainly not as alarming as say, issuing
an md5 signed certificate, it is still an error and is worth reporting.

I believe it is decidedly off-topic to debate what BR violations are worth
reporting.

If you think certain BR rules are outdated or sub-par, I am sure the
community would welcome that discussion but it should be its own thread.

-Vincent

On Mon, Aug 7, 2017 at 4:57 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 07/08/2017 22:47, Jonathan Rudenberg wrote:
>

> Why are you so obsessed with the least significant BR requirements?
>
> The original prohibition on https revocation URLs was based on the risk
> that CAs might misconfigure this in a way that causes infinite recursion
> in clients checking that particular https certificate for revocation.
>
> This was before mass-surveillance became such a big issue, and might
> have been decided otherwise today.
>
> 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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
Vincent Lynch

[Jonathan Rudenberg]

> On Aug 7, 2017, at 16:57, Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On 07/08/2017 22:47, Jonathan Rudenberg wrote:

> Why are you so obsessed with the least significant BR requirements?

I’m not convinced this is insignificant. NSS only supports http:// URLs for OCSP, and I suspect the majority of OCSP clients do the same.

https://hg.mozilla.org/projects/nss/file/3c4f0e9f6e45/lib/certhigh/ocsp.c#l2844

[Jakob Bohm]

On 07/08/2017 23:05, Vincent Lynch wrote:
> Jakob,
>
> I don't see what is wrong with Jonathan reporting these issues. The authors
> and ratifiers of the BRs made the choice to specify these small details.
> While a minor encoding error is certainly not as alarming as say, issuing
> an md5 signed certificate, it is still an error and is worth reporting.
>
> I believe it is decidedly off-topic to debate what BR violations are worth
> reporting.
>
> If you think certain BR rules are outdated or sub-par, I am sure the
> community would welcome that discussion but it should be its own thread.
>

Since the CT made it possible, I have seen an increasing obsession with
enforcing every little detail of the BRs, things that would not only
have gone unnoticed, but also been considered unremarkable before CT.

Do we really want the CA community to be filled with bureaucratic
enforcement of harsh punishments for every slight misstep? This is the
important question that any organization (in this case this community)
needs to ask itself whenever new surveillance abilities make it possible
to catch microscopic infractions.

Do we want to be the kind of place where people are punished for not
polishing their boots perfectly or having a picture of their wife on
their desk? (To mention other rules that some organizations have
overzealously enforced a long time ago).

[Matthew Hardeman]

> Do we really want the CA community to be filled with bureaucratic
> enforcement of harsh punishments for every slight misstep? This is the
> important question that any organization (in this case this community)
> needs to ask itself whenever new surveillance abilities make it possible
> to catch microscopic infractions.

I can certainly see both sides.

The discovery of these matters is a natural consequence of the increasing prevalence (and ultimately mandatory nature) of CT.

I do think strong approach of identifying issues and potential issues accompanied with as forgiving a perspective as possible is important moving forward:

It is important that issues or potential issues (I would regard variance from the accepted norm in areas where there is ambiguity as to the propriety of a given encoding / parameter / etc in the standards as a "potential issue") be identified so that conclusions can be made as to what is or is not correct and proper and so that any unintended (or worse, precisely intended) consequences can be determined.

It is also important, however, that where there is no direct security risk, that there be a great deal of leeway and time to resolve the issues moving forward. If this is not the case, the easy answer for any commercial CA would be to use the exact same software stack as every other CA. There is already, in fact, a lot of concentration in that area. If using same config X on software version Y of package A is the formula that every CA implements in order to not get caught out on these issues, this will create a significant monoculture as to key pieces of the PKI infrastructure which might easily create a greater ecosystem risk than some of these technical noncompliances.

Harsh punishments or consequences should be reserved for real security problems, real intentional deception, actual harms, etc.

The one gray area that must be watched for is constant issues of one form or another from a broad array of problem areas. The community is NOT the basic compliance test bed. A CA can not expect to just have the community do their QA and compliance testing. Frequent issues on well resolved matters of a broad array all arising from a single CA would bring a question of whether the CA is exercising due care in their operations.

[Ryan Sleevi]

As mentioned earlier, you would be best to start your own thread.

As a peer for the module, I greatly appreciate the work Jonathan is doing, and encourage him to do more. If you feel otherwise, it may be best if you simply don't participate in those discussions, since the contrariness or explanations are not providing significant value to these discussions.

As others suspected, the use of an HTTPS URI for OCSP effectively prevents clients from being able to check, as clients including NSS, CryptoAPI, Chrome, and SecureTransport all refuse to check OCSP via HTTPS due to circular dependencies. This means that the inclusion of such a URL does not provide revocation services, and as those are presently required by the BRs, fails to meet those objectives.

Your proposed approach - of dividing things you feel are serious or minor - are actively harmful to the efforts of this community, in part due to seeming to lack sufficient context to assess the seriousness or minorness of the impact (as shown in this week's threads). Issues you have felt were minor are, in fact, serious, and the prevalence of a myriad of minor issues has historically been and continues to be a reasonable signal for more serious issues in either policy or practice. Perhaps it may be worth holding back on sharing opinions at first, so that these technical details can be shared and a better sense of serious and minor developed.

[Nick Lamb]

On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote:
> Since the CT made it possible, I have seen an increasing obsession with
> enforcing every little detail of the BRs, things that would not only
> have gone unnoticed, but also been considered unremarkable before CT.

Even if I had no other reason to be concerned about violations of the BRs (and I do have plenty, as we saw here in this case it looks like the certificate can be revoked but it effectively can't) the Brown M&M Rider reason is enough,

The rider (hospitality and technical requirements for a performing artist) can be pretty detailed, some venues may glance at it and agree to whatever is inside without knowing the details. This is a _huge_ problem, and Van Halen is famous for a clause in their rider (requiring a bowl of M&Ms but with the brown ones removed) which they say existed not out of spite but precisely to check that the venue had actually read the rider in full and not just skimmed it, so that they would have early warning if a particular venue were sloppy and might cause surprise problems with technical implementation.

We need CAs to be detail oriented. It is not enough to "kinda, mostly" get this job right. If you can't do _exactly_ what it says in the BRs, don't bother doing it at all. Neither Mozilla nor any other trust store compel CAs to stay in this business, if they decide they'd rather sell pancakes or mow lawns, that's up to them. So long as they want to be trusted public CAs, they need to obey the rules that are in place to make that safe for everybody.

[Jakob Bohm]

While the Brown M&M Rider argument would be good if, like the van Halen
clause, there was only a small number of such intentional gotcha rules,
in this case we are dealing with a large corpus of rules, some explicit,
some in documents referenced from other documents etc.

That makes the situation much more like the situation with other large
sets of rules for people to follow, which means that there will, in
practice, always be rules more important than others. And hence a
natural expectation that those tasked with enforcing the rules actually
know the difference and don't issue large penalties for what is
obviously minor infractions.

Now in this *specific* case, it has been found that Mozilla's NSS
doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a
specific need to prevent their public use until NSS gains the ability to
handle them safely (because there is a benefit to it). Discussing that
benefit and planning appropriate transition plans is an issue for
another thread, possibly in another forum.

[Alex Gaynor]

Luckily we have tools like certlint, which can be run on certificates to
catch this stuff!

I'd feel very differently if CAs were starting these threads because they'd
caught issues with certlint, than the fact that independent researchers are
noticing.

Alex

On Tue, Aug 8, 2017 at 7:52 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 08/08/2017 12:54, Nick Lamb wrote:
>

> While the Brown M&M Rider argument would be good if, like the van Halen
> clause, there was only a small number of such intentional gotcha rules,
> in this case we are dealing with a large corpus of rules, some explicit,
> some in documents referenced from other documents etc.
>
> That makes the situation much more like the situation with other large
> sets of rules for people to follow, which means that there will, in
> practice, always be rules more important than others. And hence a
> natural expectation that those tasked with enforcing the rules actually
> know the difference and don't issue large penalties for what is
> obviously minor infractions.
>
> Now in this *specific* case, it has been found that Mozilla's NSS
> doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a
> specific need to prevent their public use until NSS gains the ability to
> handle them safely (because there is a benefit to it). Discussing that
> benefit and planning appropriate transition plans is an issue for
> another thread, possibly in another forum.
>
>
>

> 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

[iden...@gmail.com]

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

[Jonathan Rudenberg]

> On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:

> 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

[Ryan Sleevi]

While you may feel this way, it is again inaccurate to present it as such. It is an intentional design decision by the NSS and Firefox developers, made independently by folks at Apple, Google, and Microsoft as well for nearly two decades. This isn't "oops, NSS doesn't support it" - it is "this is a terrible idea"

I realize you are trying to present it as a bug, in order to justify the presence of brown M&Ms as "not important," but you are failing to recognize such URLs DO break implementations and are forbidden for legitimate reasons.

But certainly, further arguments on this point are best suited for another forum, because there is no good reason to change here.

[Jakob Bohm]

Actually I have long considered it a bug/errata in the PKIX standards.
Thus I was somewhat triggered when this suddenly became an enforced
rule. I wasn't making this up to defend the CA that issued those
certificates.

> But certainly, further arguments on this point are best suited for another forum, because there is no good reason to change here.
>

[iden...@gmail.com]

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

[iden...@gmail.com]

[iden...@gmail.com]

On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg wrote:

[Eric Mill]

On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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

And one of them is for what appears to be a state government revenue
service's VPN: vpn.revenue.louisiana.gov

(So it's clear, "U.S. Government" only refers to the federal government,
not state/local/tribal governments.)

I personally (and to be clear, this is in my individual capacity and I am
not representing my employer) think these are invalid organizationNames,
constitute misissuance, and that Identrust should be using the "U.S.
Government" only for hostnames providing services operated exclusively on
behalf of the federal government.

-- Eric

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[Lee]

On 8/9/17, Eric Mill via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:

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

> And one of them is for what appears to be a state government revenue
> service's VPN: vpn.revenue.louisiana.gov

I see that one - goto https://vpn.revenue.louisiana.gov/
check the cert and it says
Issued To
Common Name (CN) Vpn.revenue.louisiana.gov
Organization (O) U.S. Government

> (So it's clear, "U.S. Government" only refers to the federal government,
> not state/local/tribal governments.)
>
> I personally (and to be clear, this is in my individual capacity and I am
> not representing my employer) think these are invalid organizationNames,
> constitute misissuance, and that Identrust should be using the "U.S.
> Government" only for hostnames providing services operated exclusively on
> behalf of the federal government.

playing devils' advocate: how do you know that
https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with
the IRS or some other branch of the U.S. Government?

Lee

[Eric Mill]

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-secur...@lists.mozilla.org> wrote:
> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg

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 here.

Given the capitalization of the common name, and the
organizationalUnitName, the certificate was clearly issued to the same
company.

> And one of them is for what appears to be a state government revenue
> > service's VPN: vpn.revenue.louisiana.gov
>
> I see that one - goto https://vpn.revenue.louisiana.gov/
> check the cert and it says
> Issued To
> Common Name (CN) Vpn.revenue.louisiana.gov
> Organization (O) U.S. Government
>
> > (So it's clear, "U.S. Government" only refers to the federal government,
> > not state/local/tribal governments.)
> >
> > I personally (and to be clear, this is in my individual capacity and I am
> > not representing my employer) think these are invalid organizationNames,
> > constitute misissuance, and that Identrust should be using the "U.S.
> > Government" only for hostnames providing services operated exclusively on
> > behalf of the federal government.
>
> playing devils' advocate: how do you know that
> https://vpn.revenue.louisiana.gov/ wasn't set up in collaboration with
> the IRS or some other branch of the U.S. Government?
>

That wouldn't meet the definition that Identrust said in their email above,
which is that certificates are "issued to either U.S. Government agencies

and/or their sub-contractors in support of government programs\projects".

Maybe there's some very novel arrangement I'm not familiar with where the
State of Louisiana can act as a subcontractor to the federal government,
but in both of these cases, the burden is on Identrust to identify how it
could have been appropriate to put "U.S. Government" as the
organizationName for these certificates.

For the other 3 in the batch, there are more plausible reasons why the
hostname might exclusively be for U.S. Government purposes -

* networx-billing-pricer.nhc.noblis.org - In support of the Noblis Networx
contract
* sslacesvalid.identrust.com - In support of the overall ACES CA
* smbf1.smbisao.com - Related to a Small and Medium Business (SMB)-oriented
Information Sharing and Analysis Organization Initiative (iSAO), related to
a DHS initiative: https://www.icf.com/-/media/files/icf/white-pape
rs/2015/response_to_dhs_public_comment_information_sharing.ashx

Although it is also quite plausible that those certificates are also used
for non-USG-affiliated purposes.

Only Identrust can explain it for certain, but for at least the two I
called out, I think it is reasonable to presume their organizationName is
inaccurate until shown otherwise.

-- Eric


>
> Lee

[Lee]

On 8/9/17, Eric Mill <er...@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-secur...@lists.mozilla.org> wrote:
>> > On Tue, Aug 8, 2017 at 5:53 PM, identrust--- via dev-security-policy <
>> > dev-secur...@lists.mozilla.org> wrote:
>> >
>> >> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg

if it was a cooperative project, it seems possible/reasonable that the
USG ordered the certs.

> and/or their sub-contractors in support of government programs\projects".
> Maybe there's some very novel arrangement I'm not familiar with where the
> State of Louisiana can act as a subcontractor to the federal government,
> but in both of these cases, the burden is on Identrust to identify how it
> could have been appropriate to put "U.S. Government" as the
> organizationName for these certificates.

+1
iden...@gmail.com has been cc'ed on the thread; is that enough or is
a formal request for an explanation required?

> For the other 3 in the batch, there are more plausible reasons why the
> hostname might exclusively be for U.S. Government purposes -
>
> * networx-billing-pricer.nhc.noblis.org - In support of the Noblis Networx
> contract
> * sslacesvalid.identrust.com - In support of the overall ACES CA
> * smbf1.smbisao.com - Related to a Small and Medium Business (SMB)-oriented
> Information Sharing and Analysis Organization Initiative (iSAO), related to
> a DHS initiative: https://www.icf.com/-/media/files/icf/white-pape
> rs/2015/response_to_dhs_public_comment_information_sharing.ashx
>
> Although it is also quite plausible that those certificates are also used
> for non-USG-affiliated purposes.
>
> Only Identrust can explain it for certain, but for at least the two I
> called out, I think it is reasonable to presume their organizationName is
> inaccurate until shown otherwise.

Which means the 24 hr. countdown clock to revocation should have
already started?
That seems a bit much.. what's a reasonable period of time to wait for
an explanation from Identrust for why these certs don't need to be
revoked? 5 days? longer?

Lee

[branden....@gmail.com]

I removed a bunch of these certifications from my firefox browsers.What are they, and why?
http://www.bloomberg.com/research/stocks/private/snapshot.asp?privcapId=652184

[iden...@gmail.com]

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.

[Eric Mill]

On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy <
dev-secur...@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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[iden...@gmail.com]

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.

[paul.l...@gmail.com]

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

[Eric Mill]

On Fri, Aug 11, 2017 at 4:43 PM, identrust--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote:

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.

[Gervase Markham]

On 07/08/17 22:30, Jakob Bohm wrote:
> Since the CT made it possible, I have seen an increasing obsession with
> enforcing every little detail of the BRs, things that would not only
> have gone unnoticed, but also been considered unremarkable before CT.

I am firmly of the opinion that all BR and RFC violations are of
interest to the community. That is a separate question from what should
be done about them.

> Do we really want the CA community to be filled with bureaucratic
> enforcement of harsh punishments for every slight misstep?

No. I would expect responses (I wouldn't use the word 'punishments') to
be appropriate to the level of problem they are addressing. However,
there is a cumulative element to CA problems because it speaks to
competence.

A CA's job, in the abstract, is to read a large number of documents full
of rules and build a system which keeps those rules and doesn't allow
them to be broken. Therefore, instances of rule-breaking are of interest
to those whom the CA would like to trust their system, because they
indicate either a lack of comprehension of the rules or a lack of
ability to write code that follows them, both of which are of interest.

This is not to say that we expect perfection from every CA. But when
things do go wrong we expect a particular sort of reaction (more on that
soon, I hope), and we don't expect different things to be going wrong
every month, or the same thing to be going wrong multiple times.

Gerv

[iden...@gmail.com]

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.

[iden...@gmail.com]

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.

[Eric Mill]

On Tue, Aug 15, 2017 at 2:47 PM, identrust--- via dev-security-policy <
dev-secur...@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.

[iden...@gmail.com]

IdenTrust has revoked the identified certificates: https://misissued.com/batch/4/.

[Jonathan Rudenberg]

> On Aug 15, 2017, at 14:53, identrust--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Friday, August 11, 2017 at 6:05:29 PM UTC-4, paul.l...@gmail.com wrote:

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

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

[Jonathan Rudenberg]

> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy <dev-secur...@lists.mozilla.org> 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

[Jonathan Rudenberg]

> On Aug 16, 2017, at 13:44, Jonathan Rudenberg via dev-security-policy <dev-secur...@lists.mozilla.org> 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&iCAID=718
https://crt.sh/?Identity=%25&iCAID=5738

After clicking on a certificate ID, you can click the “Run cablint” link on the left to see the cablint output.

Jonathan

[iden...@gmail.com]

IdenTrust acknowledges receipt of this bug report and are working to provide the requested information

[iden...@gmail.com]

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

[Jonathan Rudenberg]

> On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy <dev-secur...@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

[iden...@gmail.com]

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.

[iden...@gmail.com]

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.

[Jeremy Rowley]

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 <dev-secur...@lists.mozilla.org> wrote:

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

[Gervase Markham]

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

[Jeremy Rowley]

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 <ge...@mozilla.org<mailto:ge...@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.

[Ryan Sleevi]

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-secur...@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 <ge...@mozilla.org<mailto:
> ge...@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

[Jeremy Rowley]

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<ry...@sleevi.com<mailto:ry...@sleevi.com>> 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-secur...@lists.mozilla.org<mailto:dev-secur...@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 <ge...@mozilla.org<mailto:ge...@mozilla.org><mailto:ge...@mozilla.org<mailto:ge...@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-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

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 <jeremy...@digicert.com>
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<ry...@sleevi.com> 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-secur...@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 <ge...@mozilla.org<mailto:

>> ge...@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

[iden...@gmail.com]

On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:

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.

[iden...@gmail.com]

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.

[iden...@gmail.com]

Effective August 28, 2017, IdenTrust has discontinued new issuance or reissuance of human certificates with the anyExtendedKeyUsage extension from all IdenTrust ACES CAs.

[iden...@gmail.com]

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.

[Eric Mill]

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-secur...@lists.mozilla.org> wrote:

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

[iden...@gmail.com]

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.