Re: GoDaddy Misissuance Action Items

[Jürgen Brauckmann via dev-security-policy]

Gervase Markham via dev-security-policy schrieb:
> 1) As with all CAs, update all their domain validation code to use one
> of the 10 approved methods;

I'm probably confused regarding BRs pre/post Ballot 181: Aren't there
only 4 methods per Ballot 181?

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

Re: question about DNS CAA and S/MIME certificates

[Jürgen Brauckmann via dev-security-policy]

Ryan Sleevi via dev-security-policy wrote on 14.05.2018 20:52:

And that still moves to an 'insecure-by-default', by making every site
operator that has taken steps to actually restrict issuance not have those
wishes respected.


Today, site operators have taken steps to secure issuance of server 
certificates, following the guidance of the BRs.


Email certificates are a different use case with different internal 
requirements.


Current CAA syntax lacks the possibility to distinguish between those 
two, which will come as a big surprise for organisations who whish to 
limit issuance of server certificates, but want to set different (or 
none at all) policies for email certificates.


Mandating CAA checks in its current form also for email certificates 
destroys or at least greatly hinders the rather creative technique of 
having a general "no-issuance" CAA record and setting short-lived 
issue-properties, as described in 6.3 of 
https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf


  Jürgen

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

Re: question about DNS CAA and S/MIME certificates

[Jürgen Brauckmann via dev-security-policy]

Am 15.05.2018 um 15:01 schrieb Ryan Sleevi:

On Tue, May 15, 2018 at 3:53 AM Jürgen Brauckmann 
wrote:

Today, site operators have taken steps to secure issuance of server
certificates, following the guidance of the BRs.

Email certificates are a different use case with different internal
requirements.

Current CAA syntax lacks the possibility to distinguish between those
two, which will come as a big surprise for organisations who whish to
limit issuance of server certificates, but want to set different (or
none at all) policies for email certificates.

Mandating CAA checks in its current form also for email certificates
destroys or at least greatly hinders the rather creative technique of
having a general "no-issuance" CAA record and setting short-lived
issue-properties, as described in 6.3 of
https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf

Isn’t this exactly what I said?


That CAs need to work out how to describe “disallow for server auth, allow
for S/MIME?”


I don't see how this can be done on a CA level.

How does example.org express "server certs from letsencrypt, S/MIME from 
anybody" with current CAA syntax? CA-specific issue values don't help 
with that problem.



We absolutely have to take CAA as an expression of CA restriction. It’s in
the very name! If you want to allow some CAs for some use cases, you need a
syntax to describe that.


Which is lacking today.


But you cannot make a reasonable argument that
“Just because they locked the door, they didn’t mean for us to not break a
window” - which is what every proposal to suggest CAA is server-only
fundamentally amounts to.


CAA was introduced by the BRs, and is thus felt as server-only and is 
used as server-only. Changing that is absolutely possible, but should be 
done with care, as there are use-cases which will break if CAA is 
adopted naively for email certs.


This is all about responsible change.

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

[Jürgen Brauckmann via dev-security-policy]

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?


Wouldn't it be better to make that a positive list to really limit the 
scope of the change?


=
CAs MUST NOT generate the key pairs for end-entity certificates the 
scope of the Baseline Requirements.

=

Thanks,
   Jürgen












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.



Once again, I would appreciate your comments on this proposal.

- Wayne

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

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

[Jürgen Brauckmann via dev-security-policy]

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

Incident report DFN-PKI: 40 OV certificates with wrong ST

[Jürgen Brauckmann via dev-security-policy]

From 2018-10-17 to 2019-03-06, DFN-PKI issued 40 certificates with 
wrong ST-Field. 35 server certificates, 5 user certificates.


Details can be found here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1534580



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