Re: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 13/04/17 14:50, Gervase Markham wrote:

On 12/04/17 21:21, Rob Stradling wrote:

Mozilla also requires CAs to disclose intermediate cert revocations to
CCADB.  Should there be a corresponding time limit in the policy
regarding how soon after revocation this disclosure must occur?


There is:

"If a non-exempt intermediate certificate is revoked, the CCADB must be
updated to mark it as revoked, giving the reason why, within 24 hours
for a security incident, and within 7 days for any other reason."
https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md


Ah, thanks Gerv.  I hadn't looked in that doc.


https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2
GlobalSign EV intermediates that were revoked by Google Trust Services 5
days ago, but which are still unrevoked according to CCADB.  By when
must GTS notify CCADB of these 2 revocations?


Assuming they weren't revoked because of a security incident, some time
in the next two days :-)

Gerv


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Gervase Markham via dev-security-policy]

On 12/04/17 21:21, Rob Stradling wrote:
> Mozilla also requires CAs to disclose intermediate cert revocations to
> CCADB.  Should there be a corresponding time limit in the policy
> regarding how soon after revocation this disclosure must occur?

There is:

"If a non-exempt intermediate certificate is revoked, the CCADB must be
updated to mark it as revoked, giving the reason why, within 24 hours
for a security incident, and within 7 days for any other reason."
https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md

> https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2
> GlobalSign EV intermediates that were revoked by Google Trust Services 5
> days ago, but which are still unrevoked according to CCADB.  By when
> must GTS notify CCADB of these 2 revocations?

Assuming they weren't revoked because of a security incident, some time
in the next two days :-)

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

Re: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 04/04/17 12:17, Gervase Markham via dev-security-policy wrote:

On 27/03/17 22:12, Andrew Ayer wrote:

[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 
]


This has now been added to the policy 2.5 draft with a one-week deadline.

Gerv


Gerv,
Mozilla also requires CAs to disclose intermediate cert revocations to 
CCADB.  Should there be a corresponding time limit in the policy 
regarding how soon after revocation this disclosure must occur?


https://crt.sh/mozilla-disclosures#disclosedbutincrl currently shows 2 
GlobalSign EV intermediates that were revoked by Google Trust Services 5 
days ago, but which are still unrevoked according to CCADB.  By when 
must GTS notify CCADB of these 2 revocations?


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Gervase Markham via dev-security-policy]

On 27/03/17 22:12, Andrew Ayer wrote:
> [ Corresponding issue on GitHub: 
> https://github.com/mozilla/pkipolicy/issues/67 ]

This has now been added to the policy 2.5 draft with a one-week deadline.

Gerv

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

Re: Grace Period for Sub-CA Disclosure

[Nick Lamb via dev-security-policy]

On Tuesday, 4 April 2017 04:18:41 UTC+1, Jakob Bohm  wrote:
> So why does Mozilla want disclosure and not just a blanket X on a form
> stating that all SubCAs are adequately audited, follow BRs etc.?

Not speaking for Mozilla of course, but as a fan of disclosure provisions:

Mandating disclosure averts hypocrisy. Hypocrisy is poisonous, so we should try 
to reduce it when doing so has a reasonable cost.

Consider you're Honest Achmed. You see a business opportunity for your CA. It 
will make a lot of money, but you suspect most people will think it is wrong. 
Historically, all you needed to do was persuade yourself (and maybe a few other 
key personnel) that it's actually fine, and you're golden. If other people find 
out what you did that's a problem, but you can put that problem off until it 
happens.

Under mandatory disclosure, you have three options right up front: You can 
persuade everybody else that it's fine too, in which case it really is fine; 
You can abandon the opportunity because the risk of disapproval is 
unacceptable; You can do it anyway and hope for forgiveness, risking absolute 
distrust.

Now, a mandatory approval requirement would strengthen this by eliminating that 
last option. But it does so at an enormously greater cost as you've identified. 
Mandatory disclosure gets us most of the benefit, at a much lower cost.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 04/04/2017 05:30, Ryan Sleevi wrote:

On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:




So why does Mozilla want disclosure and not just a blanket X on a form
stating that all SubCAs are adequately audited, follow BRs etc.?

What use does Mozilla have for any of that information if not to act on
it in relation to trust decisions?



The incorrect part is that you're assuming it's a blocking process. It's
not - it's entirely asynchronous. Us folks who actually review CP/CPSes are
barely handling it at the root layer, let alone the intermediate. That's
why the CCADB - and the automation being developed by Microsoft and the
standardization I've been pushing - is key and useful.

The tradeoff has always been that CAs are granted the flexibility to
delegate, which intentionally allows them to bypass any blocking browser
dependencies, but at the risk to the issuing CA that the issuing CA may be
suspended if they do an insufficient job. It's a distribution of workload,
in which the issuing CA accepts the liability to be "as rigorous" as the
browser programs in return for the non-blocking flexibility of the
subscriber CA. In turn, that risk proposition (of the issuing CA) is offset
by the cost they impose on the subscriber CA.



That permitted asynchronicity was never clearly stated, and I was led
astray by explicit language prohibiting issuance by the SubCA before
the moment of disclosure, which is an explicit synchronization
requirement.  Once it is clear that it is permitted to disclose after
most *other* associated risks begin, then the entire problem goes away.

That simple inconsistency is what led to all this.




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

Re: Grace Period for Sub-CA Disclosure

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 04/04/2017 05:03, Ryan Sleevi wrote:
>
>> On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> I see it as part of the underlying reasoning.  Mozilla et al wants
>>> disclosure in order to take action if the disclosed facts are deemed
>>> unacceptable (under policy or otherwise).  Upon receiving the
>>> disclosure, the root program gains the ability to take counteractions,
>>> such as protesting to the issuing CA, or manually blocking the unwanted
>>> SubCA cert via mechanisms such as OneCRL.  The rules don't make the CAs
>>> wait for the root programs to get upset, but must allow at least zero
>>> time for this time to happen.
>>>
>>
>>
>> That's not correct.
>>
>>
> So why does Mozilla want disclosure and not just a blanket X on a form
> stating that all SubCAs are adequately audited, follow BRs etc.?
>
> What use does Mozilla have for any of that information if not to act on
> it in relation to trust decisions?
>

The incorrect part is that you're assuming it's a blocking process. It's
not - it's entirely asynchronous. Us folks who actually review CP/CPSes are
barely handling it at the root layer, let alone the intermediate. That's
why the CCADB - and the automation being developed by Microsoft and the
standardization I've been pushing - is key and useful.

The tradeoff has always been that CAs are granted the flexibility to
delegate, which intentionally allows them to bypass any blocking browser
dependencies, but at the risk to the issuing CA that the issuing CA may be
suspended if they do an insufficient job. It's a distribution of workload,
in which the issuing CA accepts the liability to be "as rigorous" as the
browser programs in return for the non-blocking flexibility of the
subscriber CA. In turn, that risk proposition (of the issuing CA) is offset
by the cost they impose on the subscriber CA.

The goal is not to manually approve every Sub-CA.


> Yes, across all root programs, that is the key point, see #0.
>
>
 You're still incorrect here.
>>
>>
> Not an argument.
>

I already presented the argument demonstrating why the goal - of explicitly
having every CA aligned - is not part of the goals. The goal is not to
introduce conflicting requirements, but you've demonstrated no such
conflicting requirements beyond the abstract hypothetical (and
non-participant and unknown) browser. No one is requesting what you're
proposing they are. It's a strawman.


> I have highlight how the goals that I perceive must underlie the
> disclosure requirement, combined with the general imperative of the
> Golden Rule ("do onto others..." or "You must love thy neighbor as
> thyself") leads to a logical conclusion through a number of logical
> steps.
>

I understand that, but you're misguided and incorrect in its application,
which I've tried several ways to highlight for you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I see it as part of the underlying reasoning.  Mozilla et al wants
> disclosure in order to take action if the disclosed facts are deemed
> unacceptable (under policy or otherwise).  Upon receiving the
> disclosure, the root program gains the ability to take counteractions,
> such as protesting to the issuing CA, or manually blocking the unwanted
> SubCA cert via mechanisms such as OneCRL.  The rules don't make the CAs
> wait for the root programs to get upset, but must allow at least zero
> time for this time to happen.


That's not correct.


> I believe you're suggesting simultaneously across all root programs, is
 that correct? But that's not a requirement (and perhaps based on the
 incorrect and incomplete understanding of point 1)

>>>
>>>
>>> Yes, across all root programs, that is the key point, see #0.
>>>
>>
You're still incorrect here.


> Also, it is argued as a logical consequence of #3, #2, #0, i.e.
>>> assume another root program enacts similar rules.  Once the SubCA cert
>>> is disclosed on the CCADB for Mozilla and Chrome, the SubCA operator
>>> can download the SubCA cert from the CCADB and use it to make users of
>>> that other root program trust issued certificates before that other
>>> root program received the disclosure.
>>>
>>
>> I see zero problem with the SubCA receiving the certificate
>> immediately from the issuing CA, even prior to disclosure in the
>> CCADB.  The proposed requirement is that the SubCA not issue prior to
>> confirming the disclosure has been made.
>>
>
I agree with Peter here.


> Not receiving the certificate prevents a rogue or rookie SubCA from
> meaningfully issuing prematurely.  After all, SubCA operators are only
> humans, and usually less experienced in all this than long time major
> CA operators.
>

That's not a problem we're trying to solve here. That's great that you
care, but you've also highlighted the many problems with your proposal, so
perhaps it is a bad goal no longer worth discussing?


> By symmetry, if Mozilla has to shut down the CCADB for maintenance for
>>> 2 days, another root program might receive and publish the disclosure
>>> first, causing the same problem for users of Mozilla and Chrome
>>> products.
>>>
>>
>> I'm not sure where you see the "problem for users" here.  This is no
>> different than what happens today for many CAs.
>>
>>
> The problem for users is that their Browser/client trusts a certificate
> from a SubCA that their trusted root program has never seen, and thus
> not even had a chance to form an opinion about.


That's great. That's not the goal. The rest logically shakes out as
irrelevant.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 04/04/2017 00:31, Peter Bowen wrote:

On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
 wrote:

On 03/04/2017 21:48, Ryan Sleevi wrote:


On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:



The assumptions are:

0. All relevant root programs set similar/identical policies or they
  get incorporatated into the CAB/F BRs on a future date.



This is not correct at present.



It is a simply application of the rule that policies should not fall
apart if others in the industry do the same.  It's related to the
"Golden Rule".




1. When the SubCA must be disclosed to all root programs upon the
  *earlier* of issuance + grace period OR outside facility SubCA
  receiving the certificate (no grace period).



This is not correct as proposed.



It is intended to prevent SubCAs issued to "new" parties from
meaningfully issuing trusted certificates before root programs have had
a chance to check the contents of the disclosure (CP/CPS, point in time
audit, whatever each root program requires).


I don't see this as part of the proposed requirement.  The requirement
is simply disclosure, not approval.



I see it as part of the underlying reasoning.  Mozilla et al wants
disclosure in order to take action if the disclosed facts are deemed
unacceptable (under policy or otherwise).  Upon receiving the
disclosure, the root program gains the ability to take counteractions,
such as protesting to the issuing CA, or manually blocking the unwanted
SubCA cert via mechanisms such as OneCRL.  The rules don't make the CAs
wait for the root programs to get upset, but must allow at least zero
time for this time to happen.


2. The SubCA must not issue any certificate (other than not-yet-used
  SubCAs, OCSP certs and other such CA operation certs generated in the
  same ceremony) until Disclosure to all root programs has been
  completed.



This is correct.



3. Disclosing to an operational and not-on-holiday root program team
  (such as the the CCADB most of the time) indirectly makes the SubCA
  certificate available to the SubCA operator, *technically* (not
  legally) allowing that SubCA to (improperly) start issuing before
  rule #2 is satisfied.



And given that this disclosure (in the CCADB) satisfies #2, why is this an
issue?



It is merely a step in the detailed logic argument that Ryan Sleevi
requested.

Note that no Browser or other client will trust certificates from the
new SubCA until the new SubCA or its clients can send the browser the
signed SubCA cert.


(Note, I split my paragraph to connect your reply to the specific
sentence it applies to)


 This technical point is also crucial for after-
the-fact cross certificates.


This is a more interesting case.  Going back to the start:

"The CA with a certificate included in Mozilla's CA Certificate
Program MUST disclose this information before any such subordinate CA
is allowed to issue certificates."

This implies that the subordinate CA is not already issuing
certificates.  If a CA signs a certificate naming an existing CA as
the subject, then what?


Indeed.  The easy case would be if the existing CA was already in the
CCADB and accepted in the Mozilla root program, making the cross-cert a
mere convenience for older browsers (old Mozilla or non-Mozilla), with
an added requirement that the cross-signing CA now must now do its own
audited checking and referencing of the existing CA's status and
compliance (the cost of which is hopefully included in the fee charged
for doing so, but that's their money to gain or loose).




If the Mozilla program member certifies a CA that is not a terminal CA
(e.g. not pathlen:0) and that CA then issues to another CA, how does
that certificate get into the CCADB?



The issuing CA would gain (by existing policy, I presume) an obligation
to disclose those too, and thus an incentive to contractually require
this disclosure from the SubCA.


5. SubCA Disclosure and processing of said disclosure should be done
  nearly simultaneously to minimize the problem mentioned in 3.



I believe you're suggesting simultaneously across all root programs, is
that correct? But that's not a requirement (and perhaps based on the
incorrect and incomplete understanding of point 1)



Yes, across all root programs, that is the key point, see #0.

Also, it is argued as a logical consequence of #3, #2, #0, i.e.
assume another root program enacts similar rules.  Once the SubCA cert
is disclosed on the CCADB for Mozilla and Chrome, the SubCA operator
can download the SubCA cert from the CCADB and use it to make users of
that other root program trust issued certificates before that other
root program received the disclosure.


I see zero problem with the SubCA receiving the certificate
immediately from the issuing CA, even prior to disclosure in the
CCADB.  The proposed requirement is that the SubCA not issue prior to
confirming the 

Re: Grace Period for Sub-CA Disclosure

[Peter Bowen via dev-security-policy]

On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
 wrote:
> On 03/04/2017 21:48, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>> The assumptions are:
>>>
>>> 0. All relevant root programs set similar/identical policies or they
>>>   get incorporatated into the CAB/F BRs on a future date.
>>>
>>
>> This is not correct at present.
>>
>
> It is a simply application of the rule that policies should not fall
> apart if others in the industry do the same.  It's related to the
> "Golden Rule".
>
>>
>>> 1. When the SubCA must be disclosed to all root programs upon the
>>>   *earlier* of issuance + grace period OR outside facility SubCA
>>>   receiving the certificate (no grace period).
>>>
>>
>> This is not correct as proposed.
>>
>
> It is intended to prevent SubCAs issued to "new" parties from
> meaningfully issuing trusted certificates before root programs have had
> a chance to check the contents of the disclosure (CP/CPS, point in time
> audit, whatever each root program requires).

I don't see this as part of the proposed requirement.  The requirement
is simply disclosure, not approval.

>>> 2. The SubCA must not issue any certificate (other than not-yet-used
>>>   SubCAs, OCSP certs and other such CA operation certs generated in the
>>>   same ceremony) until Disclosure to all root programs has been
>>>   completed.
>>>
>>
>> This is correct.
>>
>>
>>> 3. Disclosing to an operational and not-on-holiday root program team
>>>   (such as the the CCADB most of the time) indirectly makes the SubCA
>>>   certificate available to the SubCA operator, *technically* (not
>>>   legally) allowing that SubCA to (improperly) start issuing before
>>>   rule #2 is satisfied.
>>>
>>
>> And given that this disclosure (in the CCADB) satisfies #2, why is this an
>> issue?
>
>
> It is merely a step in the detailed logic argument that Ryan Sleevi
> requested.
>
> Note that no Browser or other client will trust certificates from the
> new SubCA until the new SubCA or its clients can send the browser the
> signed SubCA cert.  This technical point is also crucial for after-
> the-fact cross certificates.

This is a more interesting case.  Going back to the start:

"The CA with a certificate included in Mozilla's CA Certificate
Program MUST disclose this information before any such subordinate CA
is allowed to issue certificates."

This implies that the subordinate CA is not already issuing
certificates.  If a CA signs a certificate naming an existing CA as
the subject, then what?

If the Mozilla program member certifies a CA that is not a terminal CA
(e.g. not pathlen:0) and that CA then issues to another CA, how does
that certificate get into the CCADB?

>>> 5. SubCA Disclosure and processing of said disclosure should be done
>>>   nearly simultaneously to minimize the problem mentioned in 3.
>>>
>>
>> I believe you're suggesting simultaneously across all root programs, is
>> that correct? But that's not a requirement (and perhaps based on the
>> incorrect and incomplete understanding of point 1)
>
>
> Yes, across all root programs, that is the key point, see #0.
>
> Also, it is argued as a logical consequence of #3, #2, #0, i.e.
> assume another root program enacts similar rules.  Once the SubCA cert
> is disclosed on the CCADB for Mozilla and Chrome, the SubCA operator
> can download the SubCA cert from the CCADB and use it to make users of
> that other root program trust issued certificates before that other
> root program received the disclosure.

I see zero problem with the SubCA receiving the certificate
immediately from the issuing CA, even prior to disclosure in the
CCADB.  The proposed requirement is that the SubCA not issue prior to
confirming the disclosure has been made.

> By symmetry, if Mozilla has to shut down the CCADB for maintenance for
> 2 days, another root program might receive and publish the disclosure
> first, causing the same problem for users of Mozilla and Chrome
> products.

I'm not sure where you see the "problem for users" here.  This is no
different than what happens today for many CAs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 03/04/2017 21:48, Ryan Sleevi wrote:

On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


The assumptions are:

0. All relevant root programs set similar/identical policies or they
  get incorporatated into the CAB/F BRs on a future date.



This is not correct at present.



It is a simply application of the rule that policies should not fall
apart if others in the industry do the same.  It's related to the
"Golden Rule".




1. When the SubCA must be disclosed to all root programs upon the
  *earlier* of issuance + grace period OR outside facility SubCA
  receiving the certificate (no grace period).



This is not correct as proposed.



It is intended to prevent SubCAs issued to "new" parties from
meaningfully issuing trusted certificates before root programs have had
a chance to check the contents of the disclosure (CP/CPS, point in time
audit, whatever each root program requires).





2. The SubCA must not issue any certificate (other than not-yet-used
  SubCAs, OCSP certs and other such CA operation certs generated in the
  same ceremony) until Disclosure to all root programs has been
  completed.



This is correct.



3. Disclosing to an operational and not-on-holiday root program team
  (such as the the CCADB most of the time) indirectly makes the SubCA
  certificate available to the SubCA operator, *technically* (not
  legally) allowing that SubCA to (improperly) start issuing before
  rule #2 is satisfied.



And given that this disclosure (in the CCADB) satisfies #2, why is this an
issue?


It is merely a step in the detailed logic argument that Ryan Sleevi
requested.

Note that no Browser or other client will trust certificates from the
new SubCA until the new SubCA or its clients can send the browser the
signed SubCA cert.  This technical point is also crucial for after-
the-fact cross certificates.






5. SubCA Disclosure and processing of said disclosure should be done
  nearly simultaneously to minimize the problem mentioned in 3.



I believe you're suggesting simultaneously across all root programs, is
that correct? But that's not a requirement (and perhaps based on the
incorrect and incomplete understanding of point 1)


Yes, across all root programs, that is the key point, see #0.

Also, it is argued as a logical consequence of #3, #2, #0, i.e.
assume another root program enacts similar rules.  Once the SubCA cert
is disclosed on the CCADB for Mozilla and Chrome, the SubCA operator
can download the SubCA cert from the CCADB and use it to make users of
that other root program trust issued certificates before that other
root program received the disclosure.

By symmetry, if Mozilla has to shut down the CCADB for maintenance for
2 days, another root program might receive and publish the disclosure
first, causing the same problem for users of Mozilla and Chrome
products.




I think the rest of the argument now falls apart.



7. Thus between performing the audited root key access ceremony to
  issue one or more SubCA certificates etc., and actually disclosing
  those SubCA certificates to the root programs, an issuing CA may have
  to wait for all the root programs to be *simultaneously* ready to
  receive the SubCA certificate, without violating the grace period as
  per assumption #1.



This is definitely not correct, or at the least, this is not Mozilla's
problem to solve.


Again it is a logic consequence of the other items, not an explicit
rule or assumption.




Thanks for clarifying your response. It's clear now we disagree because you
expect Mozilla to accommodate the entirety of all needs for all other
browser programs. That is something I fundamentally disagree with. It is
unnecessary to introduce complexity to the Mozilla process for hypothetical
third-parties. That is, in some degree, indistinguishable from concern
trolling (if insisted upon the hypothetical abstract, without evidence),
but is otherwise, not Mozilla's problem to solve the challenges for
hypothetical French and Russian programs. I think
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
is relevant to that case as it is to the general case.



See my answer to #0 why I consider this a valid consideration.  Think
of it as "scalability".


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

Re: Grace Period for Sub-CA Disclosure

[Nick Lamb via dev-security-policy]

Further to Ryan's reply, we can once again take lessons from the real world

Ordinarily notice in law can be given by sending a letter and waiting a few 
days. There is no obligation to prove the letter was delivered, let alone read 
and comprehended, only that it was sent and that it was correctly addressed. 
Even if in fact the letter is discarded unread by another person, eaten by a 
dog, or destroyed in a large fire at a mail sorting office, the law is clear 
that the sender is still entitled to rely upon it as notice. There are some 
special cases, but this is the general rule.

The same principle applies to this idea of notifying a trust store about 
things. The CA needs to take reasonable steps to notify, such as visiting a web 
site and pasting things into a form, sending an email, or filing a Bugzilla 
bug. But it makes no sense, and I don't believe the Mozilla policy as described 
requires, that the CA must suspend operation indefinitely if the means of 
notification is not functioning for some technical reason. The goal here is 
that the CA should be telling us stuff - it's up to us to listen and pay 
attention to what is said. If we take July off to go skiing, too bad.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Peter Bowen via dev-security-policy]

On Mon, Apr 3, 2017 at 12:36 PM, Jakob Bohm via dev-security-policy
 wrote:
> On 03/04/2017 19:24, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>> taking a holiday and not being able to process a disclosure of a new
>>> SubCA.
>>>
>>
>> Considering that the CCADB does not require any of these parties to
>> process
>> a disclosure, can you again explain why the proposed wording would not be
>> sufficient?
>>
>> I think you may be operating on incomplete/incorrect assumptions about
>> disclosure, and it would be useful to understand what you believe happens,
>> since that appears to have factored in to your suggestion. Given that the
>> proposal allows the CA to fully self-report (if they have access) or to
>> defer until they do have access, that does seem entirely appropriate and
>> relevant to allow for one week.
>>
>
> The assumptions are:
>
> 0. All relevant root programs set similar/identical policies or they
>   get incorporatated into the CAB/F BRs on a future date.

This discussion is only about Mozilla's program.

> 1. When the SubCA must be disclosed to all root programs upon the
>   *earlier* of issuance + grace period OR outside facility SubCA
>   receiving the certificate (no grace period).

Disclosure means uploading the CCADB with other data (e.g. which CPS applies).

> 2. The SubCA must not issue any certificate (other than not-yet-used
>   SubCAs, OCSP certs and other such CA operation certs generated in the
>   same ceremony) until Disclosure to all root programs has been
>   completed.

This is a good callout.  It isn't clear how to handle issuance of
certificates prior to disclosure.

> 3. Disclosing to an operational and not-on-holiday root program team
>   (such as the the CCADB most of the time) indirectly makes the SubCA
>   certificate available to the SubCA operator, *technically* (not
>   legally) allowing that SubCA to (improperly) start issuing before
>   rule #2 is satisfied.

I don't follow here.  The requirement is simply that the certificate
be uploaded prior to the CA issuing any certificates.  It doesn't
matter if the program team does anything with it.  It also has no
impact on whether the subordinate CA issues or does not issue -- the
subordinate CA controls the private key that can be used to create
signatures, not the root program team.

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

Re: Grace Period for Sub-CA Disclosure

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> The assumptions are:
>
> 0. All relevant root programs set similar/identical policies or they
>   get incorporatated into the CAB/F BRs on a future date.
>

This is not correct at present.


> 1. When the SubCA must be disclosed to all root programs upon the
>   *earlier* of issuance + grace period OR outside facility SubCA
>   receiving the certificate (no grace period).
>

This is not correct as proposed.


>
> 2. The SubCA must not issue any certificate (other than not-yet-used
>   SubCAs, OCSP certs and other such CA operation certs generated in the
>   same ceremony) until Disclosure to all root programs has been
>   completed.
>

This is correct.


> 3. Disclosing to an operational and not-on-holiday root program team
>   (such as the the CCADB most of the time) indirectly makes the SubCA
>   certificate available to the SubCA operator, *technically* (not
>   legally) allowing that SubCA to (improperly) start issuing before
>   rule #2 is satisfied.
>

And given that this disclosure (in the CCADB) satisfies #2, why is this an
issue?


> 5. SubCA Disclosure and processing of said disclosure should be done
>   nearly simultaneously to minimize the problem mentioned in 3.
>

I believe you're suggesting simultaneously across all root programs, is
that correct? But that's not a requirement (and perhaps based on the
incorrect and incomplete understanding of point 1)

I think the rest of the argument now falls apart.


> 7. Thus between performing the audited root key access ceremony to
>   issue one or more SubCA certificates etc., and actually disclosing
>   those SubCA certificates to the root programs, an issuing CA may have
>   to wait for all the root programs to be *simultaneously* ready to
>   receive the SubCA certificate, without violating the grace period as
>   per assumption #1.
>

This is definitely not correct, or at the least, this is not Mozilla's
problem to solve.


Thanks for clarifying your response. It's clear now we disagree because you
expect Mozilla to accommodate the entirety of all needs for all other
browser programs. That is something I fundamentally disagree with. It is
unnecessary to introduce complexity to the Mozilla process for hypothetical
third-parties. That is, in some degree, indistinguishable from concern
trolling (if insisted upon the hypothetical abstract, without evidence),
but is otherwise, not Mozilla's problem to solve the challenges for
hypothetical French and Russian programs. I think
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
is relevant to that case as it is to the general case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 03/04/2017 19:24, Ryan Sleevi wrote:

On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


taking a holiday and not being able to process a disclosure of a new
SubCA.



Considering that the CCADB does not require any of these parties to process
a disclosure, can you again explain why the proposed wording would not be
sufficient?

I think you may be operating on incomplete/incorrect assumptions about
disclosure, and it would be useful to understand what you believe happens,
since that appears to have factored in to your suggestion. Given that the
proposal allows the CA to fully self-report (if they have access) or to
defer until they do have access, that does seem entirely appropriate and
relevant to allow for one week.



The assumptions are:

0. All relevant root programs set similar/identical policies or they
  get incorporatated into the CAB/F BRs on a future date.

1. When the SubCA must be disclosed to all root programs upon the
  *earlier* of issuance + grace period OR outside facility SubCA
  receiving the certificate (no grace period).

2. The SubCA must not issue any certificate (other than not-yet-used
  SubCAs, OCSP certs and other such CA operation certs generated in the
  same ceremony) until Disclosure to all root programs has been
  completed.

3. Disclosing to an operational and not-on-holiday root program team
  (such as the the CCADB most of the time) indirectly makes the SubCA
  certificate available to the SubCA operator, *technically* (not
  legally) allowing that SubCA to (improperly) start issuing before
  rule #2 is satisfied.

4. It is common IT practice to take systems that don't need 24/7
  holiday availability offline during business holidays where the
  primary users are not going to need it.  This is done for big
  "flag day" changes, such as migrating the CCADB from a SalesForce to
  Google platform or back.  This is obviously not done for every
  holiday, and often not for the entire holiday, but when it is done,
  the entire holiday is often reserved for it in semi-outside
  availability announcements.

The logical derivatives are:


5. SubCA Disclosure and processing of said disclosure should be done
  nearly simultaneously to minimize the problem mentioned in 3.

6. If any ONE root program cannot process the disclosure immediately
  (it is not using CCADB style automation or its backend infrastructure
  is offline), and the issuing CA is made aware of this, they should
  thus postpone the disclosure (and the handout of the SubCA cert)
  until the announced unavailability is over.

7. Thus between performing the audited root key access ceremony to
  issue one or more SubCA certificates etc., and actually disclosing
  those SubCA certificates to the root programs, an issuing CA may have
  to wait for all the root programs to be *simultaneously* ready to
  receive the SubCA certificate, without violating the grace period as
  per assumption #1.

8. If some less automated root program handles each SubCA disclosure
  via manual processing by a small team which goes on holiday at the
  same time, then that root program can hold back the entire thing,
  thus raising the practical minimum to which the grace period in
  assumption #1 can be set.

So here is a hypothetical example:

  Minor French browser F has its own root program but cannot process
  SubCA disclosures during weekends and the entire Gregorian Christmas
  period.

  Minor Russian browser R has its own root program but similarly cannot
  process SubCA disclosures during weekends and the entire Julian
  Christmas period (due to basing their company holidays on a Julian
  calendar interpretation of orthodocs Christianity).

  The CCADB is fully online and disclosing there would make the SubCA
  publicly visible to the SubCA operator within minutes.

  CA X schedules a high security, audit root key access ceremony for
  Dec 22 in some year and arranges for the parties to be present.

  On Dec 20, French team F sends them their holiday mail, it is too
  late to reschedule the ceremony.

  On Dec 22 around noon PST, CA X holds a key signing ceremony to
  generate fresh SubCA certificates for the next calendar year, for
  both themselves and external SubCAs (including one brand new SubCA).

  Because The French browser F team went on holiday around 16:00 CET
  (8:00 AM PST), CA X cannot proceed until CA F opens for manual
  processing on Jan 6.

  But because Russian browser R similarly closed offices on Jan 2
  Gregorian, CA X must actually wait until Jan 19 Gregorian.

  Jan 19 happens to be a Saturday, so CA X needs to wait until Monday
  Jan 21.

  So on Jan 21, CA X sends/uploads SubCA disclosures to all root
  programs, including the CCADB, French team F and Russian team R.
  This starts a window of risk, where the SubCA operators could grab
  their certificates from e.g. the CCADB before officially receiving it
  from CA X.

  Withing a 17 to 24 

Re: Grace Period for Sub-CA Disclosure

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> taking a holiday and not being able to process a disclosure of a new
> SubCA.
>

Considering that the CCADB does not require any of these parties to process
a disclosure, can you again explain why the proposed wording would not be
sufficient?

I think you may be operating on incomplete/incorrect assumptions about
disclosure, and it would be useful to understand what you believe happens,
since that appears to have factored in to your suggestion. Given that the
proposal allows the CA to fully self-report (if they have access) or to
defer until they do have access, that does seem entirely appropriate and
relevant to allow for one week.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 01/04/2017 03:49, Ryan Sleevi wrote:

On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


As previously stated, I think this will be too short if the issuance
happens at a time when a non-CCADB root program (or the CCADB
infrastructure) is closed for holidays, such as the following:



I'm not sure I've heard of many web pages being closed for the holidays.
Are yours?

I think Rob Stradling's suggestion more than addresses this - within 1 week
of the intermediate being issued or the CA being granted access to the
CCADB, whichever is the later?

Considering CAs must have 24/7 uptime and be able to review and respond to
certificate problem reports within 24 hours, I think the suggestion of how
to define holidays is unnecessary.



I am not talking about web pages being shut down for holidays, nor of
any CA being shut down for holidays.

I am talking about root program teams and facilities, such as the CCADB
facility, the Mozilla Root Program team (Kathleen, Gerv), The
Google/Blink root program (You and ?), the Apple root program team, the
Microsoft root program team, the Oracle root program team, the Debian
root program team (ca-certificates package maintainers) etc. etc.
taking a holiday and not being able to process a disclosure of a new
SubCA.

And of cause I am talking about worst case durations, not best case
(which is just a few seconds).



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

Re: Grace Period for Sub-CA Disclosure

[Ryan Sleevi via dev-security-policy]

On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> As previously stated, I think this will be too short if the issuance
> happens at a time when a non-CCADB root program (or the CCADB
> infrastructure) is closed for holidays, such as the following:
>

I'm not sure I've heard of many web pages being closed for the holidays.
Are yours?

I think Rob Stradling's suggestion more than addresses this - within 1 week
of the intermediate being issued or the CA being granted access to the
CCADB, whichever is the later?

Considering CAs must have 24/7 uptime and be able to review and respond to
certificate problem reports within 24 hours, I think the suggestion of how
to define holidays is unnecessary.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 30/03/17 13:11, Gervase Markham via dev-security-policy wrote:

On 28/03/17 12:21, Rob Stradling wrote:

Increased attack surface.  An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being compromised by an attacker, or to
being accidentally used to misissue a cert) than an offline root key.


If it's dormant, there's no particular reason the HSM will be online.
But it might be, and it doesn't make much sense to make a distinction in
the policy.


IINM, the purpose (so far) of Mozilla's intermediate cert disclosure
policy is to map the attack surface.  Right?


That's certainly one goal :-)

Does a week sound about right?


SGTM.

Presumably that week begins at either 1) the moment the intermediate is 
issued or 2) the moment the CA is first granted access to the CCADB, 
whichever is the latter?


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Grace Period for Sub-CA Disclosure

[Gervase Markham via dev-security-policy]

On 28/03/17 12:21, Rob Stradling wrote:
> Increased attack surface.  An undisclosed dormant sub-CA most likely has
> its private key in an online HSM, and so I think it's prudent to assume
> that it's more vulnerable (to being compromised by an attacker, or to
> being accidentally used to misissue a cert) than an offline root key.

If it's dormant, there's no particular reason the HSM will be online.
But it might be, and it doesn't make much sense to make a distinction in
the policy.

> IINM, the purpose (so far) of Mozilla's intermediate cert disclosure
> policy is to map the attack surface.  Right?

That's certainly one goal :-)

Does a week sound about right?

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

Re: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 28/03/17 13:32, Jakob Bohm via dev-security-policy wrote:


On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:



Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?



Actually, I think it is about ensuring that there are no non-compliant
issuers of Mozilla-trusted certificates, that might be issuing
improperly validated certificates.


We're talking about the policy's requirement for disclosing "dormant" 
sub-CAs, not sub-CAs "that might be issuing".


By the time a sub-CA issues its first cert, that sub-CA MUST have 
already been disclosed.  The policy is already clear on this point.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 28/03/2017 12:21, Rob Stradling wrote:

On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:

On 27/03/17 23:12, Andrew Ayer wrote:

My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.  If the sub-CA is created as a backup that is never used, the
disclosure would never need to happen.

I think this is bad.


Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?


Increased attack surface.  An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being compromised by an attacker, or to
being accidentally used to misissue a cert) than an offline root key.

IINM, the purpose (so far) of Mozilla's intermediate cert disclosure
policy is to map the attack surface.  Right?



Actually, I think it is about ensuring that there are no non-compliant
issuers of Mozilla-trusted certificates, that might be issuing
improperly validated certificates.

Any unknown SubCA would be trusted by recursion, but would not have
given Mozilla sufficient assurance it is using this ability in a policy
compliant manner.


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

Re: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:

On 27/03/17 23:12, Andrew Ayer wrote:

My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.  If the sub-CA is created as a backup that is never used, the
disclosure would never need to happen.

I think this is bad.


Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?


Increased attack surface.  An undisclosed dormant sub-CA most likely has 
its private key in an online HSM, and so I think it's prudent to assume 
that it's more vulnerable (to being compromised by an attacker, or to 
being accidentally used to misissue a cert) than an offline root key.


IINM, the purpose (so far) of Mozilla's intermediate cert disclosure 
policy is to map the attack surface.  Right?


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Grace Period for Sub-CA Disclosure

[Gervase Markham via dev-security-policy]

On 27/03/17 23:12, Andrew Ayer wrote:
> My interpretation of the policy is that a CA could delay disclosure for
> quite some time if the sub-CA is not used to issue certificates right
> away.  If the sub-CA is created as a backup that is never used, the
> disclosure would never need to happen.
> 
> I think this is bad.

Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?

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

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 28/03/2017 00:16, Ben Wilson wrote:

What if the third party needs to review the certificate to see whether it
meets expected profile requirements?  In some cases the certificate subject
must first "accept" the certificate.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Jakob Bohm via dev-security-policy
Sent: Monday, March 27, 2017 3:58 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Grace Period for Sub-CA Disclosure

On 27/03/2017 23:41, Rob Stradling wrote:

On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote:


It should also be made a requirement that the issued SubCA
certificate is provided to the CCADB and other root programs before
providing it to the SubCA owner/operator,


That'd be a bit difficult in the common case where the Sub-CA operator
and the Sub-CA certificate's issuer are the same entity!



Oops forgot to include "3rd party" in that sentence.  This extra requirement
would only apply to 3rd party SubCA signing, as well as to SubCA signing for
a different part of the same organization.

It should not apply where the new SubCA is located in the same place and
receives the SubCA cert as part of the same high security signing ceremony.




Even if the subject rejects a provided certificate, the subject can
still use it (subject to revocation checking).

Thus for browsers that have replaced actual revocation checking by
things like OneCRL, disclosure of such a rejected SubCA certificate is
still required.


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

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 27/03/2017 23:41, Rob Stradling wrote:

On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote:


It should also be made a requirement that the issued SubCA certificate
is provided to the CCADB and other root programs before providing it to
the SubCA owner/operator,


That'd be a bit difficult in the common case where the Sub-CA operator
and the Sub-CA certificate's issuer are the same entity!



Oops forgot to include "3rd party" in that sentence.  This extra
requirement would only apply to 3rd party SubCA signing, as well as to
SubCA signing for a different part of the same organization.

It should not apply where the new SubCA is located in the same place
and receives the SubCA cert as part of the same high security signing
ceremony.



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

Grace Period for Sub-CA Disclosure

[Andrew Ayer via dev-security-policy]

[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 
]

Mozilla's CA Certificate Policy says:

> All certificates that are capable of being used to issue new
> certificates, that are not technically constrained, and that directly
> or transitively chain to a certificate included in Mozilla's CA
> Certificate Program MUST be audited in accordance with Mozilla's CA
> Certificate Policy and MUST be publicly disclosed in the CCADB by the
> CA that has their certificate included in Mozilla's CA Certificate
> Program.

One cannot disclose a sub-CA certificate without first signing it, so
there will always be some delay between the creation of a sub-CA and
its disclosure in the CCADB.  How long can a CA delay the disclosure?
All the policy currently says is this:

> The CA with a certificate included in Mozilla's CA Certificate
> Program MUST disclose this information before any such subordinate CA
> is allowed to issue certificates.

My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.  If the sub-CA is created as a backup that is never used, the
disclosure would never need to happen.

I think this is bad.  An upper limit on the delay should be precisely
specified by the policy.  My opinion is that it should be on the order
of days, although the policy might need to afford some leeway to CAs
that are new to the Mozilla program and do not have access yet to CCADB.

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