Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

crt.sh deliberately doesn't monitor any of Google's dedicated test logs 
(Testtube, Crucible, Solera20XX), but it does monitor some multi-purpose 
logs that are sometimes used for testing (e.g., Dodo).


On 01/10/18 20:09, Doug Beattie wrote:

Thanks Wayne.

Rob, Adriano : I had no idea that crt.sh included logs that supported 
test roots or roots that weren’t in some/all root programs.  I assumed 
these were all production level roots that needed to comply with the 
BRs.  Thanks for that tid-bit!


Alex: I’ll keep an eye on https://misissued.com  and use that as a 
better, more filtered report once it returns to life.


Doug

*From:*Wayne Thayer 
*Sent:* Monday, October 1, 2018 2:58 PM
*To:* Doug Beattie 
*Cc:* mozilla-dev-security-policy 


*Subject:* Re: Increasing number of Errors found in crt.sh

Doug,

Responding to your original question, I look at crt.sh and other data 
sources for certificate errors when reviewing inclusion requests or 
doing other sorts of investigations. I am not currently reviewing the 
crt.sh report for misissuance on a regular basis, but maybe I should.


I went through the current list and identified the following problems 
affecting certificates trusted by Mozilla:


* KIR S.A.: Multiple issues - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495497


* Government of Spain FNMT: OU exceeds 64 characters - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495507


* Assecco DS (Certum): Unallowed key usage for EC public key - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495518


* Certinomis: issued & revoked a precertificate containing a SAN of 
'www', didn't report it - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495524


- Wayne

On Mon, Oct 1, 2018 at 8:51 AM Rob Stradling via dev-security-policy 
> wrote:


Hi Iñigo.

I suspect it's because my script that produces the 1 week summary data
[1] isn't using a consistent view of the underlying linting results
throughout its processing.  Hopefully this [2] will fix it.

100% errors from that Comodo issuing CA is because it's issuing SHA-1
certs that chain to a no-longer-publicly-trusted root.


[1]

https://github.com/crtsh/certwatch_db/blob/master/lint_update_1week_stats.sql

[2]

https://github.com/crtsh/certwatch_db/commit/8ce0c96c9c50bfb51db33c6f44c9c1d1a9f5a96c

On 01/10/2018 15:35, Inigo Barreira wrote:
 > And checking this site, how can Comodo have more certs with
errors (15030) than certs issued (15020).
 >
 > Regards
 > 
 > From: dev-security-policy
mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf of
Adriano Santoni via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
 > Sent: Monday, October 01, 2018 10:09 PM
 > To: Rob Stradling; Doug Beattie
 > Cc: mozilla-dev-security-policy
 > Subject: Re: Increasing number of Errors found in crt.sh
 >
 > I also agree.
 >
 > As I said before, that's a non-trusted certificate. It was issued
by a
 > test CA that does /not/ chain to a public root.
 >
 >
 > Il 01/10/2018 16:04, Rob Stradling ha scritto:
 >> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
 >>> Hi Adriano,
 >>>
 >>> First, I didn't mean to call you out specifically, but you happened
 >>> to be
 >>> first alphabetically, sorry.  I find this link very helpful to list
 >>> all CAs
 >>> with errors or warnings: https://crt.sh/?cablint=1+week
 >>>
 >>> Second, How do you define a "test CA"?  I thought that any CA that
 >>> chains to
 >>> a public root was by definition not a test CA,
 >>
 >> I agree with that.
 >>
 >>> and since the issued cert was
 >>> in CT logs, I assumed that your root was publicly trusted.
Maybe I'm
 >>> mistaken on one of these points
 >>
 >> Actually, some non-publicly-trusted roots are accepted by some
of the
 >> logs that crt.sh monitors.
 >>
 >>> Doug
 >>>
 >>> -Original Message-
 >>> From: dev-security-policy
 >>> mailto:dev-security-policy-boun...@lists.mozilla.org>> On
 >>> Behalf Of Adriano Santoni via dev-security-policy
 >>> Sent: Monday, October 1, 2018 9:49 AM
 >>> To: dev-security-policy@lists.mozilla.org

 >>> Subject: Re: Increasing number of Errors found in crt.sh
 >>>
 >>> Thank you Rob!
 >>>
 >>> If I am not mistaken, it seems to me that we have just 1
certificate
 >>> in that
 >>> list, and it's a non-trusted certificate (it was issued by a
test CA).
 >>>
 >>>
 >>> Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha
scritto:
  On 01/10/2018 14:38, Adriano Santoni via dev-security-policy
wrote:
 > Is it possible to filter the list https://crt.sh/?cablint

RE: Increasing number of Errors found in crt.sh

[Doug Beattie via dev-security-policy]

Thanks Wayne.

 

Rob, Adriano : I had no idea that crt.sh included logs that supported test 
roots or roots that weren’t in some/all root programs.  I assumed these were 
all production level roots that needed to comply with the BRs.  Thanks for that 
tid-bit!

 

Alex: I’ll keep an eye on https://misissued.com  and use that as a better, more 
filtered report once it returns to life.

 

Doug

 

 

From: Wayne Thayer  
Sent: Monday, October 1, 2018 2:58 PM
To: Doug Beattie 
Cc: mozilla-dev-security-policy 
Subject: Re: Increasing number of Errors found in crt.sh

 

Doug,

 

Responding to your original question, I look at crt.sh and other data sources 
for certificate errors when reviewing inclusion requests or doing other sorts 
of investigations. I am not currently reviewing the crt.sh report for 
misissuance on a regular basis, but maybe I should.

 

I went through the current list and identified the following problems affecting 
certificates trusted by Mozilla:

* KIR S.A.: Multiple issues - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495497

* Government of Spain FNMT: OU exceeds 64 characters - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495507

* Assecco DS (Certum): Unallowed key usage for EC public key - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1495518

* Certinomis: issued & revoked a precertificate containing a SAN of 'www', 
didn't report it - https://bugzilla.mozilla.org/show_bug.cgi?id=1495524

 

- Wayne

 

On Mon, Oct 1, 2018 at 8:51 AM Rob Stradling via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hi Iñigo.

I suspect it's because my script that produces the 1 week summary data 
[1] isn't using a consistent view of the underlying linting results 
throughout its processing.  Hopefully this [2] will fix it.

100% errors from that Comodo issuing CA is because it's issuing SHA-1 
certs that chain to a no-longer-publicly-trusted root.


[1] 
https://github.com/crtsh/certwatch_db/blob/master/lint_update_1week_stats.sql

[2] 
https://github.com/crtsh/certwatch_db/commit/8ce0c96c9c50bfb51db33c6f44c9c1d1a9f5a96c

On 01/10/2018 15:35, Inigo Barreira wrote:
> And checking this site, how can Comodo have more certs with errors (15030) 
> than certs issued (15020).
> 
> Regards
> 
> From: dev-security-policy   > on behalf of Adriano 
> Santoni via dev-security-policy   >
> Sent: Monday, October 01, 2018 10:09 PM
> To: Rob Stradling; Doug Beattie
> Cc: mozilla-dev-security-policy
> Subject: Re: Increasing number of Errors found in crt.sh
> 
> I also agree.
> 
> As I said before, that's a non-trusted certificate. It was issued by a
> test CA that does /not/ chain to a public root.
> 
> 
> Il 01/10/2018 16:04, Rob Stradling ha scritto:
>> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
>>> Hi Adriano,
>>>
>>> First, I didn't mean to call you out specifically, but you happened
>>> to be
>>> first alphabetically, sorry.  I find this link very helpful to list
>>> all CAs
>>> with errors or warnings: https://crt.sh/?cablint=1+week
>>>
>>> Second, How do you define a "test CA"?  I thought that any CA that
>>> chains to
>>> a public root was by definition not a test CA,
>>
>> I agree with that.
>>
>>> and since the issued cert was
>>> in CT logs, I assumed that your root was publicly trusted. Maybe I'm
>>> mistaken on one of these points
>>
>> Actually, some non-publicly-trusted roots are accepted by some of the
>> logs that crt.sh monitors.
>>
>>> Doug
>>>
>>> -Original Message-
>>> From: dev-security-policy
>>> >>  > On
>>> Behalf Of Adriano Santoni via dev-security-policy
>>> Sent: Monday, October 1, 2018 9:49 AM
>>> To: dev-security-policy@lists.mozilla.org 
>>>  
>>> Subject: Re: Increasing number of Errors found in crt.sh
>>>
>>> Thank you Rob!
>>>
>>> If I am not mistaken, it seems to me that we have just 1 certificate
>>> in that
>>> list, and it's a non-trusted certificate (it was issued by a test CA).
>>>
>>>
>>> Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
 On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
> Is it possible to filter the list https://crt.sh/?cablint=issues
> based on the issuing CA ?

 Yes.

 First, visit this page:
 https://crt.sh/?cablint=1+week

 Next, click on the link in the "Issuer CN, OU or O" column that
 corresponds to the issuing CA you're interested in.

> Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:
>> Hi Wayne and all,
>>
>>
>> I've been noticing an increasing number of CA errors,
>> https://crt.sh/?cablint=issues  Is anyone monitoring this list and
>> asking
>> for misissuance reports for those that are not compliant? 

Re: Increasing number of Errors found in crt.sh

[Wayne Thayer via dev-security-policy]

Doug,

Responding to your original question, I look at crt.sh and other data
sources for certificate errors when reviewing inclusion requests or doing
other sorts of investigations. I am not currently reviewing the crt.sh
report for misissuance on a regular basis, but maybe I should.

I went through the current list and identified the following problems
affecting certificates trusted by Mozilla:
* KIR S.A.: Multiple issues -
https://bugzilla.mozilla.org/show_bug.cgi?id=1495497
* Government of Spain FNMT: OU exceeds 64 characters -
https://bugzilla.mozilla.org/show_bug.cgi?id=1495507
* Assecco DS (Certum): Unallowed key usage for EC public key -
https://bugzilla.mozilla.org/show_bug.cgi?id=1495518
* Certinomis: issued & revoked a precertificate containing a SAN of 'www',
didn't report it - https://bugzilla.mozilla.org/show_bug.cgi?id=1495524

- Wayne

On Mon, Oct 1, 2018 at 8:51 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Iñigo.
>
> I suspect it's because my script that produces the 1 week summary data
> [1] isn't using a consistent view of the underlying linting results
> throughout its processing.  Hopefully this [2] will fix it.
>
> 100% errors from that Comodo issuing CA is because it's issuing SHA-1
> certs that chain to a no-longer-publicly-trusted root.
>
>
> [1]
>
> https://github.com/crtsh/certwatch_db/blob/master/lint_update_1week_stats.sql
>
> [2]
>
> https://github.com/crtsh/certwatch_db/commit/8ce0c96c9c50bfb51db33c6f44c9c1d1a9f5a96c
>
> On 01/10/2018 15:35, Inigo Barreira wrote:
> > And checking this site, how can Comodo have more certs with errors
> (15030) than certs issued (15020).
> >
> > Regards
> > 
> > From: dev-security-policy 
> on behalf of Adriano Santoni via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> > Sent: Monday, October 01, 2018 10:09 PM
> > To: Rob Stradling; Doug Beattie
> > Cc: mozilla-dev-security-policy
> > Subject: Re: Increasing number of Errors found in crt.sh
> >
> > I also agree.
> >
> > As I said before, that's a non-trusted certificate. It was issued by a
> > test CA that does /not/ chain to a public root.
> >
> >
> > Il 01/10/2018 16:04, Rob Stradling ha scritto:
> >> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
> >>> Hi Adriano,
> >>>
> >>> First, I didn't mean to call you out specifically, but you happened
> >>> to be
> >>> first alphabetically, sorry.  I find this link very helpful to list
> >>> all CAs
> >>> with errors or warnings: https://crt.sh/?cablint=1+week
> >>>
> >>> Second, How do you define a "test CA"?  I thought that any CA that
> >>> chains to
> >>> a public root was by definition not a test CA,
> >>
> >> I agree with that.
> >>
> >>> and since the issued cert was
> >>> in CT logs, I assumed that your root was publicly trusted. Maybe I'm
> >>> mistaken on one of these points
> >>
> >> Actually, some non-publicly-trusted roots are accepted by some of the
> >> logs that crt.sh monitors.
> >>
> >>> Doug
> >>>
> >>> -Original Message-
> >>> From: dev-security-policy
> >>>  On
> >>> Behalf Of Adriano Santoni via dev-security-policy
> >>> Sent: Monday, October 1, 2018 9:49 AM
> >>> To: dev-security-policy@lists.mozilla.org
> >>> Subject: Re: Increasing number of Errors found in crt.sh
> >>>
> >>> Thank you Rob!
> >>>
> >>> If I am not mistaken, it seems to me that we have just 1 certificate
> >>> in that
> >>> list, and it's a non-trusted certificate (it was issued by a test CA).
> >>>
> >>>
> >>> Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
>  On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
> > Is it possible to filter the list https://crt.sh/?cablint=issues
> > based on the issuing CA ?
> 
>  Yes.
> 
>  First, visit this page:
>  https://crt.sh/?cablint=1+week
> 
>  Next, click on the link in the "Issuer CN, OU or O" column that
>  corresponds to the issuing CA you're interested in.
> 
> > Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:
> >> Hi Wayne and all,
> >>
> >>
> >> I've been noticing an increasing number of CA errors,
> >> https://crt.sh/?cablint=issues  Is anyone monitoring this list and
> >> asking
> >> for misissuance reports for those that are not compliant? There
> >> are 15
> >> different errors and around 300 individual errors (excluding the
> >> SHA-1
> >> "false" errors).  Some CAs are issuing certs to CNs of localhost,
> are
> >> including RFC822 SANs, not including OCSP links and many more.
> >>
> >> -  Actalis,
> >>
> >> -  Digicert,
> >>
> >> -  Microsoft,
> >>
> >> -
> >>
> >>
> >> There are also some warning checks that should actually be errors
> >> like
> >> underscores in CNs or SANs.
> >>
> >>
> >> Doug
> >>
>
> --
> Rob Stradling
> Se

Re: Concerns with Dun & Bradstreet as a QIIS

[Ryan Sleevi via dev-security-policy]

On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos 
wrote:

> No, this was not about the domain name but about the information displayed
> to the Relying Party with the attributes included in the OV/EV Certificate
> (primarily the Organization). So, I'm still uncertain if Ian's "misleading
> street address" was trying to get a certificate for domain "stripe.com"
> owned by "Stripe Inc." in California, or was trying to get a certificate
> for "ian's domain.com" owned by "Stripe Inc." in Kentucky, as was the
> previous discussions. The discussion so far indicates that it's the latter,
> with the additional element that now the Street Address is also misleading.
>

I'm not sure the source of confusion. As the original message pointed out,
this was about a Cloudflare certificate (or more aptly, two entities named
Cloudflare). In both the "Stripe, Inc" and in this case, it was a domain
that Ian owned and could demonstrate, for a legally incorporated entity
that Ian represented. In the "Stripe, Inc" case, the information included
in the certificate reflected the accurate entity - that is, the only
"confusion" here was relying party confusion, while the information within
the certificate was accurate.

During those discussions, some suggested that it was this point - that the
information was accurate, and a 'discerning' RP could distinguish between
Kentucky and California - that prevented a "Stripe, Inc" cert from being
problematic. This more recent "Cloudflare" issue builds upon that claim, by
showing that CAs also use unreliable data sources, such that even a
discerning RP may not be able to fully distinguish. In this case, Ian's
attempted example was an 'off-by-one' error on a street address, while
otherwise keeping all of the same information (except for serial number,
since that's related to jurisdictional details).

However, independent of any "name-collidey" discussion between
Ian-Cloudflare and 'Real'-Cloudflare, the fact that some CAs treat D&B as a
Reliable Data Source shows that unreliable data is able to be introduced
into certificates.


> I am certainly not suggesting that CAs should put inaccurate and
> misleading information in certificates :-) I merely said that if the
> Subscriber introduces misleading or inaccurate information in certificates
> via a reliable information source, then there will probably be a trail
> leading back to the Subscriber. This fact, combined with the lack of clear
> damage that this can cause to Relying Parties, makes me wonder why doesn't
> the Subscriber, that wants to mislead Relying Parties, just use a DV
> Certificate where this probably doesn't leave so much evidence tracing back
> to the Subscriber?
>

"The lack of clear damage" - I'm not sure how better to communicate, since
we're discussing fundamental damage to the value that OV and EV are said to
provide. The only way we can say "lack of clear damage" is to say that OV
and EV are worthless - otherwise, it's incredibly damaging.

I have no idea where the notion of 'tracability' comes from, or why that's
relevant. It again seems to be anchoring on getting a certificate for the
real cloudflare.com or stripe.com, which is not the discussion. We're
talking about "confusing" a user (or subscriber or relying party or threat
monitoring system) by suggesting that the certificates being issued are
'benign' or 'authorized'.


> But this inaccurate data is not used in the validation process nor
> included in the certificates. Perhaps I didn't describe my thoughts
> accurately. Let me have another try using my previous example. Consider an
> Information Source that documents, in its practices, that they provide:
>
>
>1. the Jurisdiction of Incorporation (they check official government
>records),
>2. registry number (they check official government records),
>3. the name of legal representative (they check official government
>records),
>4. the official name of the legal entity (they check official
>government records),
>5. street address (they check the address of a utility bill issued
>under the name of the legal entity),
>6. telephone numbers (self-reported),
>7. color of the building (self-reported).
>
> The CA evaluates this practice document and accepts information 1-5 as
> reliable, dismisses information 6 as non-reliable, and dismisses
> information 7 as irrelevant.
>
> Your argument suggests that the CA should dismiss this information source
> altogether, even though it clearly has acceptable and verified information
> for 1-5. Is that an accurate representation of your statement?
>
Yes, I'm stating that the existence of and inclusion of 5-7 calls into
question whether or not this is a reliable data source. Your parenthetical
about how they check that is what the CA has the burden to demonstrate,
particularly given that they have evidence that there is less-than-reliable
data included. How does the competent CA ensure that the registry number is
not self-reported - or

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

Hi Iñigo.

I suspect it's because my script that produces the 1 week summary data 
[1] isn't using a consistent view of the underlying linting results 
throughout its processing.  Hopefully this [2] will fix it.


100% errors from that Comodo issuing CA is because it's issuing SHA-1 
certs that chain to a no-longer-publicly-trusted root.



[1] 
https://github.com/crtsh/certwatch_db/blob/master/lint_update_1week_stats.sql


[2] 
https://github.com/crtsh/certwatch_db/commit/8ce0c96c9c50bfb51db33c6f44c9c1d1a9f5a96c


On 01/10/2018 15:35, Inigo Barreira wrote:

And checking this site, how can Comodo have more certs with errors (15030) than 
certs issued (15020).

Regards

From: dev-security-policy  on behalf 
of Adriano Santoni via dev-security-policy 
Sent: Monday, October 01, 2018 10:09 PM
To: Rob Stradling; Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Increasing number of Errors found in crt.sh

I also agree.

As I said before, that's a non-trusted certificate. It was issued by a
test CA that does /not/ chain to a public root.


Il 01/10/2018 16:04, Rob Stradling ha scritto:

On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:

Hi Adriano,

First, I didn't mean to call you out specifically, but you happened
to be
first alphabetically, sorry.  I find this link very helpful to list
all CAs
with errors or warnings: https://crt.sh/?cablint=1+week

Second, How do you define a "test CA"?  I thought that any CA that
chains to
a public root was by definition not a test CA,


I agree with that.


and since the issued cert was
in CT logs, I assumed that your root was publicly trusted. Maybe I'm
mistaken on one of these points


Actually, some non-publicly-trusted roots are accepted by some of the
logs that crt.sh monitors.


Doug

-Original Message-
From: dev-security-policy
 On
Behalf Of Adriano Santoni via dev-security-policy
Sent: Monday, October 1, 2018 9:49 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Increasing number of Errors found in crt.sh

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate
in that
list, and it's a non-trusted certificate (it was issued by a test CA).


Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:

Is it possible to filter the list https://crt.sh/?cablint=issues
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that
corresponds to the issuing CA you're interested in.


Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and
asking
for misissuance reports for those that are not compliant? There
are 15
different errors and around 300 individual errors (excluding the
SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors
like
underscores in CNs or SANs.


Doug




--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

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

RE: InfoCert investment in LuxTrust

[Yves Nullens via dev-security-policy]

Wayne,

I confirm that the only change following this investment is the update of the 
overview chapter.

Best regards,
Yves

From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: 28 September 2018 21:19
To: Yves Nullens
Cc: mozilla-dev-security-policy
Subject: Re: InfoCert investment in LuxTrust

Yves,

Thank you for bringing this to our attention. Section 8.1 of the Mozilla Root 
Store policy [1] applies here. It is not completely clear to me that 50% 
ownership is a "controlling stake", but even if it is, InfoCert is already a 
member of the Mozilla root program by way of its acquisition of Camerfirma 
earlier this year. In that case, our policy simply requires the following:

Mozilla MUST be notified of any resulting changes in the CA's CP or CPS.

Can you confirm that this investment will cause no CP/CPS changes other than 
the updates to the overview chapter that you described?

- Wayne

On Fri, Sep 28, 2018 at 8:38 AM Yves Nullens via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Dear all,

We would like to inform you that Tecnoinvestimenti, through its subsidiary 
InfoCert S.p.A. ("InfoCert"), has signed an agreement to invest into LuxTrust. 
The shareholding will be as follows:

-  50% historic shareholders

-  50% Infocert

 This investment has currently no impact/modification

o   on the organization

o   on the services provided

o   on the infrastructure

LSTI our conformity assessment body and ILNAS the Luxemburgish national entity 
in charge of supervising our certification have also just been informed of this 
investment.


We plan to add in the overview chapter of our CP, CPS Infocert to the list of 
entities constituting our partnership : "LuxTrust is a partnership between the 
Luxembourg government, the major private financial actors in Luxembourg and 
Infocert"

Best regards,
Yves Nullens

[LuxTrust_logo_blue_signature]


___
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: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

Yeah, it would be good to make it possible to filter 
https://crt.sh/?cablint=1+week by trust context.


On 01/10/2018 15:07, Alex Gaynor wrote:
A broader issue is that a lot of the certs listed on these pages are 
publicly-trusted, but not by the Mozilla Root Program, that is to say, 
Microsoft or Apple (or occasionally Adobe) trusts them.


misissued.com  (which is currently erroring on all 
requests 😬)  tried to address this by only showing certificates from 
CA's in the Mozilla Root Program, since that's the extent of our 
jurisdiction (and CA's applying for inclusion, which in some cases are 
ones which have a history of non-compliance under other root programs, 
but there's no way to programatically tell if a CA is applying for 
inclusion).


Alex


On Mon, Oct 1, 2018 at 10:05 AM Rob Stradling via dev-security-policy 
> wrote:


On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
 > Hi Adriano,
 >
 > First, I didn't mean to call you out specifically, but you
happened to be
 > first alphabetically, sorry.  I find this link very helpful to
list all CAs
 > with errors or warnings: https://crt.sh/?cablint=1+week
 >
 > Second, How do you define a "test CA"?  I thought that any CA
that chains to
 > a public root was by definition not a test CA,

I agree with that.

 > and since the issued cert was
 > in CT logs, I assumed that your root was publicly trusted.  Maybe I'm
 > mistaken on one of these points

Actually, some non-publicly-trusted roots are accepted by some of the
logs that crt.sh monitors.

 > Doug
 >
 > -Original Message-
 > From: dev-security-policy
mailto:dev-security-policy-boun...@lists.mozilla.org>> On
 > Behalf Of Adriano Santoni via dev-security-policy
 > Sent: Monday, October 1, 2018 9:49 AM
 > To: dev-security-policy@lists.mozilla.org

 > Subject: Re: Increasing number of Errors found in crt.sh
 >
 > Thank you Rob!
 >
 > If I am not mistaken, it seems to me that we have just 1
certificate in that
 > list, and it's a non-trusted certificate (it was issued by a test
CA).
 >
 >
 > Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha
scritto:
 >> On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
 >>> Is it possible to filter the list https://crt.sh/?cablint=issues
 >>> based on the issuing CA ?
 >>
 >> Yes.
 >>
 >> First, visit this page:
 >> https://crt.sh/?cablint=1+week
 >>
 >> Next, click on the link in the "Issuer CN, OU or O" column that
 >> corresponds to the issuing CA you're interested in.
 >>
 >>> Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha
scritto:
  Hi Wayne and all,
 
 
  I've been noticing an increasing number of CA errors,
  https://crt.sh/?cablint=issues  Is anyone monitoring this list and
  asking
  for misissuance reports for those that are not compliant?
There are 15
  different errors and around 300 individual errors (excluding
the SHA-1
  "false" errors).  Some CAs are issuing certs to CNs of
localhost, are
  including RFC822 SANs, not including OCSP links and many more.
 
  -  Actalis,
 
  -  Digicert,
 
  -  Microsoft,
 
  -
 
 
  There are also some warning checks that should actually be
errors like
  underscores in CNs or SANs.
 
 
  Doug

-- 
Rob Stradling

Senior Research & Development Scientist
Email: r...@comodoca.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-security-policy



--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

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

RE: Increasing number of Errors found in crt.sh

[Inigo Barreira via dev-security-policy]

And checking this site, how can Comodo have more certs with errors (15030) than 
certs issued (15020). 

Regards

From: dev-security-policy  on 
behalf of Adriano Santoni via dev-security-policy 

Sent: Monday, October 01, 2018 10:09 PM
To: Rob Stradling; Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Increasing number of Errors found in crt.sh

I also agree.

As I said before, that's a non-trusted certificate. It was issued by a
test CA that does /not/ chain to a public root.


Il 01/10/2018 16:04, Rob Stradling ha scritto:
> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
>> Hi Adriano,
>>
>> First, I didn't mean to call you out specifically, but you happened
>> to be
>> first alphabetically, sorry.  I find this link very helpful to list
>> all CAs
>> with errors or warnings: https://crt.sh/?cablint=1+week
>>
>> Second, How do you define a "test CA"?  I thought that any CA that
>> chains to
>> a public root was by definition not a test CA,
>
> I agree with that.
>
>> and since the issued cert was
>> in CT logs, I assumed that your root was publicly trusted. Maybe I'm
>> mistaken on one of these points
>
> Actually, some non-publicly-trusted roots are accepted by some of the
> logs that crt.sh monitors.
>
>> Doug
>>
>> -Original Message-
>> From: dev-security-policy
>>  On
>> Behalf Of Adriano Santoni via dev-security-policy
>> Sent: Monday, October 1, 2018 9:49 AM
>> To: dev-security-policy@lists.mozilla.org
>> Subject: Re: Increasing number of Errors found in crt.sh
>>
>> Thank you Rob!
>>
>> If I am not mistaken, it seems to me that we have just 1 certificate
>> in that
>> list, and it's a non-trusted certificate (it was issued by a test CA).
>>
>>
>> Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
>>> On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
 Is it possible to filter the list https://crt.sh/?cablint=issues
 based on the issuing CA ?
>>>
>>> Yes.
>>>
>>> First, visit this page:
>>> https://crt.sh/?cablint=1+week
>>>
>>> Next, click on the link in the "Issuer CN, OU or O" column that
>>> corresponds to the issuing CA you're interested in.
>>>
 Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:
> Hi Wayne and all,
>
>
> I've been noticing an increasing number of CA errors,
> https://crt.sh/?cablint=issues  Is anyone monitoring this list and
> asking
> for misissuance reports for those that are not compliant? There
> are 15
> different errors and around 300 individual errors (excluding the
> SHA-1
> "false" errors).  Some CAs are issuing certs to CNs of localhost, are
> including RFC822 SANs, not including OCSP links and many more.
>
> -  Actalis,
>
> -  Digicert,
>
> -  Microsoft,
>
> -
>
>
> There are also some warning checks that should actually be errors
> like
> underscores in CNs or SANs.
>
>
> Doug
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Increasing number of Errors found in crt.sh

[Adriano Santoni via dev-security-policy]

I also agree.

As I said before, that's a non-trusted certificate. It was issued by a 
test CA that does /not/ chain to a public root.



Il 01/10/2018 16:04, Rob Stradling ha scritto:

On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:

Hi Adriano,

First, I didn't mean to call you out specifically, but you happened 
to be
first alphabetically, sorry.  I find this link very helpful to list 
all CAs

with errors or warnings: https://crt.sh/?cablint=1+week

Second, How do you define a "test CA"?  I thought that any CA that 
chains to

a public root was by definition not a test CA,


I agree with that.


and since the issued cert was
in CT logs, I assumed that your root was publicly trusted. Maybe I'm
mistaken on one of these points


Actually, some non-publicly-trusted roots are accepted by some of the 
logs that crt.sh monitors.



Doug

-Original Message-
From: dev-security-policy 
 On

Behalf Of Adriano Santoni via dev-security-policy
Sent: Monday, October 1, 2018 9:49 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Increasing number of Errors found in crt.sh

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate 
in that

list, and it's a non-trusted certificate (it was issued by a test CA).


Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:

Is it possible to filter the list https://crt.sh/?cablint=issues
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that
corresponds to the issuing CA you're interested in.


Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and
asking
for misissuance reports for those that are not compliant? There 
are 15
different errors and around 300 individual errors (excluding the 
SHA-1

"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors 
like

underscores in CNs or SANs.


Doug




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

Re: Increasing number of Errors found in crt.sh

[Alex Gaynor via dev-security-policy]

A broader issue is that a lot of the certs listed on these pages are
publicly-trusted, but not by the Mozilla Root Program, that is to say,
Microsoft or Apple (or occasionally Adobe) trusts them.

misissued.com (which is currently erroring on all requests 😬)  tried to
address this by only showing certificates from CA's in the Mozilla Root
Program, since that's the extent of our jurisdiction (and CA's applying for
inclusion, which in some cases are ones which have a history of
non-compliance under other root programs, but there's no way to
programatically tell if a CA is applying for inclusion).

Alex


On Mon, Oct 1, 2018 at 10:05 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
> > Hi Adriano,
> >
> > First, I didn't mean to call you out specifically, but you happened to be
> > first alphabetically, sorry.  I find this link very helpful to list all
> CAs
> > with errors or warnings: https://crt.sh/?cablint=1+week
> >
> > Second, How do you define a "test CA"?  I thought that any CA that
> chains to
> > a public root was by definition not a test CA,
>
> I agree with that.
>
> > and since the issued cert was
> > in CT logs, I assumed that your root was publicly trusted.  Maybe I'm
> > mistaken on one of these points
>
> Actually, some non-publicly-trusted roots are accepted by some of the
> logs that crt.sh monitors.
>
> > Doug
> >
> > -Original Message-
> > From: dev-security-policy 
> On
> > Behalf Of Adriano Santoni via dev-security-policy
> > Sent: Monday, October 1, 2018 9:49 AM
> > To: dev-security-policy@lists.mozilla.org
> > Subject: Re: Increasing number of Errors found in crt.sh
> >
> > Thank you Rob!
> >
> > If I am not mistaken, it seems to me that we have just 1 certificate in
> that
> > list, and it's a non-trusted certificate (it was issued by a test CA).
> >
> >
> > Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
> >> On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
> >>> Is it possible to filter the list https://crt.sh/?cablint=issues
> >>> based on the issuing CA ?
> >>
> >> Yes.
> >>
> >> First, visit this page:
> >> https://crt.sh/?cablint=1+week
> >>
> >> Next, click on the link in the "Issuer CN, OU or O" column that
> >> corresponds to the issuing CA you're interested in.
> >>
> >>> Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:
>  Hi Wayne and all,
> 
> 
>  I've been noticing an increasing number of CA errors,
>  https://crt.sh/?cablint=issues  Is anyone monitoring this list and
>  asking
>  for misissuance reports for those that are not compliant? There are 15
>  different errors and around 300 individual errors (excluding the SHA-1
>  "false" errors).  Some CAs are issuing certs to CNs of localhost, are
>  including RFC822 SANs, not including OCSP links and many more.
> 
>  -  Actalis,
> 
>  -  Digicert,
> 
>  -  Microsoft,
> 
>  -
> 
> 
>  There are also some warning checks that should actually be errors like
>  underscores in CNs or SANs.
> 
> 
>  Doug
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
> ___
> 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: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:

Hi Adriano,

First, I didn't mean to call you out specifically, but you happened to be
first alphabetically, sorry.  I find this link very helpful to list all CAs
with errors or warnings: https://crt.sh/?cablint=1+week

Second, How do you define a "test CA"?  I thought that any CA that chains to
a public root was by definition not a test CA,


I agree with that.


and since the issued cert was
in CT logs, I assumed that your root was publicly trusted.  Maybe I'm
mistaken on one of these points


Actually, some non-publicly-trusted roots are accepted by some of the 
logs that crt.sh monitors.



Doug

-Original Message-
From: dev-security-policy  On
Behalf Of Adriano Santoni via dev-security-policy
Sent: Monday, October 1, 2018 9:49 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Increasing number of Errors found in crt.sh

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate in that
list, and it's a non-trusted certificate (it was issued by a test CA).


Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:

Is it possible to filter the list https://crt.sh/?cablint=issues
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that
corresponds to the issuing CA you're interested in.


Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and
asking
for misissuance reports for those that are not compliant? There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.


Doug


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

RE: Concerns with Dun & Bradstreet as a QIIS

[Tim Hollebeek via dev-security-policy]

Getting the whitelist figured out and workable will take a while.  Disclosure 
could happen much faster.

 

And I’m curious why you think it would be unauditable.  It seems 

pretty straightforward to verify such disclosures.

 

It think both ideas are worth considering.  There’s no reason we have to do 
only one or the other.

 

-Tim

 

From: Ryan Sleevi  
Sent: Friday, September 28, 2018 6:35 PM
To: Tim Hollebeek 
Cc: Dimitris Zacharopoulos ; Ian Carroll ; 
mozilla-dev-security-policy ; 
r...@sleevi.com
Subject: Re: Concerns with Dun & Bradstreet as a QIIS

 

Yes, we can punt the problem down a few years, by allowing CAs to self-report 
in unauditable ways, and shift the burden of evaluation on to the community to 
try and detect CAs misbehaving.

 

Or we can take sensible steps forward that nip the problem at its root, don’t 
require misunderstanding or misusing unrelated technologies, and instead 
achieve the goals that CAs have been claiming are valuable to achieve years 
sooner.

 

Obviously, simpler is better - and a whitelist of QGIS quickly establishes an 
interoperable and consistent baseline for organizational information, and can 
be readily deployed today, without any unnecessary infrastructure, and with 
immediate utility to existing relying parties.

 

On Fri, Sep 28, 2018 at 7:43 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

Perhaps a simple first step is to mandate disclosure of which information
source was used for validation.  Then if someone uses Google Maps or
similar, People Who Pay Attention To Such Things can start a public
discussion about whether the source is a QIIS, and whether the certificate
is mis-issued.

This would be yet another use case for my certificate metadata transparency
idea.  CAs have lots of information about the validation, issuance,
management, and revocation of certificates that really does not need to be
private.  As I've noted a few times this year, the issue keeps coming up.

If there were more hours in my day, there'd be an RFC for it already.  If
anyone wants to help with it, I'd be more than happy to work with them.

-Tim

> -Original Message-
> From: dev-security-policy   >
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Friday, September 28, 2018 10:04 AM
> To: Dimitris Zacharopoulos mailto:ji...@it.auth.gr> >
> Cc: mozilla-dev-security-policy
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >;
> Ian Carroll mailto:i...@certly.io> >
> Subject: Re: Concerns with Dun & Bradstreet as a QIIS
> 
> On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
dev-security-policy
>   > wrote:
> 
> >
> > Forgive my ignorance, but could you please explain what was your
> > ultimate goal, as "an attacker", what were you hoping to gain and how
> > could you use this against Relying Parties?
> >
> > I read your email several times but I could not easily find a case
> > where your fake address creates any serious concern for Relying
> > Parties. Even if you used the same street address as CloudFlare, the
> > CA would check against the database and would find two company records
> > that share the same address. That would obviously block the process
> > and additional checks would take place. Now, as a way to delay
> > certificate issuance for CloudFlare, I find it interesting but it
> > certainly doesn't seem to affect Relying Parties.
> >
> 
> I'm not Ian, but I would have thought his email would have been obvious
and
> clear. The confusion here is that two jurisdictions can allow different
entities
> the same name. The EVGs seek to resolve this by making use of a variety of
> ancilliary fields - such as serialNumber and the incorporation information
- to
> presumably attempt to establish to the relying party the identity they're
> speaking to.
> 
> In the "Stripe, Inc" case, the user was able to distinguish 'real' from
'fake' by
> virtue of the incorporation information - Kentucky vs California.
> However, in this case, the attack went further, in as much as through the
CA
> using an unreliable datasource to verify the jurisdictional information.
> If the CA used an unreliable datasource, then the end user would see
> something that, for intents and purposes, appears the same.
> 
> I'm not sure your point about the same address - Ian made it clear it was
a
> different but *similar* address - and I'm not sure why you suggest it
would
> block for the legitimate subscriber. Does that explain it simply enough?
> 
> 
> > And to take this one step further, I believe there are several GISs
> > that also accept whatever address you tell them because:
> >
> >  1. They have no reason to believe that you will lie to them (they know
> > who you are and in some Jurisdictions you might be prosecuted for
> > lying to the government)
> >  2. No foreseeable harm to others could be done if you misrepresent your
> > own address

RE: Increasing number of Errors found in crt.sh

[Doug Beattie via dev-security-policy]

Hi Adriano,

First, I didn't mean to call you out specifically, but you happened to be
first alphabetically, sorry.  I find this link very helpful to list all CAs
with errors or warnings: https://crt.sh/?cablint=1+week 

Second, How do you define a "test CA"?  I thought that any CA that chains to
a public root was by definition not a test CA, and since the issued cert was
in CT logs, I assumed that your root was publicly trusted.  Maybe I'm
mistaken on one of these points

Doug

-Original Message-
From: dev-security-policy  On
Behalf Of Adriano Santoni via dev-security-policy
Sent: Monday, October 1, 2018 9:49 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Increasing number of Errors found in crt.sh

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate in that
list, and it's a non-trusted certificate (it was issued by a test CA).


Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
> On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
>> Is it possible to filter the list https://crt.sh/?cablint=issues 
>> based on the issuing CA ?
>
> Yes.
>
> First, visit this page:
> https://crt.sh/?cablint=1+week
>
> Next, click on the link in the "Issuer CN, OU or O" column that 
> corresponds to the issuing CA you're interested in.
>
>> Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:
>>> Hi Wayne and all,
>>>
>>>
>>> I've been noticing an increasing number of CA errors,
>>> https://crt.sh/?cablint=issues  Is anyone monitoring this list and 
>>> asking
>>> for misissuance reports for those that are not compliant? There are 15
>>> different errors and around 300 individual errors (excluding the SHA-1
>>> "false" errors).  Some CAs are issuing certs to CNs of localhost, are
>>> including RFC822 SANs, not including OCSP links and many more.
>>>
>>> -  Actalis,
>>>
>>> -  Digicert,
>>>
>>> -  Microsoft,
>>>
>>> -
>>>
>>>
>>> There are also some warning checks that should actually be errors like
>>> underscores in CNs or SANs.
>>>
>>>
>>> Doug
>


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: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

On 01/10/2018 14:48, Adriano Santoni via dev-security-policy wrote:

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate in 
that list, and it's a non-trusted certificate (it was issued by a test CA).


For certs issued (and logged) within the last 1 week, yes, that's correct.

The summary page only deals with the past 1 week.  However, once you 
click on a link to (for example) https://crt.sh/?caid=31477&opt=cablint 
("Actalis Domain Validation Server CA G1"), there's an undocumented 
feature...


Add "minNotBefore=-MM-DD" to the URL to view linting info on older 
certs issued by that CA.

e.g., https://crt.sh/?caid=31477&opt=cablint&minNotBefore=2018-01-01

(This feature is undocumented because not all historical certs have been 
linted by crt.sh).



Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
Is it possible to filter the list https://crt.sh/?cablint=issues 
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that 
corresponds to the issuing CA you're interested in.



Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and 
asking

for misissuance reports for those that are not compliant? There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.


Doug


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

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

Re: Increasing number of Errors found in crt.sh

[Adriano Santoni via dev-security-policy]

Thank you Rob!

If I am not mistaken, it seems to me that we have just 1 certificate in 
that list, and it's a non-trusted certificate (it was issued by a test CA).



Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
Is it possible to filter the list https://crt.sh/?cablint=issues 
based on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that 
corresponds to the issuing CA you're interested in.



Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and 
asking

for misissuance reports for those that are not compliant? There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.


Doug




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

Re: Increasing number of Errors found in crt.sh

[Rob Stradling via dev-security-policy]

On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
Is it possible to filter the list https://crt.sh/?cablint=issues based 
on the issuing CA ?


Yes.

First, visit this page:
https://crt.sh/?cablint=1+week

Next, click on the link in the "Issuer CN, OU or O" column that 
corresponds to the issuing CA you're interested in.



Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and asking
for misissuance reports for those that are not compliant?  There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.


Doug


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Increasing number of Errors found in crt.sh

[Adriano Santoni via dev-security-policy]

Is it possible to filter the list https://crt.sh/?cablint=issues based 
on the issuing CA ?


Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:

Hi Wayne and all,

  


I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and asking
for misissuance reports for those that are not compliant?  There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-

  


There are also some warning checks that should actually be errors like
underscores in CNs or SANs.

  


Doug


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


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

RE: Increasing number of Errors found in crt.sh

[Doug Beattie via dev-security-policy]

That last email got away from me before I finished compiling the list, but
you get the idea.

-Original Message-
From: dev-security-policy  On
Behalf Of Doug Beattie via dev-security-policy
Sent: Monday, October 1, 2018 9:27 AM
To: mozilla-dev-security-policy

Subject: Increasing number of Errors found in crt.sh

Hi Wayne and all,

 

I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and asking
for misissuance reports for those that are not compliant?  There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-   

 

There are also some warning checks that should actually be errors like
underscores in CNs or SANs.

 

Doug



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

Increasing number of Errors found in crt.sh

[Doug Beattie via dev-security-policy]

Hi Wayne and all,

 

I've been noticing an increasing number of CA errors,
https://crt.sh/?cablint=issues  Is anyone monitoring this list and asking
for misissuance reports for those that are not compliant?  There are 15
different errors and around 300 individual errors (excluding the SHA-1
"false" errors).  Some CAs are issuing certs to CNs of localhost, are
including RFC822 SANs, not including OCSP links and many more.

-  Actalis,

-  Digicert,

-  Microsoft,

-   

 

There are also some warning checks that should actually be errors like
underscores in CNs or SANs.

 

Doug



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: Concerns with Dun & Bradstreet as a QIIS

[Dimitris Zacharopoulos via dev-security-policy]

On 1/10/2018 1:06 μμ, Ryan Sleevi via dev-security-policy wrote:

On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos 
wrote:


Perhaps I am confusing different past discussions. If I recall correctly,
in previous discussions we described the case where an attacker tries to
get a certificate for a company "Example Inc." with domain "example.com".
This domain has a domain Registrant Address as "123 Example Street".

The attacker registers a company with the same name "Example Inc." in a
different jurisdiction, with address "123 Example Street" and a different
(attacker's) phone number. How is the attacker able to get a certificate
for example.com? That would be a real "attack" scenario.


Yes, you are confusing things, as I would have thought this would be a
'simple' discussion. Perhaps this confusion comes from only thinking the
domain name matters in making an 'attack'. If that's the case, we can do
away with EV and OV entirely, because they do not provide value to that
domain validation. Alternatively, if we say that information is relevant,
then the ability to spoof any of that information also constitutes an
'attack' - to have the information for one organization presented in a
different (logical, legal) organization's associated information.


I'm just trying to understand the "attack" scenario of Ian. Domain 
Validation is the baseline and OV/EV builds on top of that to include 
verified information to the Relying Parties to assist in Trust 
decisions. There were suggestions in the past that the use of OV/EV 
validation of identity can substitute parts of Domain Validation but 
it's clear that this is not the case we are discussing.







Unless this topic comes as a follow-up to the previous discussion of
displaying the "Stripe Inc." information to Relying Parties, with the
additional similarity in Street Address and not just the name of the
Organization. If I recall correctly, that second "Stripe Inc." was not a
"fake" entity but a "real" entity that was properly registered in some
Jurisdiction. This doesn't seem to be the same attack scenario as getting a
certificate for a Domain for which you are not the owner nor control, but a
way to confuse Relying Parties. Certainly, in case of fraud, this leaves a
lot more evidence for the authorities to trail back to a source, than for a
case without Organization information.


This also seems to be fixing on the domain name, but I have no idea why
you've chosen that as the fixation, as the discussion to date doesn't
involve that. I don't think it's your intent, but it sounds like you're
saying "It's better for CAs to put inaccurate and misleading information in
certificates, because at least then it's there" - which surely makes no
sense.



No, this was not about the domain name but about the information 
displayed to the Relying Party with the attributes included in the OV/EV 
Certificate (primarily the Organization). So, I'm still uncertain if 
Ian's "misleading street address" was trying to get a certificate for 
domain "stripe.com" owned by "Stripe Inc." in California, or was trying 
to get a certificate for "ian's domain.com" owned by "Stripe Inc." in 
Kentucky, as was the previous discussions. The discussion so far 
indicates that it's the latter, with the additional element that now the 
Street Address is also misleading.


I am certainly not suggesting that CAs should put inaccurate and 
misleading information in certificates :-) I merely said that if the 
Subscriber introduces misleading or inaccurate information in 
certificates via a reliable information source, then there will probably 
be a trail leading back to the Subscriber. This fact, combined with the 
lack of clear damage that this can cause to Relying Parties, makes me 
wonder why doesn't the Subscriber, that wants to mislead Relying 
Parties, just use a DV Certificate where this probably doesn't leave so 
much evidence tracing back to the Subscriber?



But they do have some Reliable and Qualified Information according to our
standards (for example registry number, legal representative, company
name). If a CA uses only this information from that source, why shouldn't
it be considered reliable? We all need to consider the fact that CAs use
tools to do their validation job effectively and efficiently. These tools
are evaluated continuously. Complete dismissal of tools must be justified
in a very concrete way.


No, they are not Reliable Data Sources. Using unreliable data sources,
under the motto that "even a stopped clock is right twice a day", requires
clear and concrete justification. The burden is on the CA to demonstrate
the data sources reliability. If there is any reason to suspect that a
Reliable Data Source contains inaccurate data, you should not be using it -
for any data.


But this inaccurate data is not used in the validation process nor 
included in the certificates. Perhaps I didn't describe my thoughts 
accurately. Let me have another try using my previous example. 

Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)

[Matt Palmer via dev-security-policy]

On Wed, Sep 26, 2018 at 07:36:57AM -0700, josselin.allemandou--- via 
dev-security-policy wrote:
> Thank you for your exchanges. We hope that the additions below will answer 
> your questions.

It appears that your response has removed most indications of what parts of
your message are my questions, compared to your responses.  For clarity,
I've re-added appropriate formatting, but it would be appreciated if you
could use standard e-mail formatting in the future.

> > Was the action required to manually override the CAA validation failure
> > different from what would be required if the CAA validation had succeeded? 
> > Could an operator have just "clicked the same button they always clicked",
> > and have the CAA validation failure overridden?  Or was there a separate
> > sequence of UI interactions required to override a CAA validation failure?
> > 
> > This answer does not address the controls in place at the time of the
> > misissuance.  Any action which an operator can manually take should be able
> > to be audited for correctness, but I don't see any mention of that being a
> > possibility in your response.  I take that to mean that there are no
> > functional audit logs, or at least that there are no effective audits
> > (sampling or otherwise) of those logs, for decisions and actions undertaken
> > by registration agents.
> 
> The check on the authorization to be issued for the organization was the
> only one that combined both the verification of the consent form and the
> verification of DNS CAA alerts.  The operator could view the alert but the
> same validation button was used to proceed to the next step, whether the
> DNS CAA is valid or not.

Thank you for this clear statement of your validation interface design. 
Unfortunately, this sounds like a design which is extremely risky, from an
unintentional errors perspective.  What form(s) of review for UX, including
but not limited to human factors of safety, were applied to this interface
prior to it being deployed?

> Each operation performed by an operator is traced so that it can be
> audited.  The periodic audits of registration requests are also intended
> to ensure the conduct of controls by RA and the conformity of their
> results.

Based on your initial report, I got the impression that the misissuance
we're discussing was not picked up by an ordinary operational audit, but was
instead identified by some sort of extraordinary review.  Is that an
accurate impression?  If so, can you provide more detail around the
criteria you use for selecting operations for auditing, and the frequency of
those audits, with particular reference to how such an unusual event
(overriding a CAA validation failure) wasn't picked up by ordinary auditing?

> > This sounds like there may have been a misunderstanding in the BR
> > description of CAA validation.
> > 
> > What specific language in the BRs surrounding CAA validation caused you to
> > believe that successful CAA validation was optional in the presence of other
> > forms of consent?
> >
> > What changes do you propose in the language of the CAA validation
> > requirements in the BRs to ensure that no other CA could possibly
> > misunderstand the CAA validation requirements?
> 
> We have no improvement to issue regarding BRs.  We understood the
> requirement and implemented the DNS CAA control but we made two errors:
>
> - The first is to have assessed that the existing control having the same
>   purpose, made it possible to cover the risks and requirements related to
>   the control of the DNS CAA.  This decision led to wrongly allow RA
>   operators to validate this checkpoint despite DNS CAA alerts.
>
> - The second is to have accumulated these two controls (consent + DNS CAA)
>   in the same validation step because they had the same objective, and
>   this without imposing that the DNS CAA negative result be blocking.

I'm unable to reconcile your two statements.  "We understood the
requirements" cannot be true at the same time as you made errors in
understanding the requirements.  It's not logically possible for both of
those to be true at the same time.

That the misunderstand occured is not at issue.  The important question that
needs answering is: how did the misunderstanding occur?  Perhaps the BRs are
insufficiently clear, either on the particulars of the need for CAA
validation, or in the larger sense that the prescriptive controls laid out
in the BRs cannot be substituted for controls which the CA happens to feel
are equivalent.  If that is the case, then the BRs need to be clarified in
some way, so that other CAs cannot suffer from the same misunderstanding in
the future.

Alternately, if the BRs *are*, in fact, sufficiently clear in all respects,
the only other possibility that comes to my mind is that Certigna failed to
correctly interpret the BRs, which is far more concerning -- for Certigna,
at least.  It would mean that there could be any number of other, as yet
unidentified, misunde

Re: Concerns with Dun & Bradstreet as a QIIS

[Ryan Sleevi via dev-security-policy]

On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos 
wrote:

> Perhaps I am confusing different past discussions. If I recall correctly,
> in previous discussions we described the case where an attacker tries to
> get a certificate for a company "Example Inc." with domain "example.com".
> This domain has a domain Registrant Address as "123 Example Street".
>
> The attacker registers a company with the same name "Example Inc." in a
> different jurisdiction, with address "123 Example Street" and a different
> (attacker's) phone number. How is the attacker able to get a certificate
> for example.com? That would be a real "attack" scenario.
>

Yes, you are confusing things, as I would have thought this would be a
'simple' discussion. Perhaps this confusion comes from only thinking the
domain name matters in making an 'attack'. If that's the case, we can do
away with EV and OV entirely, because they do not provide value to that
domain validation. Alternatively, if we say that information is relevant,
then the ability to spoof any of that information also constitutes an
'attack' - to have the information for one organization presented in a
different (logical, legal) organization's associated information.


> Unless this topic comes as a follow-up to the previous discussion of
> displaying the "Stripe Inc." information to Relying Parties, with the
> additional similarity in Street Address and not just the name of the
> Organization. If I recall correctly, that second "Stripe Inc." was not a
> "fake" entity but a "real" entity that was properly registered in some
> Jurisdiction. This doesn't seem to be the same attack scenario as getting a
> certificate for a Domain for which you are not the owner nor control, but a
> way to confuse Relying Parties. Certainly, in case of fraud, this leaves a
> lot more evidence for the authorities to trail back to a source, than for a
> case without Organization information.
>

This also seems to be fixing on the domain name, but I have no idea why
you've chosen that as the fixation, as the discussion to date doesn't
involve that. I don't think it's your intent, but it sounds like you're
saying "It's better for CAs to put inaccurate and misleading information in
certificates, because at least then it's there" - which surely makes no
sense.


> But they do have some Reliable and Qualified Information according to our
> standards (for example registry number, legal representative, company
> name). If a CA uses only this information from that source, why shouldn't
> it be considered reliable? We all need to consider the fact that CAs use
> tools to do their validation job effectively and efficiently. These tools
> are evaluated continuously. Complete dismissal of tools must be justified
> in a very concrete way.
>

No, they are not Reliable Data Sources. Using unreliable data sources,
under the motto that "even a stopped clock is right twice a day", requires
clear and concrete justification. The burden is on the CA to demonstrate
the data sources reliability. If there is any reason to suspect that a
Reliable Data Source contains inaccurate data, you should not be using it -
for any data.


> I would accept your conclusion for an Information Source that claimed, in
> their practices, that they verify some information against a secondary
> government database and the CA gets evidence that they don't actually do
> that. This means that the rest of the "claimed as verified" information is
> now questionable. This is very much similar to the Browsers checking for
> misbehavior on CAs where they claim certain practices in their CP/CPS and
> don't actually implement them. That would be a case where the CA might
> decide to completely distrust that Information Source.
>
> I hope you can see the difference.
>

I hope you can understand that this is not an apt or accurate comparison.
An organization that lacks a process, which is the case for unreliable
data, is no different than an organization that declares a process but does
not follow it.


> I remember this argument being supported in the past and although I used
> to agree to it, with the recent developments and CA disqualifications, I
> support the opposite. That is, Subscribers start to choose their CA more
> carefully and pay attention to the trust, reputation and practices, because
> of the risk of getting their Certificates challenged, revoked or the CA
> distrusted.
>

So you believe it's in best interests of Subscribers to have CAs
distrusted, certificates challenged and revoked, and for relying parties to
constantly call into question the certificates they encounter? And that
this is somehow better than consistently applied and executed validation
processes? I wish I could share your "Mad Max" level of optimism, but it
also fails to understand that we're not talking about Subscriber selection,
we're talking about adversarial models. The weakest link matters, not
"market reputation", as much as some CAs would like to believe.