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

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

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

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

[Eric Mill via dev-security-policy]

On Tue, Aug 15, 2017 at 2:47 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We have been moderately successful in replacing the five (5)
> certificates.  One (1) has been voluntarily replaced, we have a commitment
> from our client to initiate a replacement for one (1) tomorrow and three
> (3) have been revoked by IdenTrust.
>

Thank you for this -- this information is very helpful to the community in
evaluating ongoing impact to clients, and in how specific issues are being
handled beyond the expected 24-hour timespan.

-- Eric


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



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

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

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

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

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

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

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

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

[Gervase Markham via dev-security-policy]

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

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

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

[Eric Mill via dev-security-policy]

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

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

Thanks for the background and the detail. Given that you're intentionally
ignoring the 24-hour revocation rule, could you at least provide an
estimate of when Identrust will force revocations to be done by? Have
clients initiated prompt replacements?

-- Eric


>
> Thank you for the opportunity to represent our position.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

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

[Paul Kehrer via dev-security-policy]

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

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

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

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

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

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

[Eric Mill via dev-security-policy]

On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> We acknowledge seeing this issue and are looking into it.
> Details will be supplied as soon we can but not later that today’s end of
> business day.
>

Thanks for looking into it. It's coming up on the end of the day - do you
have an update?

-- Eric


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



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

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

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

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

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

[branden.dickerson--- via dev-security-policy]

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

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

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

[Lee via dev-security-policy]

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

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 

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

[Eric Mill via dev-security-policy]

On Wed, Aug 9, 2017 at 4:28 PM, Lee  wrote:

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

You're not doing anything wrong, that hostname is just not using that
certificate at this time, at least not to public users. But issuance is
what matters 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 

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

[Lee via dev-security-policy]

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

What am I doing wrong?  goto https://www.mudiaminc.com/
check the cert and it says
Issued To
Common Name (CN)*.opentransfer.com
Organization (O)ECOMMERCE, INC.


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

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

[Eric Mill via dev-security-policy]

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

> On Tuesday, August 8, 2017 at 12:06:47 PM UTC-4, Jonathan Rudenberg wrote:
> > > On Aug 8, 2017, at 10:29, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > On Monday, August 7, 2017 at 4:47:39 PM UTC-4, Jonathan Rudenberg
> wrote:
> > >> “IdenTrust ACES CA 2” has issued five certificates with an OCSP
> responder URL that has a HTTPS URI scheme. This is not valid, the OCSP
> responder URI is required to have the plaintext HTTP scheme according to
> Baseline Requirements section 7.1.2.2(c).
> > >>
> > >> Here’s the list of certificates: https://misissued.com/batch/4/
> > >>
> > >> Jonathan
> > >
> > > IdenTrust had previously interpreted HTTP to be inclusive of HTTPS in
> this
> > > context.  That being said, we have altered our profiles for
> certificates
> > > issued under this Sub CA to include only HTTP OCSP URLs.  All
> certificates
> > > issued going forward will contain an HTTP OCSP URL.  We will also
> examine all
> > > other sub CA to ensure only HTTP OCSP URLs are included.  Thank you
> for giving
> > > us an opportunity to address this with the community
> >
> > Thanks for the update.
> >
> > Can you also clarify why the subject organizationName is "U.S.
> Government” for all of these certificates, despite the other subject fields
> indicating organizations that are not a component of the US Government?
> >
> > Jonathan
>
> Yes,
> IdenTrust ACES SSL Certificates are issued in accordance with the ACES
> certificate policy defined by U.S. General Service Administration (
> http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/docum
> ents/ACES-CP-v3-2_signed_05122017.pdf) and the GSA approved IdenTrust CPS
> (https://secure.identrust.com/certificates/policy/aces/IdenT
> rust_ACES_CPS_v5.1_20161110.pdf)
> These ACES SSL certificates are issued to either U.S. Government agencies
> and/or their sub-contractors in support of government programs\projects.
> The
> CP requires an approved CA, such as IdenTrust, to identify U.S. Government
> in
> subject organizationName along with other applicable organizations (e.g.
> sub-contractors, or local government agency, etc...).
>

If that's the case, I would expect each certificate to be authenticating
hostnames that are used solely to provide such services to the U.S.
Government. That doesn't appear to be the case with these.

For example, one of them is for the homepage for a service provider:
www.mudiaminc.com

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

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

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

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

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

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

Yes,
IdenTrust ACES SSL Certificates are issued in accordance with the ACES
certificate policy defined by U.S. General Service Administration 
(http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/documents/ACES-CP-v3-2_signed_05122017.pdf)
 
and the GSA approved IdenTrust CPS
(https://secure.identrust.com/certificates/policy/aces/IdenTrust_ACES_CPS_v5.1_20161110.pdf)
These ACES SSL certificates are issued to either U.S. Government agencies
and/or their sub-contractors in support of government programs\projects.  The
CP requires an approved CA, such as IdenTrust, to identify U.S. Government in
subject organizationName along with other applicable organizations (e.g.
sub-contractors, or local government agency, etc...).
Marco Schambach
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

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

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

Yes,
IdenTrust ACES SSL Certificates are issued in accordance with the ACES 
certificate policy defined by U.S. General Service Administration 
(http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/documents/ACES-CP-v3-2_signed_05122017.pdf)
 and the GSA approved IdenTrust CPS 
(https://secure.identrust.com/certificates/policy/aces/IdenTrust_ACES_CPS_v5.1_20161110.pdf)
 
These ACES SSL certificates are issued to either U.S. Government agencies 
and/or their sub-contractors in support of government programs\projects.  The 
CP requires an approved CA, such as IdenTrust, to identify U.S. Government in 
subject organizationName along with other applicable organizations (e.g. 
sub-contractors, or local government agency, etc...).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 08/08/2017 19:44, Ryan Sleevi wrote:

On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote:

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

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



While the Brown 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.


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 as "not important," but you are failing to 
recognize such URLs DO break implementations and are forbidden for 
legitimate reasons.




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.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm wrote:
> On 08/08/2017 12:54, Nick Lamb wrote:
> > 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 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 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.
> > 
> 
> While the Brown 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.

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

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

[Jonathan Rudenberg via dev-security-policy]

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

Thanks for the update.

Can you also clarify why the subject organizationName is "U.S. Government” for 
all of these certificates, despite the other subject fields indicating 
organizations that are not a component of the US Government?

Jonathan

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

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

[Alex Gaynor via dev-security-policy]

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

> On 08/08/2017 12:54, Nick Lamb wrote:
>
>> 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 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 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.
>>
>>
> While the Brown 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
> ___
> 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: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jakob Bohm via dev-security-policy]

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

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



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

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

[Nick Lamb via dev-security-policy]

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

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

[Ryan Sleevi via dev-security-policy]

On Tuesday, August 8, 2017 at 6:31:34 AM UTC+9, Jakob Bohm wrote:
> 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).
> 
> 
> 
> 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

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

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

[Matthew Hardeman via dev-security-policy]

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

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

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

[Jakob Bohm via dev-security-policy]

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



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jonathan Rudenberg via dev-security-policy]

> On Aug 7, 2017, at 16:57, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 07/08/2017 22:47, Jonathan Rudenberg wrote:
>> “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder 
>> URL that has a HTTPS URI scheme. This is not valid, the OCSP responder URI 
>> is required to have the plaintext HTTP scheme according to Baseline 
>> Requirements section 7.1.2.2(c).
>> Here’s the list of certificates: https://misissued.com/batch/4/
>> Jonathan
> 
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Vincent Lynch via dev-security-policy]

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

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



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

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

[Jakob Bohm via dev-security-policy]

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

“IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
required to have the plaintext HTTP scheme according to Baseline Requirements 
section 7.1.2.2(c).

Here’s the list of certificates: https://misissued.com/batch/4/

Jonathan



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

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

[Jonathan Rudenberg via dev-security-policy]

> On Aug 7, 2017, at 16:47, Jonathan Rudenberg via dev-security-policy 
>  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.

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

Certificates issued with HTTPS OCSP responder URL (IdenTrust)

[Jonathan Rudenberg via dev-security-policy]

“IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL 
that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is 
required to have the plaintext HTTP scheme according to Baseline Requirements 
section 7.1.2.2(c).

Here’s the list of certificates: https://misissued.com/batch/4/

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