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: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

I must be missing something still? The implication here is that a purchaser who 
is not yet part of the root program is permitted to take possession of the root 
cert private key and possibly the physical space, key personnel, networking 
infrastructure, revocation systems, and responsibility for subordinates without 
having first demonstrated any competence at ‎running a CA organization.

I think we need to beef up this section of the policy but if you'd prefer to 
discuss that at a later time (separate from the Google acquisition thread), 
that will work for me.


  Original Message  
From: Gervase Markham
Sent: Saturday, April 1, 2017 6:02 AM
To: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 31/03/17 20:26, Peter Kurrasch wrote:
> The revised example is not entirely what I had in mind (more on that
> in a minute) but as written now is mostly OK by me. I do have a
> question as to whether the public discussion as mentioned must take
> place before the actual transfer? In other words, will Mozilla
> require that whatever entity is trying to purchase the root must be
> fully admitted into the root program before the transfer takes
> place?

No. As currently worded, it has to take place before issuance is permitted.

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

[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: Next CA Communication

[Kathleen Wilson via dev-security-policy]

On Monday, April 3, 2017 at 10:13:22 AM UTC-7, Kathleen Wilson wrote:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> still shows version 2.4. 

It's been updated to version 2.4.1.

Thanks,
Kathleen

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

Re: DRAFT - BR Self Assessments

[Kathleen Wilson via dev-security-policy]

I updated https://wiki.mozilla.org/CA:BRs-Self-Assessment to add a section 
called 'Annual BR Self Assessment', which states: 
"CAs with included root certificates that have the Websites trust bit set must 
do an annual self-assessment of their compliance with the BRs, and must update 
their CP and CPS documents at least once every year."

I added a section about this to the root inclusion/update Information Checklist:
https://wiki.mozilla.org/CA:Information_checklist#Baseline_Requirements_Self_Assessement

And I updated ACTION 2 of the CA Communication
https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o03WrzBC
to include a link to this.

Thanks,
Kathleen


___
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 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: Next CA Communication

[Kathleen Wilson via dev-security-policy]

On Saturday, April 1, 2017 at 3:59:28 AM UTC-7, Gervase Markham wrote:
> On 31/03/17 22:20, Kathleen Wilson wrote:
> > Please let me know asap if you see any problems, typos, etc. in this
> > version.
> 
> Now that policy 2.4.1 has been published, we should update Action 3 to
> say the following at the top:
> 
> Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been
> published. Differences between 2.4 and 2.3 (published Dec 2016),
> and between 2.4 and 2.2 (published July 2013) may be viewed on
> Github. Version 2.4.1 contains exactly the same normative requirements
> as version 2.4 but has been completely reorganized. Please review
> version 2.4.1 policy and confirm that your CA complies with it.
> 
> 


https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
still shows version 2.4. Shall I wait until it shows version 2.4.1 before I 
send the CA Communication?

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

Re: Symantec Issues List

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 3, 2017 at 12:46 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> How about this simple explanation (purely a guess, not at all checked):
>

I think we should focus on objective facts and statements. While there are
a number of possible ways to interpret things, both positively and
negatively, the fact that such multiple interpretations exist highlight a
problem that needs public clarification and resolution - both on behalf of
Symantec and their auditors.
___
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

Questions for Symantec

[Gervase Markham via dev-security-policy]

Hi Steve and Rick,

You have told me that you are considering your response(s) to the
Symantec issues list, which is fine. Based on the list and further
discussions which have been happening in m.d.s.policy, and on your
recent audit publication, I thought it would be helpful to give a few
specific questions that we are seeking answers to. (This should in no
way be seen as trying to limit what else Symantec may wish to say.) It
would be most convenient if you were to post the answers as a reply
message in m.d.s.policy.

Q1) Symantec's audit for 2014-2015:
https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf
says on page 11:

"We noted that audit reports were not obtained during the examination
period for 2 of 5 external partner subordinate CAs signed by the
GeoTrust Global CA and managed by contracted third parties as part of
the GeoRoot service). In addition, the report obtained for 1 of 5
external partner subordinate CAs was not in accordance with permitted
audit schemes.

Furthermore, in lieu of third party audits completed by delegated third
parties, no out-of-band mechanisms were used to confirm the authenticity
of the certificate requests, or the information supporting the
certificate and internal reviews were not performed by Symantec to
determine third party compliance with baseline requirements.

For the 2 external partners where reports were not obtained during the
examination period, one external partner’s subordinate CA has since
expired and Symantec subsequently received an audit report for the
other. For the other external partner, Symantec reviewed the report
obtained and requested that their next report be in accordance with
permitted audit schemes."

  A) Can you please identify all of the companies referenced here, by
putting names to each reference?

  B) When the second paragraph, beginning "Furthermore", refers to
"delegated third parties", does it mean the same five subordinate CAs as
the first paragraph, or does it refer to the RA program that you
recently shut down?

  C) If it refers to the same subordinate CAs, can you explain how the
RA audits for CrossCert, Certisign, Certsuperior, and Certisur featured
in the 2014-2015 auditing process? Where they examined by KPMG?

Q2) Please give the names of all companies who have been in your RA
program recently enough that there still exist unexpired certificates
which were issued by them, and their start and end dates in the program.
Although we have had some of this information before, for completeness
please provide links to all audits for each company.

Q3) Please give the names of all companies who have been in your GeoRoot
program recently enough that there still exist unexpired certificates
which were issued by them, and their start and end dates in the program.
Please provide links to all audits for each company.

Q4) Are there any other programs Symantec runs or has run in the past
five years, other than the recently-terminated RA program and the
GeoRoot program, which puts either the power of domain ownership
validation or the power of certificate issuance in the hands of an
organization other than Symantec or its Affiliates? If so, please give
details of the program, and lists of companies, dates and any applicable
audits as outlined above.

Q5) You have recently released your 2016 audits, split into two parts at
June 16th (6.5 months into the 12-month period). The audits for the
first six months contain almost all of the qualifications that the 2015
audits have. Please can you give exact or approximate dates for "start
of issue", "discovery of issue" and "problem fixed/ceased" for each of
the following issues which led to a qualification:

  A) Test certificates issued for domains Symantec did not own or
 control
  B) Failure to maintain physical security records for 7 years
  C) Unauthorized employees with access to certificate issuance
 capability
  D) Failure to review application and system logs
  E) Background checks not renewed for trusted personnel after 5 years

Q6) The management assertions in the audits for neither the first-half
nor the second-half of 2016 contain any qualification related to the
audit status of either your GeoRoot or RA program partners. Does this
indicate that Symantec felt that all partners in these programs were in
good standing audit-wise during the period from December 1st 2015 to
November 31st 2016?

Q7) In your comments at the time on what is now labelled Issue D, the
misissuance of test certificates, you wrote:

"First, we continued to issue internal test certificates to unregistered
domains after the April 2014 change in the Baseline Requirements that
removed authorization to do so."

By "the April 2014 change", do you mean by ballot 112?
https://cabforum.org/2014/04/03/ballot-112-replace-definition-internal-server-name-internal-name/
If so, can you explain how you see this ballot as affecting the
correctness or otherwise of issuing certificate for 

Re: Symantec Issues List

[Gervase Markham via dev-security-policy]

On 03/04/17 02:37, Peter Bowen wrote:
> I believe Issue L is incorrectly dated.  

Thank you for this; I have updated Issue L to hopefully be more
accurate, but I intend to keep it as a separate issue.

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

Re: Symantec Issues List

[Gervase Markham via dev-security-policy]

On 01/04/17 05:57, Peter Bowen wrote:
> The GeoRoot program was very similar to that offered by many CAs a few
> years ago.  CyberTrust (then Verizon, now DigiCert) has the OmniRoot
> program, Entrust has a root signing program[1], and GlobalSign Trusted
> Root[2] are just a few examples.

While this is true, it's not just about the existence of the legacy
program with problems, but about how the situation is handled. Verizon
were not able to bring their program into BR compliance; DigiCert bought
it and worked closely with Mozilla to generate some breathing space for
them to clean the system up. They posted public plans, kept us informed
of the issues found and their plans for remediation, and completed the
work pretty much on time. The Web PKI is a better place for it.

This does not seem to be the approach taken by Symantec, if we accept
Ryan's account of events.

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

Re: Symantec Issues List

[Gervase Markham via dev-security-policy]

On 01/04/17 00:38, Ryan Sleevi wrote:
> On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham via dev-security-policy <
> Thanks for organizing this information, as much of it was related to and
> relevant to Google's recent announcement. I want to take this opportunity
> to share additional details regarding the interactions for UniCredit, which
> I believe may be useful and relevant both for understanding that issue and
> the GeoTrust audits.

Thank you for this. I will attempt to integrate it into the document and
I'm sure we will hear comments from Symantec on it.

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