Re: Misissued certificates

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

Lee

On 8/9/17, Alex Gaynor via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> was to IdenTrust)
>
> Hi,
>
> The following certificates appear to be misissued:
>
> https://crt.sh/?id=77893170&opt=cablint
> https://crt.sh/?id=77947625&opt=cablint
> https://crt.sh/?id=78102129&opt=cablint
> https://crt.sh/?id=92235995&opt=cablint
> https://crt.sh/?id=92235998&opt=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
>
0
Lee
8/10/2017 4:23:45 AM
mozilla.dev.security.policy 1159 articles. 1 followers. Post Follow

14 Replies
56 Views

Similar Articles

[PageSpeed] 2

On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> What's it going to take for mozilla to set up near real-time
> monitoring/auditing of certs showing up in ct logs?
> 
> Lee
> 
> On 8/9/17, Alex Gaynor via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> > (Whoops, accidentally originally CC'd to m.d.s originally! Original mail
> > was to IdenTrust)
> >
> > Hi,
> >
> > The following certificates appear to be misissued:
> >
> > https://crt.sh/?id=77893170&opt=cablint
> > https://crt.sh/?id=77947625&opt=cablint
> > https://crt.sh/?id=78102129&opt=cablint
> > https://crt.sh/?id=92235995&opt=cablint
> > https://crt.sh/?id=92235998&opt=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.
 
0
identrust
8/10/2017 3:55:11 PM
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
> > <dev-security-policy@lists.mozilla.org> wrote:
> > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
> mail
> > > was to IdenTrust)
> > >
> > > Hi,
> > >
> > > The following certificates appear to be misissued:
> > >
> > > https://crt.sh/?id=77893170&opt=cablint
> > > https://crt.sh/?id=77947625&opt=cablint
> > > https://crt.sh/?id=78102129&opt=cablint
> > > https://crt.sh/?id=92235995&opt=cablint
> > > https://crt.sh/?id=92235998&opt=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
>
0
Alex
8/10/2017 4:19:05 PM
On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > What's it going to take for mozilla to set up near real-time
> > monitoring/auditing of certs showing up in ct logs?
> >
> > Lee
> >
> > On 8/9/17, Alex Gaynor via dev-security-policy
> > <dev-security-policy@lists.mozilla.org> wrote:
> > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
> mail
> > > was to IdenTrust)
> > >
> > > Hi,
> > >
> > > The following certificates appear to be misissued:
> > >
> > > https://crt.sh/?id=77893170&opt=cablint
> > > https://crt.sh/?id=77947625&opt=cablint
> > > https://crt.sh/?id=78102129&opt=cablint
> > > https://crt.sh/?id=92235995&opt=cablint
> > > https://crt.sh/?id=92235998&opt=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
0
Ryan
8/10/2017 4:20:36 PM
My apologies, it was pointed out to me off list that two of these are
pre-certs for other certs in that batch.

Alex

On Thu, Aug 10, 2017 at 12:19 PM, Alex Gaynor <agaynor@mozilla.com> wrote:

> 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
>> > <dev-security-policy@lists.mozilla.org> wrote:
>> > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
>> mail
>> > > was to IdenTrust)
>> > >
>> > > Hi,
>> > >
>> > > The following certificates appear to be misissued:
>> > >
>> > > https://crt.sh/?id=77893170&opt=cablint
>> > > https://crt.sh/?id=77947625&opt=cablint
>> > > https://crt.sh/?id=78102129&opt=cablint
>> > > https://crt.sh/?id=92235995&opt=cablint
>> > > https://crt.sh/?id=92235998&opt=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
>>
>
>
0
Alex
8/10/2017 4:24:32 PM
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-c=
ertificates _for_ the other two certificates, so there is nothing further h=
ere that could be revoked.

And as Ryan writes, what we'd want to see here in m.d.s.policy isn't revoca=
tions (though those are required by the BRs anyway so we do expect them) bu=
t an investigation of what went wrong and a summary of what was done to ens=
ure 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 certificat=
e was mis-issued, but we can try to reduce the number of future mis-issuanc=
es by learning from past mistakes and putting in place technologies, polici=
es and practices that avoid mis-issuance in the future.
0
Nick
8/10/2017 4:43:52 PM
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.
0
Matthew
8/10/2017 6:11:26 PM
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.
0
Matthew
8/10/2017 6:14:46 PM
------=_NextPart_000_0435_01D311D5.175E2B30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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-policy@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

------=_NextPart_000_0435_01D311D5.175E2B30
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD3cw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFZjCCBE6gAwIBAgIQ
C4B3By87NWBjv2prStoEyDANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTUxMDEzMDAwMDAwWhcNMTkwMTEwMTIwMDAwWjCBgTEL
MAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxDTALBgNVBAcTBExlaGkxETAPBgNVBAoTCERpZ2lD
ZXJ0MRYwFAYDVQQDEw1KZXJlbXkgUm93bGV5MSkwJwYJKoZIhvcNAQkBFhpqZXJlbXkucm93bGV5
QGRpZ2ljZXJ0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPJD3aoxfpY1uYfF
u5kKTI2hpWfWAy2E7VM3EI5e9b0SODOlkomYlH27ngILqbEJ8b5fActAXcFZl5ziAFL6qRas2YTS
HPAxhzPrr14E+PmqEL5/aj5bdOAjeYcxPxhVb6rN53loBn5M6dWeR+kYqjaEzs3Q1sq9PUPBs5tY
1vZU6rF9HMaqKGLZNvaKKtdgb21c9CY4LbeBK3adu207YddQmrpSVA0U9/WCywMIkdG8N3jLvAws
rlwMFQ+vFMd91G4GFPbr8hcQYSfN0k/tWsNK+BOomE5UJyrWIxKDcJYn4ZMJuMUvpUB7k4q6SRkR
VeNoXZfQLVkCkRrglAS+RHcCAwEAAaOCAfMwggHvMB8GA1UdIwQYMBaAFOcCI4AAT9jXvJQL2T90
OUkyPIp5MB0GA1UdDgQWBBTxLS35I9rcAKGmBG/IIsVlfEFvBzAMBgNVHRMBAf8EAjAAMCUGA1Ud
EQQeMByBGmplcmVteS5yb3dsZXlAZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB
BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo
dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g
O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu
Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t
MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz
dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCsuDvp30eNIwYCBZWqJl+9t67A7Jz/zE+8
QPcGn/yvyUqpH4ve9/Pax9CF8cHBBv53uuuMA5quLWfRHxZE9nBr9PorW3AgxE3nrvW6jo+vy214
mI/RAc8kRU3GYoeDQSFRKUxHBCGXxXzVp98g6HGOivcGRWjOFCiwKrJzdMWBCgjZEhbFr9Tpf/Cd
6d+twH/j67MMas3ozImL7ItJxWDxVDG8vdNQq5nv5+MaSCee5i1stvGLITRYqfLCDpgnVSXCfSlO
uWJYxeQ9HFshZOMbJSoR8+sdyysKkJqXncVht82CVXGqi7k8mUqmnsMyeavKh/rrJ5pJm/rXBf0g
xQ+wMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD
VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t
MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN
MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD
VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg
Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U
FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ
xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/
vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG
2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9
CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0
BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD
VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE
Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl
ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq
MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy
dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo
AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA
YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv
AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA
cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5
ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A
IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK
eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ
J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ
FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y
D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh
7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f
ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCA78wggO7AgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT
BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb
RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMA0GCWCGSAFlAwQC
AQUAoIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MTAx
ODM1MDRaMC8GCSqGSIb3DQEJBDEiBCBXUl3xiuuFVPfUuX8zYRdCm1jHqFyN6T0KuBDEOkBR1jCB
iAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkw
FwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQg
SUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwgYoGCyqGSIb3DQEJEAILMXugeTBlMQswCQYDVQQGEwJV
UzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD
VQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwgZMGCSqG
SIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCG
SAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwCwYJYIZIAWUDBAIBMAsGCWCG
SAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEAP+BWn5dc4wyV
NT14VJxLoAfWn2ok5/mn/CoN7gE83NIRHg4N8qZpoPWnN+ynYYUUjPaNcXZ8jatzpIoV84S2gxTV
iIK9EWFFzneYcHCtlEIMTJoD/y0uHnIzTx2Xnou50/vjALmsPtOq9WTBq2zXs7xKurKzuhBu5Rb6
ejklsKYmcY4Hxttb8nkrNtfod8ADLWElro7J/mfBvEKoDJj9aOnVAe7khFc7NHGWuSd47Ff0RUlv
n81jm6wz9eE+uV355l1ENH8VmGRJ22ciFMFOWh5pgr0zrHYAiMZUlOo7eo0s/GJodQ7Z6lJfBh6m
u/lfttnORUVLmUAgkUW6WztWrQAAAAAAAA==

------=_NextPart_000_0435_01D311D5.175E2B30--
0
Jeremy
8/10/2017 6:35:05 PM
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
0
Jakob
8/10/2017 9:04:34 PM
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:
>=20
> > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote:
> > > What's it going to take for mozilla to set up near real-time
> > > monitoring/auditing of certs showing up in ct logs?
> > >
> > > Lee
> > >
> > > On 8/9/17, Alex Gaynor via dev-security-policy
> > > <dev-security-policy@lists.mozilla.org> wrote:
> > > > (Whoops, accidentally originally CC'd to m.d.s originally! Original
> > mail
> > > > was to IdenTrust)
> > > >
> > > > Hi,
> > > >
> > > > The following certificates appear to be misissued:
> > > >
> > > > https://crt.sh/?id=3D77893170&opt=3Dcablint
> > > > https://crt.sh/?id=3D77947625&opt=3Dcablint
> > > > https://crt.sh/?id=3D78102129&opt=3Dcablint
> > > > https://crt.sh/?id=3D92235995&opt=3Dcablint
> > > > https://crt.sh/?id=3D92235998&opt=3Dcablint
> > > >
> > > > All of these certificates have a pathLenConstraint value with CA:FA=
LSE,
> > > > this violates 4.2.1.9 of RFC 5280: CAs MUST NOT include the
> > > > pathLenConstraint field unless the cA boolean is asserted and the k=
ey
> > 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 certificat=
es;
> > however, one has expired. We have revoked the other two certificates. T=
he
> > remaining two (2) are pre-certificates.
>=20
>=20
> It might be helpful if you can share more details regarding this situatio=
n,
> to better help the community understand the procedures Identrust has in
> place.
>=20
> 1) Were you aware of this issue before it was reported? It's unclear, bas=
ed
> 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 certificate=
s
> 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 form=
s
> 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?
>=20
> 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 tha=
t
> Identrust is making. If the answer is "There was a bug, we fixed it," the=
n
> it's useful to understand what, if any, changes are being made to detect
> and/or prevent such bugs in the future.
>=20
> Cheers

Your questions are reasonable.  Here is additional information to address y=
our follow up comments.  IdenTrust did identify this situation during a rou=
tine audit in March of 2017.  The fix mentioned previously was put into pla=
ce at that time.  The certificates (which are all internal to IdenTrust) we=
re reissued and those that were incorrect were intended to be revoked; unfo=
rtunately the revocation did not occur. =20

Additional information that might be useful:

These certificates were created during the process of building a new produc=
t, which has not yet been officially launched and no additional certificate=
s have been issued under this profile.  Quarterly audits, comprised of eval=
uating 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 wa=
rranted. =20

With respect to the revocation snafu, because these certificates were not p=
roduction certificates issued to actual subscribers, our standard revocatio=
n process for =E2=80=9Clive certificates=E2=80=9D does not appear to have b=
een followed; rather, an informal emailed request was initiated and was app=
arently overlooked.  We have addressed this internally and put remediation =
steps into place that will alleviate this possibility in the future.
0
identrust
8/10/2017 9:26:44 PM
> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy =
<dev-security-policy@lists.mozilla.org> wrote:
>=20
> 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

0
Jonathan
8/10/2017 10:29:45 PM
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?

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
0
Jakob
8/11/2017 2:43:16 AM
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
0
Paul
8/11/2017 3:11:22 AM
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
0
Gervase
8/15/2017 1:33:47 PM
Reply: