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

[Peter Bowen via dev-security-policy]

I don't think that is true.  Remember for OV/IV/EV certificates, the
Subscriber is the natural person or Legal Entity identified in the
certificate Subject.  If the Subscriber is using the certificate on a
CDN, it is probably better to have the CDN generate the key rather
than the Subscriber.  The key is never being passed around, in PKCS#12
format or otherwise, even though the Subscriber isn't generating the
key.

On Tue, May 15, 2018 at 9:17 PM, Tim Hollebeek via dev-security-policy
 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.
>
> If you want to ban key generation by anyone but the end entity, ban key
> generation by anyone but the end entity.
>
> -Tim
>
>> -Original Message-
>> From: dev-security-policy [mailto:dev-security-policy-
>> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
>> Thayer via dev-security-policy
>> Sent: Tuesday, May 15, 2018 4:10 PM
>> To: Dimitris Zacharopoulos 
>> Cc: mozilla-dev-security-policy 
>> 
>> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
>> generation to policy)
>>
>> I'm coming to the conclusion that this discussion is about "security 
>> theater"[1].
>> As long as we allow CAs to generate S/MIME key pairs, there are gaping holes
>> in the PKCS#12 requirements, the most obvious being that a CA can just
>> transfer the private key to the user in pem format! Are there any objections 
>> to
>> dropping the PKCS#12 requirements altogether and just forbidding key
>> generation for TLS certificates as follows?
>>
>> CAs MUST NOT generate the key pairs for end-entity certificates that have an
>> EKU extension containing the KeyPurposeIds id-kp-serverAuth or
>> anyExtendedKeyUsage.
>>
>> - Wayne
>>
>> [1] https://en.wikipedia.org/wiki/Security_theater
>>
>> On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos 
>> wrote:
>>
>> >
>> >
>> > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:
>> >
>> > Did you consider any changes based on Jakob’s comments?  If the
>> > PKCS#12 is distributed via secure channels, how strong does the password
>> need to be?
>> >
>> >
>> >
>> >
>> >
>> > I think this depends on our threat model, which to be fair is not
>> > something we've defined. If we're only concerned with protecting the
>> > delivery of the
>> > PKCS#12 file to the user, then this makes sense. If we're also
>> > concerned with protection of the file while in possession of the user,
>> > then a strong password makes sense regardless of the delivery mechanism.
>> >
>> >
>> > I think once the key material is securely delivered to the user, it is
>> > no longer under the CA's control and we shouldn't assume that it is.
>> > The user might change the passphrase of the PKCS#12 file to whatever,
>> > or store the private key without any encryption.
>> >
>> >
>> > Dimitris.
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-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#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

> This going to require 19 randomly generated Base64 characters and that does
> not include removing common confused characters which will drive up the
> length a bit more, but if this is what the Mozilla risk assessment came up 
> with,
> then we’ll all have to comply.  I hope there is a sufficiently long time for 
> CAs to
> change their processes and APIs and to roll out updated training and
> documentation to their customers (for this unplanned change).

A reasonable transition period is reasonable.

> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20 character
> password will have just 48 bits of entropy, and characters after that only 
> add 1
> bite of entropy each.  User stink at generating Entropy (right Tim?)

Yes, users struggle to generate a single bit of entropy per character.  This is 
why
users should not generate keys or passwords.

An encoded CSPRNG can hit 5-6 bits of entropy per character, so 20 is a pretty 
good number for password lengths.  Copy/paste solves most of the usability 
issues.

There are some subtleties that require some care, but the general gist is right.

-Tim



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

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

I agree with Phillip; if we want email CAA to be a thing, we need to define
and
specify that thing.  And I think it should be a thing.

New RFCs are not that hard and need not even be that long.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Phillip
> Hallam-Baker via dev-security-policy
> Sent: Tuesday, May 15, 2018 9:22 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: question about DNS CAA and S/MIME certificates
> 
> When I wrote CAA, my intention was for it to apply to SSL/TLS certs only.
I did
> not consider S/MIME certs to be relevant precisely because of the
> al...@gmail.com problem.
> 
> I now realize that was entirely wrong and that there is in fact great
utility in
> allowing domain owners to control their domains (or not).
> 
> If gmail want to limit the issue of Certs to one CA, fine. That is a
business choice
> they have made. If you want to have control of your online identity, you
need
> to have your own personal domain. That is why I have hallambaker.com. All
my
> mail is forwarded to gmail.com but I control my identity and can change
mail
> provider any time I want.
> 
> One use case that I see as definitive is to allow paypal to S/MIME sign
their
> emails. That alone could take a bite out of phishing.
> 
> But even with gmail, the only circumstance I could see where a mail
service
> provider like that would want to restrict cert issue to one CA would be if
they
> were to roll out S/MIME with their own CA.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/XjZsJF4yykVlCzqgt57_FIwsOTe0fR6a3C5kS
> Yh_IZ4=?d=lJg-wcLQ8TKi5x2vK8SJOJCjdKNbOFzJppz0UZwOpX_uS1wS1Mw-
> 5j_nOlfxrvZ_g0tSYqMRWJezQvAWyNySPmWiq8oV2gEI6bF-
> MXCodHj66yn6adEuwqxiAwHJd6tamadI6Kf-
> pHadUoBbCN15Wb8AEG3D126zrUxw7umhl5JRMC5lYu4kHiYb5kss5F0cvapf8h_
> U7XuRliUCpAUdVY_VtggCy6Hbk0u6x2IlNY411Cb49wMqOGMavYTwrT8CADJZ_
> OJ3cmVnrJLAclZ2Y96VSVSZpzc4h5UeBneGuFjm8T-ikCgGY3kDZfTHOOex-
> VrdHh0nbhZf-yoOgGiXg0naMQ0MnoHA_-L9tUotMKl1e-yScY5S-
> BG6sVyAe68iMOFtJaUYcyEV14-JlCiHpK8pRgYpdvB1V8O3IASeKCzuOiTPvJLrn-
> gCM2xICBAH-
> QzxWPVhgGZtP9OqMlqRDCJUeiAg9PJt=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-security-policy


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

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

[Tim Hollebeek via dev-security-policy]

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.

If you want to ban key generation by anyone but the end entity, ban key 
generation by anyone but the end entity.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, May 15, 2018 4:10 PM
> To: Dimitris Zacharopoulos 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> I'm coming to the conclusion that this discussion is about "security 
> theater"[1].
> As long as we allow CAs to generate S/MIME key pairs, there are gaping holes
> in the PKCS#12 requirements, the most obvious being that a CA can just
> transfer the private key to the user in pem format! Are there any objections 
> to
> dropping the PKCS#12 requirements altogether and just forbidding key
> generation for TLS certificates as follows?
> 
> CAs MUST NOT generate the key pairs for end-entity certificates that have an
> EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
> 
> - Wayne
> 
> [1] https://en.wikipedia.org/wiki/Security_theater
> 
> On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos 
> wrote:
> 
> >
> >
> > On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:
> >
> > Did you consider any changes based on Jakob’s comments?  If the
> > PKCS#12 is distributed via secure channels, how strong does the password
> need to be?
> >
> >
> >
> >
> >
> > I think this depends on our threat model, which to be fair is not
> > something we've defined. If we're only concerned with protecting the
> > delivery of the
> > PKCS#12 file to the user, then this makes sense. If we're also
> > concerned with protection of the file while in possession of the user,
> > then a strong password makes sense regardless of the delivery mechanism.
> >
> >
> > I think once the key material is securely delivered to the user, it is
> > no longer under the CA's control and we shouldn't assume that it is.
> > The user might change the passphrase of the PKCS#12 file to whatever,
> > or store the private key without any encryption.
> >
> >
> > Dimitris.
> >
> ___
> 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

As you note, the focus on gmail.com is to entirely miss the point of
paypal.com - and virtually every other organizational identity out there
that wishes to sign their certificates.

Further, even when using 'hosted' mail provisioning, it's possible to use
S/MIME, possibly even with auto-enrollment (and even server-mediated S/MIME
- https://support.google.com/a/answer/6374496?hl=en ).

It's the same distinction between, say, Google AppEngine (in which Google
manages the certs and TLS termination) versus Google Cloud Platform (in
which you could fully terminate TLS in your VM with your own domain).

On Tue, May 15, 2018 at 9:21 PM, Phillip Hallam-Baker via
dev-security-policy  wrote:

> When I wrote CAA, my intention was for it to apply to SSL/TLS certs only.
> I did not consider S/MIME certs to be relevant precisely because of the
> al...@gmail.com problem.
>
> I now realize that was entirely wrong and that there is in fact great
> utility in allowing domain owners to control their domains (or not).
>
> If gmail want to limit the issue of Certs to one CA, fine. That is a
> business choice they have made. If you want to have control of your online
> identity, you need to have your own personal domain. That is why I have
> hallambaker.com. All my mail is forwarded to gmail.com but I control my
> identity and can change mail provider any time I want.
>
> One use case that I see as definitive is to allow paypal to S/MIME sign
> their emails. That alone could take a bite out of phishing.
>
> But even with gmail, the only circumstance I could see where a mail
> service provider like that would want to restrict cert issue to one CA
> would be if they were to roll out S/MIME with their own CA.
> ___
> 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: question about DNS CAA and S/MIME certificates

[Phillip Hallam-Baker via dev-security-policy]

When I wrote CAA, my intention was for it to apply to SSL/TLS certs only. I did 
not consider S/MIME certs to be relevant precisely because of the 
al...@gmail.com problem.

I now realize that was entirely wrong and that there is in fact great utility 
in allowing domain owners to control their domains (or not).

If gmail want to limit the issue of Certs to one CA, fine. That is a business 
choice they have made. If you want to have control of your online identity, you 
need to have your own personal domain. That is why I have hallambaker.com. All 
my mail is forwarded to gmail.com but I control my identity and can change mail 
provider any time I want.

One use case that I see as definitive is to allow paypal to S/MIME sign their 
emails. That alone could take a bite out of phishing. 

But even with gmail, the only circumstance I could see where a mail service 
provider like that would want to restrict cert issue to one CA would be if they 
were to roll out S/MIME with their own CA.
___
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

[Ryan Sleevi via dev-security-policy]

There's a lot of contradictory statements here, so I'm not sure how best to
unpack them.

"I think CAA is and should be HTTPS only" is inconsistent, it seems, with
https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/PZgO5Qe0CQAJ

"There isn't much value to CAA if only a few CAs do it" seems inconsistent
with "another RFC explaining CAA for email" - rough consensus and running
code.

I agree that it's useful to determine what the priorities should be.

CAs' CP/CPS can document today what they do with CAA in S/MIME. CAA, as
written today, absolutely can support email. In an ideal world, CAs would
take the maximally restrictive approach to issuance, recognizing that
domain operators have primacy over their domains compared to any other
entity within their management authority, and that necessarily includes
e-mail.

I do not think it's at odds with the LAMPS charter for 6844-bis, because I
do not think it's at odds with 6844.

That said, this is all largely moot, because CAs have strong incentives to
not do anything with CAA until they're forced to, and to try to make it
someone else's problem as much as possible (passing the buck between CABF,
IETF, and root stores for S/MIME), and in the mean time, site operators
lose because unless and until CAs do something about it, there's no way
they can restrict S/MIME issuance, and thus there's fundamentally
questionable value to S/MIME issuance today. To the extent CAs want to cut
off their nose to spite their face, I suppose that's their prerogative.

The principle at play here, though - that CAA is not an intent to do
exactly what it says, which is restrict the issuance of certificates
bearing that domain (in all forms), is deeply troubling for any future
PKIs, and merely shows the trouble with reliance on third-party CAs in any
new PKIs.

On Tue, May 15, 2018 at 3:42 PM, Tim Hollebeek 
wrote:

> I think CAA is and should be HTTPS only until there are clear rules for
> how it should work for email, and how to keep web CAA from interfering with
> email CAA.  E-mail is currently the wild west and that needs to be fixed.
>
>
>
> I’m strongly in favor of email CAA, once we get it ‘right’.  But there’s
> no document out there that specifies what ‘right’ is yet.  And there isn’t
> much value to CAA if only a few CAs do it.
>
>
>
> That’s why I think we need 8644-bis first.  Or another RFC explaining CAA
> for email.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:r...@sleevi.com]
> *Sent:* Tuesday, May 15, 2018 12:44 PM
> *To:* Tim Hollebeek 
> *Cc:* r...@sleevi.com; Pedro Fuentes ;
> mozilla-dev-security-policy  >
> *Subject:* Re: question about DNS CAA and S/MIME certificates
>
>
>
> Tim,
>
>
>
> Could you clarify then. Are you disagreeing that CAA is HTTPS only? As
> these were your words only 3 hours ago - https://groups.google.com/d/
> msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ
>
>
>
> On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek <
> tim.holleb...@digicert.com> wrote:
>
> Blatantly false.  I actually suspect DigiCert might already support CAA
> for email.  I haven’t double-checked.
>
>
>
> -Tim
>
>
>
> The only reason that "CAA is HTTPS-only" today is because CAs are not
> interested in doing the 'right' thing.
>
>
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

Reminder: there is one week left in the discussion period for this
inclusion request.

On Tue, May 1, 2018 at 12:02 PM Wayne Thayer  wrote:

> This request is for inclusion of the OISTE WISeKey Global Root GC CA as
> documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1403591
>
> * BR Self Assessment is here:
> https://bugzilla.mozilla.org/attachment.cgi?id=8912732
>
> * Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8955363
>
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8912737
>
> CP/CPS:
> https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf
>
> * This request is to turn on the Websites and Email trust bits. EV
> treatment is not requested.
>
> * EV Policy OIDs: Not EV
>
> * Test Websites
> https://gcvalidssl.hightrusted.com/
> https://gcexpiredssl.hightrusted.com/
> https://gcrevokedssl.hightrusted.com/
>
> * CRL URL: http://public.wisekey.com/crl/wcidgcas1.crl
>
> * OCSP URL: http://ocsp.wisekey.com/
>
> * Audit: Annual audits are performed by AUREN according to the WebTrust
> for CA and BR audit criteria.
> WebTrust:
> https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf
> BR:
> https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf
> EV: Not EV
>
> I’ve reviewed the CPS, BR Self Assessment, and related information for the
> OISTE WISeKey Global Root GC CA inclusion request that are being tracked in
> this bug and have the following comments:
>
> ==Good==
> * This root was created in May of 2017 and the intermediate appears to
> have only signed test certs since then.
> * Problem reporting mechanism is clearly labeled as such in the CPS.
>
> ==Meh==
> * The older OISTE WISeKey Global Root GA CA that is in our program has
> issued a few certs containing linting errors (some are false positives for
> OCSP signing certs):
> https://crt.sh/?caid=15102=cablint,zlint,x509lint=2010-01-01
> Two notable concerns are:
> ** Valid wildcard certificate for a public suffix:
> https://crt.sh/?id=76535370=cablint (BR 3.2.2.6 permits this only if
> “the applicant proves its rightful control of the entire Domain Namespace“)
> ** Valid cert containing a non-printable string in the Subject :
> https://crt.sh/?id=308365498=x509lint,ocsp
> * WISeKey was the subject of one misissuance bug for “invalid dnsNames”
> and “CN not in SAN” errors to which they responded promptly:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1391089
> ** They also failed to respond to a problem report during this
> incident.
> Domain validations procedures are listed in an appendix instead of section
> 3.2.2.4 of the CPS and they include the soon-to-be-banned 3.2.2.4.1 and
> 3.2.2.4.5 methods. A note indicates that 3.2.2.4.5 will be discontinued
> after August 1st. The reference to 3.2.2.4.1 appears to be a documentation
> error.
> During my initial review, the CPS was missing CAA information and still
> referenced 3-year validity periods. WISeKey quickly made the needed changes
> but indicated that they update their CPS during an annual review rather
> than regularly as new requirements come into effect.
>
> ==Bad==
> Nothing to report
>
> This begins the 3-week comment period for this request [1].
>
> I will greatly appreciate your thoughtful and constructive feedback on the
> acceptance of this root into the Mozilla CA program.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Application_Process
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

I'm coming to the conclusion that this discussion is about "security
theater"[1]. As long as we allow CAs to generate S/MIME key pairs, there
are gaping holes in the PKCS#12 requirements, the most obvious being that a
CA can just transfer the private key to the user in pem format! Are there
any objections to dropping the PKCS#12 requirements altogether and just
forbidding key generation for TLS certificates as follows?

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

- Wayne

[1] https://en.wikipedia.org/wiki/Security_theater

On Tue, May 15, 2018 at 10:23 AM Dimitris Zacharopoulos 
wrote:

>
>
> On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:
>
> Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is
> distributed via secure channels, how strong does the password need to be?
>
>
>
>
>
> I think this depends on our threat model, which to be fair is not something
> we've defined. If we're only concerned with protecting the delivery of the
> PKCS#12 file to the user, then this makes sense. If we're also concerned
> with protection of the file while in possession of the user, then a strong
> password makes sense regardless of the delivery mechanism.
>
>
> I think once the key material is securely delivered to the user, it is no
> longer under the CA's control and we shouldn't assume that it is. The user
> might change the passphrase of the PKCS#12 file to whatever, or store the
> private key without any encryption.
>
>
> Dimitris.
>
___
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

[Tim Hollebeek via dev-security-policy]

I think CAA is and should be HTTPS only until there are clear rules for how it 
should work for email, and how to keep web CAA from interfering with email CAA. 
 E-mail is currently the wild west and that needs to be fixed.

 

I’m strongly in favor of email CAA, once we get it ‘right’.  But there’s no 
document out there that specifies what ‘right’ is yet.  And there isn’t much 
value to CAA if only a few CAs do it.

 

That’s why I think we need 8644-bis first.  Or another RFC explaining CAA for 
email.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, May 15, 2018 12:44 PM
To: Tim Hollebeek 
Cc: r...@sleevi.com; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

Tim,

 

Could you clarify then. Are you disagreeing that CAA is HTTPS only? As these 
were your words only 3 hours ago - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ

 

On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek  > wrote:

Blatantly false.  I actually suspect DigiCert might already support CAA for 
email.  I haven’t double-checked.

 

-Tim

 

The only reason that "CAA is HTTPS-only" today is because CAs are not 
interested in doing the 'right' thing.

 

 



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

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

The LAMPS re-charter is still open for discussion.  I personally have no 
problem with CAA for email being in scope for 6844-bis.  I’m actually in favor 
of that if it really is currently out of scope (I haven’t checked).  Best to 
ask on the LAMPS charter thread.

 

-Tim

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Tuesday, May 15, 2018 12:41 PM
To: Tim Hollebeek 
Cc: Ryan Sleevi ; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

I don't see how this debate is leading us to a solution. Can we just 
acknowledge that, prior to this discussion, the implications of CAA for the 
issuance of email certificates was not well understood by CAs or domain name 
registrants?

 

I share the desire to have a system that fails closed in the presence of any 
CAA record, but that is a challenge as long as ecosystem participants view CAA 
as applicable only to server certificates. The sooner we address this issue, 
the better.

 

Mozilla policy isn't a great place to define CAA syntax. The CA/Browser Forum 
currently has no jurisdiction over email, so at best could define syntax to 
limit CAA scope to server certificates. The scope of the LAMPS recharter for 
6844bis appears too narrow to include this. What is the best path forward?

 

- Wayne

 

On Tue, May 15, 2018 at 9:29 AM Tim Hollebeek via dev-security-policy 
 > wrote:

Blatantly false.  I actually suspect DigiCert might already support CAA for 
email.  I haven’t double-checked.



-Tim



The only reason that "CAA is HTTPS-only" today is because CAs are not 
interested in doing the 'right' thing.



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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of May 2018 Audit Reminder Emails
Date: Tue, 15 May 2018 19:00:06 + (GMT)


Mozilla: Audit Reminder
Root Certificates:
   GDCA TrustAUTH R5 ROOT**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: https://cert.webtrust.org/SealFile?seal=2231=pdf
Audit Statement Date: 2017-04-14
BR Audit: https://cert.webtrust.org/SealFile?seal=2232=pdf
BR Audit Statement Date: 2017-04-14
EV Audit: https://cert.webtrust.org/SealFile?seal=2233=pdf
EV Audit Statement Date: 2017-04-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   COMODO RSA Certification Authority
   USERTrust ECC Certification Authority
   AAA Certificate Services
   AddTrust Class 1 CA Root
   AddTrust External CA Root
   COMODO Certification Authority
   COMODO ECC Certification Authority
   UTN-USERFirst-Client Authentication and Email
   USERTrust RSA Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2270=pdf
Audit Statement Date: 2017-06-02
BR Audit: https://cert.webtrust.org/SealFile?seal=2274=pdf
BR Audit Statement Date: 2017-06-02
BR Audit:
BR Audit Statement Date:
EV Audit: https://cert.webtrust.org/SealFile?seal=2272=pdf
EV Audit Statement Date: 2017-06-02
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ComSign CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1368471.bmoattachments.org/attachment.cgi?id=8872330

Audit Statement Date: 2017-04-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SecureSign RootCA11
Standard Audit: https://cert.webtrust.org/SealFile?seal=2251=pdf
Audit Statement Date: 2017-05-10
BR Audit: https://bug1369520.bmoattachments.org/attachment.cgi?id=8873589
BR Audit Statement Date: 2017-05-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Entrust Root Certification Authority - EC1
   Entrust Root Certification Authority - G2
   AffirmTrust Commercial
   AffirmTrust Networking
   AffirmTrust Premium
   AffirmTrust Premium ECC
   Entrust Root Certification Authority
   Entrust.net Certification Authority (2048)
Standard Audit: https://cert.webtrust.org/SealFile?seal=2248=pdf
Audit Statement Date: 2017-05-17
Standard Audit: 
https://www.affirmtrust.com/wp-content/uploads/20170114-20170531-AffirmTrust-WebTrust-for-CA.pdf

Audit Statement Date: 2017-06-12
BR Audit: https://cert.webtrust.org/SealFile?seal=2248=pdf
BR Audit Statement Date: 2017-05-17
BR Audit: 
https://www.affirmtrust.com/wp-content/uploads/20170114-20170531-AffirmTrust-SSL-Baseline-Requirements..pdf

BR Audit Statement Date: 2017-06-12
EV Audit: https://cert.webtrust.org/SealFile?seal=2248=pdf
EV Audit Statement Date: 2017-05-17
EV Audit: 
https://www.affirmtrust.com/wp-content/uploads/20170114-20170531-AffirmTrust-WebTrust-for-EV-SSL.pdf

EV Audit Statement Date: 2017-06-12
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Government Root Certification Authority - Taiwan
Standard Audit: https://cert.webtrust.org/SealFile?seal=2252=pdf
Audit Statement Date: 2017-05-24
BR Audit: https://cert.webtrust.org/SealFile?seal=2253=pdf
BR Audit Statement Date: 2017-05-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Trustis Limited - Trustis FPS Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399

Audit Statement Date: 2017-03-01
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399
BR Audit Statement Date: 2017-03-01
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1360184#c10




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

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

[Dimitris Zacharopoulos via dev-security-policy]

On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote:

Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is
distributed via secure channels, how strong does the password need to be?





I think this depends on our threat model, which to be fair is not something
we've defined. If we're only concerned with protecting the delivery of the
PKCS#12 file to the user, then this makes sense. If we're also concerned
with protection of the file while in possession of the user, then a strong
password makes sense regardless of the delivery mechanism.


I think once the key material is securely delivered to the user, it is 
no longer under the CA's control and we shouldn't assume that it is. The 
user might change the passphrase of the PKCS#12 file to whatever, or 
store the private key without any encryption.



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

[Ryan Sleevi via dev-security-policy]

Tim,

Could you clarify then. Are you disagreeing that CAA is HTTPS only? As
these were your words only 3 hours ago -
https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ

On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek 
wrote:

> Blatantly false.  I actually suspect DigiCert might already support CAA
> for email.  I haven’t double-checked.
>
>
>
> -Tim
>
>
>
> The only reason that "CAA is HTTPS-only" today is because CAs are not
> interested in doing the 'right' thing.
>
>
>
___
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

[Matthew Hardeman via dev-security-policy]

I concur with Wayne's position that the discussion up to this point isn't
leading to a solution.

I represent nothing further than that I'm a systems and DNS administrator
and domain holder (and thus, I submit, an interested and not entirely
uninformed ecosystem participant) who has had an understanding historically
(whether or not correct) that CAA pertained to server certificates.

On Tue, May 15, 2018 at 11:40 AM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I don't see how this debate is leading us to a solution. Can we just
> acknowledge that, prior to this discussion, the implications of CAA for the
> issuance of email certificates was not well understood by CAs or domain
> name registrants?
>
> I share the desire to have a system that fails closed in the presence of
> any CAA record, but that is a challenge as long as ecosystem participants
> view CAA as applicable only to server certificates. The sooner we address
> this issue, the better.
>
> Mozilla policy isn't a great place to define CAA syntax. The CA/Browser
> Forum currently has no jurisdiction over email, so at best could define
> syntax to limit CAA scope to server certificates. The scope of the LAMPS
> recharter for 6844bis appears too narrow to include this. What is the best
> path forward?
>
> - Wayne
>
> On Tue, May 15, 2018 at 9:29 AM Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Blatantly false.  I actually suspect DigiCert might already support CAA
> > for email.  I haven’t double-checked.
> >
> >
> >
> > -Tim
> >
> >
> >
> > The only reason that "CAA is HTTPS-only" today is because CAs are not
> > interested in doing the 'right' thing.
> >
> >
> ___
> 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: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

On Tue, May 15, 2018 at 12:25 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Nobody bothered with deploying CAA records until the run-up to eventual
> enforcement for issuance of server certificates.
>

This is also factually untrue. You can't just make up stories here to
support your argument. Unless the argument is that "Nobody bothered with
deploying CAA records until CAA existed", by presuming that the 'run-up'
was from existence to requirement, in which case, that's a tautologically
true statement being used to try to misrepresent and mislead. Which is,
itself, problematic.


> It was the incentive of having control over who would be permitted to issue
> server certificates that inspired those who have done so to deploy CAA
> records.
>

Similarly, this continues to present opinion as fact.


>
> It is, in practical terms, revisionist to change the impact of those extant
> deployments.
>
> On Tue, May 15, 2018 at 11:14 AM, Ryan Sleevi  wrote:
>
> > Disingenuous seems like an unreasonable stretch.
> >
> > By the logic expressed here, applying CAA enforcement to HTTPS was
> > applying CAA "after the fact" - after all, until CAs were required to
> > enforce CAA, how do we know that domains (... such as google.com or
> > opera.com) meant to restrict server certificate issuance? Couldn't they
> > have been (in this poor stretch of logic) trying to restrict issuance of
> > S/MIME certificates instead?
> >
> > That's why the argument makes no sense.
> >
> > As to rfc822 names not being mapped onto DNS, that's just definitionally
> > inaccurate. RFC822 names include a domain component. The addr-spec is
> > local-part "@" domain. With domain being the routable definition that we
> > all know and love. You can't just pretend that's not part of the scoping
> or
> > authority here.
> >
> >
> > On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via
> dev-security-policy
> >  wrote:
> >
> >> It is disingenuous to apply CAA to S/MIME and other certificate purposes
> >> after the fact.
> >>
> >> As a domain holder myself, having implemented CAA in certain domains, I
> >> did
> >> intent to restrict issuance of server certificates.  I have never
> intended
> >> this to be a restriction of S/MIME certificate issuance.  The name
> spaces
> >> are different for email addresses versus DNS names.  CAA aligns cleanly
> to
> >> DNS names.  It does not align cleanly to rfc822 names.
> >>
> >> Mr. Sleevi's complaints regarding fail-open security are reasonable.
> >> However, they seem misplaced within the scope of CAA, which at the most
> >> basic level is a fail-open mechanism: lack of a CAA record assumes all
> >> issuance allowed.
> >>
> >> Reinterpreting the scope of extant CAA records might well have a
> chilling
> >> effect on further adoption of CAA.
> >>
> >> When an expressed intent such as CAA has (by definition OR by real-world
> >> effect) a limited scope, many participants will not appreciate that
> scope
> >> being expanded.
> >>
> >> I believe the "issue" and "issuewild" tags should be regarded as
> >> pertaining
> >> only to certificates which either 1) lack any EKU OR 2) include either
> >> anyPurpose EKU or serverAuth EKUs.
> >>
> >>
> >>
> >> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> >
> >> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> >> wrote:
> >> > >
> >> > > For that matter, can whoever is in charge of gmail.com <
> >> > http://gmail.com/> speak to their intent as to CAA for S/MIME?
> >> > >
> >> > > I've certainly held certificates which include my personal gmail
> >> address
> >> > before.  At no point did I need or seek Google's blessing to do so.  I
> >> can
> >> > not imagine that was an uncommon case.  (At least, not uncommon
> >> relative to
> >> > the universe of issued S/MIME certificates.)
> >> >
> >> > Well, I don’t see a CAA record for gmail.com ,
> thus
> >> > even if CAA issue tags were reinterpreted, as suggested, to cover
> >> S/MIME,
> >> > such issuance would not be prohibited (unlike, say, google.com <
> >> > http://google.com/>, which does have a CAA record).
> >> >
> >> > In other words, those certificates that you were issued hitherto could
> >> not
> >> > have violated CAA policy, since there was no such expression of
> policy.
> >> >
> >> > Regards,
> >> >
> >> > Neil
> >> > ___
> >> > 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: question about DNS CAA and S/MIME certificates

[Wayne Thayer via dev-security-policy]

I don't see how this debate is leading us to a solution. Can we just
acknowledge that, prior to this discussion, the implications of CAA for the
issuance of email certificates was not well understood by CAs or domain
name registrants?

I share the desire to have a system that fails closed in the presence of
any CAA record, but that is a challenge as long as ecosystem participants
view CAA as applicable only to server certificates. The sooner we address
this issue, the better.

Mozilla policy isn't a great place to define CAA syntax. The CA/Browser
Forum currently has no jurisdiction over email, so at best could define
syntax to limit CAA scope to server certificates. The scope of the LAMPS
recharter for 6844bis appears too narrow to include this. What is the best
path forward?

- Wayne

On Tue, May 15, 2018 at 9:29 AM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Blatantly false.  I actually suspect DigiCert might already support CAA
> for email.  I haven’t double-checked.
>
>
>
> -Tim
>
>
>
> The only reason that "CAA is HTTPS-only" today is because CAs are not
> interested in doing the 'right' thing.
>
>
___
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

[Ryan Sleevi via dev-security-policy]

That's shifting the goalposts in order to argue against a strawman.

The minimum necessary for CAA for email is to restrict the domain access.

Might some people desire more feature-rich syntax? Perhaps. Is that a
necessary requirement? No.

On Tue, May 15, 2018 at 12:22 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> They certainly do share a common namespace.  The trouble is that the email
> address has more than just that common namespace.
>
> If CAA is proposed for email certificates, I should be able to define a CAA
> policy that prevents any CA from issuing for
> particular.maligned.user.undeserving.of.email.secur...@mydomain.com while
> allowing the following CAs to issue for any email address over the same
> domain.
>
> On Tue, May 15, 2018 at 11:15 AM, Ryan Sleevi  wrote:
>
> > Both types share a common namespace. The domain name space.
> >
> > On Tue, May 15, 2018 at 12:10 PM, Matthew Hardeman via
> dev-security-policy
> >  wrote:
> >
> >> Agreed.  My point was to query the position of the administration of a
> >> large generic email service as to their understanding of the
> implications
> >> of CAA on their domains.
> >>
> >> Certificates have different types of SANs for good cause: the nuances of
> >> the name space differ.
> >>
> >> For example, SAN rfc822Names versus SAN dnsNames.  The X.509 certificate
> >> distinguishes these names as belonging to separate name spaces.  CAA
> does
> >> not presently have this concept.  Yet the proposal here would have us
> >> relying upon the more simplistic DNS names expressed in CAA records.
> >>
> >> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> >
> >> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> >> wrote:
> >> > >
> >> > > For that matter, can whoever is in charge of gmail.com <
> >> > http://gmail.com/> speak to their intent as to CAA for S/MIME?
> >> > >
> >> > > I've certainly held certificates which include my personal gmail
> >> address
> >> > before.  At no point did I need or seek Google's blessing to do so.  I
> >> can
> >> > not imagine that was an uncommon case.  (At least, not uncommon
> >> relative to
> >> > the universe of issued S/MIME certificates.)
> >> >
> >> > Well, I don’t see a CAA record for gmail.com ,
> thus
> >> > even if CAA issue tags were reinterpreted, as suggested, to cover
> >> S/MIME,
> >> > such issuance would not be prohibited (unlike, say, google.com <
> >> > http://google.com/>, which does have a CAA record).
> >> >
> >> > In other words, those certificates that you were issued hitherto could
> >> not
> >> > have violated CAA policy, since there was no such expression of
> policy.
> >> >
> >> > Regards,
> >> >
> >> > Neil
> >> > ___
> >> > dev-security-policy mailing list
> >> > dev-security-policy@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-security-policy
> >> >
> >> ___
> >> dev-security-policy mailing list
> >> dev-security-policy@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-security-policy
> >>
> >
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
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

[Tim Hollebeek via dev-security-policy]

Blatantly false.  I actually suspect DigiCert might already support CAA for 
email.  I haven’t double-checked.

 

-Tim

 

The only reason that "CAA is HTTPS-only" today is because CAs are not 
interested in doing the 'right' thing.

 



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

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

Nobody bothered with deploying CAA records until the run-up to eventual
enforcement for issuance of server certificates.

It was the incentive of having control over who would be permitted to issue
server certificates that inspired those who have done so to deploy CAA
records.

It is, in practical terms, revisionist to change the impact of those extant
deployments.

On Tue, May 15, 2018 at 11:14 AM, Ryan Sleevi  wrote:

> Disingenuous seems like an unreasonable stretch.
>
> By the logic expressed here, applying CAA enforcement to HTTPS was
> applying CAA "after the fact" - after all, until CAs were required to
> enforce CAA, how do we know that domains (... such as google.com or
> opera.com) meant to restrict server certificate issuance? Couldn't they
> have been (in this poor stretch of logic) trying to restrict issuance of
> S/MIME certificates instead?
>
> That's why the argument makes no sense.
>
> As to rfc822 names not being mapped onto DNS, that's just definitionally
> inaccurate. RFC822 names include a domain component. The addr-spec is
> local-part "@" domain. With domain being the routable definition that we
> all know and love. You can't just pretend that's not part of the scoping or
> authority here.
>
>
> On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy
>  wrote:
>
>> It is disingenuous to apply CAA to S/MIME and other certificate purposes
>> after the fact.
>>
>> As a domain holder myself, having implemented CAA in certain domains, I
>> did
>> intent to restrict issuance of server certificates.  I have never intended
>> this to be a restriction of S/MIME certificate issuance.  The name spaces
>> are different for email addresses versus DNS names.  CAA aligns cleanly to
>> DNS names.  It does not align cleanly to rfc822 names.
>>
>> Mr. Sleevi's complaints regarding fail-open security are reasonable.
>> However, they seem misplaced within the scope of CAA, which at the most
>> basic level is a fail-open mechanism: lack of a CAA record assumes all
>> issuance allowed.
>>
>> Reinterpreting the scope of extant CAA records might well have a chilling
>> effect on further adoption of CAA.
>>
>> When an expressed intent such as CAA has (by definition OR by real-world
>> effect) a limited scope, many participants will not appreciate that scope
>> being expanded.
>>
>> I believe the "issue" and "issuewild" tags should be regarded as
>> pertaining
>> only to certificates which either 1) lack any EKU OR 2) include either
>> anyPurpose EKU or serverAuth EKUs.
>>
>>
>>
>> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> >
>> > > On 15 May 2018, at 07:59, Matthew Hardeman 
>> wrote:
>> > >
>> > > For that matter, can whoever is in charge of gmail.com <
>> > http://gmail.com/> speak to their intent as to CAA for S/MIME?
>> > >
>> > > I've certainly held certificates which include my personal gmail
>> address
>> > before.  At no point did I need or seek Google's blessing to do so.  I
>> can
>> > not imagine that was an uncommon case.  (At least, not uncommon
>> relative to
>> > the universe of issued S/MIME certificates.)
>> >
>> > Well, I don’t see a CAA record for gmail.com , thus
>> > even if CAA issue tags were reinterpreted, as suggested, to cover
>> S/MIME,
>> > such issuance would not be prohibited (unlike, say, google.com <
>> > http://google.com/>, which does have a CAA record).
>> >
>> > In other words, those certificates that you were issued hitherto could
>> not
>> > have violated CAA policy, since there was no such expression of policy.
>> >
>> > Regards,
>> >
>> > Neil
>> > ___
>> > dev-security-policy mailing list
>> > dev-security-policy@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

They certainly do share a common namespace.  The trouble is that the email
address has more than just that common namespace.

If CAA is proposed for email certificates, I should be able to define a CAA
policy that prevents any CA from issuing for
particular.maligned.user.undeserving.of.email.secur...@mydomain.com while
allowing the following CAs to issue for any email address over the same
domain.

On Tue, May 15, 2018 at 11:15 AM, Ryan Sleevi  wrote:

> Both types share a common namespace. The domain name space.
>
> On Tue, May 15, 2018 at 12:10 PM, Matthew Hardeman via dev-security-policy
>  wrote:
>
>> Agreed.  My point was to query the position of the administration of a
>> large generic email service as to their understanding of the implications
>> of CAA on their domains.
>>
>> Certificates have different types of SANs for good cause: the nuances of
>> the name space differ.
>>
>> For example, SAN rfc822Names versus SAN dnsNames.  The X.509 certificate
>> distinguishes these names as belonging to separate name spaces.  CAA does
>> not presently have this concept.  Yet the proposal here would have us
>> relying upon the more simplistic DNS names expressed in CAA records.
>>
>> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> >
>> > > On 15 May 2018, at 07:59, Matthew Hardeman 
>> wrote:
>> > >
>> > > For that matter, can whoever is in charge of gmail.com <
>> > http://gmail.com/> speak to their intent as to CAA for S/MIME?
>> > >
>> > > I've certainly held certificates which include my personal gmail
>> address
>> > before.  At no point did I need or seek Google's blessing to do so.  I
>> can
>> > not imagine that was an uncommon case.  (At least, not uncommon
>> relative to
>> > the universe of issued S/MIME certificates.)
>> >
>> > Well, I don’t see a CAA record for gmail.com , thus
>> > even if CAA issue tags were reinterpreted, as suggested, to cover
>> S/MIME,
>> > such issuance would not be prohibited (unlike, say, google.com <
>> > http://google.com/>, which does have a CAA record).
>> >
>> > In other words, those certificates that you were issued hitherto could
>> not
>> > have violated CAA policy, since there was no such expression of policy.
>> >
>> > Regards,
>> >
>> > Neil
>> > ___
>> > dev-security-policy mailing list
>> > dev-security-policy@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

Both types share a common namespace. The domain name space.

On Tue, May 15, 2018 at 12:10 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Agreed.  My point was to query the position of the administration of a
> large generic email service as to their understanding of the implications
> of CAA on their domains.
>
> Certificates have different types of SANs for good cause: the nuances of
> the name space differ.
>
> For example, SAN rfc822Names versus SAN dnsNames.  The X.509 certificate
> distinguishes these names as belonging to separate name spaces.  CAA does
> not presently have this concept.  Yet the proposal here would have us
> relying upon the more simplistic DNS names expressed in CAA records.
>
> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> wrote:
> > >
> > > For that matter, can whoever is in charge of gmail.com <
> > http://gmail.com/> speak to their intent as to CAA for S/MIME?
> > >
> > > I've certainly held certificates which include my personal gmail
> address
> > before.  At no point did I need or seek Google's blessing to do so.  I
> can
> > not imagine that was an uncommon case.  (At least, not uncommon relative
> to
> > the universe of issued S/MIME certificates.)
> >
> > Well, I don’t see a CAA record for gmail.com , thus
> > even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> > such issuance would not be prohibited (unlike, say, google.com <
> > http://google.com/>, which does have a CAA record).
> >
> > In other words, those certificates that you were issued hitherto could
> not
> > have violated CAA policy, since there was no such expression of policy.
> >
> > Regards,
> >
> > Neil
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

Disingenuous seems like an unreasonable stretch.

By the logic expressed here, applying CAA enforcement to HTTPS was applying
CAA "after the fact" - after all, until CAs were required to enforce CAA,
how do we know that domains (... such as google.com or opera.com) meant to
restrict server certificate issuance? Couldn't they have been (in this poor
stretch of logic) trying to restrict issuance of S/MIME certificates
instead?

That's why the argument makes no sense.

As to rfc822 names not being mapped onto DNS, that's just definitionally
inaccurate. RFC822 names include a domain component. The addr-spec is
local-part "@" domain. With domain being the routable definition that we
all know and love. You can't just pretend that's not part of the scoping or
authority here.

On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It is disingenuous to apply CAA to S/MIME and other certificate purposes
> after the fact.
>
> As a domain holder myself, having implemented CAA in certain domains, I did
> intent to restrict issuance of server certificates.  I have never intended
> this to be a restriction of S/MIME certificate issuance.  The name spaces
> are different for email addresses versus DNS names.  CAA aligns cleanly to
> DNS names.  It does not align cleanly to rfc822 names.
>
> Mr. Sleevi's complaints regarding fail-open security are reasonable.
> However, they seem misplaced within the scope of CAA, which at the most
> basic level is a fail-open mechanism: lack of a CAA record assumes all
> issuance allowed.
>
> Reinterpreting the scope of extant CAA records might well have a chilling
> effect on further adoption of CAA.
>
> When an expressed intent such as CAA has (by definition OR by real-world
> effect) a limited scope, many participants will not appreciate that scope
> being expanded.
>
> I believe the "issue" and "issuewild" tags should be regarded as pertaining
> only to certificates which either 1) lack any EKU OR 2) include either
> anyPurpose EKU or serverAuth EKUs.
>
>
>
> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> wrote:
> > >
> > > For that matter, can whoever is in charge of gmail.com <
> > http://gmail.com/> speak to their intent as to CAA for S/MIME?
> > >
> > > I've certainly held certificates which include my personal gmail
> address
> > before.  At no point did I need or seek Google's blessing to do so.  I
> can
> > not imagine that was an uncommon case.  (At least, not uncommon relative
> to
> > the universe of issued S/MIME certificates.)
> >
> > Well, I don’t see a CAA record for gmail.com , thus
> > even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> > such issuance would not be prohibited (unlike, say, google.com <
> > http://google.com/>, which does have a CAA record).
> >
> > In other words, those certificates that you were issued hitherto could
> not
> > have violated CAA policy, since there was no such expression of policy.
> >
> > Regards,
> >
> > Neil
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

Agreed.  My point was to query the position of the administration of a
large generic email service as to their understanding of the implications
of CAA on their domains.

Certificates have different types of SANs for good cause: the nuances of
the name space differ.

For example, SAN rfc822Names versus SAN dnsNames.  The X.509 certificate
distinguishes these names as belonging to separate name spaces.  CAA does
not presently have this concept.  Yet the proposal here would have us
relying upon the more simplistic DNS names expressed in CAA records.

On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On 15 May 2018, at 07:59, Matthew Hardeman  wrote:
> >
> > For that matter, can whoever is in charge of gmail.com <
> http://gmail.com/> speak to their intent as to CAA for S/MIME?
> >
> > I've certainly held certificates which include my personal gmail address
> before.  At no point did I need or seek Google's blessing to do so.  I can
> not imagine that was an uncommon case.  (At least, not uncommon relative to
> the universe of issued S/MIME certificates.)
>
> Well, I don’t see a CAA record for gmail.com , thus
> even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> such issuance would not be prohibited (unlike, say, google.com <
> http://google.com/>, which does have a CAA record).
>
> In other words, those certificates that you were issued hitherto could not
> have violated CAA policy, since there was no such expression of policy.
>
> Regards,
>
> Neil
> ___
> 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: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

It is disingenuous to apply CAA to S/MIME and other certificate purposes
after the fact.

As a domain holder myself, having implemented CAA in certain domains, I did
intent to restrict issuance of server certificates.  I have never intended
this to be a restriction of S/MIME certificate issuance.  The name spaces
are different for email addresses versus DNS names.  CAA aligns cleanly to
DNS names.  It does not align cleanly to rfc822 names.

Mr. Sleevi's complaints regarding fail-open security are reasonable.
However, they seem misplaced within the scope of CAA, which at the most
basic level is a fail-open mechanism: lack of a CAA record assumes all
issuance allowed.

Reinterpreting the scope of extant CAA records might well have a chilling
effect on further adoption of CAA.

When an expressed intent such as CAA has (by definition OR by real-world
effect) a limited scope, many participants will not appreciate that scope
being expanded.

I believe the "issue" and "issuewild" tags should be regarded as pertaining
only to certificates which either 1) lack any EKU OR 2) include either
anyPurpose EKU or serverAuth EKUs.



On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On 15 May 2018, at 07:59, Matthew Hardeman  wrote:
> >
> > For that matter, can whoever is in charge of gmail.com <
> http://gmail.com/> speak to their intent as to CAA for S/MIME?
> >
> > I've certainly held certificates which include my personal gmail address
> before.  At no point did I need or seek Google's blessing to do so.  I can
> not imagine that was an uncommon case.  (At least, not uncommon relative to
> the universe of issued S/MIME certificates.)
>
> Well, I don’t see a CAA record for gmail.com , thus
> even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> such issuance would not be prohibited (unlike, say, google.com <
> http://google.com/>, which does have a CAA record).
>
> In other words, those certificates that you were issued hitherto could not
> have violated CAA policy, since there was no such expression of policy.
>
> Regards,
>
> Neil
> ___
> 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: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> On 15 May 2018, at 07:59, Matthew Hardeman  wrote:
> 
> For that matter, can whoever is in charge of gmail.com  
> speak to their intent as to CAA for S/MIME?
> 
> I've certainly held certificates which include my personal gmail address 
> before.  At no point did I need or seek Google's blessing to do so.  I can 
> not imagine that was an uncommon case.  (At least, not uncommon relative to 
> the universe of issued S/MIME certificates.)

Well, I don’t see a CAA record for gmail.com , thus even if 
CAA issue tags were reinterpreted, as suggested, to cover S/MIME, such issuance 
would not be prohibited (unlike, say, google.com , which 
does have a CAA record).

In other words, those certificates that you were issued hitherto could not have 
violated CAA policy, since there was no such expression of policy.

Regards,

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

[Ryan Sleevi via dev-security-policy]

On Tue, May 15, 2018 at 11:02 AM, Jürgen Brauckmann via dev-security-policy
 wrote:

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


Sure they do. A CA that wished to do the right thing could define a syntax
in the CA/Browser Forum that all issuers are supposed to understand, such
as "scope=https" or even 'ekus=[foo,bar,baz]'

Absent a scope issuer parameter, then it's presumed to be global scope.
Present a scope parameter, it's syntax is defined.

That's an application of policy - what to do when CAA restrictions exist -
and that can be 'easily' defined.

There is, of course, the route of adding new flags or properties, both with
spec-required registries, but a security-positive CA can and should be
exploring ways to issue scoped restrictions (e.g. could introduce an
'issueserverauth')


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

Sure, and in the absence of a force that actually ensures CAs respect
domain holders, we know there's not going to be any 'naive' adoption - that
is, it's clear that unless and until Root Stores require it, CAs won't
adopt it.


>
> This is all about responsible change.
>

CAA was introduced in the BRs because, despite 5 years of discussion, CAs
were opposed to it, because it would restrict what they could issue. The
same story is now playing out, with the same set of overwrought concerns.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

On Tue, May 15, 2018 at 7:51 AM Doug Beattie 
wrote:

> Wayne,
>
>
>
> This going to require 19 randomly generated Base64 characters and that
> does not include removing common confused characters which will drive up
> the length a bit more, but if this is what the Mozilla risk assessment came
> up with, then we’ll all have to comply.
>
>
As discussed earlier in this thread, 112 bits of entropy is not something
we just made up. It's grounded in guidance from NIST and other industry
bodies.
>

>   I hope there is a sufficiently long time for CAs to change their
> processes and APIs and to roll out updated training and documentation to
> their customers (for this unplanned change).
>
>
>
>
I'll propose January 1, 2019 as the effective date.
>

> Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is
> distributed via secure channels, how strong does the password need to be?
>
>
>
>
I think this depends on our threat model, which to be fair is not something
we've defined. If we're only concerned with protecting the delivery of the
PKCS#12 file to the user, then this makes sense. If we're also concerned
with protection of the file while in possession of the user, then a strong
password makes sense regardless of the delivery mechanism.
>

> Doug
>
>
>
>
>
>
>
> *From:* Wayne Thayer [mailto:wtha...@mozilla.com]
> *Sent:* Monday, May 14, 2018 4:54 PM
> *To:* Doug Beattie ;
> mozilla-dev-security-policy  >
> *Subject:* Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on
> CA key generation to policy)
>
>
>
> On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>
> I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
> Dean???
> - We can’t permit user generated passwords (at least that is Tim's
> proposal, Wayne may not agree yet but he will when he reads this email)
> - We can’t distribute both the password and PKCS#12 over the same channel,
> even if it's a secure channel like HTTPS
>
> We have 2 choices for where the password is generated: CA or User
>
> >
>
> Or the user could generate the key :-)
>
> >
>
> 1) If we require CAs to generate the passwords and they can’t distribute
> the necessary information to the end user via the portal over TLS (because
> of the dual channel requirement), then that is a relatively large impact on
> us, and probably anyone else that supports PKCS#12 file formats.  If the
> channel is secure, do you need to use different channels?
>
>
> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20
> character password will have just 48 bits of entropy, and characters after
> that only add 1 bite of entropy each.  User stink at generating Entropy
> (right Tim?)
>
> NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
> following scheme to roughly estimate the entropy of human-generated
> passwords (Subsequent updates of this publication gave up trying to compute
> entropy for user generated passwords, and when they talk about entropy they
> talk about 20 bits max):
> •   The entropy of the first character is four bits;
> •   The entropy of the next seven characters are two bits per
> character;
> •   The ninth through the twentieth character has 1.5 bits of entropy
> per character;
> •   Characters 21 and above have one bit of entropy per character.
> •   A "bonus" of six bits is added if both upper case letters and
> non-alphabetic characters are used.
> •   A "bonus" of six bits is added for passwords of length 1 through
> 19 characters following an extensive dictionary check to ensure the
> password is not contained within a large dictionary. Passwords of 20
> characters or more do not receive this bonus because it is assumed they are
> pass-phrases consisting of multiple dictionary words.
>
> https://pages.nist.gov/800-63-3/
>
> Some CAs are probably asking the user for a password during the request
> thus there is no need to distribute it later.  But, if the Applicant
> provides the password over HTTPS and then later the CA provides the PKCS#12
> via download link and they obtain it via HTTPS, is that a single channel
> that they were both distributed over?
>
> I still object to not being able to use HTTPS for collection and/or
> distribution of the Password and the PKCS#12.  I also believe 112 bits of
> entropy is way too much for user generated password (assuming we want to
> continue supporting that option).
>
> Perhaps the following language is a workable solution to the first
> objection?
>
>
>
> PKCS#12 files must employ an encryption key and algorithm that is
> sufficiently strong to protect the key pair for its useful life based on
> current guidelines published by a recognized standards body. PKCS#12 files
> MUST be 

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: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

For that matter, can whoever is in charge of gmail.com speak to their
intent as to CAA for S/MIME?

I've certainly held certificates which include my personal gmail address
before.  At no point did I need or seek Google's blessing to do so.  I can
not imagine that was an uncommon case.  (At least, not uncommon relative to
the universe of issued S/MIME certificates.)

On Mon, May 14, 2018 at 11:13 PM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >  If there are proponents of a 'fail open' model,
> > especially amongst CAs, then does it behove them to specify as quickly as
> > possible a 'fail closed' model, so that we don't have to try and divine
> > intent and second guess site operators as to whether they meant to
> restrict
> > HTTPS or everything?
>
> While this is in no way comprehensive or scientific, could we not just
> poll those (larger) domain owners who also operate publicly available mail
> services (like Yahoo) what they consider the scope of their CAA assertions?
> There can’t be a super abundance of them, surely?
>
> I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of
> ninja-changing semantics either. If domain owners intended to only express
> a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS
> or whatever); then might they not be amenable to altering their expression
> to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the
> scope of their (in-)actions?
>
> That would then enable a future move for CAs to respect ‘issue’ and
> ‘issuewild’ to cover all cert types, while still allowing domain owners
> finer grained expression of their policies. It’s pretty much an entire
> reversal of my earlier suggestion(!), but perhaps a modification which
> would preserve the expressions of (handwave, handwave) 95% of CAA records
> owners who don’t operate public mail services, and yet still can cover
> those mail providers?
>
> But without the courtesy of at least asking those few domain owners what
> they meant, it just seems a bit rude to assume their intentions.
>
> Regards,
>
> Neil
> ___
> 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: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

Tim,

I hope you can see how this sort of response doesn't really do much to
engender faith and trust in CAs. I am not sure if you're aware of how this
can be perceived, but I suspect if you were, it might not have been so
glibly dismissed.

The only reason that "CAA is HTTPS-only" today is because CAs are not
interested in doing the 'right' thing. That is, to actually treat the CAA
as part of an integrated system of domain validation. The only reason we
even have HTTPS today is because browsers - notably Mozilla taking the lead
- required that CAs check CAA for HTTPS as a condition for remaining
trusted.

It appears that you're stating that unless a CA is forced to do something,
they have no incentive to actually adopt it. Rather than help establish
what secure norms are - that is, treat CAA is exactly what it tries to be
(a restriction on what CAs can issue) - it seems that you're arguing "As
long as everyone else can do bad, we have no reason to be better."

CAA has been finalized for 6 years (modulo the delay in editorial
formatting), and as a concept, goes back 8 years. Every step along the way,
a number of CAs opposed to, because they were concerned they wouldn't be
able to issue certs. Now we're hearing the same argument.

I hope you can do better than that, and that this sort of response doesn't
sully what remaining good will that DigiCert has. Consider how you could,
as a CA, more productively contribute to the discussion:

From a purely informational standpoint:
1) Check CAA during the issuance of S/MIME certificates, and share details
about how many S/MIME certificates would fail the CAA check
2) Require CAA checks to succeed for S/MIME by default. If they fail,
require the customer/applicant give details about why the failure

From an actually lead in security, rather than hide in a crowd of bad
actors:
3) Require CAA checks to succeed for S/MIME. Require the domain holder to
demonstrate explicit intent to allow DigiCert S/MIME issuance (for example,
adding a parameter to their issue records)

There are ways in which DigiCert is uniquely capable of showing technical
leadership and contributing to the discussion. Glib replies like this do
not do that, and only further cement the "CAs are shady" idea that further
erodes trust in PKIs, particularly S/MIME.

On Tue, May 15, 2018 at 9:11 AM, Tim Hollebeek 
wrote:

> CAA is HTTPS only today.  That’s the reality.
>
>
>
> I don’t have to want to argue in favor of reality.  Reality wins
> regardless of what I do.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:r...@sleevi.com]
> *Sent:* Monday, May 14, 2018 11:55 PM
>
> *To:* Tim Hollebeek 
> *Cc:* r...@sleevi.com; Pedro Fuentes ;
> mozilla-dev-security-policy  >
> *Subject:* Re: question about DNS CAA and S/MIME certificates
>
>
>
> I'm not sure how that's advancing the discussion forward or adding new
> information. The discussion of CAA and wanting to get feedback predates
> even the IETF finalization, as multiple browsers kept encouraging CAs to
> experiment with and attempt to deploy CAA so that we could make sure the
> kinks were ironed out.
>
>
>
> Regardless of posturing and grandstanding for past statements, can we at
> least agree that a model that argues "fail open" as a solution is a
> fundamentally insecure one? If there are proponents of a 'fail open' model,
> especially amongst CAs, then does it behove them to specify as quickly as
> possible a 'fail closed' model, so that we don't have to try and divine
> intent and second guess site operators as to whether they meant to restrict
> HTTPS or everything?
>
>
>
> Put differently, if you want to argue that CAA is HTTPS only, then you
> need to define a way to ensure it's not HTTPS-only, and ASAP. Otherwise,
> the solution is that when S/MIME BRs come around, we simply cannot and
> should not second guess site operators and try to argue CAA was only
> 'those' type of certs - and instead require anyone with a CAA record to
> explicitly opt-in to allowing (potentially unbounded) S/MIME. I don't see
> any other realistic or practical solution - you can't say "This protects
> you" and then propose 2 years down the road, with S/MIME BRs, that it
> didn't actually 'protect' the site operator - the same way you can't say
> "Restrict access to these five email addresses" and then introduce a dozen
> more 2 years down the road.
>
>
>
> On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Normally I’d agree that IETF cannot and should not be a blocker for action
> at Mozilla and/or CABF, but based on our experience with CAA for web
> certificates, I would encourage people to get in their time machines and go
> back two to three years, and listen to Tim standing up and saying “I like
> CAA for the Web PKI, but what have we not thought of?”
>
>
>
> -Tim
>
>

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

[Doug Beattie via dev-security-policy]

Wayne,

This going to require 19 randomly generated Base64 characters and that does not 
include removing common confused characters which will drive up the length a 
bit more, but if this is what the Mozilla risk assessment came up with, then 
we’ll all have to comply.  I hope there is a sufficiently long time for CAs to 
change their processes and APIs and to roll out updated training and 
documentation to their customers (for this unplanned change).

Did you consider any changes based on Jakob’s comments?  If the PKCS#12 is 
distributed via secure channels, how strong does the password need to be?

Doug



From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Monday, May 14, 2018 4:54 PM
To: Doug Beattie ; mozilla-dev-security-policy 

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

On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy 
>
 wrote:

I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean???
- We can’t permit user generated passwords (at least that is Tim's proposal, 
Wayne may not agree yet but he will when he reads this email)
- We can’t distribute both the password and PKCS#12 over the same channel, even 
if it's a secure channel like HTTPS

We have 2 choices for where the password is generated: CA or User
>
Or the user could generate the key :-)
>
1) If we require CAs to generate the passwords and they can’t distribute the 
necessary information to the end user via the portal over TLS (because of the 
dual channel requirement), then that is a relatively large impact on us, and 
probably anyone else that supports PKCS#12 file formats.  If the channel is 
secure, do you need to use different channels?


2) Trying to compute the entropy of a user generated password is  nearly 
impossible.  According to NIST Special Publication 800-63, a good 20 character 
password will have just 48 bits of entropy, and characters after that only add 
1 bite of entropy each.  User stink at generating Entropy (right Tim?)

NIST Special Publication 800-63 of June 2004 (revision 2) suggested the 
following scheme to roughly estimate the entropy of human-generated passwords 
(Subsequent updates of this publication gave up trying to compute entropy for 
user generated passwords, and when they talk about entropy they talk about 20 
bits max):
•   The entropy of the first character is four bits;
•   The entropy of the next seven characters are two bits per character;
•   The ninth through the twentieth character has 1.5 bits of entropy per 
character;
•   Characters 21 and above have one bit of entropy per character.
•   A "bonus" of six bits is added if both upper case letters and 
non-alphabetic characters are used.
•   A "bonus" of six bits is added for passwords of length 1 through 19 
characters following an extensive dictionary check to ensure the password is 
not contained within a large dictionary. Passwords of 20 characters or more do 
not receive this bonus because it is assumed they are pass-phrases consisting 
of multiple dictionary words.

https://pages.nist.gov/800-63-3/

Some CAs are probably asking the user for a password during the request thus 
there is no need to distribute it later.  But, if the Applicant provides the 
password over HTTPS and then later the CA provides the PKCS#12 via download 
link and they obtain it via HTTPS, is that a single channel that they were both 
distributed over?

I still object to not being able to use HTTPS for collection and/or 
distribution of the Password and the PKCS#12.  I also believe 112 bits of 
entropy is way too much for user generated password (assuming we want to 
continue supporting that option).
Perhaps the following language is a workable solution to the first objection?

PKCS#12 files must employ an encryption key and algorithm that is sufficiently 
strong to protect the key pair for its useful life based on current guidelines 
published by a recognized standards body. PKCS#12 files MUST be encrypted and 
signed; or, MUST have a password that exhibits at least 112 bits of entropy, 
and the password MUST be transmitted via a secure channel.

I really don't seem a benefit to user generation of these passwords - either 
they are weak and memorable, or sufficiently complicated that there's little 
value in being able to choose it.

Doug

___
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

[Neil Dunbar via dev-security-policy]

> On 15 May 2018, at 05:56, Ryan Sleevi  wrote:
> 
> No. I am expressly opposed to any solution that is “ask the big guys and let 
> them decide what it means for the Internet”.
> 
> While I can’t speak for Mozilla, that definitely seems against the spirit of 
> Mozilla’s principles of open and equal access.
> 
> It has a recasting failure mode as well, in that anyone who isn’t aware of 
> the subtlety of this proposed redefinition ends up less secure.
> 
> Surely you would agree that both of these consequences should be unacceptable?

Then it seems we are at an impasse. I am 100% in favour of allowing domain 
holders (defined broadly) being able to express policy via CAA (and since CAA 
tags are extensible, such policies have only just begun to be developed), I am 
not yet convinced that current CAA expressions intended to bind anything except 
TLS certificate issuance for end entities within the domain holders.

If I might rudely (and probably wrongly) paraphrase Tim, my opinion on what is 
or should be is all but irrelevant, if those are the facts on the ground.

I’m certainly not in favour of ‘ask the big players what it means’ if that 
means accepting everything they have to say as holy writ - but garnering 
expressions of intent, from a clearly impacted contingent, in order to better 
inform a debate, is not equivalent to that, to my way of thinking.

At the very least, Mozilla would want to publicise more widely the scope of any 
proposed reinterpretation of CAA records; having the reinterpretation happen 
within a relatively small, though not exclusive, conclave doesn’t seem like 
good policy.

Regards,

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

[Tim Hollebeek via dev-security-policy]

CAA is HTTPS only today.  That’s the reality.

 

I don’t have to want to argue in favor of reality.  Reality wins regardless of 
what I do.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, May 14, 2018 11:55 PM
To: Tim Hollebeek 
Cc: r...@sleevi.com; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

I'm not sure how that's advancing the discussion forward or adding new 
information. The discussion of CAA and wanting to get feedback predates even 
the IETF finalization, as multiple browsers kept encouraging CAs to experiment 
with and attempt to deploy CAA so that we could make sure the kinks were ironed 
out.

 

Regardless of posturing and grandstanding for past statements, can we at least 
agree that a model that argues "fail open" as a solution is a fundamentally 
insecure one? If there are proponents of a 'fail open' model, especially 
amongst CAs, then does it behove them to specify as quickly as possible a 'fail 
closed' model, so that we don't have to try and divine intent and second guess 
site operators as to whether they meant to restrict HTTPS or everything?

 

Put differently, if you want to argue that CAA is HTTPS only, then you need to 
define a way to ensure it's not HTTPS-only, and ASAP. Otherwise, the solution 
is that when S/MIME BRs come around, we simply cannot and should not second 
guess site operators and try to argue CAA was only 'those' type of certs - and 
instead require anyone with a CAA record to explicitly opt-in to allowing 
(potentially unbounded) S/MIME. I don't see any other realistic or practical 
solution - you can't say "This protects you" and then propose 2 years down the 
road, with S/MIME BRs, that it didn't actually 'protect' the site operator - 
the same way you can't say "Restrict access to these five email addresses" and 
then introduce a dozen more 2 years down the road.

 

On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy 
 > wrote:

Normally I’d agree that IETF cannot and should not be a blocker for action at 
Mozilla and/or CABF, but based on our experience with CAA for web certificates, 
I would encourage people to get in their time machines and go back two to three 
years, and listen to Tim standing up and saying “I like CAA for the Web PKI, 
but what have we not thought of?”



-Tim



From: Ryan Sleevi [mailto:r...@sleevi.com  ] 
Sent: Monday, May 14, 2018 8:24 PM
To: Tim Hollebeek  >
Cc: r...@sleevi.com  ; Pedro Fuentes 
 >; 
mozilla-dev-security-policy  >
Subject: Re: question about DNS CAA and S/MIME certificates



I don't actually think there is any IETF component to this. There can be, but 
it's not required to be.



On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy 
  
 > > wrote:

There’s an IETF component, but minimum necessary standards for email 
certificate issuance is a policy issue, not a technical one.



Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in 
accordance with CAA-bis.”



-Tim




With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.



Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?


___
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

 



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

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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

> 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
>
> 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 feel like proponents of the minimally scoped CAA interpretation are in an
indefensible position - and the very self-same arguments that it “only”
applies to server auth could be made, just as incorrectly, that CAA only
applies to HTTPS certs and not SMTPS or the like.

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

[Ryan Sleevi via dev-security-policy]

On Tue, May 15, 2018 at 12:13 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >  If there are proponents of a 'fail open' model,
> > especially amongst CAs, then does it behove them to specify as quickly as
> > possible a 'fail closed' model, so that we don't have to try and divine
> > intent and second guess site operators as to whether they meant to
> restrict
> > HTTPS or everything?
>
> While this is in no way comprehensive or scientific, could we not just
> poll those (larger) domain owners who also operate publicly available mail
> services (like Yahoo) what they consider the scope of their CAA assertions?
> There can’t be a super abundance of them, surely?
>

No. I am expressly opposed to any solution that is “ask the big guys and
let them decide what it means for the Internet”.

While I can’t speak for Mozilla, that definitely seems against the spirit
of Mozilla’s principles of open and equal access.

It has a recasting failure mode as well, in that anyone who isn’t aware of
the subtlety of this proposed redefinition ends up less secure.

Surely you would agree that both of these consequences should be
unacceptable?


> I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of
> ninja-changing semantics either. If domain owners intended to only express
> a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS
> or whatever); then might they not be amenable to altering their expression
> to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the
> scope of their (in-)actions?
>
> That would then enable a future move for CAs to respect ‘issue’ and
> ‘issuewild’ to cover all cert types, while still allowing domain owners
> finer grained expression of their policies. It’s pretty much an entire
> reversal of my earlier suggestion(!), but perhaps a modification which
> would preserve the expressions of (handwave, handwave) 95% of CAA records
> owners who don’t operate public mail services, and yet still can cover
> those mail providers?
>
> But without the courtesy of at least asking those few domain owners what
> they meant, it just seems a bit rude to assume their intentions.
>
> Regards,
>
> Neil
> ___
> 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: 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