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

2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

[josh--- via dev-security-policy]

At 11:30am PST on August 10, 2017, Let’s Encrypt was made aware of a compliance 
issue regarding unicode normalization of domain names. During the same day we 
were made aware of the issue, all unexpired non-compliant certificates were 
found and revoked, a fix was applied to our CA systems, and we communicated 
with our community. We consider the matter to be fully resolved at this point, 
please let us know if we missed anything.

We were notified by a community member that Let's Encrypt had issued a number 
of certificates containing punycode domain names which had not undergone 
compliant unicode normalization. We confirmed that this was the case and began 
investigating our code and the relevant RFCs.

We noticed that the code we added to check the validity of punycode encodings 
in CSRs when we implemented support for IDNs didn't enforce any form of Unicode 
Normalization. We started developing a fix. After seeking outside insight into 
the issue and reading the relevant reference documents we came to the 
conclusion that Normalization Form KC was required. The BRs reference RFC 5280, 
which in turn references the encoding specified in RFC 3490 for IDNs, which 
requires Normalization Form KC. We finished our fix and deployed it to our CA 
at 5:20PM PST.

While developing the fix we searched our issuance databases for all unexpired 
certificates containing punycode DNS names and checked them for non-NFKC 
compliant names. We found 16, which are listed below. We revoked these 
certificates and notified the subscribers who requested them.

I would like to thank the community members that discovered this issue, as well 
as the Let's Encrypt team that worked hard to resolve it quickly.

--
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA

Serial numbers of affected and revoked certificates:

03d03877cbcec666b81340ed6a39c47556d1
03758d04a7816ba893847658e636a58e1f71
03ef82538ca2e54e97ae2b180ecb32f8cee4
044568f36455d8847713adb24c69e60bf123
033e73ebfd2f270bc6109925f1ed40edca8b
038295d240613cdb9367506c0d3cf8002401
03556fbc38b13ea3a9b7f4dd59dacc350293
030cfe12721e17ca02c095b4a0c5e60ca8da
03ca6617e634f2f5ad9224ca32ca4c835909
03bd090cfe0fbd07b4fc60df07bbc5770b35
0314017b4eab87bb0f211e9e2bb329ca4297
03f48a8c02c473ce971236b6407ad7d00d89
03bfa7b8f318a30a88894523ebd2717ea9b4
032d7c46b0a815faa41a1876fed4d66a9993
039f94badc798eea44f8c81ceb0515024871
038f81a32455e41b702ffb1732186be3a007
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with improperly normalized IDNs

[Jakob Bohm via dev-security-policy]

On 11/08/2017 00:14, Ryan Sleevi wrote:

On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


This raises the question if CAs should be responsible for misissued
domain names, or if they should be allowed to issue certificates to
actually existing DNS names.



No. It doesn't. That's been addressed several times in the CA/Browser Forum
with other forms of 'invalid' (non-preferred name syntax) domain names,
such as those with underscores.
> It's not permitted under RFC 5280, thus, CAs are responsible. Full stop.



As an aside (not applicable to this case), it is worth noting that some
newer RFCs explicitly require DNS names with underscores, though
currently only for things that won't to go in a certificate dnsName SAN
extension.




I don't know if the bad punycode encodings are in the 2nd level names (a
registrar/registry responsibility, both were from 2012 or before) or in
the 3rd level names (locally created at an unknown date).

An online utility based on the older RFC349x round trips all of these.
So if the issue is only compatibility with a newer RFC not referenced from
the current BRs, these would probably be OK under the current BRs and
certLint needs to accept them.



No, it's a newer RFC not referenced in RFC 5280, so it's not permitted
under the current BRs.

There's no retroactive immunity.



As you could see, in the snipped part of my posting, I was checking the
wrong name from the certificate and concluding that it was apparently
valid under RFC349x, which Jonathan wrote was the one referenced by the
BRs.  Therefore I mistook the report for complaining that the encoding
was not valid under RFC5890, which is not referenced by the BRs.

In a later post, Jonathan explained that the problematic name was a
different one which I did not look at.



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 with improperly normalized IDNs

[Jakob Bohm via dev-security-policy]

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



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

On 10/08/2017 22:22, Jonathan Rudenberg wrote:

RFC 5280 section 7.2 and the associated IDNA RFC requires that 
Internationalized Domain Names are normalized before encoding to punycode.
Let’s Encrypt appears to have issued at least three certificates that have at 
least one dnsName without the proper Unicode normalization applied.
https://crt.sh/?id=187634027=cablint
https://crt.sh/?id=187628042=cablint
https://crt.sh/?id=173493962=cablint
It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
requires normalization form KC, but RFC 5891 which replaces RFC 3491 requires 
normalization form C. I believe that the BRs and/or RFC 5280 should be updated 
to reference RFC 5890 and by extension RFC 5891 instead.
Jonathan


All 3 dnsName values exist in the DNS and point to the same server (IP
address). Whois says that the two second level names are both registered
to OOO "JilfondService" .

This raises the question if CAs should be responsible for misissued
domain names, or if they should be allowed to issue certificates to
actually existing DNS names.

I don't know if the bad punycode encodings are in the 2nd level names (a
registrar/registry responsibility, both were from 2012 or before) or in
the 3rd level names (locally created at an unknown date).

An online utility based on the older RFC349x round trips all of these.
So if the issue is only compatibility with a newer RFC not referenced from the 
current BRs, these would probably be OK under the current BRs and certLint 
needs to accept them.


In this case, the NFC and NFKC representations are the same:

$ irb
irb(main):001:0> require 'simpleidn'
=> true
irb(main):002:0> a = "xn--109-3veba6djs1bfxlfmx6c9g"
=> "xn--109-3veba6djs1bfxlfmx6c9g"
irb(main):003:0> u = SimpleIDN.to_unicode(a)
=> "؈؜ب1؈ؘؑ؞؈ءؒؔ0؛9ؘؚ؜"
irb(main):004:0> u.unicode_normalize(:nfc) == a
=> false
irb(main):005:0> u.unicode_normalize(:nfc) == u.unicode_normalize(:nfkc)
=> true
irb(main):006:0> n = SimpleIDN.to_ascii(u.unicode_normalize(:nfc))
=> "xn--109-3veba6djs0bgykfmx6c9g"
irb(main):007:0> n == a
=> false



Ah, I missed that this was about one of many extra SANs in the
certificate, not the main name, as this was not previously reported and
I don't have the tools handy to easily go through all those SANs myself.


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

[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: Certificates with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

On 11/08/2017 00:12, Ryan Sleevi wrote:

Could you explain how it benefits Mozilla users to optimize for OV or EV,
given that it does not provide any additional security value?



Of all the browsers I have tried, Firefox is the one that most
aggressively promotes EV certificates, going to the extent of displaying
unhelpful status messages ("This website does not supply ownership
information") for OV and DV certificates.


It seems far better for the security of users, and the ecosystem, to have
such certificates revoked in 24 hours. If the subscriber's selection of
certificate type (e.g. OV or EV) makes it difficult to replace, then that's
a market choice they've made, given that it offers no objective security
value over DV, and it being possible to replace that certificate with a DV
certificate in a timely fashion.


Note that I was considering the desirability of the subscriber switching
CAs in response to such events (others have argued for that in this
thread).  If the subscriber switches to a different CA, that CA has no
validation data on file.

Also, the way the BRs specify the validation data reuse period and the
maximum certificate validity period, they encourage the creation of
situations where certificates expire long after the validation data
reuse limit.  Some CAs go out of their way to avoid that, but it is not
a BR requirement.



24 hours is enough for most subscribers to get a reissued certificate. I
don't think we should speculate about what cost it is (that's between them
and the CA) or their selection of validation type (of which, for objective
security value, only the domain name matters).



The only cost consideration I mentioned was a strong suggestion that if
the original CA issues the replacement certificate, the CA should bear
the cost.



On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


But that would require the issuer of the replacement cert (which might
not be a fast-issue DV cert) to complete validation in something like 36
hours, which is much shorter than the normal time taken to do proper OV
and/or EV validation.

I have previously suggested 14 days for live certificates that don't
cause actual security issues.  This would be enough for most subscribers
to either get a reissued certificate (for free) from the original CA or
set up an account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:


No objection to 72 hours v. 1 business day.  I agree it should be short
and
72 hours seems perfectly reasonable .

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
com@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:


All CAS are required to maintain the capability to process and receive


revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their
certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it
does sound like a good solution. However, I think it's another example of
the general difference of opinion between people on this list around
whether
we should be holding CAs to the highest standards or not. These mis-issued
certificates are typically not a security concern, but they speak to
either
ignorance on the part of CA operators or a pattern of lackadaisical
controls
within the issuance systems. Neither of these is acceptable behavior at
this
juncture. Conformance with the BRs has been mandatory for over 5 years
now.
Customers need to be made aware of the failures of their chosen providers
and the responsibilities incumbent upon them as subscribers, and if their
own certificate installation/replacement processes are sufficiently
archaic
as to make it difficult to replace a certificate in an automated fashion
then they should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business
days"
really mean?Does the CA get 1-2 business days followed by 1-2 for the
customer? What if there's a holiday in the CA's country of operations
followed by a holiday in the customer's home country? How quickly does
this
window extend to 2+ weeks? If you were to go down this path I'd strongly
prefer it to be a hard deadline (e.g. 72 hours) and not anything related
to
business days.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

I disagree - 24 hours is enough to reissue the certificate, but  24 hours 
usually isn't enough to contact the subscriber, regardless of cert type. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, August 10, 2017 4:13 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-policy 
Subject: Re: Certificates with invalidly long serial numbers

Could you explain how it benefits Mozilla users to optimize for OV or EV, given 
that it does not provide any additional security value?

It seems far better for the security of users, and the ecosystem, to have such 
certificates revoked in 24 hours. If the subscriber's selection of certificate 
type (e.g. OV or EV) makes it difficult to replace, then that's a market choice 
they've made, given that it offers no objective security value over DV, and it 
being possible to replace that certificate with a DV certificate in a timely 
fashion.

24 hours is enough for most subscribers to get a reissued certificate. I don't 
think we should speculate about what cost it is (that's between them and the 
CA) or their selection of validation type (of which, for objective security 
value, only the domain name matters).

On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> But that would require the issuer of the replacement cert (which might 
> not be a fast-issue DV cert) to complete validation in something like 
> 36 hours, which is much shorter than the normal time taken to do 
> proper OV and/or EV validation.
>
> I have previously suggested 14 days for live certificates that don't 
> cause actual security issues.  This would be enough for most 
> subscribers to either get a reissued certificate (for free) from the 
> original CA or set up an account with a competing CA and get at least a basic 
> OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
>
>> No objection to 72 hours v. 1 business day.  I agree it should be 
>> short and
>> 72 hours seems perfectly reasonable .
>>
>> -Original Message-
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
>> com@lists.mozilla
>> .org] On Behalf Of Paul Kehrer via dev-security-policy
>> Sent: Wednesday, August 9, 2017 4:57 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Certificates with invalidly long serial numbers
>>
>> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>>
>>> All CAS are required to maintain the capability to process and 
>>> receive
>>>
>> revocation requests 24x7 under the baseline requirements. The 
>> headache is not with the CA. Rather, it's notifying the customer that 
>> their certificate will be revoked before the start of the next 
>> business day. Having a one to two business day rule  instead of 24 
>> hours for non compromise issues gives the end entity time to receive 
>> the notification and replace their certificate with a compliant 
>> version.
>>
>> I'm sure many customers would absolutely prefer that and on the 
>> surface it does sound like a good solution. However, I think it's 
>> another example of the general difference of opinion between people 
>> on this list around whether we should be holding CAs to the highest 
>> standards or not. These mis-issued certificates are typically not a 
>> security concern, but they speak to either ignorance on the part of 
>> CA operators or a pattern of lackadaisical controls within the 
>> issuance systems. Neither of these is acceptable behavior at this 
>> juncture. Conformance with the BRs has been mandatory for over 5 
>> years now.
>> Customers need to be made aware of the failures of their chosen 
>> providers and the responsibilities incumbent upon them as 
>> subscribers, and if their own certificate installation/replacement 
>> processes are sufficiently archaic as to make it difficult to replace 
>> a certificate in an automated fashion then they should rectify that 
>> immediately.
>>
>> That said, to continue the thought experiment, what does "1-2 
>> business days"
>> really mean?Does the CA get 1-2 business days followed by 1-2 for the 
>> customer? What if there's a holiday in the CA's country of operations 
>> followed by a holiday in the customer's home country? How quickly 
>> does this window extend to 2+ weeks? If you were to go down this path 
>> I'd strongly prefer it to be a hard deadline (e.g. 72 hours) and not 
>> anything related to business days.
>>
>>
>
> 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 
> 

Re: Certificates with improperly normalized IDNs

[Peter Bowen via dev-security-policy]

On Thu, Aug 10, 2017 at 2:31 PM, Jakob Bohm via dev-security-policy
 wrote:
> On 10/08/2017 22:22, Jonathan Rudenberg wrote:
>>
>> RFC 5280 section 7.2 and the associated IDNA RFC requires that
>> Internationalized Domain Names are normalized before encoding to punycode.
>>
>> Let’s Encrypt appears to have issued at least three certificates that have
>> at least one dnsName without the proper Unicode normalization applied.
>>
>> https://crt.sh/?id=187634027=cablint
>> https://crt.sh/?id=187628042=cablint
>> https://crt.sh/?id=173493962=cablint
>>
>> It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490)
>> requires normalization form KC, but RFC 5891 which replaces RFC 3491
>> requires normalization form C. I believe that the BRs and/or RFC 5280 should
>> be updated to reference RFC 5890 and by extension RFC 5891 instead.
>>
>> Jonathan
>>
>
> All 3 dnsName values exist in the DNS and point to the same server (IP
> address). Whois says that the two second level names are both registered
> to OOO "JilfondService" .
>
> This raises the question if CAs should be responsible for misissued
> domain names, or if they should be allowed to issue certificates to
> actually existing DNS names.
>
> I don't know if the bad punycode encodings are in the 2nd level names (a
> registrar/registry responsibility, both were from 2012 or before) or in
> the 3rd level names (locally created at an unknown date).
>
> An online utility based on the older RFC349x round trips all of these.
> So if the issue is only compatibility with a newer RFC not referenced from
> the current BRs, these would probably be OK under the current BRs and
> certLint needs to accept them.
>
> Note: The DNS names are:
>
> xn--80aqafgnbi.xn--b1addckdrqixje4a.xn--p1ai
> xn--80aqafgnbi.xn--f1awi.xn--p1ai
> xn-blcihca2aqinbjzlgp0hrd8c.xn--f1awi.xn--p1ai

These are not the names causing issues.

"xn--109-3veba6djs1bfxlfmx6c9g.xn--b1addckdrqixje4a.xn--p1ai" from
https://crt.sh/?id=187634027=cablint
"xn--109-3veba6djs1bfxlfmx6c9g.xn--f1awi.xn--p1ai" from
https://crt.sh/?id=187628042=cablint
"xn--109-3veba6djs1bfxlfmx6c9g.xn--f1awi.xn--p1ai" from
https://crt.sh/?id=173493962=cablint (same name as the prior cert)

It is the xn--109-3veba6djs1bfxlfmx6c9g label that is incorrect in all
three.  In all three the bad label is not in the registered domain or
any public suffix.

Directly decoded, this string is:

"\u0608\u061c\u0628\u0031\u0608\u0611\u0618\u061e\u0608\u0621\u0612\u0614\u0030\u061b\u0039\u061a\u0618\u061c"

However the string when normalized to NFC is:

"\u0608\u061c\u0628\u0031\u0608\u0618\u0611\u061e\u0608\u0621\u0612\u0614\u0030\u061b\u0039\u0618\u061a\u061c"

If you look carefully, you will see two different pairs of codepoints
that are swapped in the normalized string.

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

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

A couple of people also pointed out that we previously discussed these exact
certs here:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/DgeLqKMzId
s/E9--gj5WEAAJ

The decision then was that we should prevent further issuance of certs with
N/A and other metadata but that revocation was not necessary in this case.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 10, 2017 12:24 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Certificates with metadata-only subject fields

On this particular issue, it's questionable whether these are a violation of
a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field.
Section 7.1.4.2.2(j) defines "Any other subject".

Section 7.1.4.2.2(J) :
"All other optional attributes, when present within the subject field, MUST
contain information that has been verified by the CA. Optional attributes
MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘
(i.e.   space) characters, and/or any other indication that the value is
absent, incomplete, or not applicable."

Because OU is not "all other optional attributes", j doesn't apply. I think
this gives the wrong results and am for disallowing metadata in the OU
field. However, if we're going to be persnickety on the 24 hour rule, we
should be persnickety on the other ones as well.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these non-compliant
certs to be issued, and I expect them to send post-portems to mdsp
explaining what the root cause for these issues was and how they corrected
it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues.  While I
> > appreciate it getting broad usage, I don't think pushing for
> > revocation of every certificate that trips any of the Error level
> > checks
is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it)
> onto the customer (who purchased the certificate), and thus a
> viewpoint that suggests this is somehow unjust (since it's the victim
> of misissuance who suffers), but I think an argument that suggests
> these shouldn't be revoked is similar to an argument that says those
> who purchased stolen merchandise should get to keep it, as long as
> they
didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future
action.
> Sadly, humans are terrible at recognizing those potential long-term
> costs (c.f. obesity/heart disease/dental care/global warming as all
> examples of long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also
> the right incentive - for CAs, and the overall ecosystem - to ensure
> that any misissuance is revoked in a timely fashion (which is
> currently 24 hours), because it helps encourage a market where the
> best step a CA can take to minimize risk to their subscribers, the
> ones actually paying them money and engaging in a business
> relationship with them, is to simply not misissue the 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

RE: Certificates with invalidly long serial numbers

[Jeremy Rowley via dev-security-policy]

Not really - most CAs reuse validation information for the time period
specified under the BRs, which is currently 825 days under section 4.2.1.
The hardest part of the whole process is typically contacting the customer
to start the replacement process. The problem is probably worse for fully
automated CAs who don't necessarily have a close relationship with the
customer, perhaps only an email address that can be used to let them know
their website is about to go down.   

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, August 10, 2017 3:40 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

But that would require the issuer of the replacement cert (which might not
be a fast-issue DV cert) to complete validation in something like 36 hours,
which is much shorter than the normal time taken to do proper OV and/or EV
validation.

I have previously suggested 14 days for live certificates that don't cause
actual security issues.  This would be enough for most subscribers to either
get a reissued certificate (for free) from the original CA or set up an
account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:
> No objection to 72 hours v. 1 business day.  I agree it should be 
> short and
> 72 hours seems perfectly reasonable .
> 
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> ozilla .org] On Behalf Of Paul Kehrer via dev-security-policy
> Sent: Wednesday, August 9, 2017 4:57 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with invalidly long serial numbers
> 
> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>> All CAS are required to maintain the capability to process and 
>> receive
> revocation requests 24x7 under the baseline requirements. The headache 
> is not with the CA. Rather, it's notifying the customer that their 
> certificate will be revoked before the start of the next business day. 
> Having a one to two business day rule  instead of 24 hours for non 
> compromise issues gives the end entity time to receive the 
> notification and replace their certificate with a compliant version.
> 
> I'm sure many customers would absolutely prefer that and on the 
> surface it does sound like a good solution. However, I think it's 
> another example of the general difference of opinion between people on 
> this list around whether we should be holding CAs to the highest 
> standards or not. These mis-issued certificates are typically not a 
> security concern, but they speak to either ignorance on the part of CA 
> operators or a pattern of lackadaisical controls within the issuance 
> systems. Neither of these is acceptable behavior at this juncture.
Conformance with the BRs has been mandatory for over 5 years now.
> Customers need to be made aware of the failures of their chosen 
> providers and the responsibilities incumbent upon them as subscribers, 
> and if their own certificate installation/replacement processes are 
> sufficiently archaic as to make it difficult to replace a certificate 
> in an automated fashion then they should rectify that immediately.
> 
> That said, to continue the thought experiment, what does "1-2 business
days"
> really mean?Does the CA get 1-2 business days followed by 1-2 for the 
> customer? What if there's a holiday in the CA's country of operations 
> followed by a holiday in the customer's home country? How quickly does 
> this window extend to 2+ weeks? If you were to go down this path I'd 
> strongly prefer it to be a hard deadline (e.g. 72 hours) and not 
> anything related to business days.
> 


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


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: TrustCor root inclusion request

[Andrew R. Whalley via dev-security-policy]

Greetings,

I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
following notes:

*CP* (http://www.trustcor.ca/resources/cp.pdf)

1.6.3
1.6.4
Nit:
Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
TrustCor CA makes no authoritative statement, will have either the text “No
stipulation” or “Not Applicable”." but these sections are just blank.

3.3.1
"Level 2 Client certificates - demonstration of a pre-shared key and OTP
validation as described in Section 3.2.3 is sufficient to allow re- key."
however section 3.2.3 makes no mention of pre-shared key and OTP validation.

4.4.2 Publication of the certificate by the CA
Note that is at odds with any future CT requirement.

6.1.5
"OCSP responses may respond using the SHA-1 hash if the request used
SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
(section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
TrustCor does not, and never has, used SHA-1 as a component of any
signature algorithm on a certificate.

6.1.6
This section references version 1.3.0 of the BRs, which date from 2015.

*CPS* (http://www.trustcor.ca/resources/cps.pdf)

1.4.1
The maximum validity of the different certificate types, while within
what's allowed by the BRs, aren't consistent with the limits specified in
section 6.3.2 of the CP (e.g. 12 months vs 398 days).

2.2
https://catest1-revoked.trustcor.ca/ is not resolving.
https://catest1-expired.trustcor.ca/ is not resolving.
https://catest2-revoked.trustcor.ca/ is not resolving.
https://catest2-expired.trustcor.ca/ is not resolving.

2.2.1
Commitment to make incident reports public - very good.
(Note that at the moment
https://www.trustcor.ca/resources/issuance-incidents/ currently just
redirects to the home page)

3.2.2.4.7
Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
will *query* the authoritative DNS servers"

3.2.2.8
Fail shut CAA - good

3.2.6
While it's good that TrustCor will publish cross-signed certificates it
issues to other CAs, my understanding of section 3.2.6 of the BRs is that
it requires cross certifications that a CA obtains from other CAs (i.e.
where it is the Subject of the cert) to be published.

4.9.1.1
Even though section 4.9.2 states that a subscriber can request revocation
of their certificate, 4.9.1.1 does not list a subscriber request as a
reason for revocation.

4.9.1.2
I would like to hope that there are technical, not just business, controls
in place to limit the actions an "insufficiently aware staff member" could
perform.

7.1.2.2
Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
MUST be present and SHOULD NOT be marked critical." for Subordinate CA
Certificates, however this section implies that certificatePolicies is only
specified for Enterprise Subordinate CAs.

7.1.2.3
For the Secure Mail profiles, the subjectAlternativeName is defined as
containing an "emailAddress". Should this not be rfc822Name?

7.1.2.4
It seems odd that this section references itself and 7.1.2.5.  Where these
meant to be 7.1.2.2 and 7.1.2.3?

The CP requires the subject key identifier and authority key identifier
extensions, but these are not specified in the cert profiles in the CPS.

7.1.6.3
This seems at odds with 7.1.2.2 of the BRs.

Those comments aside, I found both documents clear, well written, and they
provided sufficient detail to assess the policies in place.

Many thanks,

Andrew
___
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: Certificates with improperly normalized IDNs

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> This raises the question if CAs should be responsible for misissued
> domain names, or if they should be allowed to issue certificates to
> actually existing DNS names.
>

No. It doesn't. That's been addressed several times in the CA/Browser Forum
with other forms of 'invalid' (non-preferred name syntax) domain names,
such as those with underscores.

It's not permitted under RFC 5280, thus, CAs are responsible. Full stop.


> I don't know if the bad punycode encodings are in the 2nd level names (a
> registrar/registry responsibility, both were from 2012 or before) or in
> the 3rd level names (locally created at an unknown date).
>
> An online utility based on the older RFC349x round trips all of these.
> So if the issue is only compatibility with a newer RFC not referenced from
> the current BRs, these would probably be OK under the current BRs and
> certLint needs to accept them.
>

No, it's a newer RFC not referenced in RFC 5280, so it's not permitted
under the current BRs.

There's no retroactive immunity.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

[Ryan Sleevi via dev-security-policy]

Could you explain how it benefits Mozilla users to optimize for OV or EV,
given that it does not provide any additional security value?

It seems far better for the security of users, and the ecosystem, to have
such certificates revoked in 24 hours. If the subscriber's selection of
certificate type (e.g. OV or EV) makes it difficult to replace, then that's
a market choice they've made, given that it offers no objective security
value over DV, and it being possible to replace that certificate with a DV
certificate in a timely fashion.

24 hours is enough for most subscribers to get a reissued certificate. I
don't think we should speculate about what cost it is (that's between them
and the CA) or their selection of validation type (of which, for objective
security value, only the domain name matters).

On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> But that would require the issuer of the replacement cert (which might
> not be a fast-issue DV cert) to complete validation in something like 36
> hours, which is much shorter than the normal time taken to do proper OV
> and/or EV validation.
>
> I have previously suggested 14 days for live certificates that don't
> cause actual security issues.  This would be enough for most subscribers
> to either get a reissued certificate (for free) from the original CA or
> set up an account with a competing CA and get at least a basic OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
>
>> No objection to 72 hours v. 1 business day.  I agree it should be short
>> and
>> 72 hours seems perfectly reasonable .
>>
>> -Original Message-
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
>> com@lists.mozilla
>> .org] On Behalf Of Paul Kehrer via dev-security-policy
>> Sent: Wednesday, August 9, 2017 4:57 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Certificates with invalidly long serial numbers
>>
>> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>>
>>> All CAS are required to maintain the capability to process and receive
>>>
>> revocation requests 24x7 under the baseline requirements. The headache is
>> not with the CA. Rather, it's notifying the customer that their
>> certificate
>> will be revoked before the start of the next business day. Having a one to
>> two business day rule  instead of 24 hours for non compromise issues gives
>> the end entity time to receive the notification and replace their
>> certificate with a compliant version.
>>
>> I'm sure many customers would absolutely prefer that and on the surface it
>> does sound like a good solution. However, I think it's another example of
>> the general difference of opinion between people on this list around
>> whether
>> we should be holding CAs to the highest standards or not. These mis-issued
>> certificates are typically not a security concern, but they speak to
>> either
>> ignorance on the part of CA operators or a pattern of lackadaisical
>> controls
>> within the issuance systems. Neither of these is acceptable behavior at
>> this
>> juncture. Conformance with the BRs has been mandatory for over 5 years
>> now.
>> Customers need to be made aware of the failures of their chosen providers
>> and the responsibilities incumbent upon them as subscribers, and if their
>> own certificate installation/replacement processes are sufficiently
>> archaic
>> as to make it difficult to replace a certificate in an automated fashion
>> then they should rectify that immediately.
>>
>> That said, to continue the thought experiment, what does "1-2 business
>> days"
>> really mean?Does the CA get 1-2 business days followed by 1-2 for the
>> customer? What if there's a holiday in the CA's country of operations
>> followed by a holiday in the customer's home country? How quickly does
>> this
>> window extend to 2+ weeks? If you were to go down this path I'd strongly
>> prefer it to be a hard deadline (e.g. 72 hours) and not anything related
>> to
>> business days.
>>
>>
>
> 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 with improperly normalized IDNs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 10/08/2017 22:22, Jonathan Rudenberg wrote:
>> RFC 5280 section 7.2 and the associated IDNA RFC requires that 
>> Internationalized Domain Names are normalized before encoding to punycode.
>> Let’s Encrypt appears to have issued at least three certificates that have 
>> at least one dnsName without the proper Unicode normalization applied.
>> https://crt.sh/?id=187634027=cablint
>> https://crt.sh/?id=187628042=cablint
>> https://crt.sh/?id=173493962=cablint
>> It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
>> requires normalization form KC, but RFC 5891 which replaces RFC 3491 
>> requires normalization form C. I believe that the BRs and/or RFC 5280 should 
>> be updated to reference RFC 5890 and by extension RFC 5891 instead.
>> Jonathan
> 
> All 3 dnsName values exist in the DNS and point to the same server (IP
> address). Whois says that the two second level names are both registered
> to OOO "JilfondService" .
> 
> This raises the question if CAs should be responsible for misissued
> domain names, or if they should be allowed to issue certificates to
> actually existing DNS names.
> 
> I don't know if the bad punycode encodings are in the 2nd level names (a
> registrar/registry responsibility, both were from 2012 or before) or in
> the 3rd level names (locally created at an unknown date).
> 
> An online utility based on the older RFC349x round trips all of these.
> So if the issue is only compatibility with a newer RFC not referenced from 
> the current BRs, these would probably be OK under the current BRs and 
> certLint needs to accept them.

In this case, the NFC and NFKC representations are the same:

$ irb
irb(main):001:0> require 'simpleidn'
=> true
irb(main):002:0> a = "xn--109-3veba6djs1bfxlfmx6c9g"
=> "xn--109-3veba6djs1bfxlfmx6c9g"
irb(main):003:0> u = SimpleIDN.to_unicode(a)
=> "؈؜ب1؈ؘؑ؞؈ءؒؔ0؛9ؘؚ؜"
irb(main):004:0> u.unicode_normalize(:nfc) == a
=> false
irb(main):005:0> u.unicode_normalize(:nfc) == u.unicode_normalize(:nfkc)
=> true
irb(main):006:0> n = SimpleIDN.to_ascii(u.unicode_normalize(:nfc))
=> "xn--109-3veba6djs0bgykfmx6c9g"
irb(main):007:0> n == a
=> false
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with improperly normalized IDNs

[Roland Bracewell Shoemaker via dev-security-policy]

We are aware of this and are looking into it further.

On 08/10/2017 01:22 PM, Jonathan Rudenberg via dev-security-policy wrote:
> RFC 5280 section 7.2 and the associated IDNA RFC requires that 
> Internationalized Domain Names are normalized before encoding to punycode.
> 
> Let’s Encrypt appears to have issued at least three certificates that have at 
> least one dnsName without the proper Unicode normalization applied.
> 
> https://crt.sh/?id=187634027=cablint
> https://crt.sh/?id=187628042=cablint
> https://crt.sh/?id=173493962=cablint
> 
> It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
> requires normalization form KC, but RFC 5891 which replaces RFC 3491 requires 
> normalization form C. I believe that the BRs and/or RFC 5280 should be 
> updated to reference RFC 5890 and by extension RFC 5891 instead.
> 
> Jonathan
> 
> ___
> 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 with invalidly long serial numbers

[Jakob Bohm via dev-security-policy]

But that would require the issuer of the replacement cert (which might
not be a fast-issue DV cert) to complete validation in something like 36
hours, which is much shorter than the normal time taken to do proper OV
and/or EV validation.

I have previously suggested 14 days for live certificates that don't
cause actual security issues.  This would be enough for most subscribers
to either get a reissued certificate (for free) from the original CA or
set up an account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:

No objection to 72 hours v. 1 business day.  I agree it should be short and
72 hours seems perfectly reasonable .

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:

All CAS are required to maintain the capability to process and receive

revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it
does sound like a good solution. However, I think it's another example of
the general difference of opinion between people on this list around whether
we should be holding CAs to the highest standards or not. These mis-issued
certificates are typically not a security concern, but they speak to either
ignorance on the part of CA operators or a pattern of lackadaisical controls
within the issuance systems. Neither of these is acceptable behavior at this
juncture. Conformance with the BRs has been mandatory for over 5 years now.
Customers need to be made aware of the failures of their chosen providers
and the responsibilities incumbent upon them as subscribers, and if their
own certificate installation/replacement processes are sufficiently archaic
as to make it difficult to replace a certificate in an automated fashion
then they should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days"
really mean?Does the CA get 1-2 business days followed by 1-2 for the
customer? What if there's a holiday in the CA's country of operations
followed by a holiday in the customer's home country? How quickly does this
window extend to 2+ weeks? If you were to go down this path I'd strongly
prefer it to be a hard deadline (e.g. 72 hours) and not anything related to
business days.




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 with improperly normalized IDNs

[Jakob Bohm via dev-security-policy]

On 10/08/2017 22:22, Jonathan Rudenberg wrote:

RFC 5280 section 7.2 and the associated IDNA RFC requires that 
Internationalized Domain Names are normalized before encoding to punycode.

Let’s Encrypt appears to have issued at least three certificates that have at 
least one dnsName without the proper Unicode normalization applied.

https://crt.sh/?id=187634027=cablint
https://crt.sh/?id=187628042=cablint
https://crt.sh/?id=173493962=cablint

It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
requires normalization form KC, but RFC 5891 which replaces RFC 3491 requires 
normalization form C. I believe that the BRs and/or RFC 5280 should be updated 
to reference RFC 5890 and by extension RFC 5891 instead.

Jonathan



All 3 dnsName values exist in the DNS and point to the same server (IP
address). Whois says that the two second level names are both registered
to OOO "JilfondService" .

This raises the question if CAs should be responsible for misissued
domain names, or if they should be allowed to issue certificates to
actually existing DNS names.

I don't know if the bad punycode encodings are in the 2nd level names (a
registrar/registry responsibility, both were from 2012 or before) or in
the 3rd level names (locally created at an unknown date).

An online utility based on the older RFC349x round trips all of these.
So if the issue is only compatibility with a newer RFC not referenced 
from the current BRs, these would probably be OK under the current BRs 
and certLint needs to accept them.


Note: The DNS names are:

xn--80aqafgnbi.xn--b1addckdrqixje4a.xn--p1ai
xn--80aqafgnbi.xn--f1awi.xn--p1ai
xn-blcihca2aqinbjzlgp0hrd8c.xn--f1awi.xn--p1ai

Or broken down into DNS labels:

ICANN tld:

xn--p1ai

Second level domains, registrar is currently RUCENTER-RF

xn--b1addckdrqixje4a
xn--f1awi

Third level domains, subscriber responsibility:

xn--80aqafgnbi
xn-blcihca2aqinbjzlgp0hrd8c


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

[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

Certificates with improperly normalized IDNs

[Jonathan Rudenberg via dev-security-policy]

RFC 5280 section 7.2 and the associated IDNA RFC requires that 
Internationalized Domain Names are normalized before encoding to punycode.

Let’s Encrypt appears to have issued at least three certificates that have at 
least one dnsName without the proper Unicode normalization applied.

https://crt.sh/?id=187634027=cablint
https://crt.sh/?id=187628042=cablint
https://crt.sh/?id=173493962=cablint

It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) 
requires normalization form KC, but RFC 5891 which replaces RFC 3491 requires 
normalization form C. I believe that the BRs and/or RFC 5280 should be updated 
to reference RFC 5890 and by extension RFC 5891 instead.

Jonathan

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

Fwd: Misissued certificates - pathLenConstraint with CA:FALSE

[Daniel Veditz via dev-security-policy]

Forwarding to the right (cert-related) group


 Forwarded Message 
Subject: Misissued certificates - pathLenConstraint with CA:FALSE
Date: Wed, 9 Aug 2017 19:25:31 -0400
From: Alex Gaynor 
To: helpd...@identrust.com, dev-secur...@lists.mozilla.org


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

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

Thinking about it more, this particular issue is the most annoying one because:

1.  There’s not a limited defined set of items that encompass what the OU 
may include,
2.  The OU is generally the dumping ground for information, and
3.  There’s no requirement this information is verified other than ensuring 
it doesn’t have org/address info. 

 

Building a rule set to shore up this particular issue is difficult as the 
parameters are not well defined like they are with domain and identity 
validation.

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

 

Can you provide an example of what you believe is a bigger issue that has been 
masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, 
because maybe someone will find something non-obvious, and we don't want to 
miss out" - but that's a deeply flawed argument, and I would hope isn't the 
substance of what you're saying.

 

Note: I still disagree with you about the artificial ontology; all of these 
errors equally speak to the CA's ability to execute on Best Practices, such as 
using available tools that have been evangelized for over a year as something 
that can (and arguably should) be integrated into issuance pipelines. 
Discussions at this point are extremely relevant, as they speak to how well the 
CA is staying abreast of changes, as well as how effectively they're managing 
their subsidiaries - both issues that are key to public trust.

 

On Thu, Aug 10, 2017 at 2:17 PM, Jeremy Rowley via dev-security-policy 
 > wrote:

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise.  If there are bigger issues, let's find those.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley 
 =digicert.com@lists.mozilla

.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org 
 
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen >  > wrote:
>>
>> The point of certlint was to help identify issues.  While I
>> appreciate it getting broad usage, I don't think pushing for
>> revocation of every certificate that trips any of the Error level checks
is productive.
>
> I agree, and I don't really have a position on the revocation of
certificates with errors that do not appear to have any security impact like
these.
>
> Jonathan
>
>

I strongly disagree.  Errors like this make me question whether the
certification authority is sufficiently competent to be trusted.  Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross


President Trump demands loyalty to himself from Republican members of
Congress.  I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States.  In any case,
they all swore an oath of office to be loyal to the Constitution.
___
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

 



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

[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: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

Not really – and I don’t object to the certificate problem reports. I greatly 
appreciate the work Alex and Jonathan are doing.

 

I disagree that finding small issues indicates larger issues as a whole. 
There’s no support for that claim.  It’s just as likely that larger issues are 
going ignored because of noise as the smaller issues are indicators of 
something like domain validation going wrong. I doubt they speak equally to 
CA’s ability to execute on best practices as well.  Seems like a failure to do 
validation would be way more severe than ensuring the OU field doesn’t have 
metadata. 

 

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

 

Can you provide an example of what you believe is a bigger issue that has been 
masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, 
because maybe someone will find something non-obvious, and we don't want to 
miss out" - but that's a deeply flawed argument, and I would hope isn't the 
substance of what you're saying.

 

Note: I still disagree with you about the artificial ontology; all of these 
errors equally speak to the CA's ability to execute on Best Practices, such as 
using available tools that have been evangelized for over a year as something 
that can (and arguably should) be integrated into issuance pipelines. 
Discussions at this point are extremely relevant, as they speak to how well the 
CA is staying abreast of changes, as well as how effectively they're managing 
their subsidiaries - both issues that are key to public trust.

 

On Thu, Aug 10, 2017 at 2:17 PM, Jeremy Rowley via dev-security-policy 
 > wrote:

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise.  If there are bigger issues, let's find those.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley 
 =digicert.com@lists.mozilla

.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org 
 
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen >  > wrote:
>>
>> The point of certlint was to help identify issues.  While I
>> appreciate it getting broad usage, I don't think pushing for
>> revocation of every certificate that trips any of the Error level checks
is productive.
>
> I agree, and I don't really have a position on the revocation of
certificates with errors that do not appear to have any security impact like
these.
>
> Jonathan
>
>

I strongly disagree.  Errors like this make me question whether the
certification authority is sufficiently competent to be trusted.  Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross


President Trump demands loyalty to himself from Republican members of
Congress.  I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States.  In any case,
they all swore an oath of office to be loyal to the Constitution.
___
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

 



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: Certificates with common names not present in their SANs

[Ryan Sleevi via dev-security-policy]

CFCA stated this, in
https://cabforum.org/pipermail/public/2017-July/011733.html

Since then, no further evidence of this claim has been provided.

SHECA ( https://cabforum.org/pipermail/public/2017-July/011737.html ) and
GDCA ( https://cabforum.org/pipermail/public/2017-July/011736.html ) are
more restrained in claiming local law, although made similarly problematic
claims :)

On Thu, Aug 10, 2017 at 2:20 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Didn't someone recently float the argument that the native u-label was
> required by local regulation / custom (in China) to be included and so they
> stuffed it into the CN?
> ___
> 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 with less than 64 bits of entropy

[Matthew Hardeman via dev-security-policy]

On Thursday, August 10, 2017 at 11:27:53 AM UTC-5, Nick Lamb wrote:

> The truth is that there is no positive test for randomness, any work in this 
> area is going to end up needing a judgement call, so I think inconveniencing 
> the CAs even a small amount with such a policy change just to make automated 
> testing easier isn't the right trade off. If there happens to be some future 
> work in this policy area and the opportunity is taken to incorporate 
> Jonathan's wording I have no problem with that, but I definitely don't think 
> Mozilla should insist on it for its own sake.

Further to the point that Nick made, merely ensuring that the serial number 
field is represented as at least eight bytes prior to DER encoding still does 
not tell you whether or not the CA truly incorporated 64 bits of randomness in 
the serial number versus, for example, packing together 32 bits of randomness 
and 32 bits of sequence number.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

On this particular issue, it's questionable whether these are a violation of
a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field.
Section 7.1.4.2.2(j) defines "Any other subject".

Section 7.1.4.2.2(J) :
"All other optional attributes, when present within the subject field, MUST
contain information that has been verified by the CA. Optional attributes
MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘
(i.e.   space) characters, and/or any other indication that the value is
absent, incomplete, or not applicable."

Because OU is not "all other optional attributes", j doesn't apply. I think
this gives the wrong results and am for disallowing metadata in the OU
field. However, if we're going to be persnickety on the 24 hour rule, we
should be persnickety on the other ones as well.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these non-compliant
certs to be issued, and I expect them to send post-portems to mdsp
explaining what the root cause for these issues was and how they corrected
it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues.  While I
> > appreciate it getting broad usage, I don't think pushing for
> > revocation of every certificate that trips any of the Error level checks
is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it)
> onto the customer (who purchased the certificate), and thus a
> viewpoint that suggests this is somehow unjust (since it's the victim
> of misissuance who suffers), but I think an argument that suggests
> these shouldn't be revoked is similar to an argument that says those
> who purchased stolen merchandise should get to keep it, as long as they
didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future
action.
> Sadly, humans are terrible at recognizing those potential long-term
> costs (c.f. obesity/heart disease/dental care/global warming as all
> examples of long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also
> the right incentive - for CAs, and the overall ecosystem - to ensure
> that any misissuance is revoked in a timely fashion (which is
> currently 24 hours), because it helps encourage a market where the
> best step a CA can take to minimize risk to their subscribers, the
> ones actually paying them money and engaging in a business
> relationship with them, is to simply not misissue the 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


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: Certificates with metadata-only subject fields

[Ryan Sleevi via dev-security-policy]

Can you provide an example of what you believe is a bigger issue that has
been masked? Otherwise, it sounds like you're saying "Ignore the obvious
errors, because maybe someone will find something non-obvious, and we don't
want to miss out" - but that's a deeply flawed argument, and I would hope
isn't the substance of what you're saying.

Note: I still disagree with you about the artificial ontology; all of these
errors equally speak to the CA's ability to execute on Best Practices, such
as using available tools that have been evangelized for over a year as
something that can (and arguably should) be integrated into issuance
pipelines. Discussions at this point are extremely relevant, as they speak
to how well the CA is staying abreast of changes, as well as how
effectively they're managing their subsidiaries - both issues that are key
to public trust.

On Thu, Aug 10, 2017 at 2:17 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I strongly disagree. The discussion around errors like these masks the
> bigger issues in the noise.  If there are bigger issues, let's find those.
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=
> digicert.com@lists.mozilla
> .org] On Behalf Of David E. Ross via dev-security-policy
> Sent: Wednesday, August 9, 2017 4:35 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with metadata-only subject fields
>
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> >
> >> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
> >>
> >> The point of certlint was to help identify issues.  While I
> >> appreciate it getting broad usage, I don't think pushing for
> >> revocation of every certificate that trips any of the Error level checks
> is productive.
> >
> > I agree, and I don't really have a position on the revocation of
> certificates with errors that do not appear to have any security impact
> like
> these.
> >
> > Jonathan
> >
> >
>
> I strongly disagree.  Errors like this make me question whether the
> certification authority is sufficiently competent to be trusted.  Small
> errors can indicate an increased likelihood of serious errors.
>
> --
> David E. Ross
> 
>
> President Trump demands loyalty to himself from Republican members of
> Congress.  I always thought that members of Congress -- House and Senate --
> were required to be loyal to the people of the United States.  In any case,
> they all swore an oath of office to be loyal to the Constitution.
> ___
> 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: Certificates with common names not present in their SANs

[Matthew Hardeman via dev-security-policy]

Didn't someone recently float the argument that the native u-label was required 
by local regulation / custom (in China) to be included and so they stuffed it 
into the CN?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

[Jeremy Rowley via dev-security-policy]

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise.  If there are bigger issues, let's find those. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> 
>> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
>>
>> The point of certlint was to help identify issues.  While I 
>> appreciate it getting broad usage, I don't think pushing for 
>> revocation of every certificate that trips any of the Error level checks
is productive.
> 
> I agree, and I don't really have a position on the revocation of
certificates with errors that do not appear to have any security impact like
these.
> 
> Jonathan
> 
> 

I strongly disagree.  Errors like this make me question whether the
certification authority is sufficiently competent to be trusted.  Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross


President Trump demands loyalty to himself from Republican members of
Congress.  I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States.  In any case,
they all swore an oath of office to be loyal to the Constitution.
___
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: Certificates with less than 64 bits of entropy

[Jeremy Rowley via dev-security-policy]

Hi Jonathan, 

InfoCert's sub CA was revoked on August 1, 2017. We'll reach out to Siemens. 
They moved to Quovadis a while ago and are no longer issuing from that Sub CA.

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Thursday, August 10, 2017 9:26 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with less than 64 bits of entropy


> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> QuoVadis (560)
>Siemens Issuing CA Internet Server 2016 (560)
> 
> D-TRUST (224)
>D-TRUST SSL Class 3 CA 1 2009 (178)
>D-TRUST SSL Class 3 CA 1 EV 2009 (45)
>D-TRUST Root Class 3 CA 2 EV 2009 (1)
> 
> DigiCert (85)
>Siemens Issuing CA Class Internet Server 2013 (82)
>InfoCert Web Certification Authority (3)
> 
> Izenpe S.A. (62)
>EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)
> 
> Government of The Netherlands, PKIoverheid (Logius) (55)
>Digidentity Services CA - G2 (55)
> 
> Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
>Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)

It looks like my summary missed one QuoVadis intermediate:

Bayerische SSL-CA-2016-01 (3)

___
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: Certificates with common names not present in their SANs

[Jonathan Rudenberg via dev-security-policy]

> On Aug 5, 2017, at 17:36, alex.gaynor--- via dev-security-policy 
>  wrote:
> 
> Hi all,
> 
> 7.1.4.2.2 of the CABF Baseline Requirements requires that common names always 
> be an element from the SAN.
> 
> Here are 62 certs, from a variety of CAs which do not meet that requirement: 
> https://misissued.com/batch/1/

I sent a problem report to Symantec about these certificates via their web form 
on 2017-08-07 and received this response from them a few minutes ago:

> Thank you for reporting the issue for Symantec, Thawte and RapidSSL 
> certificates; however, we feel that the certificates we have issued are 
> compliant.  We consider the puny-coded SAN to match the native-coded CN and 
> to best cover both human consumers and machine consumers that need to be able 
> to read the name. Therefore, the certificates should not be revoked.
___
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: Certificates with less than 64 bits of entropy

[Nick Lamb via dev-security-policy]

On Thursday, 10 August 2017 16:20:56 UTC+1, Jonathan Rudenberg  wrote:
 - Three intermediates, "TeleSec ServerPass Class 2 CA”, "Go Daddy Secure 
Certificate Authority - G2”, and "Starfield Secure Certificate Authority - G2”, 
(which are not in this list) appear to issue certificates with serial numbers 
that are based on exactly 64 bits of entropy. This means that a small 
percentage of the certificates that they issue have serial numbers that are 
smaller than 8 bytes, requiring additional filtering to avoid false positives. 
It would be helpful if the policy was adjusted to require serial numbers always 
be at least 8 bytes before DER encoding to avoid these false positives.


Mmmm. I previously spoke out in favour of the practice of calling out 
non-compliant certificates because we need CAs to be doing their best, but I 
think there's also an allied element that when we're looking for problems we 
too need to put the effort in.

The truth is that there is no positive test for randomness, any work in this 
area is going to end up needing a judgement call, so I think inconveniencing 
the CAs even a small amount with such a policy change just to make automated 
testing easier isn't the right trade off. If there happens to be some future 
work in this policy area and the opportunity is taken to incorporate Jonathan's 
wording I have no problem with that, but I definitely don't think Mozilla 
should insist on it for its own sake.
___
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: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Arno Fiedler via dev-security-policy]

We´ll talk with the Management and the Certification Audit Body and will 
give feedback.


Arno


Am 10.08.2017 um 15:57 schrieb Ryan Sleevi:

Under the Baseline Requirements, v1.4.8 (current version), 4.9.1.1,

"The CA SHALL revoke a Certificate within 24 hours if one of more of the
following occurs:
  9. The CA is made aware that the Certificate was not issued in accordance
with these requirements or the CA's Certificate Policy or Certification
Practice Statement"

Since the passage of Ballot 165 (
https://cabforum.org/2016/07/08/ballot-164/ ), adopted in version 1.3.7
"Effective September 30, 2016, CAs SHALL generate Certificate serial
numbers greater than zero (0) containing at least 64 bits of output from a
CSPRNG."

So these were not issued in accordance with these Requirements, and thus
subject to revocation.

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


Hello Jonathan,

the certificate has 64 bits of entropy in the "DNqualifier" field instead
of the serial number field.

Since 2012 we used this way of adding random bits to certificates to
mitigate  preimage attacks
 From a security perspective the amount of Entropy in the certificate
should be reasonable.

Do you see a security need for revoking the certificate?

Viele Grüße

Arno Fiedler
Standardization & Consulting
Bundesdruckerei GmbH
Kommandantenstraße 18 · 10969 Berlin · Deutschland

Tel. :+ 49 30 25 98 - 3009
Mobil: + 49 172 3053272

arno.fied...@bdr.de · www.bundesdruckerei.de

Sitz der Gesellschaft: Berlin · Handelsregister: AG Berlin-Charlottenburg
HRB 80443. USt.-IdNr.: DE 813210005
Aufsichtsratsvorsitzender: Willi Berchtold
Geschäftsführer: Ulrich Hamann (Vorsitzender), Christian Helfrich

This message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, or the employee or agent
responsible for delivering the message to the intended recipient, we hereby
give notice that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this message in
error, please delete the message and notify us immediately.

Diese Nachricht kann vertrauliche und gesetzlich geschützte Informationen
enthalten. Sie ist ausschließlich für den Adressaten bestimmt. Wenn Sie
nicht der beabsichtigte Adressat sind, möchten wir Sie hiermit darüber
informieren, dass das Weiterleiten, Verteilen oder Kopieren dieser Mail
nicht gestattet ist. Wenn Sie diese Mail irrtümlicherweise erhalten haben,
informieren Sie uns bitte schnellstmöglich und löschen Sie bitte die Mail.


-Ursprüngliche Nachricht-
Von: Jonathan Rudenberg [mailto:jonat...@titanous.com]
Gesendet: Dienstag, 8. August 2017 19:12
An: Fiedler, Arno
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with
short SerialNumber



On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy <

dev-security-policy@lists.mozilla.org> wrote:

Dear Mozilla Security Policy Community,

Thanks for the advice about the short serial numbers and apologies for

the delayed response.

Since 2016, all D-TRUST TLS certificates based on electronic Certificate

Requests have a certificate serial number which includes 64 bits of entropy.

Between 2012 and July 6th, 2017 we produced a small number of

certificates with  paper-based Certificate Registration Requests using 64
bits of entropy in the "DNqualifier" field instead of the serial number
field.

Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits

of entropy in the serial number.

I hope this helps and please do not hesitate to contact us if there are

any further questions.

Hi Arno,

It doesn’t look like this certificate has been revoked yet?
https://crt.sh/?id=174827359=cablint

Can you explain why it hasn’t been revoked yet and when it will be?

Thanks,

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


.



--
Arno Fiedler
Nimbus Technologieberatung GmbH
Reichensteiner Weg 17
14195 Berlin
Mobil:  0049-(0)172-3053272
Fax:0049-(0)30-89745-777
E-Mail: arno.fied...@nimbus-berlin.com
Web:www.nimbus-berlin.com
Geschäftsführer:  Arno Fiedler
USt-IdNr. :   DE 203 269 920
D-U-N-S® Nr.  50-730-8117
HandelsregisterNr:HRB 109409 B

___
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 with less than 64 bits of entropy

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> QuoVadis (560)
>Siemens Issuing CA Internet Server 2016 (560)
> 
> D-TRUST (224)
>D-TRUST SSL Class 3 CA 1 2009 (178)
>D-TRUST SSL Class 3 CA 1 EV 2009 (45)
>D-TRUST Root Class 3 CA 2 EV 2009 (1)
> 
> DigiCert (85)
>Siemens Issuing CA Class Internet Server 2013 (82)
>InfoCert Web Certification Authority (3)
> 
> Izenpe S.A. (62)
>EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)
> 
> Government of The Netherlands, PKIoverheid (Logius) (55)
>Digidentity Services CA - G2 (55)
> 
> Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
>Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)

It looks like my summary missed one QuoVadis intermediate:

Bayerische SSL-CA-2016-01 (3)

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

Certificates with less than 64 bits of entropy

[Jonathan Rudenberg via dev-security-policy]

Baseline Requirements section 7.1 says:

> Effective September 30, 2016, CAs SHALL generate non‐sequential Certificate 
> serial numbers greater than zero (0) containing at least 64 bits of output 
> from a CSPRNG.

There are 1027 unexpired unrevoked certificates known to CT with a notBefore 
date greater than or equal to 2016-09-30 that are trusted by NSS for server 
authentication and have a serial number that has less than 64 bits of entropy.

The full list can be found here: https://misissued.com/batch/6/

Some of these were brought up in a previous thread[0], but I though a 
comprehensive picture of this issue would be helpful.

I’ve included a breakdown at the end of this email, and here are a few things 
that stood out to me while researching this:

- The "Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4” intermediate appears to 
use randomly generated 48-bit numbers.
- Three intermediates, "TeleSec ServerPass Class 2 CA”, "Go Daddy Secure 
Certificate Authority - G2”, and "Starfield Secure Certificate Authority - G2”, 
(which are not in this list) appear to issue certificates with serial numbers 
that are based on exactly 64 bits of entropy. This means that a small 
percentage of the certificates that they issue have serial numbers that are 
smaller than 8 bytes, requiring additional filtering to avoid false positives. 
It would be helpful if the policy was adjusted to require serial numbers always 
be at least 8 bytes before DER encoding to avoid these false positives.

Jonathan

[0] 
https://groups.google.com/d/topic/mozilla.dev.security.policy/vl5eq0PoJxY/discussion

—

QuoVadis (560)
Siemens Issuing CA Internet Server 2016 (560)

D-TRUST (224)
D-TRUST SSL Class 3 CA 1 2009 (178)
D-TRUST SSL Class 3 CA 1 EV 2009 (45)
D-TRUST Root Class 3 CA 2 EV 2009 (1)

DigiCert (85)
Siemens Issuing CA Class Internet Server 2013 (82)
InfoCert Web Certification Authority (3)

Izenpe S.A. (62)
EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)

Government of The Netherlands, PKIoverheid (Logius) (55)
Digidentity Services CA - G2 (55)

Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Jonathan Rudenberg via dev-security-policy]

> On Aug 10, 2017, at 07:55, Fiedler, Arno via dev-security-policy 
>  wrote:
> 
> Hello Jonathan,
> 
> the certificate has 64 bits of entropy in the "DNqualifier" field instead of 
> the serial number field. 
> 
> Since 2012 we used this way of adding random bits to certificates to mitigate 
>  preimage attacks
> From a security perspective the amount of Entropy in the certificate should 
> be reasonable.
> 
> Do you see a security need for revoking the certificate?

1) The dnQualifier appears to have a 33-bit number, not a 64-bit number.

2) One of the SAN dnsNames is "www.lbv-gis.brandenburg.de/lbvagszit”, which is 
clearly invalid.

3) The Baseline Requirements are extremely clear about this:

> The CA SHALL revoke a Certificate within 24 hours if one or more of the 
> following occurs:
> […]
> 9. The CA is made aware that the Certificate was not issued in accordance 
> with these Requirements or the CA’s Certificate Policy or Certification 
> Practice Statement;

So yes, I believe this certificate needs to be revoked immediately. It should 
have been revoked within 24 hours of learning about it. I believe July 20th was 
the latest date that you could have learned about it, when Gerv sent a 
notification to you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Ryan Sleevi via dev-security-policy]

Under the Baseline Requirements, v1.4.8 (current version), 4.9.1.1,

"The CA SHALL revoke a Certificate within 24 hours if one of more of the
following occurs:
 9. The CA is made aware that the Certificate was not issued in accordance
with these requirements or the CA's Certificate Policy or Certification
Practice Statement"

Since the passage of Ballot 165 (
https://cabforum.org/2016/07/08/ballot-164/ ), adopted in version 1.3.7
"Effective September 30, 2016, CAs SHALL generate Certificate serial
numbers greater than zero (0) containing at least 64 bits of output from a
CSPRNG."

So these were not issued in accordance with these Requirements, and thus
subject to revocation.

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

> Hello Jonathan,
>
> the certificate has 64 bits of entropy in the "DNqualifier" field instead
> of the serial number field.
>
> Since 2012 we used this way of adding random bits to certificates to
> mitigate  preimage attacks
> From a security perspective the amount of Entropy in the certificate
> should be reasonable.
>
> Do you see a security need for revoking the certificate?
>
> Viele Grüße
>
> Arno Fiedler
> Standardization & Consulting
> Bundesdruckerei GmbH
> Kommandantenstraße 18 · 10969 Berlin · Deutschland
>
> Tel. :+ 49 30 25 98 - 3009
> Mobil: + 49 172 3053272
>
> arno.fied...@bdr.de · www.bundesdruckerei.de
>
> Sitz der Gesellschaft: Berlin · Handelsregister: AG Berlin-Charlottenburg
> HRB 80443. USt.-IdNr.: DE 813210005
> Aufsichtsratsvorsitzender: Willi Berchtold
> Geschäftsführer: Ulrich Hamann (Vorsitzender), Christian Helfrich
>
> This message is intended only for the use of the individual or entity to
> which it is addressed, and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, or the employee or agent
> responsible for delivering the message to the intended recipient, we hereby
> give notice that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this message in
> error, please delete the message and notify us immediately.
>
> Diese Nachricht kann vertrauliche und gesetzlich geschützte Informationen
> enthalten. Sie ist ausschließlich für den Adressaten bestimmt. Wenn Sie
> nicht der beabsichtigte Adressat sind, möchten wir Sie hiermit darüber
> informieren, dass das Weiterleiten, Verteilen oder Kopieren dieser Mail
> nicht gestattet ist. Wenn Sie diese Mail irrtümlicherweise erhalten haben,
> informieren Sie uns bitte schnellstmöglich und löschen Sie bitte die Mail.
>
>
> -Ursprüngliche Nachricht-
> Von: Jonathan Rudenberg [mailto:jonat...@titanous.com]
> Gesendet: Dienstag, 8. August 2017 19:12
> An: Fiedler, Arno
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with
> short SerialNumber
>
>
> > On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > Dear Mozilla Security Policy Community,
> >
> > Thanks for the advice about the short serial numbers and apologies for
> the delayed response.
> >
> > Since 2016, all D-TRUST TLS certificates based on electronic Certificate
> Requests have a certificate serial number which includes 64 bits of entropy.
> >
> > Between 2012 and July 6th, 2017 we produced a small number of
> certificates with  paper-based Certificate Registration Requests using 64
> bits of entropy in the "DNqualifier" field instead of the serial number
> field.
> >
> > Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits
> of entropy in the serial number.
> >
> > I hope this helps and please do not hesitate to contact us if there are
> any further questions.
>
> Hi Arno,
>
> It doesn’t look like this certificate has been revoked yet?
> https://crt.sh/?id=174827359=cablint
>
> Can you explain why it hasn’t been revoked yet and when it will be?
>
> Thanks,
>
> Jonathan
> ___
> 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 with metadata-only subject fields

[Alex Gaynor via dev-security-policy]

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these
non-compliant certs to be issued, and I expect them to send post-portems to
mdsp explaining what the root cause for these issues was and how they
corrected it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues.  While I appreciate
> > it getting broad usage, I don't think pushing for revocation of every
> > certificate that trips any of the Error level checks is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it) onto
> the customer (who purchased the certificate), and thus a viewpoint that
> suggests this is somehow unjust (since it's the victim of misissuance who
> suffers), but I think an argument that suggests these shouldn't be revoked
> is similar to an argument that says those who purchased stolen merchandise
> should get to keep it, as long as they didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future action.
> Sadly, humans are terrible at recognizing those potential long-term costs
> (c.f. obesity/heart disease/dental care/global warming as all examples of
> long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also the
> right incentive - for CAs, and the overall ecosystem - to ensure that any
> misissuance is revoked in a timely fashion (which is currently 24 hours),
> because it helps encourage a market where the best step a CA can take to
> minimize risk to their subscribers, the ones actually paying them money and
> engaging in a business relationship with them, is to simply not misissue
> the 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: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Arno Fiedler via dev-security-policy]

Hello Jonathan,

this certificate has 64 bits of entropy in the "DNqualifier" field instead of 
the serial number field. 

Since 2012 we used this way of adding random bits to certificates to mitigate  
preimage attacks. From a security perspective the amount of Entropy in the 
certificate should be reasonable.

Do you see a security need for revoking the certificate?

Viele Grüße

Arno Fiedler
Standardization & Consulting
Bundesdruckerei GmbH
Kommandantenstraße 18 · 10969 Berlin · Deutschland

Tel. :+ 49 30 25 98 - 3009
Mobil: + 49 172 3053272
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

[Fiedler, Arno via dev-security-policy]

Hello Jonathan,

the certificate has 64 bits of entropy in the "DNqualifier" field instead of 
the serial number field. 

Since 2012 we used this way of adding random bits to certificates to mitigate  
preimage attacks
From a security perspective the amount of Entropy in the certificate should be 
reasonable.

Do you see a security need for revoking the certificate?

Viele Grüße

Arno Fiedler
Standardization & Consulting
Bundesdruckerei GmbH
Kommandantenstraße 18 · 10969 Berlin · Deutschland

Tel. :+ 49 30 25 98 - 3009
Mobil: + 49 172 3053272

arno.fied...@bdr.de · www.bundesdruckerei.de

Sitz der Gesellschaft: Berlin · Handelsregister: AG Berlin-Charlottenburg HRB 
80443. USt.-IdNr.: DE 813210005
Aufsichtsratsvorsitzender: Willi Berchtold
Geschäftsführer: Ulrich Hamann (Vorsitzender), Christian Helfrich
  
This message is intended only for the use of the individual or entity to which 
it is addressed, and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If the reader of this message 
is not the intended recipient, or the employee or agent responsible for 
delivering the message to the intended recipient, we hereby give notice that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this message in error, please delete the 
message and notify us immediately.
 
Diese Nachricht kann vertrauliche und gesetzlich geschützte Informationen 
enthalten. Sie ist ausschließlich für den Adressaten bestimmt. Wenn Sie nicht 
der beabsichtigte Adressat sind, möchten wir Sie hiermit darüber informieren, 
dass das Weiterleiten, Verteilen oder Kopieren dieser Mail nicht gestattet ist. 
Wenn Sie diese Mail irrtümlicherweise erhalten haben, informieren Sie uns bitte 
schnellstmöglich und löschen Sie bitte die Mail.


-Ursprüngliche Nachricht-
Von: Jonathan Rudenberg [mailto:jonat...@titanous.com] 
Gesendet: Dienstag, 8. August 2017 19:12
An: Fiedler, Arno
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short 
SerialNumber


> On Aug 8, 2017, at 08:58, Fiedler, Arno via dev-security-policy 
>  wrote:
> 
> Dear Mozilla Security Policy Community,
> 
> Thanks for the advice about the short serial numbers and apologies for the 
> delayed response.
> 
> Since 2016, all D-TRUST TLS certificates based on electronic Certificate 
> Requests have a certificate serial number which includes 64 bits of entropy.
> 
> Between 2012 and July 6th, 2017 we produced a small number of certificates 
> with  paper-based Certificate Registration Requests using 64 bits of entropy 
> in the "DNqualifier" field instead of the serial number field.
> 
> Since the 7th of July, 2017, all D-TRUST TLS-Certificates have 64 bits of 
> entropy in the serial number.
> 
> I hope this helps and please do not hesitate to contact us if there are any 
> further questions.

Hi Arno,

It doesn’t look like this certificate has been revoked yet? 
https://crt.sh/?id=174827359=cablint

Can you explain why it hasn’t been revoked yet and when it will be?

Thanks,

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

Re: High traffic on this list, and Mozilla root program involvement

[Gervase Markham via dev-security-policy]

Hi Jeremy,

On 09/08/17 21:57, Jeremy Rowley wrote:
> I was thinking you should just have the Cas add them all for you.  Makes it
> easier on you and demonstrates they are tracking and remediating these
> issues.  If I were going to create a bug for these in Mozilla would you
> prefer to see one bug per issue on one bug per CA. For example, should there
> be a bug for all DigiCert issues or should there be one that describes too
> long of serial number and another that says the field contains meta-data? 

That is a good point. Thank you for the suggestion.

I would like one bug per root cause, ideally, but as bugs can be more
easily duplicated against each other than split, err on the side of one
bug per issue if the root causes have not been determined with
sufficient clarity yet.

If CAs wish to file bugs about their own issues, they should do so here:

https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=CA%20Certificate%20Mis-Issuance

(We use the term "mis-issuance" broadly here.) Please include in the
initial comment at least a full copy of the original report from this
group, although you may elide details of certificates from other CAs.

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)

[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 with invalidly long serial numbers

[okaphone.elektronika--- via dev-security-policy]

The answers from CAs we typically see in this group are more along the lines of 
not thinking it necessary to revoke at all than needing more time, I'd say. So 
I don't really see what this idea that 24 hours would be too short is based on. 
I think relaxing the revocation time limit may in fact be a solution for a 
problem that doesn't exist (much). After all quite a few of these misissued 
certificates will not even work properly.

What I don't like is that the answers of CAs hardly ever explain what happened, 
how it was possible that it happened and what has/will be done to prevent is 
from happening again. It looks like they have no real incentive to do things 
right.

Yes, in some cases the bad certificates will be in use and the revocation may 
cause problems (not too much I understand as revocation mostly does not work 
;-) for CA-customers and their website visitors. But having to deal with that 
when they are doing it wrong is the only motivation a CA has for doing things 
right. As things are this doesn't seem to motivate them very much. ;-)

And customers will have to learn to choose CAs that don't cause this kind of 
problems. Or suffer them... that is up to them.

On to other hand customers also have little motivation to do things right. To 
most of them HTTPS is something they are forced into by the recent HTTPS-only 
drive by the browsers.

All in all I appreciate how CT is pulling all this garbage into broad daylight. 
We should be simply aiming to get it cleared away. And if there is stuff in 
there that is not worth revoking promptly then it would be better to remove 
theses issuance requirements than to relax the revocation requirement.

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