RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Buschart, Rufus via dev-security-policy]

> From: dev-security-policy  On 
> Behalf Of Ryan Sleevi via dev-security-policy
> On Sat, Jul 4, 2020 at 10:42 PM Peter Bowen via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > As several others have indicated, WebPKI today is effectively a subset
> > of the more generic shared PKI. It is beyond time to fork the WebPKI
> > from the general PKI and strongly consider making WebPKI-only CAs that
> > are subordinate to the broader PKI; these WebPKI-only CAs can be
> > carried by default in public web browsers and operating systems, while
> > the broader general PKI roots can be added locally (using centrally
> > managed policies or local configuration) by those users who what a
> > superset of the WebPKI.
> >
> 
> +1.  This is the only outcome that, long term, balances the tradeoffs
> appropriately.

+1. Maybe a first step would be to write an RFC that explains, how technical 
constraining based on EKU (and Certificate Policies) through the layers of a 
multi-tier-PKI-Hierarchy should work. We have seen in this thread, that 
different Application Software Suppliers have different ideas, sometimes not 
even consistent within their application. I would be willing to support it.

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered 
offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Buschart, Rufus via dev-security-policy]

> From: dev-security-policy  On 
> Behalf Of Matt Palmer via dev-security-policy
> Sent: Sonntag, 5. Juli 2020 06:36
> 
> On Sat, Jul 04, 2020 at 07:42:12PM -0700, Peter Bowen wrote:
> > On Sat, Jul 4, 2020 at 7:12 PM Matt Palmer via dev-security-policy
> >  wrote:
> > >
> > > > On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via 
> > > > dev-security-policy wrote:
> > > >
> > > > In the CIA triad Availability is as important as Confidentiality.
> > > > Has anyone done a threat model and a serious risk analysis to
> > > > determine what a reasonable risk mitigation strategy is?
> > >
> > > Did you do a threat model and a serious risk analysis before you
> > > chose to use the WebPKI in your application?
> >
> > I think it is important to keep in mind that many of the CA
> > certificates that were identified are constrained to not issue TLS
> > certificates.  The certificates they issue are explicitly excluded
> > from the Mozilla CA program requirements.
> 
> Yes, I'm aware of that.
> 
> > I don't think it is reasonable to assert that everyone impacted by
> > this should have been aware of the possibly of revocation
> 
> At the limits, I agree with you.  However, to whatever degree that there is 
> complaining to be done, it should be directed at the CA(s)
> which sold a product that, it is now clear, was not fit for whatever purpose 
> it has been put to, and not at Mozilla.

Let me quote from the NSS website of Mozilla 
(https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Overview):

  If you want to add support for SSL, S/MIME, or other Internet security 
standards to your application, you can use Network Security Services (NSS) to 
implement
  all your security features. NSS provides a complete open-source 
implementation of the crypto libraries used by AOL, Red Hat, Google, and other 
companies in a
  variety of products, including the following:
  * Mozilla products, including Firefox, Thunderbird, SeaMonkey, and Firefox OS.
  * [and a long list of additional reference applications]

Probably it would be good if someone from Mozilla team steps in here, but 
S/MIME _is_ an advertised use-case for NSS. And the Mozilla website says 
nowhere, that the demands and rules of WebPKI / CA/B-Forum overrule all other 
demands. It is simply not to be expected by a consumer of S/MIME certificates 
that they become invalid within 7 days just because the BRGs for TLS 
certificates are requiring it. This feels close to intrusive behavior of the 
WebPKI community.

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered 
offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Buschart, Rufus via dev-security-policy]

From: Eric Mill 
Sent: Sonntag, 5. Juli 2020 00:55
To: Buschart, Rufus (SOP IT IN COR) 
Cc: mozilla-dev-security-policy 
; r...@sleevi.com; 
mark.arno...@gmail.com
Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous 
Delegated Responder Cert


On Sat, Jul 4, 2020 at 3:15 PM Buschart, Rufus via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
...especially since many of those millions of certificates are not even TLS 
certificates and their consumers never expected the hard revocation deadlines 
of the BRGs to be of any relevance for them. And therefore they didn't design 
their infrastructure to be able to do an automated mass-certificate exchange.

This is a clear, straightforward statement of perhaps the single biggest core 
issue that limits the agility and security of the Web PKI: certificate 
customers (particularly large enterprises) don't seem to actually expect they 
may have to revoke many certificates on short notice, despite it being 
extremely realistic that they may need to do so. We're many years into the Web 
PKI now, and there have been multiple mass-revocation events along the way. At 
some point, these expectations have to change and result in redesigns that 
match them.

[>] Maybe I wasn’t able to bring over my message: those 700 k certificates that 
are hurting us most, have never been “WebPKI” certificates. They are from 
technically constrained issuing CAs that are limited to S/MIME and client 
authentication. We are just ‘collateral damage’ from a compliance point of view 
(of course not in a security pov). In the upcoming BRGs for S/MIME I hope that 
the potential technical differences between TLS certificates (nearly all stored 
as P12 files in on-line server) and S/MIME certificates (many of them stored 
off-line on smart-cards or other tokens) will be reflected also in the 
revocation requirements. For WebPKI (aka TLS) certificates, we are getting 
better based on the lessons learned of the last mass exchanges.

It's extremely convenient and cost-effective for organizations to rely on the 
WebPKI for non-public-web needs, and given that the WebPKI is still 
(relatively) more agile than a lot of private PKIs, there will likely continue 
to be security advantages for organizations that do so. But if the security and 
agility needs of the WebPKI don't align with an organization's needs, using an 
alternate PKI is a reasonable solution that reduces friction on both sides of 
the equation.

[>] But we are talking in S/MIME also about “public needs”: It’s about the 
interchange of signed and encrypted emails between different entities that 
don’t share a private PKI.

--
Eric Mill
617-314-0966 | 
konklone.com<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkonklone.com%2F=02%7C01%7Crufus.buschart%40siemens.com%7Cf2f26fa2fbe34263c93808d8206d650e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637295001505543267=6H0qC1Ag9B1vuJ05d2BFrvaL0WBv5grib86q2NOSLuA%3D=0>
 | 
@konklone<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkonklone=02%7C01%7Crufus.buschart%40siemens.com%7Cf2f26fa2fbe34263c93808d8206d650e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637295001505543267=7MwPiz4jDprx9fNj8gcwq6W59s6VcZ46yotvY4dsqTs%3D=0>



With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens<http://www.twitter.com/siemens>
www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife>
[cid:image001.gif@01D6526A.82B24320]
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered 
offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

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

RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Buschart, Rufus via dev-security-policy]

Dear Mark!

> -Original Message-
> From: dev-security-policy  On 
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Samstag, 4. Juli 2020 20:06
> 
> On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > This is insane!
> > Those 300 certificates are used to secure healthcare information
> > systems at a time when the global healthcare system is strained by a
> > global pandemic. 

Thank you for bringing in your perspective as a certificate consumer. We at 
Siemens - as a certificate consumer - also have ~ 700 k affected personal 
S/MIME certificates out in the field, all of them stored on smart cards (+ code 
signing and TLS certificates ...). You can imagine, that rekeying them on short 
notice would be a total nightmare.

> To be clear; "the issue" we're talking about is only truly 'solved' by the 
> rotation and key destruction. Anything else, besides that, is just
> a risk calculation, and the CA is responsible for balancing that. Peter's 
> highlighting how the fix for the *compliance* issued doesn't fix
> the *security* issue, as other CAs, like DigiCert, have also noted.

Currently, I'm not convinced, that the underlying security issue (whose 
implication I of course fully understand and don't want to downplay) can only 
be fixed by revoking the issuing CAs and destructing the old keys. Sadly, all 
the brilliant minds on this mailing list are discussing compliance issues and 
the interpretation of RFCs, BRGs and 15-year-old Microsoft announcements, but 
it seems nobody is trying to find (or at least publicly discuss) a solution 
that can solve the security issue, is BRG / RFC compliant and doesn't require 
the replacement of millions of certificates - especially since many of those 
millions of certificates are not even TLS certificates and their consumers 
never expected the hard revocation deadlines of the BRGs to be of any relevance 
for them. And therefore they didn't design their infrastructure to be able to 
do an automated mass-certificate exchange.

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered 
offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)

[Buschart, Rufus via dev-security-policy]

Thank you Ryan for spending your 4th of July weekend answering my questions! 
From my purely technical understanding, without knowing too much about the 
history in the discussion between the ETSI community and you nor about the 
“Überbau” of the audit schemes, I would believe that most of the points you 
mentioned could be easily fixed, especially since they don’t seem to be 
unreasonable. Of course, I can’t speak for ETSI but since Siemens is a 
long-standing member of ETSI I’ll forward your email to the correct working 
group and try to make sure that you will receive a constructive answer.

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens
www.siemens.com/ingenuityforlife
[cid:image001.gif@01D6525A.EA305A60]
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered 
offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

From: Ryan Sleevi 
Sent: Samstag, 4. Juli 2020 16:37
To: Buschart, Rufus (SOP IT IN COR) 
Cc: Peter Bowen ; 
mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com
Subject: Re: Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT 
FOR CAs: The curious case of the Dangerous Delegated Responder Cert)



On Sat, Jul 4, 2020 at 9:17 AM Buschart, Rufus 
mailto:rufus.busch...@siemens.com>> wrote:
Dear Ryan!

> From: dev-security-policy 
> mailto:dev-security-policy-boun...@lists.mozilla.org>>
>  On Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Freitag, 3. Juli 2020 23:30
> To: Peter Bowen mailto:pzbo...@gmail.com>>
> Cc: Ryan Sleevi mailto:r...@sleevi.com>>; Pedro Fuentes 
> mailto:pfuente...@gmail.com>>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous 
> Delegated Responder Cert
>
> On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen 
> mailto:pzbo...@gmail.com>> wrote:
> > I agree that we cannot make blanket statements that apply to all CAs,
> > but these are some examples where it seems like there are alternatives
> > to key destruction.
> >
>
> Right, and I want to acknowledge, there are some potentially viable paths 
> specific to WebTrust, for which I have no faith with respect
> to ETSI precisely because of the nature and design of ETSI audits, that, in 
> an ideal world, could provide the assurance desired.

Could you elaborate a little bit further, why you don't have "faith in respect 
to ETSI"? I have to admit, I never totally understood your concerns with ETSI 
audits because a simple comparison between WebTrust test requirements and ETSI 
test requirements don't show a lot of differences. If requirements are missing, 
we should discuss them with ETSI representatives to have them included in one 
of the next updates.

ETSI ESI members, especially the vice chairs, often like to make this claim of 
“simple comparison”, but that fails to take into account the holistic picture 
of how the audits are designed, operated, and their goals to achieve.

For example, you will find nothing to the detail of say the AICPA Professional 
Standards (AT-C) to provide insight into the obligations about how the audit is 
performed, methodological requirements such as sampling design, professional 
obligations regarding statements being made which can result in censure or loss 
of professional qualification. You have clear guidelines on reporting and 
expectations which can be directly mapped into the reports produced. You also 
have a clear recognition by WebTrust auditors about the importance of 
transparency. They are not a checklist of things to check, but an entire set of 
“assume the CA is not doing this” objectives. And even if all this fails, the 
WebTrust licensure and review process provides an incredibly valuable check on 
shoddy auditors, because it’s clear they harm the “WebTrust brand”

ETSI ESI-based audits lack all of that. They are primarily targeted at a 
different entity - the Supervisory Body within a Member State - and ETSI 
auditors fail to recognize that browsers want, and expect, as much detail as 
provided to the SB and more. We see the auditors, and the TC, entirely 
dismissive to the set of concerns regarding the lack of consistency and 
transparency. There is similarly no equivalent set of professional standards 
here: this is nominally handled by the accreditation process for the CAB by the 
NAB, except that the generic nature upon which ETSI ESI audits are designed 
means there are few normative 

Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)

[Buschart, Rufus via dev-security-policy]

Dear Ryan!

> From: dev-security-policy  On 
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Freitag, 3. Juli 2020 23:30
> To: Peter Bowen 
> Cc: Ryan Sleevi ; Pedro Fuentes ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous 
> Delegated Responder Cert
> 
> On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen  wrote:
> > I agree that we cannot make blanket statements that apply to all CAs,
> > but these are some examples where it seems like there are alternatives
> > to key destruction.
> >
> 
> Right, and I want to acknowledge, there are some potentially viable paths 
> specific to WebTrust, for which I have no faith with respect
> to ETSI precisely because of the nature and design of ETSI audits, that, in 
> an ideal world, could provide the assurance desired.

Could you elaborate a little bit further, why you don't have "faith in respect 
to ETSI"? I have to admit, I never totally understood your concerns with ETSI 
audits because a simple comparison between WebTrust test requirements and ETSI 
test requirements don't show a lot of differences. If requirements are missing, 
we should discuss them with ETSI representatives to have them included in one 
of the next updates.

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered 
offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

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

AW: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Buschart, Rufus via dev-security-policy]

Von: Ryan Sleevi  
> On Fri, Oct 25, 2019 at 6:44 PM Buschart, Rufus 
>  wrote:
>> And while writing this email, I think I found one more problem: You are 
>> using the term "email account holder"
>> which isn't defined anywhere. Who is the "email account holder" for 
>> john.doe@mycompany.example?
>> Is it John Doe or is it "mycompany"? And in the case of 
>> john.doe@public-mail-provider.example? Is it John Doe
>> or the "public mail provider"? I think we need a definition, ideally based 
>> on the terms "Subject" and
>> "Subscriber". Or we replace "email account holder" with one of the two terms?
>
> Isn't it handled within that same sentence?
>
> "the entity submitting the request controls the email account associated with 
> the email address referenced
> in the certificate" seems like it should be clear that the "email account 
> holder" (the following clause) is "the
> entity that controls the email account associated with the email address" 
> (since it's handling the situation where
> the applicant is not that entity)

> The clunkier reword (not a fan, but seeing how you feel about this, Rufus) 
> would be "the entity submitting
> the request is *either* the entity that controls the email account associated 
> with the email address referenced
> in the certificate *or* has been authorized by the entity that controls the 
> email address referenced within the
> certificate"
>
> That avoids introducing the backreference term, but is a mouthful. I'm 
> assuming you meant Applicant and not
> Subscriber, since we're talking pre-issuance validation ;)

Maybe the following could be a reasonable rewording of the paragraph that makes 
the intention of the discussion clear, but isn't to 'clunky':

For a certificate capable of being used for digitally signing or encrypting 
email messages, the CA SHALL validate that the Applicant Representative (as 
defined in the BRGs) of the request controls the email account associated with 
the email address referenced in the certificate, except when the CA and the 
owner of the domain are Affiliates (as defined in the BRGs). The CA SHALL NOT 
delegate the validation of an email address. The CA's CP/CPS must clearly 
specify the procedure(s) that the CA employs to perform this validation.

With this wording we would reach:

1) The request can be initiated by the Applicant or Applicant Representative - 
due to the definition of Applicant Representative in the BRGs
2) Every CA can continue to issue S/MIME certificates as long as they perform a 
validation of the control of the email address
3) The CA cannot delegate the validation process
4) If the operator of the mail server operates its own CA, he doesn't have to 
perform error prone email address validations
5) We don't mix the words validation and verification for the same activity

> As to which is it - is it the MX admin/domain admin or the individual meat 
> person - it seems that the answer is
> either/or/both, at least from the perspective of RFC 822. The meat-person may 
> control the account, or the admin
> of the account may themselves control the account, or the admin of the domain 
> may control the MX that controls
> the account. In all cases, they control the email account associated.

In the upcoming S/MIME WG I see a lot of discussions around this topic arising.

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
http://www.twitter.com/siemens
https://siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322



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

AW: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Buschart, Rufus via dev-security-policy]

Von: Wayne Thayer 
On Thu, Oct 24, 2019 at 10:33 AM Buschart, Rufus 
 wrote:
>> One last remark: I might be the only one, but I'm not 100% sure what the 
>> "this verification" at the end of the last sentence refers to.
>> Is "this verification" (a) the verification of the Authorization Domain 
>> Name, (b) the verification of the email address or (c) both together?
>> If it is (b), as I believe, I would move the whole sentence, starting from 
>> "The CA's CP/CPS...", after the first sentence (ending with "the
>> account holder's behalf").
>
> I would argue that (a) is a subset of (b) and there is no difference between 
> (b) and (c), but the intent is (c).

Your statement is, in my opinion, totally correct for external CAs. But the 
scenario I have in my mind is a little bit different: In my scenario, there is
a Root CA that is included in the Root stores serving the general public and an 
internal issuing CA only serving "mycompany". In this scenario, Root
CA issues a name-constrained S/MIME-issuing CA certificate to the internal CA 
of "mycompany" after this CA has proven control over the DNS records for
"mycompany.example". This proof of control should be based on the methods from 
BRG 3.2.2.4. (taking Ryans remark about the problems of http-
validation for this scenario into account). The internal CA issues only S/MIME 
end-entity-certificates for mailboxes under @mycompany.example.
Now we have (a) and (b) as totally separated sets of verifications. In this 
scenario, I would expect, that the root CA describes (a) and the internal
issuing CA describes (b) in their CP/CPS.

> If a CA issues both TLS and
> S/MIME certificates, their CPS could simply state that the domain component 
> is validated using the same methods as used for TLS. For a
> CA that only issues S/MIME certificates, I want to see the methods used to 
> validate the domain part documented - especially given that
> they aren't subject to the BRs - along with the methods used to validate the 
> local part or the entire address.
Maybe
> Would changing "this" to "email address" but leaving that sentence after the 
> domain part requirements make it clear? That would read:
>
> "The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to 
> perform email address verification."

If you think, that the scenario described above is covered by the proposed 
sentence I'd happy with it, but I'm not totally sure if it is covered.

And while writing this email, I think I found one more problem: You are using 
the term "email account holder" which isn't defined anywhere. Who
is the "email account holder" for john.doe@mycompany.example? Is it John Doe or 
is it "mycompany"? And in the case of
john.doe@public-mail-provider.example? Is it John Doe or the "public mail 
provider"? I think we need a definition, ideally based on the terms
"Subject" and "Subscriber". Or we replace "email account holder" with one of 
the two terms?


/Rufus



Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
http://www.twitter.com/siemens
https://siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Buschart, Rufus via dev-security-policy]

On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi  wrote:
> On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy 
>  wrote:
>> Thanks Dimitris and Rufus. Would it satisfy your concern if the requirement
>> was changed to:
>>
>> The CA SHALL NOT delegate validation of the Base Domain Name (as defined in
>> the Baseline Requirements) portion of an email address.

Thanks Wayne, I like the new wording.

> If the CA has validated "mycompany.example", associated with account 
> "mycompany", what is the expectation for 'localpart'?
> 
> Interpretation 1) The CA MAY delegate validation of the localpart to 
> 'mycompany'. However, 'mycompany' MUST take reasonable measure ...
> Interpretation 2) By validating 'mycompany' as to have control over 
> 'mycompany.example', the CA has taken reasonable measure. No further 
> validation requirements
> exist for the localpart, provided it is directed by the 'mycompany' account, 
> as 'mycompany' is seen to implicitly have control over the MX records.
>
> I'm not sure Interpretation #2 fully holds (e.g. if the CA were using 
> something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was 
> trying to get at whether
> (CA || mycompany) needs to perform some validation step for 'localpart' once 
> the validation for the domain part is done.

I simply want to avoid to come into the situation, that I as the operator of an 
internal Enterprise PKI have to do some additional email validation on our own 
mailboxes. We do have 350 k users, if the validation process fails only at 1% 
of them, we have 3500 help desk tickets.

One last remark: I might be the only one, but I'm not 100% sure what the "this 
verification" at the end of the last sentence refers to. Is "this verification" 
(a) the verification of the Authorization Domain Name, (b) the verification of 
the email address or (c) both together? If it is (b), as I believe, I would 
move the whole sentence, starting from "The CA's CP/CPS...", after the first 
sentence (ending with "the account holder's behalf").


With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
http://www.twitter.com/siemens
https://siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322


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

AW: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Buschart, Rufus via dev-security-policy]

> > Sounds good. This was your proposed response to solving this issue
> > back on May 13, so it's full circle :)
> >
> >
> > I'm going to consider this issue resolved unless there are further
> > comments.
> 
> Just checking whether the following is acceptable.
> 
> If a CA validates the domain mycompany.example being owned/controlled by 
> "mycompany", can this company delegate the issuance of
> S/MIME certificates for subsection1.mycompany.example to an internal 
> department or a subsidiary? Does the proposed language allow
> this?

I'm also not sure if I understand the wording correctly. Let's assume, an 
internal CA of company "mycompany" gets successfully validated for 
mycompany.example and receives a (possibly name constrained) certificate for 
its issuing CA from one of the root CAs. Can this internal CA issue 
certificates for every email address under @mycompany.example without further 
validation or is an internal validation process required? My opinion is, that 
such an internal validation process doesn't increase security, since mycompany 
controls the mailservers of mycompany and can anyhow validate everything.

By the way: How are CAA records to be treated in the scope of S/MIME? Since 
gmail.com has a CAA record that prevents every CA except of Google to issue 
certificates for gmail.com, does this also forbid every CA to issue 
certificates for rufus.busch...@gmail.com? 

With best regards,
Rufus Buschart

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322



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

AW: Intent to Ship: Move Extended Validation Information out of the URL bar

[Buschart, Rufus via dev-security-policy]

Dear Daniel!
 
> Please tell me if I understand this correctly...
> Is it that DV and EV certificates now both show the same lock symbol?
> That would be a great harm in my opinion. And I do not understand why you 
> want this change.
> 
> I think EV is very important and I explain why.
> 
> Let's look at following hypothetical case: We have google.com, paypal.com as 
> well as goog1e.com and paypa1.com . Notice the two
> number 1 (one) instead of a lower case L in the latter two domains. (lowecase 
> "L" and "one" look perfectly equal in Times New Roman. And
> lowercase "L" looks perfectly equal to uppercase "i" in Arial.)
> 
> In old Firefox, I get a green bar if I visit google.com and paypal.com, 
> telling me that this is a well-known company that got the EV certificate.
> The other fake domains goog1e.com and paypa1.com only have DV certificates by 
> Let's Encrypt.
> 
> In the newer Firefox, both domains, the real one and the fake one both get a 
> lock symbol. And I need to click the lock to see if it is DV or EV.
> 
> Do I understand that correctly?

Any CA that strictly follow BRGs 4.2.1 should not issue a certificate for 
paypa1.com or goog1e.com. Until recently this was also done by Let's Encrypt, 
but they stopped doing so in January 2019 - 
https://community.letsencrypt.org/t/let-s-encrypt-no-longer-checking-google-safe-browsing/82168.
 Maybe someone from the Let's Encrypt team can explain, how they are now 
fulfilling this requirement.

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

AW: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Buschart, Rufus via dev-security-policy]

> Von: Ryan Sleevi 
> Betreff: Re: What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 
> 63 bit serial numbers)
> 
> On Mon, Mar 11, 2019 at 1:18 PM Buschart, Rufus via dev-security-policy 
>  <mailto:dev-security-policy@lists.mozilla.org> > wrote:
> 
> > [...] nowhere the BRGs define the exact meaning of "non-sequential".
> > I always read this as serial numbers being totally random, but I know there 
> > is at least one CA out there that constructs its serial
> > numbers like this:
> >
> > serialNumber = timeInMS() + random(64) + 'constant_suffix'
> >
> > Serial numbers constructed like this are strict monotonously rising but 
> > never the less contain 64 bits of random data. Do we
> > consider those as "non-sequential"? We can't even go by the definition in 
> > the dictionary, because according to that (at least the one I
> > consulted), every list of numbers is 'sequential', as one number comes 
> > after another.
> 
> Oof,
> 
> With the requirement to be a positive integer greater than zero, you can 
> think of the serial number space as the one of /natural
> numbers/ (or, because zero is excluded, /whole numbers/) whose DER encoding 
> is less than or equal to twenty bytes. The sequential
> requirement is 'meant' to apply to serial numbers being constructed in order 
> of that sequence of whole numbers - that is, 1, 2, 3 is
> sequential in the set of whole numbers, although 1, 3 would be out of 
> sequence with respect to the set of valid whole number serials.
> 
> If I understand the question correctly, you're describing a situation in 
> which the serial number construct follows a strict ordering, and
> thus itself forms a sequence of whole numbers which maintain sequential order 
> of the set of all valid whole numbers, but which does
> not include each whole number, provided that no two certificates are issued 
> in the same millisecond. If two certificates are issued in
> the same millisecond, the 64-bits of entropy create a probability that the 
> certificates will not appear in sequential (monotonically
> increasing) order. Is that correct?

Yes, exactly 

> Put differently, the question is whether or not the algorithm, as specified, 
> needs to consider two certificates issued at different times
> (and, presuming time is linear and increasing, so too will the serial 
> numbers), or whether it can/should consider certificates issued at
> the same time (and thus be probabilistically out of sequential ordering)
>
> Just making sure I've phrased and framed it correctly.

You got it totally right. Now basically we have two possible definitions of 
"sequential serial numbers":

1) A CA generates "sequential serial numbers" if every generated serial number 
meets the following criteria: serialNumber(n) = serialNumber(n-1)+1, with n 
being the n-th number of generated serial numbers
2) A CA generates "sequential serial numbers" if every generated serial number 
meets the following criteria: serialNumber(n) > serialNumber(n-m) (or 
serialNumber(n) < serialNumber(n-m) ), with n being the n-th number of 
generated serial numbers and m any whole number smaller n

Since choice 1 is a logical consequence of "containing 64 bits of random data", 
I was always under the impression, that choice 2 was meant by the BRGs. If 
choice 1 is meant, then I think the requirement of being 'non-sequential' is 
just some lyrical sugar in the BRGs. Maybe there is a third definition of 
"sequential" that I haven't thought of?

To put in a concrete example: There is a CA that generated the following serial 
numbers:

1843319960437720643048278653969636 on 2019-01-11 09:53:47 UTC
1843319960437694134774632325152679 on 2019-01-10 13:49:21 UTC
1843319960437689654817618007073336 on 2019-01-10 09:05:57 UTC
1843319960437665986305459379269472 on 2019-01-09 09:24:59 UTC
1843319960437653534927818400454844 on 2019-01-08 10:24:51 UTC
1843319960437625653787354520462187 on 2019-01-08 08:40:14 UTC
1843319960437610711593417697551974 on 2019-01-08 08:39:37 UTC

Are those serial numbers sequential? I think, yes, they are, but I admit, there 
are good arguments to say, no, they are not.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and 

What's the meaning of "non-sequential"? (AW: EJBCA defaulting to 63 bit serial numbers)

[Buschart, Rufus via dev-security-policy]

Dear mdsp!

I really like reading this discussion about 64 vs. 63 bits and how to read the 
BRGs as it shows a lot of passion by all of us in the PKI community. Never the 
less, in the discussion, I miss one interesting aspect. The BRGs not only speak 
about 64 bits as output from a CSPRNG but also about serial numbers being 
"non-sequential". But nowhere the BRGs define the exact meaning of 
"non-sequential". I always read this as serial numbers being totally random, 
but I know there is at least one CA out there that constructs its serial 
numbers like this:

serialNumber = timeInMS() + random(64) + 'constant_suffix'

Serial numbers constructed like this are strict monotonously rising but never 
the less contain 64 bits of random data. Do we consider those as 
"non-sequential"? We can't even go by the definition in the dictionary, because 
according to that (at least the one I consulted), every list of numbers is 
'sequential', as one number comes after another.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Daymion Reynolds via dev-security-policy
> Gesendet: Montag, 11. März 2019 18:00
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: EJBCA defaulting to 63 bit serial numbers
> 
> On Monday, March 11, 2019 at 8:57:27 AM UTC-7, Ryan Sleevi wrote:
> > I don’t think there’s anything inherently wrong with an approach that
> > uses a fixed prefix, whether of one bit or more, provided that there
> > is at least
> > 64 bits of entropy included in the serial prior to encoding to DER.
> >
> > This means a scheme with guarantees a positive INTEGER will generate
> > *encoded* serials in the range of one bit to sixty five bits, of the
> > goal is to use the smallest possible amount of entropy.
> >
> > However, as you note, this issue only arises when one uses the
> > absolute minimum. A robust solution is to use 159 bits, the maximum
> > allowed. This helps ensure that, even when encoded, it will not exceed
> > 20 bytes, this avoiding any client interpretation issues regarding
> > whether the 20 bytes mentioned in 5280 are pre-encoding (the intent)
> > or post-encoding (as a few embedded libraries implemented).
> >
> > Note, however, even with 159 bits of entropy, it’s still possible to
> > have a compressed encoding of one byte, due to zero folding. Using a
> > one bit prefix in addition to the sign bit (thus, two fixed bits in
> > the serial) can help ensure that a leading run of zero bits are not folded 
> > when encoding.
> 
> Glad you agree 64bit serial numbers can have no fixed bits, as a fixed bit in 
> a 64 bit serial number would result in less than 64 bits of
> entropy.  If you are going to fix a significant bit it must be beyond the 
> 64th bit.  If your 64 bit serial number does not contain 1's in the
> significant byte, as long as you still write 64 full bits of data to the cert 
> with 0's left padded, then the desired entropy is achieved and is
> valid. CAs should keep this in mind while building their revocation lists.
> ___
> 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

AW: DarkMatter Concerns

[Buschart, Rufus via dev-security-policy]

Writing with my personal hat on:


> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Matthew Hardeman via dev-security-policy
> On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
> > Insane that this is even being debated. If the floodgates are opened
> > here you will NOT be able to get things back under control.
> 
> While I can appreciate the passion of comments such as this, I think we're 
> still back at a core problem:
> 
> How can you reconcile this position with the actual program rules & 
> guidelines?  If they're declined on some discretionary basis, you
> loose the transparency that's made the Mozilla root program so uniquely 
> valuable.
> 
> Other than the relatively minor issues which have already been brought to 
> light (and presently DarkMatter seems to be contemplating
> the generation of a whole new root and issuing heirarchy to address those), 
> where are the rules violations that would keep them out?

If I remember correctly, there was once a fundamental agreement not to include 
new TSP's Root CAs if they don't bring structural benefit for the whole eco 
system. I can't see, how DarkMatter brings any benefit for the eco system at 
all, so I believe there is good reason not to accept this root inclusion 
request.

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

AW: CFCA certificate with invalid domain

[Buschart, Rufus via dev-security-policy]

I just sent them a certificate problem report.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von michel.lebihan2000--- via dev-security-policy
> Gesendet: Mittwoch, 27. Februar 2019 08:54
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: CFCA certificate with invalid domain
> 
> Hello,
> 
> I noticed this certificate 
> https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an invalid 
> domain `mail.xinhua08.con` in
> SANs. This looks like a typo and `mail.xinhua08.com` is present in other 
> certificates. Such an issue makes me wonder about the quality
> of their validation.
> ___
> 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

AW: DarkMatter Concerns

[Buschart, Rufus via dev-security-policy]

> Von: dev-security-policy  Im 
> Auftrag von Matthew Hardeman via dev-security-policy
> On Mon, Feb 25, 2019 at 12:15 PM Richard Salz  wrote:
> 
> > You miss the point of my question.
> >
> > What types of certs would they issue that would NOT expect to be
> > trusted by the public?
> I get the question in principle.  If it is a certificate not intended for 
> public trust, I suppose I wonder whether or not it's truly in scope for
> policy / browser inclusion / etc discussions?

If the certificate is part of a hierarchy that chains up to a root under 
Mozillas Root Program there should be no question about this - yes it is in 
scope.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

 

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

AW: Is it allowed the suspension of Issuing CAs?

[Buschart, Rufus via dev-security-policy]

Hi Pedro!

Why do you believe that BRGs 4.9.13 is only applicable for EE / Subscriber 
certs?

> 4.9.13. Circumstances for Suspension
> The Repository MUST NOT include entries that indicate that a Certificate is 
> suspended.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Pedro Fuentes via dev-security-policy
> Gesendet: Montag, 4. Februar 2019 16:40
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Is it allowed the suspension of Issuing CAs?
> 
> Hello,
> sorry if this is a silly question, but I was wondering if it is allowed that 
> a Root or Intermediate CA suspends the certificate of an issuing
> CA.
> 
> We can imagine the case of a suspected key compromise, or even a contractual 
> breach, that could lead to recommend putting the
> Issuing CA in "quarantine".
> 
> My trouble is that BR disallows the suspension of subscriber SSL certificate, 
> so the suspension of the CA could lead to a temporary
> suspension of all SSL certificates under it.
> 
> I'd appreciate if you can help me to see the light.
> 
> Best,
> Pedro
> ___
> 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

AW: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)

[Buschart, Rufus via dev-security-policy]

Personally I think it would be better, if the revoke reason "Certificate hold" 
on the CRL would be allowed for TLS certificates, as this state would exactly 
cover the described scenario. The OCSP responder could in such a case reply 
with "bad" and deliver the reason "certificate hold". But I fully understand 
that browser developers had a lot of issues with this state, so it is still 
forbidden.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Kurt Roeckx via dev-security-policy
> Gesendet: Freitag, 1. Februar 2019 23:38
> An: Wayne Thayer 
> Cc: mozilla-dev-security-policy 
> 
> Betreff: Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR)
> 
> On Fri, Feb 01, 2019 at 03:02:17PM -0700, Wayne Thayer wrote:
> > It was pointed out to me that the OCSP status of the misissued
> > certificate that is valid for over 5 years is still "unknown" despite
> > having been revoked a week ago. I asked KIR about this in the bug [1]
> > and am surprised by their response:
> >
> > This certificate is revoked on CRL. Because the certificate has been
> > never
> > > received by the customer its status on OCSP is "unknown". To make
> > > the certificate "revoked" on OCSP first we should make it "valid"
> > > what makes no sense. I know there is inconsistency between CRL and
> > > OCSP but there are some scenarios when it can be insecure to make it
> > > valid just in order to make it revoked.
> > >
> >
> > Upon further questioning KIR states:
> >
> > Of course I can mark it as revoked after I make it valid, but I think
> > it is
> > > more secure practice not to change its status at all when the
> > > certificate is not received by the customer. Let's suppose the
> > > scenario when your CA generate certificate and the customer wants
> > > you to deliver it to its office. What OCSP status the certificate
> > > should have when you are on your way to the customer office? valid -
> > > I do not think so. When the certificate is stolen you are in
> > > trouble. So the only option is "unknown" but then we have different
> > > statuses on CRL and OCSP - but we are still safe. It is not only my 
> > > opinion, we had a big discuss with our auditors about that.
> > >
> >
> > Does anyone other then KIR and their auditor (Ernst & Young) think
> > this is currently permitted? At the very least, I believe that returning 
> > "unknown"
> > for a revoked certificate is misleading to Firefox users who will
> > receive the "SEC_ERROR_OCSP_UNKNOWN_CERT" error instead of
> > "SEC_ERROR_REVOKED_CERTIFICATE".
> >
> > Does anyone other than KIR and Ernst & Young believe that this meets
> > WebTrust for CAs control 6.8.12? [2]
> 
> If you follow the RFC, the "unknown" answer can mean that it doesn't know, 
> and that an other option like a CRL can be tried.
> With "unknown", it doesn't say anything about being valid or not.
> 
> I don't think that interpretation is very useful. I think that the OCSP 
> server should know about the certificate before the customer has
> the certificate. I think that if you have a properly signed certificate 
> within it's validity period, the OCSP should always return either
> "good" or "revoked", never "unknown". Once a certificate is generated and 
> it's not revoked it's valid.
> 
> Would it be useful to have a requirement in the BRs that the OCSP server 
> should not answer with "unknown" for an issued certificate
> within it's validity period?
> 
> 
> Kurt
> 
> ___
> 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

AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

> Von: Ryan Sleevi  
>> On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus 
>>  wrote:
>>> Von: Ryan Sleevi  
>>> 
>>> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>>
>> Sorry to be picky, but this check only proofs that a label is a valid IDNA 
>> label but not that it is _not_ a weird server name.
>
> Picky is good! Obviously I'm very picky ;)
> 
> What's not clear to me is why that distinction is relevant, particularly on 
> the validation side of things. IDNA-aware software will,
> by virtue of being IDNA-aware, treat it as an A-label if it's a valid ACE 
> label with the ACE prefix, and, correspondingly, transform
> into a U-Label if they see it as appropriate. From the discussion you were 
> having with Jakob, it's not clear the relevance of that
> point about 'weird hostname' vs 'U-label' - perhaps I missed something?

At the end, it all comes down to the question, whether a CA software has to be 
IDNA aware or not. This question can be divided in two separate sub-questions:

1) MUST a CA software be IDNA aware?
2) SHOULD a CA software be IDNA aware?

Regarding 1: Ballot 202 wanted to make IDNA awareness a strict requirement for 
any CA. Ballot 202 failed, therefor it should be clear, that a CA can choose 
whether to be IDNA aware or not.
Regarding 2: Due to bullet 1 this is a business decision of any CA and I 
believe there are good reasons simply to be ignorant towards IDNA naming 
syntax, because you can't tell if this is just a weird host name or an A-label.

==> As a conclusion I believe any bug that was opened due to the issuance of 
certificates that include hostnames which could be read as an A-label should be 
rejected, as long as the A-label was validated (and all other rules of the 
BRGs, etc. are followed).

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

AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

> Von: Ryan Sleevi  
> 
> The CA can perform ToASCII(ToUnicode(label)) == label to validate.

Sorry to be picky, but this check only proofs that a label is a valid IDNA 
label but not that it is _not_ a weird server name.

With best regards,
Rufus Buschart

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

AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Hello Jakob!

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Jakob Bohm via dev-security-policy
> Gesendet: Freitag, 25. Januar 2019 18:47
> 
> Example, if the subscriber fills out the human readable order form like
> this:
>www.example.com
>chat.example.com
>example.com
>detteerenprøve.example.com
>www.example.net
>example.net
>*.eXample.com
>*.examPle.nEt
>192.0.2.3
> the best choice is probably CN=*.example.com which is one of the SANs and is 
> a wildcard covering the first SAN (www.example.com).
> The BRs do not require a specific choice among the 9 SANs that would go in 
> the certificate (all of which must of cause be validated).
> The user entered U-label detteerenprøve.example.com must of cause be 
> converted to A-label xn--detteerenprve-lnb.example.com
> before checking and encoding.

If a CA receives such a list and creates the CSR for the customer (how does the 
CA this without access to the customers private key?), they have of course to 
perform an IDNA translation from U-label to A-label. And as we have learned the 
BRGs (indirectly) enforce the use of IDNA2003. But if the CA receives a filled 
in CSR they don't perform (not even indirectly) an IDNA translation and has no 
obligation to check if the entries are valid IDNA2003 A-label.

And - ceterum censeo - there is no way a CA can tell for sure if 
xn--gau-7ka.siemens.de is just a weird server name or the IDNA2008 translation 
of gauß.siemens.de .

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322



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

AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Hi Kurt!

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Kurt Roeckx via dev-security-policy
> I expect all fields in the subject to be things you can just read, so 
> U-labels. It does not make sense to show users an A-label, they do
> not understand what that means. 

Normally the content of a certificate is not shown to the end user at all. The 
end user sees the address bar of the browser. In the address bar of the browser 
the U-label is shown. Then the browser makes the translation from the U-label 
to the A-label, either using IDNA2003 or IDNA2008. We should check the behavior 
of SSH clients but how many SSH client users are there compared to browser 
users?

> The fields in a subject allows writing things in Unicode, there is no reason 
> not to use it.

Sure it allows it, but as long as the CA doesn't permits it, the CA doesn't 
have to do any conversion from U-label to A-label at all.

> The A-label is
> really just an technical thing related to DNS, and so only belongs in places 
> where for technical reasons you need to use it.

Like the CN, as nobody non-technical ever sees the CN.

> If you want
> to show them rfc5280 says you "should" convert them to Unicode. For fields 
> where you can write Unicode, there really isn't a reason
> to not put the Unicode in it directly.
> 
> So in my opinion, the CN would be "gauß.siemens.de", and the SAN would be 
> "xn--gau-7ka.siemens.de". They might add some
> alternatives like gauss.siemens.de to the SAN, and you can then also use that 
> as CN. (But I think they should stop using that ss for ß,
> and really use gauß.)

I agree, that if a CA issues a certificate with the CN "gauß.siemens.de" the CA 
has to perform a conversion acc. IDNA2003 for all checks, but if the CA only 
issues the CN "xn--gau-7ka.siemens.de" they don't have to care if this is 
IDNA2003 or IDNA2008.

> 
> I think that if you want to force the use of A-labels in the CN field that 
> you should really update RFC5280 and X.520, so that IA5String is
> the only option in CN. But that just doesn't make any sense.

I don't want to force anybody not to use Unicode in the CN, but I want to make 
clear, that if a CA only allows CNs that follow RFC 1034, chapter 3.5, they 
don't have to care about compliance with IDNA2008 / IDNA2003.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Hello

> -Ursprüngliche Nachricht-
> Von: Hanno Böck 
> Gesendet: Donnerstag, 24. Januar 2019 12:36
> 
> On Thu, 24 Jan 2019 11:14:11 +0000
> "Buschart, Rufus via dev-security-policy"
>  wrote:
> 
> > You are right, of course there are mandatory RFC to take into account.
> > But there is - to my knowledge - no RFC that says, you MUST NOT issue
> > a certificate to a domain that could be interpreted as an
> > IDNA2008 punycode.
> 
> https://tools.ietf.org/html/rfc5891
> 
> 4.2.3.1.  Hyphen Restrictions
> 
>The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
>the third and fourth character positions and MUST NOT start or end
>with a "-" (hyphen).
> 
> This means you can't have a valid host name that is just xn--[something]. You 
> can only have it if it is also a valid IDN name.
> 
I don't read it like this. This chapter describes the "Unicode string" which is 
the U-label before conversion. The hostname is the A-label after conversion and 
in the certificate you find the hostname. The RFC 3490 clearly addressed this 
issue:

   While all ACE labels begin with the ACE prefix, not all labels
   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
   labels that begin with the ACE prefix will confuse users and SHOULD
   NOT be allowed in DNS zones.

But first of all this is only a SHOULD requirement and second it places the 
burden on the operator of the DNS zones.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

Important notice: This e-mail and any attachment thereof contain corporate 
proprietary information. If you have received it by mistake, please notify us 
immediately by reply e-mail and delete this e-mail and its attachments from 
your system. Thank you.

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

AW: AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Hello Dimitris!

You are right, of course there are mandatory RFC to take into account. But 
there is - to my knowledge - no RFC that says, you MUST NOT issue a certificate 
to a domain that could be interpreted as an IDNA2008 punycode.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: Dimitris Zacharopoulos 
> Gesendet: Donnerstag, 24. Januar 2019 11:52
> An: Buschart, Rufus (GS IT HR 7 4) ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded 
> international domain names
> 
> I referred to your comment that "you perform a successful domain validation". 
> My point, which you seem to understand and agree, is
> that there are additional rules than just DNS validation.
> 
> Dimitris.
> 
> 
> On 24/1/2019 12:21 μ.μ., Buschart, Rufus wrote:
> > Hello Dimitris,
> >
> > of course not, because the underscore is not part of the syntax for a 
> > hostname acc. RFC 1034, chapter 3.5. whereas xn--gau-
> 7ka.siemens.de is a perfectly valid hostname.
> >
> > With best regards,
> > Rufus Buschart
> >
> > Siemens AG
> > Information Technology
> > Human Resources
> > PKI / Trustcenter
> > GS IT HR 7 4
> > Hugo-Junkers-Str. 9
> > 90411 Nuernberg, Germany
> > Tel.: +49 1522 2894134
> > mailto:rufus.busch...@siemens.com
> > www.twitter.com/siemens
> >
> > www.siemens.com/ingenuityforlife
> >
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> > Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> > Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered
> > offices: Berlin and Munich, Germany; Commercial registries: Berlin
> > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Dimitris Zacharopoulos 
> >> Gesendet: Donnerstag, 24. Januar 2019 11:16
> >> An: Buschart, Rufus (GS IT HR 7 4) ;
> >> mozilla-dev-security-pol...@lists.mozilla.org
> >> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded
> >> international domain names
> >>
> >> On 24/1/2019 10:47 π.μ., Buschart, Rufus via dev-security-policy wrote:
> >>> Good morning!
> >>>
> >>> I would like to sharpen my argument from below a little bit: If a CA
> >>> gets a request to issue a certificate for the domain xn--gau-
> >> 7ka.siemens.de, how can the CA tell, that xn--gau-7ka is a punycode
> >> string in IDNA2008 and not only a very strange server name? At least
> >> I don't have a glass bowl to read the mind of my customers. Therefor I 
> >> would say, it is perfectly okay to issue a certificate for xn--
> gau-7ka.siemens.de as long as you perform a successful domain validation for 
> xn--gau-7ka.siemens.de.
> >> By following this argument, you would also approve issuance of domain 
> >> names that contain the underscore "_" character, right?
> >>
> >> Dimitris.
> >>
> >>> With best regards,
> >>> Rufus Buschart
> >>>
> >>> Siemens AG
> >>> Information Technology
> >>> Human Resources
> >>> PKI / Trustcenter
> >>> GS IT HR 7 4
> >>> Hugo-Junkers-Str. 9
> >>> 90411 Nuernberg, Germany
> >>> Tel.: +49 1522 2894134
> >>> mailto:rufus.busch...@siemens.com
> >>> www.twitter.com/siemens
> >>>
> >>> www.siemens.com/ingenuityforlife
> >>>
> >>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> >>> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> >>> Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> >>> Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered
> >>> office

AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Hello Kurt!

We don't fill in the CN of a certificate. We verify that in the CSR of the 
customer the subject:CommonName is part of the extensions:subjectAltName (as 
required in BRGs 7.1.4.2.2.a). So we would only issue a certificate with:

{
CN = xn--gau-7ka.siemens.de
SAN = xn--gau-7ka.siemens.de, gauss.siemens.de
}

but not with

{
CN = gauß.siemens.de
SAN = xn--gau-7ka.siemens.de, gauss.siemens.de
}

And technically I don't see any reason why someone would want to have a 
certificate with CN = gauß.siemens.de, as the unicode URL gauß.siemens.de is 
only of interest in the address bar of the browser and they perform the IDNA 
conversion.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Kurt Roeckx via dev-security-policy
> Gesendet: Donnerstag, 24. Januar 2019 10:04
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international 
> domain names
> 
> On 2019-01-24 9:47, Buschart, Rufus wrote:
> > Good morning!
> >
> > I would like to sharpen my argument from below a little bit: If a CA gets a 
> > request to issue a certificate for the domain xn--gau-
> 7ka.siemens.de, how can the CA tell, that xn--gau-7ka is a punycode string in 
> IDNA2008 and not only a very strange server name? At
> least I don't have a glass bowl to read the mind of my customers. Therefor I 
> would say, it is perfectly okay to issue a certificate for xn--
> gau-7ka.siemens.de as long as you perform a successful domain validation for 
> xn--gau-7ka.siemens.de.
> 
> Will you fill something in in the commonName? I think what is expected in the 
> commonName is what the user would type and expect
> to see, I don't think the commonName should contain xn--gau-7ka.siemens.de. 
> If you have a commonName, I would expect that it
> contains gauß.siemens.de. And if you create a commonName then, you are 
> required to check that it matches the xn--gau-
> 7ka.siemens.de in the SAN.
> 
> 
> Kurt
> ___
> 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

AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Hello Dimitris,

of course not, because the underscore is not part of the syntax for a hostname 
acc. RFC 1034, chapter 3.5. whereas xn--gau-7ka.siemens.de is a perfectly valid 
hostname.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: Dimitris Zacharopoulos 
> Gesendet: Donnerstag, 24. Januar 2019 11:16
> An: Buschart, Rufus (GS IT HR 7 4) ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international 
> domain names
> 
> On 24/1/2019 10:47 π.μ., Buschart, Rufus via dev-security-policy wrote:
> > Good morning!
> >
> > I would like to sharpen my argument from below a little bit: If a CA gets a 
> > request to issue a certificate for the domain xn--gau-
> 7ka.siemens.de, how can the CA tell, that xn--gau-7ka is a punycode string in 
> IDNA2008 and not only a very strange server name? At
> least I don't have a glass bowl to read the mind of my customers. Therefor I 
> would say, it is perfectly okay to issue a certificate for xn--
> gau-7ka.siemens.de as long as you perform a successful domain validation for 
> xn--gau-7ka.siemens.de.
> By following this argument, you would also approve issuance of domain names 
> that contain the underscore "_" character, right?
> 
> Dimitris.
> 
> > With best regards,
> > Rufus Buschart
> >
> > Siemens AG
> > Information Technology
> > Human Resources
> > PKI / Trustcenter
> > GS IT HR 7 4
> > Hugo-Junkers-Str. 9
> > 90411 Nuernberg, Germany
> > Tel.: +49 1522 2894134
> > mailto:rufus.busch...@siemens.com
> > www.twitter.com/siemens
> >
> > www.siemens.com/ingenuityforlife
> >
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> > Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> > Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered
> > offices: Berlin and Munich, Germany; Commercial registries: Berlin
> > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> >
> >> -Ursprüngliche Nachricht-
> >> Von: dev-security-policy
> >>  Im Auftrag von
> >> Buschart, Rufus via dev-security-policy
> >> Gesendet: Mittwoch, 23. Januar 2019 20:24
> >> An: mozilla-dev-security-pol...@lists.mozilla.org
> >> Betreff: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded
> >> international domain names
> >>
> >> Hello!
> >>
> >>> Von: Servercert-wg <mailto:servercert-wg-boun...@cabforum.org> Im
> >>> Auftrag von Wayne Thayer via Servercert-wg
> >>>
> >>>> On Mon, Jan 21, 2019 at 5:50 PM Jeremy Rowley via Servercert-wg 
> >>>> <mailto:servercert...@cabforum.org> wrote:
> >>>> We received a report for someone saying that certificates issued with 
> >>>> puny-code are mis-issued if they use IDNA2008.
> >>>> Considering a number of people probably received the same report, I 
> >>>> figured we should raise and discuss the implications here.
> >>>> ISSUES:
> >>>> 1. Does a CA have to check the puny-code provided by a customer for
> >>>> compliance? Generally, we send the validation request to the
> >>>> puny-code domain (not the pre-conversation name). This confirms
> >> control over the domain so is there a need to check this?
> >>>> If we aren’t doing the conversion, are we actually an implementer in 
> >>>> this case?
> >>> The BRs require 5280 compliance, so yes I think CAs need to ensure that 
> >>> certificates they sign conform to IDNA2003.
> >> Where exactly in RFC5280 do you find the requirement that domains
> >> that follow IDNA2008 but not IDNA2003 are not permitted in a
> >> certificate? If I understand chapter 7.3 of RFC2008 correctly, it 
> >> describes how to process a doma

AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Good morning!

I would like to sharpen my argument from below a little bit: If a CA gets a 
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can 
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a 
very strange server name? At least I don't have a glass bowl to read the mind 
of my customers. Therefor I would say, it is perfectly okay to issue a 
certificate for xn--gau-7ka.siemens.de as long as you perform a successful 
domain validation for xn--gau-7ka.siemens.de.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Buschart, Rufus via dev-security-policy
> Gesendet: Mittwoch, 23. Januar 2019 20:24
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international 
> domain names
> 
> Hello!
> 
> > Von: Servercert-wg <mailto:servercert-wg-boun...@cabforum.org> Im
> > Auftrag von Wayne Thayer via Servercert-wg
> >
> >> On Mon, Jan 21, 2019 at 5:50 PM Jeremy Rowley via Servercert-wg 
> >> <mailto:servercert...@cabforum.org> wrote:
> >> We received a report for someone saying that certificates issued with 
> >> puny-code are mis-issued if they use IDNA2008.
> >> Considering a number of people probably received the same report, I 
> >> figured we should raise and discuss the implications here.
> >> ISSUES:
> >> 1. Does a CA have to check the puny-code provided by a customer for
> >> compliance? Generally, we send the validation request to the puny-code 
> >> domain (not the pre-conversation name). This confirms
> control over the domain so is there a need to check this?
> >> If we aren’t doing the conversion, are we actually an implementer in this 
> >> case?
> > The BRs require 5280 compliance, so yes I think CAs need to ensure that 
> > certificates they sign conform to IDNA2003.
> 
> Where exactly in RFC5280 do you find the requirement that domains that follow 
> IDNA2008 but not IDNA2003 are not permitted in a
> certificate? If I understand chapter 7.3 of RFC2008 correctly, it describes 
> how to process a domain that follows IDNA2003 (rfc3490) but
> it does not forbid that a domain can be encoded in IDNA2008 (rfc5890 / 
> rfc5891). It simply says nothing special about how to handle it.
> Therefor I would interpret RFC5280 that in this case the domain name in 
> punycode can (or better say MUST) be treated like any other
> domain name.
> 
> Excerpt from the bug mentioned by Jürgen:
> > Question: Are ACE-labels not encoded as IDNA 2003 in certificates a 
> > misissuance under the Baseline Requirements? Yes, we think
> this is currently the case:
> >
> > Baseline Requirements mandate conformance to exactly RFC 5280 and
> > don't reference/allow any updates, e.g., RFC 8399
> >
> > Chapter 7.2 of RFC 5280 https://tools.ietf.org/html/rfc5280#page-97 states:
> > "Specifically, conforming implementations MUST perform the conversion 
> > operation specified in Section 4 of RFC 3490, with the
> following clarifications: "
> >
> > So, IDNs must be converted according to the rules of RFC 3490
> >
> > We, as a CA, don't perform the conversion mentioned in RFC 5280. We 
> > receive/process ACE-labels only. This means that our system
> is likely not meant by the wording "conforming implementations" of RFC 5280.
> >
> > However, our systems have the technical means and generally the 
> > responsibility to check for correct input. So, we shall
> check/enforce IDNA 2003 ACE-labels.
> 
> I don't share your opinion, that you MUST check if a domain is a valid 
> IDNA2003 domain, just because you could technically do so. I
> think this leads on a very slippery road. With the same argument one could 
> require a CA to scan every web server before the issuance
> of a certificate (or even regularly while the certificate is valid) if the 
> web server is distributing malware (BRGs chapter 9.6.3 sub bullet
> 8). And this is obviously 

AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

Hello!

> Von: Servercert-wg  Im Auftrag von 
> Wayne Thayer via Servercert-wg
>
>> On Mon, Jan 21, 2019 at 5:50 PM Jeremy Rowley via Servercert-wg 
>>  wrote:
>> We received a report for someone saying that certificates issued with 
>> puny-code are mis-issued if they use IDNA2008.
>> Considering a number of people probably received the same report, I figured 
>> we should raise and discuss the implications here.  
>> ISSUES:
>> 1. Does a CA have to check the puny-code provided by a customer for 
>> compliance? Generally, we send the validation request to
>> the puny-code domain (not the pre-conversation name). This confirms control 
>> over the domain so is there a need to check this?
>> If we aren’t doing the conversion, are we actually an implementer in this 
>> case?
> The BRs require 5280 compliance, so yes I think CAs need to ensure that 
> certificates they sign conform to IDNA2003. 

Where exactly in RFC5280 do you find the requirement that domains that follow 
IDNA2008 but not IDNA2003 are not permitted in a certificate? If I understand 
chapter 7.3 of RFC2008 correctly, it describes how to process a domain that 
follows IDNA2003 (rfc3490) but it does not forbid that a domain can be encoded 
in IDNA2008 (rfc5890 / rfc5891). It simply says nothing special about how to 
handle it. Therefor I would interpret RFC5280 that in this case the domain name 
in punycode can (or better say MUST) be treated like any other domain name.

Excerpt from the bug mentioned by Jürgen:
> Question: Are ACE-labels not encoded as IDNA 2003 in certificates a 
> misissuance under the Baseline Requirements? Yes, we think this is currently 
> the case:
> 
> Baseline Requirements mandate conformance to exactly RFC 5280 and don't 
> reference/allow any updates, e.g., RFC 8399
>
> Chapter 7.2 of RFC 5280 https://tools.ietf.org/html/rfc5280#page-97 states:
> "Specifically, conforming implementations MUST perform the conversion 
> operation specified in Section 4 of RFC 3490, with the following 
> clarifications: "
> 
> So, IDNs must be converted according to the rules of RFC 3490
> 
> We, as a CA, don't perform the conversion mentioned in RFC 5280. We 
> receive/process ACE-labels only. This means that our system is likely not 
> meant by the wording "conforming implementations" of RFC 5280.
> 
> However, our systems have the technical means and generally the 
> responsibility to check for correct input. So, we shall check/enforce IDNA 
> 2003 ACE-labels.

I don't share your opinion, that you MUST check if a domain is a valid IDNA2003 
domain, just because you could technically do so. I think this leads on a very 
slippery road. With the same argument one could require a CA to scan every web 
server before the issuance of a certificate (or even regularly while the 
certificate is valid) if the web server is distributing malware (BRGs chapter 
9.6.3 sub bullet 8). And this is obviously not the duty of a CA. So I 
understand the spirit of RFC 5280 and the BRGs that a CA has to perform domain 
validation on the ACE-label but not to enforce any additional syntax on top of 
validated dNSNames.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Jürgen Brauckmann via dev-security-policy
> Gesendet: Mittwoch, 23. Januar 2019 13:42
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain 
> names
> 
> We received a report about non-idna2003 encoded international domain names. 4 
> certificates were affected and are revoked by now.
> 
> Details can be found here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1522080
> 
> Please also take note of the ongoing discussion regarding this topic in the 
> CA/B Forum's Server Certificate Working Group mailing list:
> https://cabforum.org/pipermail/servercert-wg/2019-January/000520.html ff.
> 
> Thanks,
> Jürgen
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list

AW: AlwaysOnSSL web security issues

[Buschart, Rufus via dev-security-policy]

 The certificate [1] seems also to be 'back-dated' by about 18 hours. What is 
Mozillas opinion about this in the light of 
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date
 ?
 
> It appears AlwaysOnSSL is not completely disabled - if we trust CT as a 
> timestamping service, [1] was issued after Hanno's email.
[...]
> [1] https://crt.sh/?id=1097197338
[...] 
> On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy 
>  wrote:
> >
> > Hi,
> >
> > AlwaysOnSSL was a free certificate authority operated by CertCenter.
> > I recently noticed that their main webpage was gone, but pieces of the
> > service were still online.
> > I immediately found a few web security issues. I reported those to
> > certcenter and digicert (which is the root CA their intermediate
> > chains to).
[...]
> > In response to this the service was completely disabled.
[...]
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: CA Communication: Underscores in dNSNames

[Buschart, Rufus via dev-security-policy]

> On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
> > On 10/12/2018 18:09, Ryan Sleevi wrote:
> > > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via
> > > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > >
> > >> Hello!
> > >>
> > >> It would be helpful, if the CA/B or Mozilla could publish a
> > >> document on its web pages to which we can redirect our customers,
> > >> if they have technical questions about this underscore issue. Right
> > >> now, I can only
> > tell
> > >> them, that they are forbidden because the ballot to explicitly
> > >> allow
> > them
> > >> failed, but not really why. Especially since the first result in
> > >> Google
> > for
> > >> "underscore domain name" is a StackOverflow article (
> > >> https://stackoverflow.com/a/2183140/1426535) stating that it is
> > >> technically perfectly okay and also RFC 5280 says "These characters
> > >> [underscore and at-sign] often appear in Internet addresses.  Such
> > >> addresses  MUST be encoded using an ASN.1 type that supports them."
> > >>
> > >
> > > There's definitely been a lot of back and forth on this topic. It's
> > unclear
> > > if you're looking for a clearer statement about why they're
> > > forbidden or where they're forbidden.
> > >
> >
> > It is clear that Rufus is looking for a link to the deprecation
> > ballot, rather than the old (failed) non-deprecation ballot.
> >
> 
> Thanks for sharing your interpretation. I don't think that is an accurate 
> summary, but it's useful to understand your perspective and
> how you interpret things.
> 

Thank you very much for the good and constructive discussion that followed my 
question. The main problem I had with this underscore issue is, that the first 
hit at Google links to a SO article 
(https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it/2183140#2183140)
 which is a little bit misleading, if not being red with a lot of care. But 
based on this discussion and the statement of Wayne I think everything is clear 
now. Thank you once again!

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

AW: s/MIME certs and authentication

[Buschart, Rufus via dev-security-policy]

We do re-verify on every re-issuance and do not re-use verification 
information. But we are probably not the most typical example, as all our 
verification information are coming from HR systems.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Jeremy Rowley via dev-security-policy
> Gesendet: Donnerstag, 13. Dezember 2018 02:00
> An: mozilla-dev-security-policy 
> 
> Betreff: s/MIME certs and authentication
> 
> Now that the Symantec TLS distrust is essentially behind us, we're working on 
> migrating all of the s/MIME certificates to DigiCert
> hierarchies. Once this is complete, the browsers can remove the legacy 
> Symantec roots completely. In my new compliance role, I'm
> looking at how to create a smooth, but compliant, transition process. One 
> major question I had while reviewing some of the systems is
> the frequency of s/MIME cert reverification. Nothing is specified in the 
> policy that I could see. I thought I'd raise the question here to
> see if there's a policy somewhere else or if Mozilla wants to consider an 
> official policy in one of its next updates.
> 
> 
> 
> Some systems look like they verify the email address/domain name at issuance 
> and then never again for the same account. Other
> systems verify the email address and domain every 825 days. The last set 
> verifies the email address each time a certificate is issued.  I
> think each are equally compliant, but the set-it-and-forget it method doesn't 
> seem in the spirit of ensuring control over the email
> address. Is there guidance on how often this reverification should occur?
> 
> 
> 
> Thanks for the input.
> 
> Jeremy

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

AW: CA Communication: Underscores in dNSNames

[Buschart, Rufus via dev-security-policy]

Hello!

It would be helpful, if the CA/B or Mozilla could publish a document on its web 
pages to which we can redirect our customers, if they have technical questions 
about this underscore issue. Right now, I can only tell them, that they are 
forbidden because the ballot to explicitly allow them failed, but not really 
why. Especially since the first result in Google for "underscore domain name" 
is a StackOverflow article (https://stackoverflow.com/a/2183140/1426535) 
stating that it is technically perfectly okay and also RFC 5280 says "These 
characters [underscore and at-sign] often appear in Internet addresses.  Such 
addresses  MUST be encoded using an ASN.1 type that supports them."

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von rahat3858--- via dev-security-policy
> Gesendet: Montag, 10. Dezember 2018 01:45
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: CA Communication: Underscores in dNSNames
> 
> On Monday, November 12, 2018 at 3:19:17 PM UTC-8, Wayne Thayer wrote:
> > As you may be aware, the CA/Browser Forum recently passed ballot SC12
> > [1] creating a sunset period for TLS certificates containing an
> > underscore
> > ("_") character in the SAN. This practice was widespread until a year
> > ago when it was pointed out that underscore characters are not
> > permitted in dNSName name forms, and ballot 202 was proposed to create
> > an exception to RFC 5280 that would allow the practice to continue.
> > When that ballot failed, some CAs stopped allowing underscore
> > characters in SANs and others continued. Ballot SC12 is intended to
> > resolve this inconsistency and provide clear guidance to auditors.
> >
> > The sunset period defined by ballot SC12 is very short. Today Mozilla
> > sent an email to all CAs in our program informing them of this change
> > and asking them to take any steps necessary to comply [2].
> >
> > - Wayne
> >
> > [1]
> > https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-
> > dnsnames/
> > [2]
> > https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communicat
> > ion_.28Underscores_in_dNSNames.29
> 
> ___
> 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

AW: Incident report D-TRUST: syntax error in one tls certificate

[Buschart, Rufus via dev-security-policy]

To simplify the process of monitoring crt.sh, we at Siemens have implemented a 
little web service which directly queries crt.sh DB and returns the errors as 
JSON. By this you don't have to parse HTML files and can directly integrate it 
into your monitoring. Maybe this function is of interest for some other CA:

https://eo0kjkxapi.execute-api.eu-central-1.amazonaws.com/prod/crtsh-monitor?caID=52410=30=false

To monitor your CA, replace the caID with your CA's ID from crt.sh. In case you 
receive an endpoint time-out message, try again, crt.sh DB often returns time 
outs. For more details or function requests, have a look into its GitHub repo: 
https://github.com/RufusJWB/crt.sh-monitor


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Enrico Entschew via dev-security-policy
> Gesendet: Dienstag, 27. November 2018 18:17
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: Incident report D-TRUST: syntax error in one tls certificate
> 
> Am Montag, 26. November 2018 18:34:38 UTC+1 schrieb Jakob Bohm:
> 
> > In addition to this, would you add the following:
> >
> > - Daily checks of crt.sh (or some other existing tool) if  additional
> > such certificates are erroneously issued before  the automated
> > countermeasures are in place?
> 
> Thank you, Jakob. This is what we intended to do. We are monitoring crt.sh at 
> least twice daily every day from now on.
> 
> As to your other point, we do restrict the serial number element and the 
> error occurred precisely in defining the constraints for this
> field. As mentioned above, we plan to make adjustments to our systems to 
> prevent this kind of error in future.
> ___
> 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

AW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Buschart, Rufus via dev-security-policy]

Did we somehow came to a conclusion / agreed wording here? I'm not sure if I 
missed something, but the last email I've received in regards to this issue is 
from mid of May and the last change in 
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md dates to 
beginning of March. I don't want to make artificial pressure here but want to 
be sure I don't miss something important.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Tim Hollebeek via dev-security-policy
> Gesendet: Mittwoch, 16. Mai 2018 08:23
> An: Wayne Thayer; mozilla-dev-security-policy
> Betreff: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on 
> CA key generation to policy)
> 
> When we debated it last, my predictions were hypothetical.
> 
> 
> 
> I wish they had remained hypothetical.
> 
> 
> 
> -Tim
> 
> 
> 
> From: Wayne Thayer [mailto:wtha...@mozilla.com]
> Sent: Wednesday, May 16, 2018 12:33 AM
> To: Tim Hollebeek ; 
> mozilla-dev-security-policy 
> 
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on 
> CA key generation to policy)
> 
> 
> 
> On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek   > wrote:
> 
> My only objection is that this will cause key generation to shift to 
> partners and affiliates, who will almost certainly do an even worse job.
> 
> >
> 
> This is already a Mozilla requirement [1] - we're just moving it into the 
> policy document.
> 
> >
> 
> If you want to ban key generation by anyone but the end entity, ban key 
> generation by anyone but the end entity.
> 
> >
> 
> We've already debated this [2] and didn't come to that conclusion.
> 
> >
> 
> -Tim
> 
> 
> 
> [1]
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distrib
> uting_Generated_Private_Keys_in_PKCS.2312_Files
> 
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA
> 4/AC4xgZ9CBgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Buschart, Rufus via dev-security-policy]

Basically I like the new wording:

> PKCS#12 files [...] SHALL have a password containing at least 112 bits 
> of output from a CSPRNG, [...]

But I think there is a practical problem here: Directly using the output of any 
random number generator ("C" or not) to generate a password will lead to 
passwords which contain most probably characters that are either not printable 
or at least not type-able on a 'normal' western style keyboard. Therefore I 
think we need to reword the password strength section a little bit, maybe like 
the following:

> PKCS#12 files [...] SHALL have a 14 character long password consisting 
> of characters, digits and special characters based on output from a 
> CSPRNG, [...]

When I originally proposed my wording, I had the serial numbers in my mind (for 
which directly using the output of a CSPRNG works), but didn't think on the 
encoding problem.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322


> -Ursprüngliche Nachricht-
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
> Gesendet: Mittwoch, 2. Mai 2018 07:45
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation 
> to policy
> 
> On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote:
> > Ryan - thanks for raising these issues again. I still have concerns 
> > about getting this specific in the policy, but since we're now 
> > headed down that road...
> >
> > On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < 
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > A few problems I see with the proposed text:
> > >
> > > - What is sufficient? I would go with a definition tied to the 
> > > effective strength of the keys it protects; in other words, you 
> > > should protect a 2048bit RSA key with something that offers 
> > > similar properties or that 2048bit key does not live up to its
> > > 2048 bit properties. This is basically the same CSPRNG 
> > > conversation but it's worth looking at https://www.keylength.com/
> >
> >
> > The latest proposal replaces "sufficient" with "at least 64 bits of 
> > output from a CSPRNG". We could go back to "sufficient strength for 
> > the keys it protects", but that also leaves quite a bit of room for 
> > misinterpretation.
> >
> > Are there objections to "at least 112 bits of output from a CSPRNG" 
> > as Tim proposed?
> 
> I'd recommend making a requirement that it be "protected" by at least 
> as many bits of strength as the key it protects. Not doing so could cause 
> compliance issues: things like PCI [1] and the NIST [2] recommendations 
> require this type of protection.
> However, like Wayne said, this still leaves room for interpretation, 
> if mentioning bits is necessary, can we just bump it up to 256 rather than 
> 112?
> 
> I went back to the word "protect" to rule out the use of 3DES because 
> bumping up the password past 112 bits doesn't really do much good if the 
> underlying algorithm maxes out its protective strength at 112.
> I realize this will decrease the utility of the p12/pfx files since 
> none of the  adequately protected files would be openable on any 
> version of Windows. However, the team at Microsoft is well aware of this and 
> they can prioritize their own backlog (they just don't appear to have been 
> given the right incentive to do so as of yet). Perhaps we can add a 
> date-gate..
> 
> How about:
> 
> PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password 
> containing at least 112 bits of output from a CSPRNG, and the password 
> SHALL be transferred using a different channel than the PKCS#12 file. 
> Beginning January 1, 2020 PKCS#12 files must be protected by at least 256 
> bits of output from a CSPRNG.
> 
> This would give people like Microsoft some extra time to update their 
> implementations to support AES.
> 
> 
> -Carl
> 
> [1] PCI - DSS v3.2, Section 3.5
> [2] 800-57 Part 1, Section 6.2.1.3 -
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt
> 1r4.pdf ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Buschart, Rufus via dev-security-policy]

---=== Intern ===---
Hello!

I would like to suggest to rephrase the central sentence a little bit:

Original:

CAs MUST NOT distribute or transfer certificates in PKCS#12 form through 
insecure electronic channels. The PKCS#12 file must have a  sufficiently secure 
password, and the password must not be transferred  together with the file.

Proposal:

CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through 
insecure electronic channels. If the CA chooses to do so, the PKCS#12 file 
SHALL have a  password containing at least 32 bit of output from a CSPRNG, and 
the password SHALL be transferred using a different channel as the PKCS#12 file.


My proposal would allow a CA to centrally generate a P12 file, send it to the 
Subject by unencrypted email and send the P12 pin as a SMS or Threema message. 
This is an important use case if you want to have email encryption on a mobile 
device that is not managed by a mobile device management system. Additionally I 
made the wording a little bit more rfc2119-ish and made clear, what defines a 
'sufficiently secure password' as the original wording lets a lot of room for 
'interpretation'.

What do you think?

/Rufus


Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy 
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Wayne Thayer via dev-security-policy
> Gesendet: Freitag, 27. April 2018 19:30
> An: Enrico Entschew
> Cc: mozilla-dev-security-policy
> Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation 
> to policy
> 
> On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I suggest to make the requirement „* The PKCS#12 file must have a 
> > sufficiently secure password, and the password must be transferred 
> > via a separate channel than the PKCS#12 file.” binding for both 
> > transfer methods and not be limited to physical data storage.
> > Otherwise I agree with this proposal.
> >
> > Enrico
> >
> > That seems like a good and reasonable change, resulting in the 
> > following
> policy:
> 
> CAs MUST NOT generate the key pairs for end-entity certificates that 
> have EKU extension containing the KeyPurposeIds id-kp- serverAuth or 
> anyExtendedKeyUsage.
> 
> CAs MUST NOT distribute or transfer certificates in PKCS#12 form 
> through insecure electronic channels. The PKCS#12 file must have a 
> sufficiently secure password, and the password must not be transferred 
> together with the file. If a PKCS#12 file is distributed via a 
> physical data storage device, then the storage must be packaged in a 
> way that the opening of the package causes irrecoverable physical 
> damage. (e.g. a security seal)
> 
> Unless other comments are made, I'll consider this to be the conclusion of 
> discussion on this topic.
> 
> Wayne
> ___
> 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

"multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Buschart, Rufus via dev-security-policy]

Hi Ryan!

The "multiple perspective validations" is an interesting idea. Did you think 
about combining it with CAA checking? I could imagine having a new tag, e.g. 
"allowedMethods", in which the legitimate owner of  a domain can specify the 
set of allowed methods to validate his domain. As an example the value 
"(3.2.2.4.1 AND 3.2.2.4.5) OR 3.2.2.4.9" in the new "allowedMethods" tag could 
mean, that a certificate may only be issued, if two validations acc. 3.2.2.4.1 
and 3.2.2.4.1 were successful or if one validation acc. 3.2.2.4.9 was 
successful. Any other method of validation would be not allowed. I see here the 
benefit, that the owner of a domain can choose how to verify according his 
business needs and select the appropriate level of security for his domains.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322


> -Ursprüngliche Nachricht-
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Ryan Hurst via dev-security-policy
> Gesendet: Mittwoch, 25. April 2018 10:57
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: Regional BGP hijack of Amazon DNS infrastructure
> 
> On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote:
> > This story is still breaking, but early indications are that:
> >
> > 1.  An attacker at AS10297 (or a customer thereof) announced several 
> > more specific subsets of some Amazon DNS infrastructure prefixes:
> >
> > 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24
> >
> > 2.  It appears that AS10297 via peering arrangement with Google got 
> > Google's infrastructure to buy (accept) the hijacked advertisements.
> >
> > 3.  It has been suggested that at least one of the any cast 8.8.8.8 
> > resolvers performed resolutions of some zones via the hijacked targets.
> >
> > It seems prudent for CAs to look into this deeper and scrutinize any 
> > domain validations reliant in DNS from any of those ranges this morning.
> 
> This is an example of why ALL CA's should either already be doing 
> multi-perspective domain control validation or be working towards that in the 
> very near future.
> 
> These types of attacks are far from new, we had discussions about them 
> back in the early 2000s while at Microsoft and I know we were not the 
> only ones. One of the earlier papers I recall discussing this topic 
> was from the late 08 timeframe from CMU - 
> https://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/
> 
> The most recent work on this I am aware of is the Princeton paper from last 
> year:
> http://www.cs.princeton.edu/~jrex/papers/bamboozle18.pdf
> 
> As the approved validation mechanisms are cleaned up and hopefully 
> reduced to a limited few with known security properties the natural next step 
> is to require those that utilize these methods to also use multiple 
> perspective validations to mitigate this class of risk.
> 
> Ryan Hurst (personal)
> ___
> 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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Buschart, Rufus via dev-security-policy]

I believe the wording "insecure electronic channels" leaves a lot of space for 
interpretation. In corporate PKIs for email encryption it is quite common to 
transfer centrally generated email encryption p12-files to mobile device 
management systems, email encryption gateways or directly to mobile devices 
using a wide variety of 'electronic channels'. From the proposed wording it 
doesn't seem to be clear which of those channels are 'insecure' and which not. 
Even if not that common, the same applies for email signature p12-files for 
e.g. email signature on mail gateways or mobile devices. Most of the mobile 
devices out in the field neither support hardware token, key-pair-generation in 
the mailer software nor installation of downloaded p12-files (prohibited by app 
sandboxing).

Maybe it would be possible to restrict the new wording to the EKU kp-ServerAuth 
first and have a detailed discussion about email-encryption and user 
authentication with more interested parties in the next months?

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Wayne Thayer via dev-security-policy
Sent: Dienstag, 17. April 2018 02:24
To: mozilla-dev-security-policy
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Tue, Apr 10, 2018 at 7:22 AM, Jürgen Brauckmann via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

>
>
> Am 10.04.2018 um 01:10 schrieb Wayne Thayer via dev-security-policy:
>
>> Getting back to the earlier question about email certificates, I am 
>> now of the opinion that we should limit the scope of this policy 
>> update to TLS certificates. The current language for email 
>> certificates isn't clear and any attempt to fix it requires us to 
>> answer the bigger question of "under what circumstances is CA key generation 
>> acceptable?"
>>
>> My updated proposal is to add the following paragraphs to section 5.3 
>> “Forbidden and Required Practices”:
>>
>> CAs MUST not generate the key pairs for end-entity certificates, 
>> except for
>>
>>> email certificates with the Extended Key Usage extension present and 
>>> set to id-kp-emailProtection.
>>>
>>
>
> What about user certificates for logon/authentication? CN=John Doe, 
> extendedKeyUsage=clientAuth? Is that different from email certificates?
>
> Yes, but certificates with only the clientAuth EKU are out of scope
according to section 1.1 of the Mozilla policy

Wouldn't it be better to make that a positive list to really limit the
> scope of the change?
>
> Yes, I think so.

=
> CAs MUST NOT generate the key pairs for end-entity certificates the 
> scope of the Baseline Requirements.
> =
>
> But this is too vague. I propose that we add the following paragraphs 
> to
section 5.2:

CAs MUST NOT generate the key pairs for end-entity certificates that have
> EKU extension containing the KeyPurposeIds id-kp-serverAuth or 
> anyExtendedKeyUsage.
>

>
CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. If a PKCS#12 file is distributed via a 
> physical data storage device, then:
> * The storage must be packaged in a way that the opening of the 
> package causes irrecoverable physical damage. (e.g. a security seal)
> * The PKCS#12 file must have a sufficiently secure password, and the 
> password must not be transferred together with the storage.


Here it is on GitHub:
https://github.com/mozilla/pkipolicy/commit/456f869a15b6b9ca9be1df1897852b0c508932c7

Are there any concerns with this approach?

- Wayne

Thanks,
>Jürgen
>
>
___
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....

[Buschart, Rufus via dev-security-policy]

If your CA is audited according ETSI 319 401, there is a clear obligation for a 
CA (aka TSP) "to issue to those meeting the qualifications specified" 

* REQ-7.1.1-02: Trust service practices under which the TSP operates shall be 
non-discriminatory.
* REQ-7.1.1-03: The TSP should make its services accessible to all applicants 
whose activities fall within its declared field of operation and that agree to 
abide by their obligations as specified in the TSP's terms and conditions.

I don't know, if WebTrust has a similar requirement.

From: Matthew Hardeman via dev-security-policy
> Perhaps it should be the broader question of both issuance policy and 
> revocation?
>
> For example, guidelines denote what issuance is permissible but 
> nowhere in the BR policies (or in any of the root programs as far as 
> I'm aware) is an affirmative obligation to issue to those meeting the 
> qualifications specified.
>
>
> On Thu, Apr 12, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Eric raised an issue distinct from 'the value of EV' that I think is
> > important: Can certificate revocation be used as a form of censorship? 
> > As HTTPS becomes the default state of the web, it becomes more 
> > important to consider this issue and what should be done about it. I 
> > plan to discuss this with others at Mozilla, and I welcome more 
> > discussion here on the topic (perhaps in a new thread).
> >
> > - Wayne

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

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

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Buschart, Rufus via dev-security-policy]

>> I don’t think you should include #2 because it's a common practice to 
>> issue one certificate for Secure Mail that is used to both sign and 
>> encrypt, and this would preclude CA key generation for those types of 
>> certificates.
>>
>> I was attempting to match the existing "forbidden practice" 
>> requirement
>that carves out an exception only for email encryption.
>I don't know why that exception exists, but I do agree with you that it is 
>uncommon for an S/MIME certificate to support encryption but not signatures.

Actually it is very common: our CA has a couple of hundred thousand S/MIME 
certificates in the field, that are either for mail encryption or for mail 
signature but not for both. And I believe there are a lot of other enterprise 
CAs that do the same. There is a good reason for doing so: the private keys for 
both types of certificates are safely stored on our employees corporate ID 
smart card. But only the signature keys are also generated on the smart card. 
The encryption keys are generated centrally in the CA and then securely 
injected into the smart card. The reason for this split is, that we want to be 
absolutely sure, that the email signature is non-repudiationable by the holder 
of the card (as required by the European Unions eIDAS regulation for 'advanced 
electronic signature') but on the other hand side, we need to be able to 
perform a key escrow for the encryption keys, in case the card is damaged or 
lost or if there is court requirement to decrypt corporate emails and the 
holder of the card is not willing to do so.

Don't hesitate to contact me, if you want to know more, how it works in our 
case.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife
___
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 English Language Audit Reports

[Buschart, Rufus via dev-security-policy]

I would like to suggest to add the clause "if legally allowed" at the end. I 
had some crazy discussions with colleagues in Russia and Québec about documents 
in English. Also it should be added that the audit information must be publicly 
available in the Internet. The whole sentence would be:

"The audit information MUST be publicly available in the Internet. An English 
version MUST be provided. The English version MUST be authoritative if legally 
possible under the jurisdiction of the CAs home country."

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Tim Hollebeek via dev-security-policy
Sent: Donnerstag, 5. April 2018 02:49
To: Ryan Hurst; mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Policy 2.6 Proposal: Require English Language Audit Reports

Call me crazy, but for this particular requirement, I think simple sentences 
might be better.

"The audit information MUST be publicly available.  An English version MUST be 
provided.  The English version MUST be authoritative."

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of 
> bounces+Ryan
> Hurst via dev-security-policy
> Sent: Wednesday, April 4, 2018 7:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Policy 2.6 Proposal: Require English Language Audit 
> Reports
> 
> 
> > An authoritative English language version of the publicly-available 
> > audit information MUST be supplied by the Auditor.
> >
> > it would be helpful for auditors that issue report in languages 
> > other than English to confirm that this won't create any issues.
> 
> That would address my concern.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/qGy7WL45gRate5ccNJV7plt7IjXPV-pd-
> LTa9gPkQc8=?d=fgUiNjCpj8UK6ue4NShfzLGHGzkJWwPb3tOchiTvGntTxuK9bVX
> 5aMMPzBijLrabsuGnsFF4O9QSQsBjPBTpEb0gpSmHGiantqc2OcSQ0D4jZ5aLA1u
> eomyRD8-dNmIp4I87-T1G40WpIGyLEnm-
> Z2ye83FoVpIrjeWcM6ujsgxkvPTYEEPgJJ5S8QA9fQctHsjXIyT8HT8j6vDTknG1enh
> GZ_T_dA6JBbp81zJ4L1Ca2eX6aXcvz5BgcHvS6yotf6bd2EfLLWJKAZnR6o1yRxbzw
> lGl0_7xHVJs8xbMEdUuaI4b4pcup6QbPJsW1UQHIPAR6GFsxCauMSz5EJ-
> 5c38HJOLDPZLF5Tj0N6r-
> JIozX3YVUyZqRdSb4iIILNv8LsXVCwyud6ALgaqx4PJwF_leqzOCmmHBoYDZqI9z0
> 932I7QTktLec_1ZHGSkFGA664AXspslouRvtqP4eZfikJgsBoxEO1G2a2tx6n5uwZle
> -vFX=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-polic
> y
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: 825 days success and future progress!

[Buschart, Rufus via dev-security-policy]

By practical means in an IT department of a large company, it is always easier 
to discuss about money, if such a plan is written down in a standard that can 
be referenced and shown (like the BRGs) than in the depths of the archive of a 
mailing list. So if there is a plan, I would like to suggest to add it to the 
standard.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife>
[www.siemens.com/ingenuityforlife]
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Montag, 2. April 2018 21:16
To: Buschart, Rufus (GS IT HR 7 4)
Cc: Alex Gaynor; Tim Hollebeek; MozPol
Subject: Re: 825 days success and future progress!

In past discussions, the proposal was 1 year to 2 years, and 1 year to 1 year 
after that. We're now at the midway point, so it seems appropriate to discuss 
how to get shorter.

On Mon, Apr 2, 2018 at 3:11 PM, Buschart, Rufus via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hi all!

>From the discussions we had in the last months internally at Siemens IT 
>department about the 825 days rule, I can report that our server operators 
>need a long term roadmap in this issue. The main point here is, that there are 
>a hell lot of applications out there that don't (easily) support automated 
>SSL/TLS certificate replacement (e.g. some SAP systems). To enable those 
>systems to support automated certificate replacement a significant amount of 
>money will need to be invested. To get approval for such an investment, one 
>needs to calculate a business case. And this business case looks obviously 
>much different, if a certificate on a system needs to be replaced every 825 
>days, 731 days, 366 days or even 90 days. So I would like to propose not to 
>start discuss about the next reduction step now, but agree on a clear 
>(semi-)final goal (e.g. max life span of a certificate is 45 days in 2023 
>(five years from now)) and then agree on the intermediate steps to reach this 
>goal.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com<mailto:rufus.busch...@siemens.com>

www.siemens.com/ingenuityforlife<http://www.siemens.com/ingenuityforlife>


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart<mailto:dev-security-policy-bounces%2Brufus.buschart>=siemens@lists.mozilla.org<mailto:siemens@lists.mozilla.org>]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Montag, 2. April 2018 20:51
To: Tim Hollebeek
Cc: MozPol
Subject: Re: 825 days success and future progress!

Hi Tim,

I'd have suggested an even shorter period, say 13 months, except I anticipated 
CAs would object that it was too great a change too suddenly, precisely as they 
did when this subject was last discussed!

While I appreciate that changing BRs can be difficult for customer 
communications, the fact that we are doing this in multiple steps instead of in 
one fell swoop is a result of CAs saying such a big leap was too disruptive. 
Frankly, you can't have it both ways.

Alex

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek 
<tim.holleb...@digicert.com<mailto:tim.holleb...@digicert.com>>
wrote:

> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>
> People have to stop wanting to constantly change the max validity period.
> It's difficult enough to communicate these changes to consumers and
> customers, and it really drives them nuts.  I can only imagine what a
> non-integral number of years will do to various company's planning and
> budgeting processes.
>
> I would propose, instead, a minimum one year moratorium on proposals
> to change the max validity period after the previous change to the max
> validity period goes into effect.  That would make much more sense.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy 
> > [mailto:dev-security-policy-<mailto:dev-security-policy->
> > bounces+tim.hollebeek=digicert@lists.mozilla.org<mailto:digicert@lists.mozilla.org>]
> >  On Behalf Of
> > bounces+Alex
> > Gaynor via dev-security-policy
> > Sent: Monday, April 2, 2018 1:07 PM
> > To: MozPol 
> > <mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
> > Subject: 825 days success and future progress!
> >
> > Afternoon all!
> >
> > A month ago a new BR rule went into effect, putting a maximum
> > validity
> period
> > of 825 days on newly issued cert

RE: 825 days success and future progress!

[Buschart, Rufus via dev-security-policy]

Hi all!

>From the discussions we had in the last months internally at Siemens IT 
>department about the 825 days rule, I can report that our server operators 
>need a long term roadmap in this issue. The main point here is, that there are 
>a hell lot of applications out there that don't (easily) support automated 
>SSL/TLS certificate replacement (e.g. some SAP systems). To enable those 
>systems to support automated certificate replacement a significant amount of 
>money will need to be invested. To get approval for such an investment, one 
>needs to calculate a business case. And this business case looks obviously 
>much different, if a certificate on a system needs to be replaced every 825 
>days, 731 days, 366 days or even 90 days. So I would like to propose not to 
>start discuss about the next reduction step now, but agree on a clear 
>(semi-)final goal (e.g. max life span of a certificate is 45 days in 2023 
>(five years from now)) and then agree on the intermediate steps to reach this 
>goal.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Montag, 2. April 2018 20:51
To: Tim Hollebeek
Cc: MozPol
Subject: Re: 825 days success and future progress!

Hi Tim,

I'd have suggested an even shorter period, say 13 months, except I anticipated 
CAs would object that it was too great a change too suddenly, precisely as they 
did when this subject was last discussed!

While I appreciate that changing BRs can be difficult for customer 
communications, the fact that we are doing this in multiple steps instead of in 
one fell swoop is a result of CAs saying such a big leap was too disruptive. 
Frankly, you can't have it both ways.

Alex

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek 
wrote:

> 18 months is not significantly different from 825 days.   So there's really
> no benefit.
>
> People have to stop wanting to constantly change the max validity period.
> It's difficult enough to communicate these changes to consumers and 
> customers, and it really drives them nuts.  I can only imagine what a 
> non-integral number of years will do to various company's planning and 
> budgeting processes.
>
> I would propose, instead, a minimum one year moratorium on proposals 
> to change the max validity period after the previous change to the max 
> validity period goes into effect.  That would make much more sense.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of 
> > bounces+Alex
> > Gaynor via dev-security-policy
> > Sent: Monday, April 2, 2018 1:07 PM
> > To: MozPol 
> > Subject: 825 days success and future progress!
> >
> > Afternoon all!
> >
> > A month ago a new BR rule went into effect, putting a maximum 
> > validity
> period
> > of 825 days on newly issued certificates.
> >
> > Truthfully, I was expecting tons of CAs to screw up, forget to 
> > implement
> it, or
> > have no technical controls, and there to be tons of miss-issuance.
> > To me delight, the results have been pretty good:
> > https://crt.sh/?zlint=1081=2018-03-01 the majority of 
> > violations have been from the US Government (whose PKI isn't 
> > remotely BR compliant, nor trusted by Mozilla).
> >
> > In light of this incredible success, I think it's time to begin a
> discussion on what
> > the next in this chain is. While obviously actually encoding this in 
> > the
> BRs will
> > be a function of the CABF, as mdsp is the premier public discussion 
> > forum
> for
> > the PKI, I wanted to start here.
> >
> > I propose that our next target should be a max validity period of 18
> months
> > (~550 days), starting in ~6 months from now.
> >
> > The value of shorter-lived certificates has been discussed many 
> > times,
> but
> to
> > rehash: They afford the ecosystem significantly more agility, by 
> > allowing
> us to
> > remove mistakes in shorter periods of time without breaking valid
> certificates.
> > It also encourages subscribers to adopt more automation, which 
> > further
> helps
> > with agility.
> >
> > Alex
> > ___
> > 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

RE: Audits for new subCAs

[Buschart, Rufus via dev-security-policy]

Operating a technically unconstrained issuing CA, Siemens CA (aka TSP) does 
something very similar in case a new CA is necessary:

* In an audited ceremony based on the operational and technical controls 
audited in the last annual audit a key pair is generated on one of the HSMs
* A CSR is constructed and sent to our cross signing partner, together with the 
witness report of the auditor, filled with all the information required by 
Microsoft in the Audit Cover Letter Template
* The cross signing partner checks the report and creates the certificate for 
the issuing CA After receiving the new certificate we update our CPS Only after 
the new CPS is published certificates are issued

In the next annual audit the new CA is part of the normal audit.

So I would recommend to choose a combination of options #1 and #2.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Bruce via dev-security-policy
Sent: Mittwoch, 28. März 2018 23:38
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Audits for new subCAs

Entrust does the following:
- Each subCA certificate is created through a audited ceremony. The auditor 
creates a report indicating the key ID and the CPS which was used for key 
generation.
- When it is time for the subCA to go into production, an intermediate 
certificate is issued from a root. The intermediate certificate will meet the 
requirements of the CPS and the BRs if applicable.
- The subCA can now issue certificates. The end entity certificates will have a 
certificate policy which is stated in the CPS. As such, issuing a certificate 
is an assertion that the subCA is issuing in accordance with the certificate 
policy and CPS.
- The new subCA is compliance audited at the next time in our annual audit 
cycle. Note the new subCA is operated the same as all other CAs meeting the 
same certificate policy.

I would note that if there was a significant change such as data center 
location or new certificate policy, then we may want to consider a 
point-in-time readiness assessment. I think that all CAs required a 
point-in-time readiness assessment, before we started to issue EV certificates.

I suppose that I am stating that I support option 1 as I think the option 2 
attestments are already covered. However, option 3 may be required for a new 
data center or a policy which has not been previously audited.

Thanks, Bruce.
___
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: ETSI Audits Almost Always FAIL to list audit period

[Buschart, Rufus via dev-security-policy]

 For example, in all our audits for other standards, no “audit 
 period” is clearly documented in the report; time since previous 
 audit is always implied.
>>>
>>> Again, I don't believe that it is reasonable to assume that 
>>> auditing/sampling has been done over the full year.
>>>
>> 
>> [NS]: No assumptions are made. This is common practice and common 
>> understanding.
>
>
>Sigh. If it were so well understood then I would think CAs and auditors 
>would be providing better answers regarding whether their audits are 
>point-in-time or full audits, and what the audit period start and end dates 
>are.

In the ETSI audits I've been participating (and also in nearly all other 
audits, be it ISO 27001 or ISO 9001) the auditor was differentiating between a 
Test of Design (ToD) and Test of Effectiveness (ToE) for every control. For the 
ToD the auditor looks at the very moment of the audit into the processes or 
technical methods that are in place to fulfill the requirements of the specific 
control. He assesses if those methods or processes seem to be sound and 
reasonable by his professional experience or other standards. For the ToE the 
auditor takes evidence from the audit period in the past to check, first, if 
the auditee always followed the methods or processes checked in the ToD and, 
second, if the methods and processes really worked to fulfill the goal of the 
control. Failures in the tests are documented in the audit report. The 
certificate is only issued if there were no significant deviations found.

My question to the WebTrust community would be, if the WebTrust auditors work 
significantly different? And if yes, what are the differences?

>Sorry if I'm being slow here, but how do we get the ETSI audits and audit 
>statements fixed ASAP?

Microsoft has published a form (http://aka.ms/rootcertapply) that needs to be 
filled in after every audit by the auditor with all additional information 
required by Microsoft beyond the normal audit certificate. This form is 
collected by Microsoft from the Root CAs and by the Root CA from their Issuing 
CAs. Maybe introducing such a form for Mozilla as well could be a low hanging 
fruit to increase audit documentation quality.

Further more you could publish the names of the auditors or the auditing 
companies that fail to comply with your requirements. If there is a cluster of 
auditors / companies that often fail to comply those would practically be 
disqualified for further audits since nobody with a straight mind would hire 
such an auditor / audit company again.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

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

RE: ETSI audits not listing audit periods

[Buschart, Rufus via dev-security-policy]

Our ETSI audit report (https://www.siemens.com/corp/pool/pki/siemens_etsi.pdf) 
states:

> An audit of the certification service, documented in a report, provided 
> evidence that the requirements of the following
> specification have been fulfilled. The audit was conducted on 22th - 24th 
> February 2017 covering the timeframe
> 27th February 2016 to 21st February 2017. It was a full audit covering all 
> aspects of the standard performed.
> A second and third audit was performed on 19th and 20th June 2017 to 
> implement further Issuing CAs and in the time
> between 23rd to 30th August.

We repeat this full audit annually. From what I understand out of this 
discussion, this will meet your requirements, correct?

If you want us to move from ETSI to Webtrust we, and probably every other CA 
relying on ETSI, would highly appreciate a reasonable grace period to do so, 
since we are already in the middle of the preparation of our next audit in 
February 2018.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Montag, 30. Oktober 2017 23:31
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: ETSI audits not listing audit periods

On Monday, October 30, 2017 at 2:59:31 PM UTC-7, Ryan Sleevi wrote:
> 
> I would expect that it would be incumbent on the CABs and the CAs 
> providing EN 319 411-1 certificates to help the community better 
> understand the level of assurance provided. That is, I think those 
> supporting the continued recognition of ETSI should attempt to 
> demonstrate where either the understanding of WebTrust-based audits or 
> EN 319 411-1 certificates is incorrect or inaccurate. Otherwise, I 
> think your conclusions - about no longer recognizing such schemes - are 
> reasonable.


I hope that CAs who rely on ETSI audits are following this discussion forum, 
and that they will promptly add their comments/explanation here, and ask their 
auditors to do the same. 

I've filed this issue:
https://github.com/mozilla/pkipolicy/issues/105
In which I said:
~~
I think that all CAs should be held to the same level of assurance/audits.

So, I think we have two choices:

1) Remove ETSI as an acceptable audit scheme.

2) The ETSI folks update their audit schemes (that Mozilla's Root Store Policy 
currently allows) to meet our requirements about looking backward at 
certificate issuance data -- period-of-time audits as described above and in 
our policy and the BRs.
~~


Thanks,
Kathleen
___
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: Draft Security Blog about v2.5 of Root Store Policy

[Buschart, Rufus via dev-security-policy]

Hello Kathleen!

Thank you for sharing your draft version. I have a question regarding the 
meaning of:

> * The latest versions of the WebTrust and ETSI audit criteria are now 
> required, and auditors are required to be appropriately qualified.

Will you still accept ETSI TS 102 042 audits or does it mean, you will only 
accept ETSI EN 319 411-1 audits? Both are acceptable according to BRG 8.4.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Mittwoch, 6. September 2017 20:23
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Draft Security Blog about v2.5 of Root Store Policy

All,

Here is a draft of a security blog about version 2.5 of Mozilla's Root Store 
Policy.  I will greatly appreciate constructive feedback about it.

Thanks,
Kathleen

== Mozilla Releases Version 2.5 of Root Store Policy ==

Recently, Mozilla released version 2.5 of our Root Store Policy, which 
continues our efforts to improve standards and reinforce public trust in the 
security of the Web. We are grateful to all those in the security and 
Certificate Authority (CA) communities who contributed constructively to the 
discussions surrounding the new provisions.

The changes of greatest note in version 2.5 of our Root Store Policy are as 
follows:

* CAs are required to follow industry best practice for securing their 
networks, for example by conforming to the CA/Browser Forum’s Network Security 
Guidelines or a successor document.

* CAs are required to use only those methods of domain ownership validation 
which are specifically documented in the CA/Browser Forum’s Baseline 
Requirements 1.4.1.

* Additional requirements were added for intermediate certificates that are 
used to sign certificates for S/MIME. In particular, such intermediate 
certificates must be name constrained in order to be considered 
technically-constrained and exempt from being audited and disclosed on the 
Common CA Database. 

* Clarified that point-in-time audit statements do not replace the required 
period-of-time assessments. Mozilla continues to require full-surveillance 
period-of-time audits that must be conducted annually, and successive audit 
periods must be contiguous.

* Clarified the information that must be provided in each audit statement, 
including the distinguished name and SHA-256 fingerprint for each root and 
intermediate certificate in scope of the audit.

* CAs are required to follow and be aware of discussions in the 
mozilla.dev.security.policy forum, where Mozilla's root program is coordinated, 
although they are not required to participate. 

* The latest versions of the WebTrust and ETSI audit criteria are now required, 
and auditors are required to be appropriately qualified.

* CAs are required at all times to operate in accordance with the applicable 
Certificate Policy (CP) and Certificate Practice Statement (CPS) documents, 
which must be reviewed and updated at least once every year.

* Our policy on root certificates being transferred from one organization or 
location to another has been updated and included in the main policy. Trust is 
not transferable; Mozilla will not automatically trust the purchaser of a root 
certificate to the level it trusted the previous owner.

The differences between versions 2.5 and 2.4.1 may be viewed on Github. 
(Version 2.4.1 contained exactly the same normative requirements as version 2.4 
but was completely reorganized.)

As always, we re-iterate that participation in Mozilla’s CA Certificate Program 
is at our sole discretion, and we will take whatever steps are necessary to 
keep our users safe. Nevertheless, we believe that the best approach to 
safeguard that security is to work with CAs as partners, to foster open and 
frank communication, and to be diligent in looking for ways to improve.

Mozilla Security Team

==



___
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