Re: Appropriate role for lists of algorithms and key sizes

2017-01-27 Thread Ryan Sleevi 
On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham  wrote:
>
> * RSA keys with a minimum modulus size of 2048 bits
>

Nits and niggles: Perhaps 2048, 3072, 4096?

- 8K RSA keys cause Web PKI interop problems
- RSA keys that aren't modulo 8 create interop problems


> 2) Brian has also suggested we mandate a matching of ECDSA curves with
> digest algorithms. Do we want to do that?
>

Yes, ideally. Jakob's reply confused the issue, but it's not ideal to see
P-521 with SHA-256, for example.


> 3) Do we want to add Ed25519?
>

No. This was discussed at the CA/Browser Forum meeting in Seattle. Although
you have RFC 8032, you're still missing the appropriate assignments
relative to PKIX (which a separate draft was working on). You also have the
issue that the BRs currently require that the CA's private key be stored in
an appropriately protected HSM, but the specifications for the HSMs (FIPS
140-2 level 3 or CC EAL equivalent) don't allow the use of Ed25519.


> 4) Do we want to do the spec using AlgorithmIdentifiers instead of free
> text? Aren't AlgorithmIdentifiers used for something a bit different?
>

There's the AlgorithmIdentifier of the key, and the AlgorithmIdentifier of
the signature produced with that key. For the key, you can allow something
like P-256, but for the signature, you want to restrict it to P-256 with
SHA-256.

This is similar to identifying the key as rsaEncryption, but the signature
as sha1withRSAEncryption.

Which aspect were you thinking of?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued/Suspicious Symantec Certificates

2017-01-27 Thread Nick Lamb 
On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham  wrote:
> * It's not clear what the problem is with the issuance in category F. I
> don't see any mention of "dev119money.com" in Andrew's initial report.
> Can you explain (and provide a crt.sh link)?

https://crt.sh/?id=48539119 appears to be the certificate in question.

The certificate is clearly bogus in that it identifies the Subject O=test, 
OU=test, etc. yet real DNS names are included in the SANs. It is not clear to 
me either why this is different from Category D and so I too would appreciate 
more information from Steven about that.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued/Suspicious Symantec Certificates

2017-01-27 Thread Gervase Markham 
Hi Steve,

On 27/01/17 01:30, Steve Medin wrote:
> Here is an attached PDF update regarding this certificate problem report.

Thanks for the update. Here are some questions:

* It's not clear what the problem is with the issuance in category F. I
don't see any mention of "dev119money.com" in Andrew's initial report.
Can you explain (and provide a crt.sh link)?

* Root Cause, bullet 2 refers to "certificates issued between July 2016
and January 2017"; is it correct that this corresponds to categories A
(one of four certificates), B, D, E and F?

* What processes, other than requiring and inspecting a WebTrust report,
does Symantec have in place to ensure that its RAs behave in accordance
with the CP and CPS of the Symantec-owned roots under which they are
issuing? (Perhaps this will be covered in the report you will issue
after the "additional follow-up" steps are completed?)

* Do such processes include regular, occasional or any review of the
audit logs which show the overriding of compliance failure flags?

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

Re: Policy 2.4 Proposal: Codify requirements relating to Common CA Database into the policy

2017-01-27 Thread Jakob Bohm 

On 27/01/2017 10:06, Gervase Markham wrote:

On 26/01/17 14:12, Jakob Bohm wrote:

Given that Mozilla has been reducing the scope and generality of their
root store over the past few years, I would suggest reaching out to
those organizations that base their public root stores on the Mozilla
store, but have a slightly different focus.  Such organizations may
wish, either individually or together, to pick up the slack via joint
use of facilities such as the CCADB and perhaps this newsgroup.


This is a bit orthogonal to the question under consideration. Kathleen
has more than enough to do without trying to recruit more CCADB
participants. But, having said that, if people approach us, we will of
course try and be welcoming.

Gerv



Of cause.  Someone else expressed that at least one other root program
should show interest in using the CCADB before splitting out a common
CCADB part from the Mozilla Policy.  So I was trying to suggest a
likely candidate for fulfilling that expressed need and a reason that
might motivate them.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy