Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Wayne Thayer via dev-security-policy]

As an alternative to requiring newly-issued subCA Certificates to be listed
in the relevant CP/CPS prior to issuing certificates, would it be
reasonable for Mozilla to require the Certificate Policies extension in
these certificates to contain a URL pointing to the relevant policy
document(s)? I believe that most subCA certificates already contain this
information.

In theory, we could also permit three options - add the new subCA
certificate to the relevant CP/CPS, include a Certificate Policies pointer,
or publish an attestation, but I'd prefer a single, consistent mechanism
that allows a relying party to determine which policies apply.

- Wayne

On Thu, Apr 5, 2018 at 1:12 PM, Ben Wilson  wrote:

> That is a distinction without a difference.  If I create a subCA, it’s
> because I want to put it into production soon afterwards. This proposal is
> going to add hours per week that DigiCert is going to have to do, on top of
> reporting CAs to the CCADB, and everything else that CAs have to do.  What
> is the security-critical driver behind this?  Where is the
> risk-cost-benefit analysis?
>
>
>
> *From:* Wayne Thayer [mailto:wtha...@mozilla.com]
> *Sent:* Thursday, April 5, 2018 1:56 PM
> *To:* Ben Wilson 
> *Cc:* Dimitris Zacharopoulos ; r...@sleevi.com;
> mozilla-dev-security-policy  >
> *Subject:* Re: Policy 2.6 Proposal: Audit requirements for new subCA
> certificates
>
>
>
> On Thu, Apr 5, 2018 at 12:05 PM, Ben Wilson 
> wrote:
>
> If I create a new sub CA on a weekly basis, will that mean that I have to
> republish my CPS every week?  That makes absolutely no sense.
>
> As proposed, the requirement isn't based on when the subCA certificate is
> created - it requires the subCA to be added to the CP/CPS before being used
> to issue certificates. Refer to the following thread for background on this
> proposal: https://groups.google.com/d/msg/mozilla.dev.security.
> policy/CAaC2a2HMiQ/IKimeW4NBgAJ
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

I've gone ahead and removed references to ETSI TS 101 456 and TS 102 042
from the 2.6 branch of the policy:
https://github.com/mozilla/pkipolicy/commit/49a07119a1fd5c887d4b506f60e210fad941b26a

- Wayne


On Tue, Mar 27, 2018 at 12:44 PM, Wayne Thayer  wrote:

> There has been a lot of confusion about the transition to the new
> standards, and I believe that this change makes it clearer that Mozilla no
> longer accepts audits based on the older ETSI standards.
>
> On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> European Conformity Assessment Bodies are nowadays issuing Audit
>> Certificates aligned with EN 319 401, EN 319-411-1 and EN 319 411-2
>> standards.
>>
>> There is no need to explicitly deny validity to previous standars,
>> because as Jakob states, they can reflect the chain of audits.
>>
>> In fact, TS 102 042 and TS 101 456 are basically the same standards, but
>> instead of changing only the version number, ETSI opted to renew the full
>> reference code, more in the approach of IETF for RFCs.
>>
>> The Mozilla rule also is aligned with CAB Forum Baseline Requirements for
>> the Issuance and Management of Publicly-Trusted Certificates and Extended
>> Validation SSL Certificate Guidelines, and any change to those documents
>> would need a ballot.
>>
>> This is the kind of confusion that I hope to avoid. Mozilla policy is not
> aligned with the BRs now that Mozilla does not accept TS 102 042 and TS 101
> 456 audits.
>
> Regards,
>>
>> Julian Inza
>>
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Matthew Hardeman via dev-security-policy]

Isn't that question a little disingenuous?

There was massive controversy in the mainstream tech press and throughout
the InfoSec press and elsewhere when a certificate with this EV indication
for this entity name for this website and purpose previously issued.  It
invites trouble in the sense that one must assume that the reaction will be
more of the same -- worse, actually, as it now suggests that the last time
wasn't a fluke.

It is difficult to believe that a rational actor would not expect an
issuance of the same nature as last time to yield anything other than the
same controversy.

For most commercial entities, taking an action that results in something
you're able to monetize and sell today becoming something you can no longer
meaningfully sell tomorrow is "inviting trouble".

Matt

On Wed, Apr 11, 2018 at 2:31 PM, Jonathan Rudenberg 
wrote:

>
>
> What "trouble" is being invited? I don't see a problem. Everything is
> operating exactly as expected. GoDaddy did nothing wrong.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Matthew Hardeman via dev-security-policy]

I'm not sure why it can't be evidence of both.

Is it an offense by GoDaddy for which there should be repercussions from
the root programs towards GoDaddy?  No.

You're correct that it illustrates that EV has an enormous value gap in its
current form.  My own opinion is that I would rather see that fixed than no
mechanism remain for tying websites to the physical world.

I do not believe it is impossible to fix.

On Wed, Apr 11, 2018 at 2:23 PM, Alex Gaynor  wrote:

> I disagree on what this is evidence of:
>
> It's evidence that the claimed benefits of EV (by CA, WRT phishing) do not
> match the technical reality. As Ryan noted, as far as I'm aware this
> certificate violates neither the BRs, nor the EVG.
>
> Alex
>
> On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via dev-security-policy
>  wrote:
>
>> Additionally, I think it's fair to say that I'm aghast that another CA
>> (who by their inclusion in the Mozilla root program has agreed to stay
>> abreast of developments on this list) has issued for the exact same entity
>> and name that already led to significant controversy covered on this list
>> less than a year ago.
>>
>> I believe that speaks to inattention to the list or failure to
>> incorporate lessons learned from controversies on this list into issuance
>> and/or validation practice.
>>
>> On Wednesday, April 11, 2018 at 1:19:03 PM UTC-5, Ryan Sleevi wrote:
>>
>> > Could you clarify what you're aghast at?
>> ___
>> 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Jonathan Rudenberg via dev-security-policy]

On Wed, Apr 11, 2018, at 15:27, Matthew Hardeman via dev-security-policy wrote:
> It was injudicious of a CA to issue another certificate in this name for
> this entity after the already well documented controversy.  Did they just
> not care that it would invite trouble or did they not know that it would
> invite controversy and trouble because they didn't track it the first time
> around?

What "trouble" is being invited? I don't see a problem. Everything is operating 
exactly as expected. GoDaddy did nothing wrong.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Matthew Hardeman via dev-security-policy]

This absolutely appears to be valid issuance.

And if it's valid issuance, that raises questions about the value of EV, if
we accept that the definition of EV is static and unchangeable.

What I propose is that the community of CAs either recognize that it's
worthless and give up on it - or - recognize that it's worthless as-is and
rapidly make significant changes in order to make it valuable to users and
attempt to save it.

It was injudicious of a CA to issue another certificate in this name for
this entity after the already well documented controversy.  Did they just
not care that it would invite trouble or did they not know that it would
invite controversy and trouble because they didn't track it the first time
around?


On Wed, Apr 11, 2018 at 2:23 PM, Jonathan Rudenberg 
wrote:

>
>
> I strongly disagree. Everything is operating correctly. Corporate entity
> names are not unique, which is why EV is not useful. There were no lessons
> to be learned from the previous thread other than the fact that EV does not
> provide any useful guarantees to Mozilla's users.
>
> Jonathan
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Alex Gaynor via dev-security-policy]

I disagree on what this is evidence of:

It's evidence that the claimed benefits of EV (by CA, WRT phishing) do not
match the technical reality. As Ryan noted, as far as I'm aware this
certificate violates neither the BRs, nor the EVG.

Alex

On Wed, Apr 11, 2018 at 2:48 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Additionally, I think it's fair to say that I'm aghast that another CA
> (who by their inclusion in the Mozilla root program has agreed to stay
> abreast of developments on this list) has issued for the exact same entity
> and name that already led to significant controversy covered on this list
> less than a year ago.
>
> I believe that speaks to inattention to the list or failure to incorporate
> lessons learned from controversies on this list into issuance and/or
> validation practice.
>
> On Wednesday, April 11, 2018 at 1:19:03 PM UTC-5, Ryan Sleevi wrote:
>
> > Could you clarify what you're aghast at?
> ___
> 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: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Jonathan Rudenberg via dev-security-policy]

On Wed, Apr 11, 2018, at 14:48, Matthew Hardeman via dev-security-policy wrote:
> Additionally, I think it's fair to say that I'm aghast that another CA 
> (who by their inclusion in the Mozilla root program has agreed to stay 
> abreast of developments on this list) has issued for the exact same 
> entity and name that already led to significant controversy covered on 
> this list less than a year ago.

This is a real legal entity, which almost certainly went through proper EV 
validation. Everything appears to be in order.

> I believe that speaks to inattention to the list or failure to 
> incorporate lessons learned from controversies on this list into 
> issuance and/or validation practice.

I strongly disagree. Everything is operating correctly. Corporate entity names 
are not unique, which is why EV is not useful. There were no lessons to be 
learned from the previous thread other than the fact that EV does not provide 
any useful guarantees to Mozilla's users.

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Matthew Hardeman via dev-security-policy]

Additionally, I think it's fair to say that I'm aghast that another CA (who by 
their inclusion in the Mozilla root program has agreed to stay abreast of 
developments on this list) has issued for the exact same entity and name that 
already led to significant controversy covered on this list less than a year 
ago.

I believe that speaks to inattention to the list or failure to incorporate 
lessons learned from controversies on this list into issuance and/or validation 
practice.

On Wednesday, April 11, 2018 at 1:19:03 PM UTC-5, Ryan Sleevi wrote:

> Could you clarify what you're aghast at?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require audits back to first issuance

[Wayne Thayer via dev-security-policy]

Thank you for responding Matthias.

On Wed, Apr 11, 2018 at 10:52 AM, m.wiedenhorst--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Hi Wayne
>
> > Can anyone say if an equivalent public-facing
> > report exists for ETSI audits? If so, I think we should require CAs to
> > provide these reports with their root inclusion requests.
>
> ETSI does require reports on key ceremonies (ETSI EN 319 411-1, 6.5.1 g).
> But ETSI does NOT require these reports to be public.
>
> Does ETSI ALLOW these reports to be public? In other words, could Mozilla
require CAs to publish them?

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

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Ryan Sleevi via dev-security-policy]

On Wed, Apr 11, 2018 at 1:51 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> I'm merely an interested community member.
>
> I'm writing because I'm aghast that yet another CA has issued a
> certificate for Stripe, Inc of Kentucky.
>

It fully complies with all stated expectations of the EV Guidelines, the
information is fully accurate, and it does not appear to be fraudulent or
misleading in that.

Could you clarify what you're aghast at?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Ian Carroll via dev-security-policy]

> an EV certificate issued and fairly promptly revoked by Comodo.


Just to clarify, Comodo revoked it at least four months after it was issued 
(https://crt.sh/?id=273634647). It was not "promptly" revoked.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require audits back to first issuance

[m.wiedenhorst--- via dev-security-policy]

Hi Wayne

> Can anyone say if an equivalent public-facing
> report exists for ETSI audits? If so, I think we should require CAs to
> provide these reports with their root inclusion requests. 

ETSI does require reports on key ceremonies (ETSI EN 319 411-1, 6.5.1 g). 
But ETSI does NOT require these reports to be public. 

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

Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Matthew Hardeman via dev-security-policy]

Hi,

I'm merely an interested community member.

I'm writing because I'm aghast that yet another CA has issued a certificate for 
Stripe, Inc of Kentucky.

One would think that the various commercial CAs would consider their communal 
self-interests in today's marketplace.

The commercial CA historically has commanded significant valuation as a 
recurring revenue model in a market with high barriers to entry.

Recently, however, economies of scale and new entrants have taken the value of 
DV-certificates to approximately $0.00 at retail.

You'd think a premium product like EV certificates, which must be a significant 
source of commercial CA revenue would be jealously policed and guarded by CAs.

You'd think the various CAs who are all required to read this mailing list 
would keep up with the controversy around this same business entity and an EV 
certificate issued and fairly promptly revoked by Comodo.

Everytime these matters arise, it raises serious community concerns to the 
value and appropriateness of browser favoritism afforded EV certificates.

Will it survive this time?  Who can say.

Be we definitely can ask GoDaddy CA why they issued a certificate for the same 
entity that in quite recent memory sparked controversy on this forum.

Thanks,

Matt

PS - I strongly suggest that any CA interested in preserving EV revenue get 
with the others and come up with a publish-for-opposition before issuance 
scheme and mandatory field-of-use monitoring for lifetime of issued 
certificates for EV or some real enhancement which will confound those would 
attempt to get these kinds of certificates.  This is technically not a 
mis-issuance, and that's a significant problem for the value case of EV.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

[Wayne Thayer via dev-security-policy]

I've asked the Government of Korea to comment on this news article in their
inclusion request (https://bugzilla.mozilla.org/show_bug.cgi?id=1377389).

- Wayne

On Wed, Apr 11, 2018 at 7:26 AM, jumping2gether--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> According to the official briefing by the Government of Korea on April 9
> 2018,
> The government CA discovered suspicious misissuance on April 5. They
> revoked the certificate on April 6 and began investigating all valid SSL
> certificates.
>
> src (in Korean): http://www.korea.kr/briefing/actuallyView.do?newsId=
> 148849591_from=naver_news
>
>
> The prompt actions by the CAs were taken in compliance with CA/Browser
> Forum BRs.
> 4.9.1.1. Reasons for Revoking a Subscriber Certificate
> The CA SHALL revoke a Certificate within 24 hours if the CA is made aware
> that a Wildcard Certificate has been used to authenticate a fraudulently
> misleading subordinate Fully-Qualified Domain Name.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CCADB disclosure of id-kp-emailProtection intermediates

[Mads Egil Henriksveen via dev-security-policy]

Hi

One of the non-technically-constrained intermediate certificates on the list 
[2] below is issued by Buypass and this was revoked today - see 
https://crt.sh/?id=157337628. 

This was done to be compliant with Section 5.3.1 of Mozilla Root Store Policy v 
2.5 [1] - as specified in Action 1 of November 2017 CA Communication: "By April 
15, 2018, all intermediate certificates (that chain up to root certificates 
included in Mozilla's program) that are capable of issuing S/MIME certificates 
but are not name constrained must be either audited and disclosed in the Common 
CA Database, or be revoked".

Please let me know if any further action(s) are required from our side. 

Regards
Mads

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Rob Stradling via dev-security-policy
Sent: tirsdag 16. januar 2018 22:29
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: CCADB disclosure of id-kp-emailProtection intermediates

[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents Mozilla's 
policy and/or current expectations.  Thanks!]

Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the non-disclosure 
(and, IINM, non-audit) of certain non-technically-constrained 
id-kp-emailProtection intermediate certificates...until yesterday:
"Instead of complying with the above paragraph, intermediate certificates 
issued before 22nd June 2017 may, until 15th January 2018..."

According to [2], there are currently 223 non-technically-constrained 
intermediate certificates known to crt.sh that chain to an NSS built-in root 
(that has the Email trust bit set) and are capable of issuing 
id-kp-emailProtection certificates but not id-kp-serverAuthentication 
certificates.

IIUC, the Mozilla policy now requires these intermediate certificates to have 
already been disclosed to the CCADB and to be audited.


[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained

[2] https://crt.sh/mozilla-disclosures#undisclosed

[3] https://crt.sh/mozilla-disclosures#undisclosedsummary

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
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: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

[jumping2gether--- via dev-security-policy]

Your inquiry was posted with unsubstantiated information. crt.sh logged that a 
certificate including www.testssl.com was issued by a CA certificate (CN: 
CA134100031) on 2017-02-17, but already revoked. 

Deloitte Anjin didn't issue a WTCA-SSL report on the CA certificate after 
2017-01-01.


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

Re: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

[jumping2gether--- via dev-security-policy]

According to the official briefing by the Government of Korea on April 9 2018, 
The government CA discovered suspicious misissuance on April 5. They revoked 
the certificate on April 6 and began investigating all valid SSL certificates. 

src (in Korean): 
http://www.korea.kr/briefing/actuallyView.do?newsId=148849591_from=naver_news


The prompt actions by the CAs were taken in compliance with CA/Browser Forum 
BRs. 
4.9.1.1. Reasons for Revoking a Subscriber Certificate
The CA SHALL revoke a Certificate within 24 hours if the CA is made aware that 
a Wildcard Certificate has been used to authenticate a fraudulently misleading 
subordinate Fully-Qualified Domain Name.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

[jumping2gether--- via dev-security-policy]

Your information is incorrect. 

According to crt.sh, Ministry of Education CA(CA134100031)issued a mis-issued 
certificate to www.testssl.com on 2017-04-03 but already revoked.
Deloitte Anjin didn't issue a WTCA-SSL report to the CA certificate after 
2017-01-01. 
 
 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy