On 12/15/15 01:48, Peter Bowen wrote:
> On Mon, Dec 14, 2015 at 5:39 PM, Kathleen Wilson <kwil...@mozilla.com> wrote:
>>
>> Another thing to consider in updating the policy is in regards to test
>> certificates versus certificates issued to customers.
>> e.g. Does the disclosure need to happen before test certificates are issued?
>> Or does the disclosure just need to happen before non-test certificates are
>> issued? (or certificates are issued to customers, or such)
> 
> Kathleen,
> 
> There is no definition of "test certificate" so carving out a specific
> exception for test certificates seems unworkable.  That being said, it
> would seem reasonable that one should be able to generate a keypair
> for a new CA, cut a cross-certificate from an existing CA, and issue
> the first certificate(s) in one ceremony.  I don't think it is
> reasonable to require a waiting period between key generation and
> certificate issuance.
> 
> Therefore, I would revise my earlier recommendation, and suggest
> placing a timeliness requirement on disclosure -- publicly disclose
> within X days of first issuance.  If there is a strong interest in
> pre-disclosure, then maybe allowing disclosure of the planned
> Distinguished Name of the CA and applicable documents would be
> appropriate with a supplementary disclosure of the public key after
> generation.

I think, at least for externally operated subCAs, Mozilla should require
predisclosure. This would make it clear that the parent CA was committed to
disclosing the subCA. I'm sceptical of an 'X days after issuing' requirement to
provide similar assurance given that externally one can't generally distinguish
between a parent CA complicity issuing a series of short-lived subCAs until
something goes wrong and a parent CA being fooled into issuing a subCA that gets
abused very quickly.

Also, whatever timeline Mozilla provides for disclosure needs to avoid the
catch-22 when issuing a cross-certificate for an existing CA, for which first
issuance is many days before the subCA certificate is issued.

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

Reply via email to