Re: Misissued certificates - pathLenConstraint with CA:FALSE

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

On Wednesday, August 9, 2017 at 9:53:14 PM UTC-4, Alex Gaynor wrote:
> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> was to IdenTrust)
> 
> Hi,
> 
> The following certificates appear to be misissued:
> 
> https://crt.sh/?id=77893170=cablint
> https://crt.sh/?id=77947625=cablint
> https://crt.sh/?id=78102129=cablint
> https://crt.sh/?id=92235995=cablint
> https://crt.sh/?id=92235998=cablint
> 
> All of these certificates have a pathLenConstraint value with CA:FALSE,
> this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> pathLenConstraint field unless the cA boolean is asserted and the key usage
> extension asserts the keyCertSign bit.
> 
> Alex
> 
> -- 
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> 
> 
> 
> 
> -- 
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
Formal reply addressing the questionnaire format:
Issue pathLenConstraint with CA:False (IdenTrust)
1.  How your CA first became aware of the problems listed below (e.g. via a 
Problem Report, via the discussion in mozilla.dev.security.policy, or via this 
Bugzilla Bug), and the date.
IdenTrust: Problem Reported to IdenTrust  via the Mozilla Dev Security Policy 
Forum on August 9, 2017
2.  Prompt confirmation that your CA has stopped issuing TLS/SSL 
certificates with the problems listed below.
IdenTrust: The issue was addressed immediately and a formal reply was supplied 
on to forum on August 10, 2017
3.  Complete list of certificates that your CA finds with each of the 
listed issues during the remediation process. The recommended way to handle 
this is to ensure each certificate is logged to CT and then attach a CSV 
file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct 
problem.
IdenTrust: There were 5 certificates reported with this issue:
https://crt.sh/?id=77893170=cablint 
https://crt.sh/?id=77947625=cablint 
https://crt.sh/?id=78102129=cablint 
https://crt.sh/?id=92235995=cablint 
https://crt.sh/?id=92235998=cablint  

4.  Summary of the problematic certificates. For each problem listed below:
number of certs, date first and last certs with that problem were issued.
IdenTrust: Those 5 certificates were issued between Jan-16 and Feb 14, 2017.
2 of them were pre-certificates.
5.  Explanation about how and why the mistakes were made, and not caught 
and fixed earlier. 
IdenTrust: IdenTrust identified this situation during a routine audit in March 
of 2017. The certificates (which are all internal to IdenTrust) were reissued 
and these that were incorrect were intended to be revoked; unfortunately the 
revocation did not occur.  
These certificates were created during the process of building a new product, 
which has not yet been officially launched and no additional certificates have 
been issued under this profile.  Quarterly audits, comprised of evaluating a 
sampling of certificates, have been conducted; however, due to the fact that a 
revocation order had been issued for these certificates and we have no active 
production certificates for this program, no sampling was warranted.  

With respect to lack of follow through on the revocation in March 2017, because 
these certificates were not production certificates issued to actual 
subscribers, our standard revocation process for certificates does not appear 
to have been followed; rather, an informal internal emailed request was 
initiated and was apparently overlooked.  We have addressed this internally and 
put remediation steps into place that will alleviate this possibility in the 
future.

6.  List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future, accompanied with a timeline 
of when your CA expects to accomplish these things.
IdenTrust:
1.  The 5 certificates were revoked on August 10, 2017 
2.  Since March 2017 we have corrected the profiles to prevent recurrence 
of this issue

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

Re: Misissued certificates

[Gervase Markham via dev-security-policy]

On 10/08/17 19:35, Jeremy Rowley wrote:
> This is interesting.  We had one Sub CA who mis-issued some pre-certs but
> then never issued an actual certificate tied to the pre-certificate.  There
> was a previous Mozilla discussion (link coming) where mis-issuance of a
> pre-certificate was akin to mis-issuance of the certificate itself.  The
> pre-certificates were later revoked at our request.  If no actual
> certificate issued, the pre-cert falls out of scope of the BRs right? Since
> it can't be used for actual server transactions thanks to the poison
> extensions? Obviously they still fall within the Mozilla policy as they
> contain serverAuth in the EKU.  However, should they be reported as issues
> and should they be revoked in accordance with the BR?

I'm having trouble disentangling your questions from each other :-) But
yes, our position (and that of the CT RFC) is that "mis-issuance of a
pre-certificate is equivalent to mis-issuance of the certificate
itself", and therefore should be reported and dealt with just as if a
cert was mis-issued.

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

Re: Misissued certificates

[Paul Kehrer via dev-security-policy]

On August 10, 2017 at 9:44:01 PM, Jakob Bohm via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

On 11/08/2017 00:29, Jonathan Rudenberg wrote:
>
>> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>>
>> Can anyone point out a real world X.509 framework that gets confused by
>> a redundant pathlen:0 in a CA:FALSE certificate? (Merely to assess the
>> seriousness of the issue, given that the certificate was already
>> revoked).
>
> Yes, the cryptography Python package:
https://github.com/pyca/cryptography/issues/3856
>

Reading that issue, the text in comment #0 is unclear. Does the python
code reject such certificates, or somehow skip extensions and declaring
possibly invalid uses to be valid?


As of the current release pyca/cryptography raises an exception during
parsing for certificates that contain a pathLength and are CA:FALSE. This
immediately halts parsing and prevents the user from viewing any extensions.

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

Re: Misissued certificates

[Jakob Bohm via dev-security-policy]

On 11/08/2017 00:29, Jonathan Rudenberg wrote:



On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy 
 wrote:

Can anyone point out a real world X.509 framework that gets confused by
a redundant pathlen:0 in a CA:FALSE certificate?  (Merely to assess the
seriousness of the issue, given that the certificate was already
revoked).


Yes, the cryptography Python package: 
https://github.com/pyca/cryptography/issues/3856



Reading that issue, the text in comment #0 is unclear.  Does the python
code reject such certificates, or somehow skip extensions and declaring
possibly invalid uses to be valid?

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: Misissued certificates

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> Can anyone point out a real world X.509 framework that gets confused by
> a redundant pathlen:0 in a CA:FALSE certificate?  (Merely to assess the
> seriousness of the issue, given that the certificate was already
> revoked).

Yes, the cryptography Python package: 
https://github.com/pyca/cryptography/issues/3856

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

Re: Misissued certificates

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

On Thursday, August 10, 2017 at 12:21:18 PM UTC-4, Ryan Sleevi wrote:
> On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > > What's it going to take for mozilla to set up near real-time
> > > monitoring/auditing of certs showing up in ct logs?
> > >
> > > Lee
> > >
> > > On 8/9/17, Alex Gaynor via dev-security-policy
> > >  wrote:
> > > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
> > mail
> > > > was to IdenTrust)
> > > >
> > > > Hi,
> > > >
> > > > The following certificates appear to be misissued:
> > > >
> > > > https://crt.sh/?id=77893170=cablint
> > > > https://crt.sh/?id=77947625=cablint
> > > > https://crt.sh/?id=78102129=cablint
> > > > https://crt.sh/?id=92235995=cablint
> > > > https://crt.sh/?id=92235998=cablint
> > > >
> > > > All of these certificates have a pathLenConstraint value with CA:FALSE,
> > > > this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> > > > pathLenConstraint field unless the cA boolean is asserted and the key
> > usage
> > > > extension asserts the keyCertSign bit.
> > > >
> > > > Alex
> > > >
> > > > --
> > > > "I disapprove of what you say, but I will defend to the death your
> > right to
> > > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > > "The people's good is the highest law." -- Cicero
> > > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > "I disapprove of what you say, but I will defend to the death your
> > right to
> > > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > > "The people's good is the highest law." -- Cicero
> > > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > > > ___
> > > > dev-security-policy mailing list
> > > > dev-security-policy@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-security-policy
> > > >
> > We aware of this situation and had previously introduced logic into our
> > certificate authority that a pathLengthConstraint will never be set for a
> > certificate other than a CA.  We have confirmed that only the stated
> > five (5)
> > certificates contain the issue.  Three (3) of these are real certificates;
> > however, one has expired. We have revoked the other two certificates. The
> > remaining two (2) are pre-certificates.
> 
> 
> It might be helpful if you can share more details regarding this situation,
> to better help the community understand the procedures Identrust has in
> place.
> 
> 1) Were you aware of this issue before it was reported? It's unclear, based
> on this reply, whether this was something you were previously aware of,
> given the logic you mentioning having introduced.
> 2) Given this issue, have you examined other Identrust-issued certificates
> for issues - for example, running the corpus of issued certificates over
> the past year (whether from your own DB or logged in CT) - for other forms
> of violations, such as by using tools as certlint or cablint?
> 3) What processes and procedures are in place at Identrust to help ensure
> certificates properly adhere to RFC 5280? Why did these not detect the
> issue? What steps are being taken in the future to provide greater
> assurance of future conformance?
> 
> While it's useful to hear that you've revoked those certificates, it's
> equally useful to help the community understand what, if any, changes that
> Identrust is making. If the answer is "There was a bug, we fixed it," then
> it's useful to understand what, if any, changes are being made to detect
> and/or prevent such bugs in the future.
> 
> Cheers

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

Additional information that might be useful:

These certificates were created during the process of building a new product, 
which has not yet been officially launched and no additional certificates have 
been issued under this profile.  Quarterly audits, comprised of evaluating a 
sampling of certificates, has been conducted; however, due to the fact that a 
revocation order had been issued for these certificates and we have no active 
production certificates for this program, no sampling was warranted.  

With respect to the revocation snafu, because these certificates were not 
production certificates issued to actual subscribers, our standard revocation 
process for “live certificates” does not appear to have been followed; rather, 
an informal emailed request was initiated and was apparently 

Re: Misissued certificates

[Jakob Bohm via dev-security-policy]

On 10/08/2017 20:14, Matthew Hardeman wrote:

Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of 
ev-valid.identrustssl.com

It has a normal 2 year validity period.

Which again sounds like a certificate administratively created to serve as a 
test point certificate for the root programs.



To me, these two facts indicate that Identitrust was being extra careful
about security and having a security mechanism that forced setting
pathlen constraints on all manually issued certificates (to prevent
omitting it from SubCA certificates).

This security-improving precaution unfortunately ran against a formal
rule in the BRs, thus forcing this issue.

I would hope that they have at least kept their original precaution for
CA:TRUE certificates.

P.S.

Can anyone point out a real world X.509 framework that gets confused by
a redundant pathlen:0 in a CA:FALSE certificate?  (Merely to assess the
seriousness of the issue, given that the certificate was already
revoked).

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: Misissued certificates

[Jeremy Rowley via dev-security-policy]

This is interesting.  We had one Sub CA who mis-issued some pre-certs but
then never issued an actual certificate tied to the pre-certificate.  There
was a previous Mozilla discussion (link coming) where mis-issuance of a
pre-certificate was akin to mis-issuance of the certificate itself.  The
pre-certificates were later revoked at our request.  If no actual
certificate issued, the pre-cert falls out of scope of the BRs right? Since
it can't be used for actual server transactions thanks to the poison
extensions? Obviously they still fall within the Mozilla policy as they
contain serverAuth in the EKU.  However, should they be reported as issues
and should they be revoked in accordance with the BR?

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, August 10, 2017 10:44 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Misissued certificates

On Thursday, 10 August 2017 16:55:22 UTC+1, iden...@gmail.com  wrote:
> certificates contain the issue.  Three (3) of these are real 
> certificates; however, one has expired. We have revoked the other two 
> certificates. The remaining two (2) are pre-certificates.

To clear this up for anybody who didn't go look: They're specifically
pre-certificates _for_ the other two certificates, so there is nothing
further here that could be revoked.

And as Ryan writes, what we'd want to see here in m.d.s.policy isn't
revocations (though those are required by the BRs anyway so we do expect
them) but an investigation of what went wrong and a summary of what was done
to ensure we won't be back here reading about the same problems at the same
CAs.

Like an Accident Investigator my focus is not on "punishing the guilty" but
on the Prevention of Future Harm. We can't undo the fact that a certificate
was mis-issued, but we can try to reduce the number of future mis-issuances
by learning from past mistakes and putting in place technologies, policies
and practices that avoid mis-issuance in the future.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Matthew Hardeman via dev-security-policy]

Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of 
ev-valid.identrustssl.com

It has a normal 2 year validity period.

Which again sounds like a certificate administratively created to serve as a 
test point certificate for the root programs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Matthew Hardeman via dev-security-policy]

I don't know whether it was noticed or if it matters to anyone, but I did note 
that for at least one of these certificates, particularly the one at 
https://crt.sh/?id=92235996 , that the sole SAN dnsName for the certificate is 
ev-expired.identrustssl.com.

The cert also had a whopping 24 hours of validity.

I am positing that this certificate, at least, was administratively created by 
Identrust in order to provide a certificate test point of the expired 
certificate type, as many root programs require for inclusion, etc.

While I imagine that this is not necessarily relevant to whether there's a BR 
issue, it may at least inform how the certificate came about, if that is of 
interest.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Nick Lamb via dev-security-policy]

On Thursday, 10 August 2017 16:55:22 UTC+1, iden...@gmail.com  wrote:
> certificates contain the issue.  Three (3) of these are real certificates;
> however, one has expired. We have revoked the other two certificates. The
> remaining two (2) are pre-certificates.

To clear this up for anybody who didn't go look: They're specifically 
pre-certificates _for_ the other two certificates, so there is nothing further 
here that could be revoked.

And as Ryan writes, what we'd want to see here in m.d.s.policy isn't 
revocations (though those are required by the BRs anyway so we do expect them) 
but an investigation of what went wrong and a summary of what was done to 
ensure we won't be back here reading about the same problems at the same CAs.

Like an Accident Investigator my focus is not on "punishing the guilty" but on 
the Prevention of Future Harm. We can't undo the fact that a certificate was 
mis-issued, but we can try to reduce the number of future mis-issuances by 
learning from past mistakes and putting in place technologies, policies and 
practices that avoid mis-issuance in the future.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > What's it going to take for mozilla to set up near real-time
> > monitoring/auditing of certs showing up in ct logs?
> >
> > Lee
> >
> > On 8/9/17, Alex Gaynor via dev-security-policy
> >  wrote:
> > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
> mail
> > > was to IdenTrust)
> > >
> > > Hi,
> > >
> > > The following certificates appear to be misissued:
> > >
> > > https://crt.sh/?id=77893170=cablint
> > > https://crt.sh/?id=77947625=cablint
> > > https://crt.sh/?id=78102129=cablint
> > > https://crt.sh/?id=92235995=cablint
> > > https://crt.sh/?id=92235998=cablint
> > >
> > > All of these certificates have a pathLenConstraint value with CA:FALSE,
> > > this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> > > pathLenConstraint field unless the cA boolean is asserted and the key
> usage
> > > extension asserts the keyCertSign bit.
> > >
> > > Alex
> > >
> > > --
> > > "I disapprove of what you say, but I will defend to the death your
> right to
> > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > "The people's good is the highest law." -- Cicero
> > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > >
> > >
> > >
> > >
> > > --
> > > "I disapprove of what you say, but I will defend to the death your
> right to
> > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > "The people's good is the highest law." -- Cicero
> > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > > ___
> > > dev-security-policy mailing list
> > > dev-security-policy@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> We aware of this situation and had previously introduced logic into our
> certificate authority that a pathLengthConstraint will never be set for a
> certificate other than a CA.  We have confirmed that only the stated
> five (5)
> certificates contain the issue.  Three (3) of these are real certificates;
> however, one has expired. We have revoked the other two certificates. The
> remaining two (2) are pre-certificates.


It might be helpful if you can share more details regarding this situation,
to better help the community understand the procedures Identrust has in
place.

1) Were you aware of this issue before it was reported? It's unclear, based
on this reply, whether this was something you were previously aware of,
given the logic you mentioning having introduced.
2) Given this issue, have you examined other Identrust-issued certificates
for issues - for example, running the corpus of issued certificates over
the past year (whether from your own DB or logged in CT) - for other forms
of violations, such as by using tools as certlint or cablint?
3) What processes and procedures are in place at Identrust to help ensure
certificates properly adhere to RFC 5280? Why did these not detect the
issue? What steps are being taken in the future to provide greater
assurance of future conformance?

While it's useful to hear that you've revoked those certificates, it's
equally useful to help the community understand what, if any, changes that
Identrust is making. If the answer is "There was a bug, we fixed it," then
it's useful to understand what, if any, changes are being made to detect
and/or prevent such bugs in the future.

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

Re: Misissued certificates

[Alex Gaynor via dev-security-policy]

Hi IdenTrust,

When you say that the remaining two are pre-certificates, are you asserting
that no corresponding certificate was ever issued? Or merely that we can't
prove one was based on what's in the existing CT logs?

Alex

On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > What's it going to take for mozilla to set up near real-time
> > monitoring/auditing of certs showing up in ct logs?
> >
> > Lee
> >
> > On 8/9/17, Alex Gaynor via dev-security-policy
> >  wrote:
> > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
> mail
> > > was to IdenTrust)
> > >
> > > Hi,
> > >
> > > The following certificates appear to be misissued:
> > >
> > > https://crt.sh/?id=77893170=cablint
> > > https://crt.sh/?id=77947625=cablint
> > > https://crt.sh/?id=78102129=cablint
> > > https://crt.sh/?id=92235995=cablint
> > > https://crt.sh/?id=92235998=cablint
> > >
> > > All of these certificates have a pathLenConstraint value with CA:FALSE,
> > > this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> > > pathLenConstraint field unless the cA boolean is asserted and the key
> usage
> > > extension asserts the keyCertSign bit.
> > >
> > > Alex
> > >
> > > --
> > > "I disapprove of what you say, but I will defend to the death your
> right to
> > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > "The people's good is the highest law." -- Cicero
> > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > >
> > >
> > >
> > >
> > > --
> > > "I disapprove of what you say, but I will defend to the death your
> right to
> > > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > > "The people's good is the highest law." -- Cicero
> > > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > > ___
> > > dev-security-policy mailing list
> > > dev-security-policy@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> We aware of this situation and had previously introduced logic into our
> certificate authority that a pathLengthConstraint will never be set for a
> certificate other than a CA.  We have confirmed that only the stated
> five (5)
> certificates contain the issue.  Three (3) of these are real certificates;
> however, one has expired. We have revoked the other two certificates. The
> remaining two (2) are pre-certificates.
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

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

On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> What's it going to take for mozilla to set up near real-time
> monitoring/auditing of certs showing up in ct logs?
> 
> Lee
> 
> On 8/9/17, Alex Gaynor via dev-security-policy
>  wrote:
> > (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> > was to IdenTrust)
> >
> > Hi,
> >
> > The following certificates appear to be misissued:
> >
> > https://crt.sh/?id=77893170=cablint
> > https://crt.sh/?id=77947625=cablint
> > https://crt.sh/?id=78102129=cablint
> > https://crt.sh/?id=92235995=cablint
> > https://crt.sh/?id=92235998=cablint
> >
> > All of these certificates have a pathLenConstraint value with CA:FALSE,
> > this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> > pathLenConstraint field unless the cA boolean is asserted and the key usage
> > extension asserts the keyCertSign bit.
> >
> > Alex
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right to
> > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > "The people's good is the highest law." -- Cicero
> > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> >
> >
> >
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right to
> > say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > "The people's good is the highest law." -- Cicero
> > GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
We aware of this situation and had previously introduced logic into our
certificate authority that a pathLengthConstraint will never be set for a
certificate other than a CA.  We have confirmed that only the stated 
five (5)
certificates contain the issue.  Three (3) of these are real certificates;
however, one has expired. We have revoked the other two certificates. The
remaining two (2) are pre-certificates.
 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued certificates

[J.C. Jones via dev-security-policy]

Lee,

Different parts of Mozilla does monitor CT, both for internal IT
purposes, as well as research into the WebPKI. It seems like crt.sh does
a great job already of handling cablint/x509lint of newly-observed certs.

What are you looking for Mozilla to provide here that isn't already
being accomplished by the community (e.g., crt.sh, censys.io, and others)?

Thanks,
J.C.

On 8/9/17 9:23 PM, Lee via dev-security-policy wrote:
> What's it going to take for mozilla to set up near real-time
> monitoring/auditing of certs showing up in ct logs?
>
> Lee
>
> On 8/9/17, Alex Gaynor via dev-security-policy
>  wrote:
>> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
>> was to IdenTrust)
>>
>> Hi,
>>
>> The following certificates appear to be misissued:
>>
>> https://crt.sh/?id=77893170=cablint
>> https://crt.sh/?id=77947625=cablint
>> https://crt.sh/?id=78102129=cablint
>> https://crt.sh/?id=92235995=cablint
>> https://crt.sh/?id=92235998=cablint
>>
>> All of these certificates have a pathLenConstraint value with CA:FALSE,
>> this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
>> pathLenConstraint field unless the cA boolean is asserted and the key usage
>> extension asserts the keyCertSign bit.
>>
>> Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right to
>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>>
>>
>>
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right to
>> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
> ___
> 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: Misissued certificates

[Lee via dev-security-policy]

What's it going to take for mozilla to set up near real-time
monitoring/auditing of certs showing up in ct logs?

Lee

On 8/9/17, Alex Gaynor via dev-security-policy
 wrote:
> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> was to IdenTrust)
>
> Hi,
>
> The following certificates appear to be misissued:
>
> https://crt.sh/?id=77893170=cablint
> https://crt.sh/?id=77947625=cablint
> https://crt.sh/?id=78102129=cablint
> https://crt.sh/?id=92235995=cablint
> https://crt.sh/?id=92235998=cablint
>
> All of these certificates have a pathLenConstraint value with CA:FALSE,
> this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> pathLenConstraint field unless the cA boolean is asserted and the key usage
> extension asserts the keyCertSign bit.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy