RE: Draft Security Blog about v2.5 of Root Store 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

RE: ETSI Audits Almost Always FAIL to list audit period

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

RE: ETSI audits not listing audit periods

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 >

AW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to 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

AW: Policy 2.6 Proposal: Add prohibition on CA key generation to 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

Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to 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

RE: Policy 2.6 Proposal: Require English Language Audit Reports

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:

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

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

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to 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

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to 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

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

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

RE: Audits for new subCAs

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

RE: 825 days success and future progress!

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)

RE: 825 days success and future progress!

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 discussio

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

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

AW: s/MIME certs and authentication

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 /

AW: CA Communication: Underscores in dNSNames

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

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

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

AW: CA Communication: Underscores in dNSNames

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

AW: AlwaysOnSSL web security issues

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 >

AW: DarkMatter Concerns

> 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

AW: CFCA certificate with invalid domain

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

AW: DarkMatter Concerns

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

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

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

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

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

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

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

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 =

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

1322 > > > >> -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 > >> Betre

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

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 ther

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

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 >

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

> 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

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

> 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

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

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

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

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

AW: Is it allowed the suspension of Issuing CAs?

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

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

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

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

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

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

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"

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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 fo

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

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

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

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