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

[Wayne Thayer via dev-security-policy]

I think we have settled on the following resolution to this issue:

Add the following to section 5.2 (Forbidden and Required Practices):

CAs MUST NOT generate the key pairs for end-entity certificates that have
> an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
>
> 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 transferred using a
> different channel than the PKCS#12 file.
>

Unless there is further discussion, I will include this language in the
final version of the policy.

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

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

[Doug Beattie via dev-security-policy]

>From: Wayne Thayer [mailto:wtha...@mozilla.com] 
>Sent: Monday, May 7, 2018 8:43 PM
>To: Doug Beattie 
>Cc: Ryan Hurst ; mozilla-dev-security-policy 
>pol...@lists.mozilla.org>
>Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key 
>generation to policy)
>
>Doug,
>
>On Mon, May 7, 2018 at 11:24 AM Doug Beattie via dev-security-policy 
>pol...@lists.mozilla.org> wrote: 
>> -Original Message-
>> From: dev-security-policy [mailto:mailto:dev-security-policy-
>> bounces+doug.beattie=mailto:globalsign@lists.mozilla.org] On Behalf Of 
>> Ryan
>> Hurst via dev-security-policy
>> Sent: Friday, May 4, 2018 4:35 PM
>> To: mailto:mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
>> generation to policy)
>> 
>> On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote:
>> > First comments on this: "MUST be encrypted and signed; or, MUST have a
>> password that..."
>> > - Isn't the password the key used for encryption?  I'm not sure if the "or"
>> makes sense since in both cases the password is the key for encryption
>> 
>> There are modes of PKCS#12 that do not use passwords.
>If you're stating that we should include the use of PKCS#12 that don't use 
>passwords and that are 
>encrupted, then we need to define the parameters of the key used for that 
>purpose,
>
>Would it be enough to say that "PKCS#12 files must employ an encryption key 
>and algorithm that is 
>sufficiently strong..." (add "key and")?
Sure, that works for me.

>> > - In general, I don't think PKCS#12 files are signed, so I'd leave that 
>> > out, a
>> signature isn't necessary.  I could be wrong...
>> 
>> They may be, see: http://unmitigatedrisk.com/?p=543
>The requirement seems to imply it must be signed, and I don't think we want 
>that, do we?  I think 
>should remove "or signed" and that will permit them to be signed, but not 
>require it.
>
> That's not hoe I read it. The proposed language provides the option of 
>'encrypted and signed' or 
>protected with a password'. Since your use case is 'protected with a 
>password', there is no requirement 
>for the file to be signed.
OK

>>
>> >
>> > I'd still like to see a modification on the requirement: "password MUST be
>> transferred using a different channel than the PKCS#12 file".  A user should 
>> be
>> able to download the P12 and password via HTTP.  Can we add an exception
>> for that?
>> 
>> Why do you want to allow the use of HTTP?
>Sorry, I meant HTTPS.  
 
___
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 Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
> this question is somewhat outside the current Baseline Requirements, but...
>
> wouldn't it be normal for the same CAA rules for server certificates to
> also apply to client certificates when the email address is for a domain
> that already has a valid CAA policy published in DNS?
>
>
> RFC 6844 doesn't seem to make any distinction between server and S/MIME
> client certificates, it combines them together by referring to certificates
> "for that domain" as a whole.
>
>
> i tested this last night - i obtained an email certificate from one of the
> CAs participating here (not for this exact address though) and it was
> happily issued even if CAA records authenticated by DNSSEC do not allow
> their CA to issue for this domain.
>
> Now, this is technically not a mis-issuance because it was a proper
> email-validated address and their CPS says that CAA is only checked for
> server-type certificates. It doesn't say anything about CAA validation for
> such client certificates.
>
> I got in touch with them and they seemed equally surprised by such
> intended use case for CAA, so my second question is: is anyone actually
> checking CAA records for client certificates where an email address is
> included in the certificate subject info and the EKU includes Secure Email?
>
>
> Or is CAA usually checked only for server-type certificates, even if RFC
> 6844 refers to certificates "for that domain" as a whole?
>

CAs are generally only checking CAA when they're required to in order to be
trusted.

Right now, CAs are only required to check CAA for server-type certificates
(by virtue of the Baseline Requirements Section 3.2.2.8).
CAs are not presently being required to check CAA for e-mail. They can, but
they are required to do it, so they are unlikely to do it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

question about DNS CAA and S/MIME certificates

[Adrian R. via dev-security-policy]

Hello,
this question is somewhat outside the current Baseline Requirements, but...

wouldn't it be normal for the same CAA rules for server certificates to also 
apply to client certificates when the email address is for a domain that 
already has a valid CAA policy published in DNS?


RFC 6844 doesn't seem to make any distinction between server and S/MIME client 
certificates, it combines them together by referring to certificates "for that 
domain" as a whole.


i tested this last night - i obtained an email certificate from one of the CAs 
participating here (not for this exact address though) and it was happily 
issued even if CAA records authenticated by DNSSEC do not allow their CA to 
issue for this domain.

Now, this is technically not a mis-issuance because it was a proper 
email-validated address and their CPS says that CAA is only checked for 
server-type certificates. It doesn't say anything about CAA validation for such 
client certificates.

I got in touch with them and they seemed equally surprised by such intended use 
case for CAA, so my second question is: is anyone actually checking CAA records 
for client certificates where an email address is included in the certificate 
subject info and the EKU includes Secure Email?


Or is CAA usually checked only for server-type certificates, even if RFC 6844 
refers to certificates "for that domain" as a whole?


Thank you,

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

Re: Mis-issuance of certificate with https in CN/SAN

[Rob Stradling via dev-security-policy]

On 16/03/18 10:27, Rob Stradling via dev-security-policy wrote:

On 16/03/18 05:17, Jakob Bohm via dev-security-policy wrote:


Please see https://crt.sh/?id=353098570=cablint



Note: This is the CT precertificate.

Note 2: According to crt.sh, the OCSP response for this precertificate
is not correct.  (error message: "OCSP response contains bad number of
certificates").


The crt.sh feature relies on Go's crypto/ocsp library, which currently 
"is just a bit limited and doesn't have support for more complex 
responses" [1].


The Go x/crypto/ocsp library was recently updated.  I've just deployed 
the update to crt.sh, and as a result https://crt.sh/ocsp-responders no 
longer shows any instances of the "bad number of certificates" error.


It's not "incorrect" for an OCSP response to contain superfluous CA 
certificates.  However, it is suboptimal (in terms of bytes on the wire).



[1] https://github.com/golang/go/issues/21527


--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

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