RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

I think "apple-id-2.com" is a high risk domain that must be blocked to issue DV 
SSL to those domains.

Here is the list of some high risk domains related to Microsoft and Google that 
Let's Encrypt issued DV SSL certificates to those domains:
https://crt.sh/?id=77034583  for microsoftonline.us.com, a fake Office 365 
login site   
https://crt.sh/?id=71789336  for mail.google-androids.ru
https://crt.sh/?id=82075006  for marketgoogle.xyz
https://crt.sh/?id=65208905  for google.ligboy.org


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, February 23, 2017 8:30 AM
To: Tony Zhaocheng Tan ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never 
> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

"Head of Let's Encrypt here. Our team is looking into this and so far we don't 
see any evidence of mis-issuance in our logs. It looks like the domain in 
question, 'apple-id-2.com', was registered and DNS resolved for it successfully 
at time of issuance. Here is the valid authorization record including the 
resolved IP addresses for 'apple-id-2.com':

https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

We can't be sure why the reporter was unable to find a WHOIS record, we can 
only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and then 
released it after getting a certificate from us."

There is currently an entry in WHOIS, because some well-meaning but unhelpful 
person registered it today. I assume that if a domain is registered and then 
released, and then re-registered, the "Creation"
date is of the re-registration, not the first ever registration.

So unless someone can show it was unregistered at the time of issuance, I don't 
see an issue here.

Gerv
___
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

Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Tony Zhaocheng Tan via dev-security-policy]

On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com. However, 
until today, the domain apple-id-2.com has apparently never been registered. 
How was the certificate issued?

Sources:

https://crt.sh/?q=24ba82659f808f6c5af1816857701bf970cf6ec5751357fea42ef8c4140a4caf

https://twitter.com/beast_fighter/status/834190510642384897

https://news.ycombinator.com/item?id=13709150
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Tony Zhaocheng Tan via dev-security-policy]

Yep, no issue here anymore. Josh Aas hadn't posted on hacker news when I sent 
this.

Thanks,
Tony


Tony Zhaocheng Tan | t...@tonytan.io | PGP Key
 Original Message 
On Feb 22, 2017, 7:30 PM, Gervase Markham wrote:

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never
> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

"Head of Let's Encrypt here. Our team is looking into this and so far we
don't see any evidence of mis-issuance in our logs. It looks like the
domain in question, 'apple-id-2.com', was registered and DNS resolved
for it successfully at time of issuance. Here is the valid authorization
record including the resolved IP addresses for 'apple-id-2.com':

https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

We can't be sure why the reporter was unable to find a WHOIS record, we
can only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and
then released it after getting a certificate from us."

There is currently an entry in WHOIS, because some well-meaning but
unhelpful person registered it today. I assume that if a domain is
registered and then released, and then re-registered, the "Creation"
date is of the re-registration, not the first ever registration.

So unless someone can show it was unregistered at the time of issuance,
I don't see an issue here.

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

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Ryan Sleevi via dev-security-policy]

There is no definition or requirement for what a high risk domain is.
That's the point/problem.

WoSign may determine "apple", "google", "microsoft", and "github" as High
Risk.
Amazon may determine certificates issued on the first of the month are more
likely to be High Risk (because it may be that the 1st of the month is the
most lucrative time for credit card scammers to use their ill-gotten gains
to produce dangerous domains)

On Wed, Feb 22, 2017 at 7:55 PM, Richard Wang  wrote:

> I don't agree this.
> If "apple", "google", "Microsoft" is not a high risk domain, then I don’t
> know which domain is high risk domain, maybe only "github".
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Thursday, February 23, 2017 11:53 AM
> To: Richard Wang 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony
> Zhaocheng Tan ; Gervase Markham 
> Subject: Re: Let's Encrypt appears to issue a certificate for a domain that
> doesn't exist
>
> On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
>  wrote:
> > As I understand, the BR 4.2.1 required this:
> >
> > “The CA SHALL develop, maintain, and implement documented procedures that
> > identify and require additional verification activity for High Risk
> > Certificate Requests prior to the Certificate’s approval, as reasonably
> > necessary to ensure that such requests are properly verified under these
> > Requirements.”
> >
> > Please clarify this request, thanks.
>
> Richard,
>
> That sentence does not say that domain names including "apple", "google",
> or
> any other string are High Risk Certificate Requests
> (HRCR).   I could define HRCR as being those that contain domain names
> that contain mixed script characters as defined in UTS #39 section 5.1.
> "apple-id-2.com" is not mixed script so it is not a HRCR based on this
> definition.
>
> Thanks,
> Peter
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued/Suspicious Symantec Certificates

[Ryan Sleevi via dev-security-policy]

Hi Steve,

Thanks for your continued attention to this matter. Your responses open
many new and important questions and which give serious question as to
whether the proposed remediations are sufficient. To keep this short, and
thereby allow Symantec a more rapid response:

1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner
since the acquisition by Symantec of the VeriSign Trust Services business
in 2010.



On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Our third response to questions, including these two below, is posted at
> Bugzilla, and directly at https://bug1334377.
> bmoattachments.org/attachment.cgi?id=8838825.
>
>
>
>
>
> From: Ryan Sleevi [mailto:r...@sleevi.com]
> Sent: Friday, February 17, 2017 6:54 PM
> To: Ryan Sleevi 
> Cc: Gervase Markham ; mozilla-dev-security-policy@
> lists.mozilla.org; Steve Medin 
> Subject: Re: Misissued/Suspicious Symantec Certificates
>
>
>
> Hi Steve,
>
>
>
> Two more question to add to the list which is already pending:
>
>
>
> In [1], in response to question 5, Symantec indicated that Certisign was a
> WebTrust audited partner RA, with [2] provided as evidence to this fact.
> While we discussed the concerns with respect to the audit letter,
> specifically in [3], questions 3 - 6, and while Symantec noted that it
> would case to accept future EY Brazil audits, I have confirmed with CPA
> Canada that at during the 2016 and 2017 periods, EY Brazil was not a
> licensed WebTrust practitioner, as indicated at [4].
>
>
>
> Given that EY Brazil was not a licensed WebTrust auditor, it appears that
> Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1
> [5], namely, that "(For audits conducted in accordance with the WebTrust
> standard) licensed by WebTrust", which is a requirement clearly articulated
> in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not
> using one of the above procedures and the Delegated Third Party is not an
> Enterprise RA, then the CA SHALL obtain an audit report, issued under the
> auditing standards that underlie the accepted audit schemes found in
> Section 8.1, ..."
>
>
>
> 1) Was Symantec's compliance team involved in the review of Certisign's
> audit?
>
> 2) Does Symantec agree with the conclusion that, on the basis of this
> evidence, Symantec failed to uphold the Baseline Requirements, independent
> of any action by a Delegated Third Party?
>
>
>
> [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933<
> https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1L
> RVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%
> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%
> 3D8831933>
>
> [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929<
> https://clicktime.symantec.com/a/1/pfZiLBH0rxpzxfeiB5YSfvWdOjwpHC
> 72M_rUahZJxKQ=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%
> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%
> 3D8831929>
>
> [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487<
> https://clicktime.symantec.com/a/1/80dDdC7HC5yMdzxfwRS0saqQ2kS5Tv
> wuo_kNWaXWLCI=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%
> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%
> 3D8836487>
>
> [4] http://www.webtrust.org/licensed-webtrust-practitioners-international/
> item64419.aspx
>
> [5] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf<
> https://clicktime.symantec.com/a/1/7AUAkdAzUJ1un022RuP_
> TfjD3UiY12QGLjanVeGgxhk=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
> 

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Ryan Sleevi via dev-security-policy]

Hi Richard,

There's no policies in the Baseline Requirements or Mozilla Requirements
that normalize or define high risk domain, which I believe your suggestion
presupposes.

Perhaps you (or Qihoo 360, as the voting member of the Forum of the
Qihoo/WoSign/StartCom collection) would consider proposing a Ballot to the
Baseline Requirements to address this. Alternatively, perhaps you would
have a concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that
might be able to address this in a consistent and auditable way and in a
manner consistent with Mozilla's policy goals regarding misissuance.

This is https://github.com/mozilla/pkipolicy/issues/1 for what it's worth,
recently resolved in Policy 2.4

On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think "apple-id-2.com" is a high risk domain that must be blocked to
> issue DV SSL to those domains.
>
> Here is the list of some high risk domains related to Microsoft and Google
> that Let's Encrypt issued DV SSL certificates to those domains:
> https://crt.sh/?id=77034583  for microsoftonline.us.com, a fake Office
> 365 login site
> https://crt.sh/?id=71789336  for mail.google-androids.ru
> https://crt.sh/?id=82075006  for marketgoogle.xyz
> https://crt.sh/?id=65208905  for google.ligboy.org
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> wosign@lists.mozilla.org] On Behalf Of Gervase Markham via
> dev-security-policy
> Sent: Thursday, February 23, 2017 8:30 AM
> To: Tony Zhaocheng Tan ; mozilla-dev-security-policy@
> lists.mozilla.org
> Subject: Re: Let's Encrypt appears to issue a certificate for a domain
> that doesn't exist
>
> On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> > On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> > However, until today, the domain apple-id-2.com has apparently never
> > been registered. How was the certificate issued?
>
> On Hacker News, Josh Aas writes:
>
> "Head of Let's Encrypt here. Our team is looking into this and so far we
> don't see any evidence of mis-issuance in our logs. It looks like the
> domain in question, 'apple-id-2.com', was registered and DNS resolved for
> it successfully at time of issuance. Here is the valid authorization record
> including the resolved IP addresses for 'apple-id-2.com':
>
> https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...
>
> We can't be sure why the reporter was unable to find a WHOIS record, we
> can only confirm that validation properly succeeded at time of issuance.
>
> Update: Squarespace has confirmed that they did register the domain and
> then released it after getting a certificate from us."
>
> There is currently an entry in WHOIS, because some well-meaning but
> unhelpful person registered it today. I assume that if a domain is
> registered and then released, and then re-registered, the "Creation"
> date is of the re-registration, not the first ever registration.
>
> So unless someone can show it was unregistered at the time of issuance, I
> don't see an issue here.
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Ryan Sleevi via dev-security-policy]

Hi Richard,

My point was that policy requirement simply states that there needs to be a
procedure, but does not establish any normative requirements. For example,
a CA could develop, maintain, and implement procedures which states that
any certificate that is qualified as High Risk requires Gerv Markham's
personal seal of approval - and could define the way to do so - but they
could also say that "Only certificates requested by Gerv Markham are
considered High Risk"

Alternatively, a CA could deem that all High Risk certificates will require
a second DNS resolution after 30 seconds, to make sure that the first was
not forged. And that can be developed, maintained, and implemented - but
again, doesn't do what you want.

Your suggestion - which was worded as specific domains, but if I might be
as bold as to suggest what you meant to say, likely meant substrings in
domains - implies that there is a certain common requirement either on how
to handle such High Risk requests (block/manually approve/require Gerv's
personal seal of approval imbued upon a wax maintained at a 78 degree
centrigrade temperature for no less than 30 minutes prior to imbuing) or
how to define what is high risk (e.g. substring, CAA, "people we don't like
because they embarrassed us")

Because the BRs (and Mozilla policy) neither specify what _is_ High Risk or
what is _acceptable_ when a High Risk request is processed, it does not
make any sense to suggest particular domains (or substrings) be prohibited
without tackling those two issues first. This is why I suggested that the
solution you've proposed, under the current policies in play, has zero
effect. If you believe your solution is right/appropriate, then the first
step would be to change the policies.

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang  wrote:

> Hi Ryan,
>
>
>
> As I understand, the BR 4.2.1 required this:
>
> “The CA SHALL develop, maintain, and implement documented procedures that
> identify and require additional verification activity for High Risk
> Certificate Requests prior to the Certificate’s approval, as reasonably
> necessary to ensure that such requests are properly verified under these
> Requirements.”
>
>
>
> Please clarify this request, thanks.
>
>
>
>
>
> Best Regards,
>
>
>
> Richard
>
>
>
> *From:* Ryan Sleevi [mailto:r...@sleevi.com]
> *Sent:* Thursday, February 23, 2017 11:21 AM
> *To:* Richard Wang 
> *Cc:* Gervase Markham ; Tony Zhaocheng Tan <
> t...@tonytan.io>; mozilla-dev-security-pol...@lists.mozilla.org
>
> *Subject:* Re: Let's Encrypt appears to issue a certificate for a domain
> that doesn't exist
>
>
>
> Hi Richard,
>
>
>
> There's no policies in the Baseline Requirements or Mozilla Requirements
> that normalize or define high risk domain, which I believe your suggestion
> presupposes.
>
>
>
> Perhaps you (or Qihoo 360, as the voting member of the Forum of the
> Qihoo/WoSign/StartCom collection) would consider proposing a Ballot to the
> Baseline Requirements to address this. Alternatively, perhaps you would
> have a concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that
> might be able to address this in a consistent and auditable way and in a
> manner consistent with Mozilla's policy goals regarding misissuance.
>
>
>
> This is https://github.com/mozilla/pkipolicy/issues/1 for what it's
> worth, recently resolved in Policy 2.4
>
>
>
> On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> I think "apple-id-2.com" is a high risk domain that must be blocked to
> issue DV SSL to those domains.
>
> Here is the list of some high risk domains related to Microsoft and Google
> that Let's Encrypt issued DV SSL certificates to those domains:
> https://crt.sh/?id=77034583  for microsoftonline.us.com, a fake Office
> 365 login site
> https://crt.sh/?id=71789336  for mail.google-androids.ru
> https://crt.sh/?id=82075006  for marketgoogle.xyz
> https://crt.sh/?id=65208905  for google.ligboy.org
>
>
> Best Regards,
>
> Richard
>
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> wosign@lists.mozilla.org] On Behalf Of Gervase Markham via
> dev-security-policy
> Sent: Thursday, February 23, 2017 8:30 AM
> To: Tony Zhaocheng Tan ; mozilla-dev-security-policy@
> lists.mozilla.org
> Subject: Re: Let's Encrypt appears to issue a certificate for a domain
> that doesn't exist
>
> On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> > On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> > However, until today, the domain apple-id-2.com has apparently never
> > been registered. How was the certificate issued?
>
> On Hacker News, Josh Aas writes:
>
> "Head of Let's Encrypt here. Our team is looking into this and so far we
> don't see any evidence of mis-issuance in our logs. It looks like the
> domain in question, 'apple-id-2.com', was 

Re: Misissued/Suspicious Symantec Certificates

[Jeremy Rowley via dev-security-policy]

Webtrust doesn't have audit criteria for RAs so the audit request may produce 
interesting results. Or are you asking for the audit statement covering the 
root that the RA used to issue from? That should all be public in the Mozilla 
database at this point.

> On Feb 22, 2017, at 8:33 PM, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> Hi Steve,
> 
> Thanks for your continued attention to this matter. Your responses open
> many new and important questions and which give serious question as to
> whether the proposed remediations are sufficient. To keep this short, and
> thereby allow Symantec a more rapid response:
> 
> 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner
> since the acquisition by Symantec of the VeriSign Trust Services business
> in 2010.
> 
> 
> 
> On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Our third response to questions, including these two below, is posted at
>> Bugzilla, and directly at https://bug1334377.
>> bmoattachments.org/attachment.cgi?id=8838825.
>> 
>> 
>> 
>> 
>> 
>> From: Ryan Sleevi [mailto:r...@sleevi.com]
>> Sent: Friday, February 17, 2017 6:54 PM
>> To: Ryan Sleevi 
>> Cc: Gervase Markham ; mozilla-dev-security-policy@
>> lists.mozilla.org; Steve Medin 
>> Subject: Re: Misissued/Suspicious Symantec Certificates
>> 
>> 
>> 
>> Hi Steve,
>> 
>> 
>> 
>> Two more question to add to the list which is already pending:
>> 
>> 
>> 
>> In [1], in response to question 5, Symantec indicated that Certisign was a
>> WebTrust audited partner RA, with [2] provided as evidence to this fact.
>> While we discussed the concerns with respect to the audit letter,
>> specifically in [3], questions 3 - 6, and while Symantec noted that it
>> would case to accept future EY Brazil audits, I have confirmed with CPA
>> Canada that at during the 2016 and 2017 periods, EY Brazil was not a
>> licensed WebTrust practitioner, as indicated at [4].
>> 
>> 
>> 
>> Given that EY Brazil was not a licensed WebTrust auditor, it appears that
>> Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1
>> [5], namely, that "(For audits conducted in accordance with the WebTrust
>> standard) licensed by WebTrust", which is a requirement clearly articulated
>> in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not
>> using one of the above procedures and the Delegated Third Party is not an
>> Enterprise RA, then the CA SHALL obtain an audit report, issued under the
>> auditing standards that underlie the accepted audit schemes found in
>> Section 8.1, ..."
>> 
>> 
>> 
>> 1) Was Symantec's compliance team involved in the review of Certisign's
>> audit?
>> 
>> 2) Does Symantec agree with the conclusion that, on the basis of this
>> evidence, Symantec failed to uphold the Baseline Requirements, independent
>> of any action by a Delegated Third Party?
>> 
>> 
>> 
>> [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933<
>> https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1L
>> RVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
>> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
>> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
>> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
>> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
>> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
>> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%
>> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%
>> 3D8831933>
>> 
>> [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929<
>> https://clicktime.symantec.com/a/1/pfZiLBH0rxpzxfeiB5YSfvWdOjwpHC
>> 72M_rUahZJxKQ=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
>> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
>> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
>> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
>> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
>> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
>> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%
>> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%
>> 3D8831929>
>> 
>> [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487<
>> https://clicktime.symantec.com/a/1/80dDdC7HC5yMdzxfwRS0saqQ2kS5Tv
>> wuo_kNWaXWLCI=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
>> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
>> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
>> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
>> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
>> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
>> 

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Matt Palmer via dev-security-policy]

On Thu, Feb 23, 2017 at 01:08:49AM +, Richard Wang via dev-security-policy 
wrote:
> I think "apple-id-2.com" is a high risk domain that must be blocked to issue 
> DV SSL to those domains.

Why?

> Here is the list of some high risk domains related to Microsoft and Google 
> that Let's Encrypt issued DV SSL certificates to those domains:
> https://crt.sh/?id=77034583  for microsoftonline.us.com, a fake Office 365 
> login site   
> https://crt.sh/?id=71789336  for mail.google-androids.ru
> https://crt.sh/?id=82075006  for marketgoogle.xyz
> https://crt.sh/?id=65208905  for google.ligboy.org

... and?  Issuance of a certificate (even EV) doesn't imply endorsement or an
attestation of anything other than "something has been done to verify
identity".  It is a means of providing *communication security* only,
attempts by the marketing departments of certain CAs to fradulently imply
otherwise notwithstanding.

- Matt

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

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[George Macon via dev-security-policy]

On 2/22/17 7:30 PM, Gervase Markham wrote:
> On Hacker News, Josh Aas writes:
>
> 
> 
> Update: Squarespace has confirmed that they did register the domain and
> then released it after getting a certificate from us."

In this case, should Squarespace have requested that the certificate be
revoked before releasing the domain?

Is there a way to automatically detect that the domain was released? (I
suspect the answer to this question is "not easily".)

Would it make sense to prohibit certificate issuance during the grace
period?

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

RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

Hi Ryan,



As I understand, the BR 4.2.1 required this:

“The CA SHALL develop, maintain, and implement documented procedures that 
identify and require additional verification activity for High Risk Certificate 
Requests prior to the Certificate’s approval, as reasonably necessary to ensure 
that such requests are properly verified under these Requirements.”



Please clarify this request, thanks.





Best Regards,



Richard



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, February 23, 2017 11:21 AM
To: Richard Wang 
Cc: Gervase Markham ; Tony Zhaocheng Tan ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist



Hi Richard,



There's no policies in the Baseline Requirements or Mozilla Requirements that 
normalize or define high risk domain, which I believe your suggestion 
presupposes.



Perhaps you (or Qihoo 360, as the voting member of the Forum of the 
Qihoo/WoSign/StartCom collection) would consider proposing a Ballot to the 
Baseline Requirements to address this. Alternatively, perhaps you would have a 
concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that might be able 
to address this in a consistent and auditable way and in a manner consistent 
with Mozilla's policy goals regarding misissuance.



This is https://github.com/mozilla/pkipolicy/issues/1 for what it's worth, 
recently resolved in Policy 2.4



On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy 
>
 wrote:

   I think "apple-id-2.com" is a high risk domain that 
must be blocked to issue DV SSL to those domains.

   Here is the list of some high risk domains related to Microsoft and Google 
that Let's Encrypt issued DV SSL certificates to those domains:
   https://crt.sh/?id=77034583  for 
microsoftonline.us.com, a fake Office 365 login 
site
   https://crt.sh/?id=71789336  for 
mail.google-androids.ru
   https://crt.sh/?id=82075006  for marketgoogle.xyz
   https://crt.sh/?id=65208905  for google.ligboy.org


   Best Regards,

   Richard


   -Original Message-
   From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org]
 On Behalf Of Gervase Markham via dev-security-policy
   Sent: Thursday, February 23, 2017 8:30 AM
   To: Tony Zhaocheng Tan >; 
mozilla-dev-security-pol...@lists.mozilla.org
   Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

   On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
   > On 2017-01-03, Let's Encrypt issued a certificate for 
apple-id-2.com.
   > However, until today, the domain apple-id-2.com has 
apparently never
   > been registered. How was the certificate issued?

   On Hacker News, Josh Aas writes:

   "Head of Let's Encrypt here. Our team is looking into this and so far we 
don't see any evidence of mis-issuance in our logs. It looks like the domain in 
question, 'apple-id-2.com', was registered and DNS 
resolved for it successfully at time of issuance. Here is the valid 
authorization record including the resolved IP addresses for 
'apple-id-2.com':

   https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

   We can't be sure why the reporter was unable to find a WHOIS record, we can 
only confirm that validation properly succeeded at time of issuance.

   Update: Squarespace has confirmed that they did register the domain and then 
released it after getting a certificate from us."

   There is currently an entry in WHOIS, because some well-meaning but 
unhelpful person registered it today. I assume that if a domain is registered 
and then released, and then re-registered, the "Creation"
   date is of the re-registration, not the first ever registration.

   So unless someone can show it was unregistered at the time of issuance, I 
don't see an issue here.

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



___
dev-security-policy mailing list

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Peter Bowen via dev-security-policy]

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
 wrote:
> As I understand, the BR 4.2.1 required this:
>
> “The CA SHALL develop, maintain, and implement documented procedures that 
> identify and require additional verification activity for High Risk 
> Certificate Requests prior to the Certificate’s approval, as reasonably 
> necessary to ensure that such requests are properly verified under these 
> Requirements.”
>
> Please clarify this request, thanks.

Richard,

That sentence does not say that domain names including "apple",
"google", or any other string are High Risk Certificate Requests
(HRCR).   I could define HRCR as being those that contain domain names
that contain mixed script characters as defined in UTS #39 section
5.1.  "apple-id-2.com" is not mixed script so it is not a HRCR based
on this definition.

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

RE: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Richard Wang via dev-security-policy]

I don't agree this.
If "apple", "google", "Microsoft" is not a high risk domain, then I don’t know 
which domain is high risk domain, maybe only "github".

Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, February 23, 2017 11:53 AM
To: Richard Wang 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony 
Zhaocheng Tan ; Gervase Markham 
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that 
doesn't exist

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy 
 wrote:
> As I understand, the BR 4.2.1 required this:
>
> “The CA SHALL develop, maintain, and implement documented procedures that 
> identify and require additional verification activity for High Risk 
> Certificate Requests prior to the Certificate’s approval, as reasonably 
> necessary to ensure that such requests are properly verified under these 
> Requirements.”
>
> Please clarify this request, thanks.

Richard,

That sentence does not say that domain names including "apple", "google", or 
any other string are High Risk Certificate Requests
(HRCR).   I could define HRCR as being those that contain domain names
that contain mixed script characters as defined in UTS #39 section 5.1. 
"apple-id-2.com" is not mixed script so it is not a HRCR based on this 
definition.

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

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Vincent Lynch via dev-security-policy]

Hi Richard,

Peter's point is that there is no standard definition of a "high-risk"
request." It is a term defined in Section 1.6.1:

"High Risk Certificate Request: A Request that the CA flags for additional
scrutiny by reference to internal criteria and databases maintained by the
CA, which may include names at higher risk for phishing or other fraudulent
usage, names contained in previously rejected certificate requests or
revoked Certificates, names listed on the Miller Smiles phishing list or
the Google Safe Browsing list, or names that the CA identifies using its
own risk‐mitigation criteria."

Because of the ambiguity of the definition, CAs are essentially given full
discretion over what THEY think high risk is. You are allowed to say
domains containing the string "apple" are high risk, and treat them as
such. However, other CAs are allowed to decide that isn't high risk.

On Wed, Feb 22, 2017 at 10:55 PM, Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I don't agree this.
> If "apple", "google", "Microsoft" is not a high risk domain, then I don’t
> know which domain is high risk domain, maybe only "github".
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Thursday, February 23, 2017 11:53 AM
> To: Richard Wang 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony
> Zhaocheng Tan ; Gervase Markham 
> Subject: Re: Let's Encrypt appears to issue a certificate for a domain that
> doesn't exist
>
> On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
>  wrote:
> > As I understand, the BR 4.2.1 required this:
> >
> > “The CA SHALL develop, maintain, and implement documented procedures that
> > identify and require additional verification activity for High Risk
> > Certificate Requests prior to the Certificate’s approval, as reasonably
> > necessary to ensure that such requests are properly verified under these
> > Requirements.”
> >
> > Please clarify this request, thanks.
>
> Richard,
>
> That sentence does not say that domain names including "apple", "google",
> or
> any other string are High Risk Certificate Requests
> (HRCR).   I could define HRCR as being those that contain domain names
> that contain mixed script characters as defined in UTS #39 section 5.1.
> "apple-id-2.com" is not mixed script so it is not a HRCR based on this
> definition.
>
> Thanks,
> Peter
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

Ryan,

Both Gerv and I posted follow up questions almost two weeks ago.  I
know you have been busy with CT days.  When do you expect to have
answers available?

Thanks,
Peter

On Fri, Feb 10, 2017 at 2:01 AM, Gervase Markham via
dev-security-policy  wrote:
> Hi Ryan,
>
> On 09/02/17 19:55, Ryan Hurst wrote:
>> - The EV OID associated with this permission is associated with GlobalSign 
>> and not Google and,
>
> Which EV OID are you referring to, precisely?
>
>> - GlobalSign is active member in good standing with the respective root 
>> programs and,
>> - Google will not be issuing EV SSL certificates,
>> - Google will operate these roots under their own CP/CPS’s and associated 
>> OIDs,
>> - Google issuing a certificate with the GlobalSign OIDs would qualify as 
>> miss-issuance.
>>
>> That it would be acceptable for us not to undergo a EV SSL audit,
>> and that GlobalSign could keep the EV right for the associated subordinate
>> CA for the remaining validity period to facilitate the transition
>> (assuming continued compliance).
>
> Just to be clear: GlobalSign continues to operate at least one subCA
> under a root which Google has purchased, and that root is EV-enabled,
> and the sub-CA continues to do EV issuance (and is audited as such) but
> the root is no longer EV audited, and nor is the rest of the hierarchy?
>
>> When looking at this issue it is important to keep in mind Google has
>> operated a WebTrust audited subordinate CA under Symantec for quite a
>> long time. As part of this they have maintained audited facilities,
>> and procedures appropriate for offline key management, CRL/OCSP
>> generation, and other related activities. Based on this, and the
>> timing of both our audit, and key transfer all parties concluded it
>> would be sufficient to have the auditors provide an opinion letter
>> about the transfer of the keys and have those keys covered by the
>> subsequent annual audit.
>
> Can you tell us what the planned start/end dates for the audit period of
> that annual audit are/will be?
>
> Are the Google roots and/or the GlobalSign-acquired roots currently
> issuing EE certificates? Were they issuing certificates between 11th
> August 2016 and 8th December 2016?
>
> Gerv
> ___
> 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: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Peter Bowen via dev-security-policy]

Rather than what you suggest, I think the following could be high risk:

свiтова-пошта.info.
xn--i--7kcbgb7fdinng1f.info.

гooms17139.link.
xn--ooms17139-uzh.link.

мцяsц.lol.
xn--s-wtb4ab7b.lol.

сaентология.net.
xn--a-ftbfnnlhbvn2m.net.

aμ.net.
xn--a-mmb.net.

μc.net.
xn--c-lmb.net.

ωe.net.
xn--e-cnb.net.

аgentur.net.
xn--gentur-2nf.net.

ωomega.net.
xn--omega-gee.net.

phantфm.net.
xn--phantm-7rf.net.

रोले盧स.net.
xn--t2bes3ds6749n.net.



On Wed, Feb 22, 2017 at 7:55 PM, Richard Wang  wrote:
> I don't agree this.
> If "apple", "google", "Microsoft" is not a high risk domain, then I don’t 
> know which domain is high risk domain, maybe only "github".
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Thursday, February 23, 2017 11:53 AM
> To: Richard Wang 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony
> Zhaocheng Tan ; Gervase Markham 
> Subject: Re: Let's Encrypt appears to issue a certificate for a domain that
> doesn't exist
>
> On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
>  wrote:
>> As I understand, the BR 4.2.1 required this:
>>
>> “The CA SHALL develop, maintain, and implement documented procedures that
>> identify and require additional verification activity for High Risk
>> Certificate Requests prior to the Certificate’s approval, as reasonably
>> necessary to ensure that such requests are properly verified under these
>> Requirements.”
>>
>> Please clarify this request, thanks.
>
> Richard,
>
> That sentence does not say that domain names including "apple", "google", or
> any other string are High Risk Certificate Requests
> (HRCR).   I could define HRCR as being those that contain domain names
> that contain mixed script characters as defined in UTS #39 section 5.1.
> "apple-id-2.com" is not mixed script so it is not a HRCR based on this
> definition.
>
> Thanks,
> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Gervase Markham via dev-security-policy]

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never
> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

"Head of Let's Encrypt here. Our team is looking into this and so far we
don't see any evidence of mis-issuance in our logs. It looks like the
domain in question, 'apple-id-2.com', was registered and DNS resolved
for it successfully at time of issuance. Here is the valid authorization
record including the resolved IP addresses for 'apple-id-2.com':

https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

We can't be sure why the reporter was unable to find a WHOIS record, we
can only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and
then released it after getting a certificate from us."

There is currently an entry in WHOIS, because some well-meaning but
unhelpful person registered it today. I assume that if a domain is
registered and then released, and then re-registered, the "Creation"
date is of the re-registration, not the first ever registration.

So unless someone can show it was unregistered at the time of issuance,
I don't see an issue here.

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

Re: Misissued/Suspicious Symantec Certificates

[Ryan Sleevi via dev-security-policy]

On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley 
wrote:

> Webtrust doesn't have audit criteria for RAs so the audit request may
> produce interesting results. Or are you asking for the audit statement
> covering the root that the RA used to issue from? That should all be public
> in the Mozilla database at this point.


Hi Jeremy,

I believe the previous questions already addressed this, but perhaps I've
misunderstood your concern.

"Webtrust doesn't have audit criteria for RAs so the audit request may
produce interesting results."

Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4
"If the CA is not using one of the above procedures and the Delegated Third
Party is not an Enterprise RA, then the
CA SHALL obtain an audit report, issued under the auditing standards that
underlie the accepted audit schemes
found in Section 8.1, that provides an opinion whether the Delegated Third
Party’s performance complies with
either the Delegated Third Party’s practice statement or the CA’s
Certificate Policy and/or Certification Practice
Statement. If the opinion is that the Delegated Third Party does not
comply, then the CA SHALL not allow the
Delegated Third Party to continue performing delegated functions. "

Note that Symantec has already provided this data for the four RA partners
involved for the 2015/2016 (varies) period, at [2]. Specifically, see the
response to Question 5 at [3].

"Or are you asking for the audit statement covering the root that the RA
used to issue from? That should all be public in the Mozilla database at
this point."

Again, referencing Question 5 at [3], and the overall topic of the thread,
no, I am not asking for the audit statement covering the root that the RA
used to issue from. I'm asking for the audit report, issued under the
auditing standards that underlie the accepted audit schemes found in
Section 8.1, that provides an opinion whether the Delegated Third Party's
performance complies with either the Delegated Third Party's practice
statement or the CA's Certificate Policy and/or Certification Practice
Statement.

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1334377
[3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued/Suspicious Symantec Certificates

[Jeremy Rowley via dev-security-policy]

I am aware of the requirements but am interested in seeing how an RA that 
doesn't have their own issuing cert structures the audit report. It probably 
looks the same, but I've never seen one (unless that is the case with the 
previously provided audit report).

On Feb 22, 2017, at 8:48 PM, Ryan Sleevi 
> wrote:



On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley 
> wrote:
Webtrust doesn't have audit criteria for RAs so the audit request may produce 
interesting results. Or are you asking for the audit statement covering the 
root that the RA used to issue from? That should all be public in the Mozilla 
database at this point.

Hi Jeremy,

I believe the previous questions already addressed this, but perhaps I've 
misunderstood your concern.

"Webtrust doesn't have audit criteria for RAs so the audit request may produce 
interesting results."

Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4
"If the CA is not using one of the above procedures and the Delegated Third 
Party is not an Enterprise RA, then the
CA SHALL obtain an audit report, issued under the auditing standards that 
underlie the accepted audit schemes
found in Section 8.1, that provides an opinion whether the Delegated Third 
Party's performance complies with
either the Delegated Third Party's practice statement or the CA's Certificate 
Policy and/or Certification Practice
Statement. If the opinion is that the Delegated Third Party does not comply, 
then the CA SHALL not allow the
Delegated Third Party to continue performing delegated functions. "

Note that Symantec has already provided this data for the four RA partners 
involved for the 2015/2016 (varies) period, at [2]. Specifically, see the 
response to Question 5 at [3].

"Or are you asking for the audit statement covering the root that the RA used 
to issue from? That should all be public in the Mozilla database at this point."

Again, referencing Question 5 at [3], and the overall topic of the thread, no, 
I am not asking for the audit statement covering the root that the RA used to 
issue from. I'm asking for the audit report, issued under the auditing 
standards that underlie the accepted audit schemes found in Section 8.1, that 
provides an opinion whether the Delegated Third Party's performance complies 
with either the Delegated Third Party's practice statement or the CA's 
Certificate Policy and/or Certification Practice Statement.

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1334377
[3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy