Re: Policy about root cert transfers

[Kathleen Wilson]

All,

Thank you for your thoughtful feedback on the new wiki page.
And I apologize for the delay in my response, due to my summer vacation.

I have updated the wiki page in an effort to incorporate all of your 
feedback:


https://wiki.mozilla.org/CA:RootTransferPolicy

+ Added a second paragraph to the "Root Transfer Policy" section.
+ Added the third paragraph to "Change in Legal Ownership"
+ Re-wrote the first paragraph of "Physical Relocation"
+ In all sections I tried to resolve the confusing dual use of CA (by 
using the word organization where it made sense)



I hope the changes are headed in the right direction, and I look forward 
to your feedback.


Thanks,
Kathleen



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

Re: Policy about root cert transfers

[Brian Howson]

I misspoke, go daddy.

On Tue, Jun 23, 2015, 12:30 PM Robin Alden  wrote:

>
> Brian Howson said..
> >  . I'm not sure if this should be additions to the
> > original inclusion request or a new request, that might depend on whether
> it is
> > wholesale (like today's Digicert acquisition of Verizon) or piecemeal
> (like the
> > one root Amazon acquired from Comodo).
>
> Amazon have not acquired a root from Comodo.
>
> Regards
> Robin Alden
> Comodo
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Policy about root cert transfers

[Robin Alden]

Brian Howson said..
>  . I'm not sure if this should be additions to the
> original inclusion request or a new request, that might depend on whether
it is
> wholesale (like today's Digicert acquisition of Verizon) or piecemeal
(like the
> one root Amazon acquired from Comodo).  

Amazon have not acquired a root from Comodo.

Regards
Robin Alden
Comodo

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

Re: Policy about root cert transfers

[bkhowson]

On Tuesday, June 2, 2015 at 1:44:59 PM UTC-4, Kathleen Wilson wrote:
> On 6/1/15 4:13 PM, David E. Ross wrote:
> > On 6/1/2015 2:45 PM, Kathleen Wilson wrote:
> >> On 5/29/15 4:55 PM, David E. Ross wrote:
> >>> On 5/29/2015 2:16 PM, Kathleen Wilson wrote:
>  On 5/28/15 7:53 PM, David E. Ross wrote:
> >> I have started the wiki page for this, and I will appreciate your
> >> feedback on it.
> >>
> >> https://wiki.mozilla.org/CA:RootTransferPolicy
> >>
> >> Thanks,
> >> Kathleen
> >>
> >
> >
> 
> 
> I've re-written the "Change in Legal Ownership" section. Please send me 
> feedback on the new version, and let me know if this is heading in the 
> right direction.
> 
> https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership
> 
> Thanks,
> Kathleen

Hello Kathleen,
 One request as a user/observer is that any transfers should result in a 
bug request like a new root inclusion.  I'm not sure if this should be 
additions to the original inclusion request or a new request, that might depend 
on whether it is wholesale (like today's Digicert acquisition of Verizon) or 
piecemeal (like the one root Amazon acquired from Comodo).  In any case, 
barring confidentiality requests at Mozilla's judgement, transfers should be 
public because any recourse would be time critical.


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

Re: Policy about root cert transfers

[Moudrick M. Dadashov]

Peter, a while back a well known [bank industry] supervisor here has 
stated: "ethics and moral are not of dimensions this world".


So, how about a more realistic scenario where TeliaSonera buys whatever 
foreign legislation needed for its baby CA in Estonia?


Since our 3 years discussion on this list I'm personally in favor of 
pure technocratic approach:
- define what constitutes the critical infrastructure (e.g. 
communication channels, network access/management, application service 
delivery);
- name management/ownership/operational conditions under which the 
infrastructure should not be considered "publicly trusted".


Of course, this implies full disclosure of business organization in 
terms of the infrastructure building blocks above.


Thanks,
M.D.

On 6/3/2015 1:29 AM, Peter Kurrasch wrote:

‎Further to David's points, I'm wondering how far Mozilla would be willing to 
go when a controversial transfer is proposed. Is removal from the trust store 
on the table?

For example suppose DigiNotar wants to get back in the cert business and buys 
up GoDaddy, what would we do then?


   Original Message
From: David E. Ross‎
Sent: Tuesday, June 2, 2015 4:32 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy about root cert transfers

On 6/2/2015 10:44 AM, Kathleen Wilson wrote:

I've re-written the "Change in Legal Ownership" section. Please send me
feedback on the new version, and let me know if this is heading in the
right direction.

https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership

Thanks,
Kathleen



That section does not address the case when ownership of the
organization changes with the new owner retaining the old owner's
physical facilities and personnel but with new organizational policies.
My 40+ years as a computer programmer and a software test engineer
(prior to retirement) shows that this is a very real situation; I
experienced this more than once.

If the organization's policies change, that might include the CP/CPS.
Even if those two documents do not change, higher-level organizational
policy changes might impact adherence to the CP/CPS. Thus, a change of
ownership of either the certification authority or a root certificate
requires some review by Mozilla beyond what is proposed.

Furthermore, I do think customers of the old certification authority
must be informed of the change of ownership. This is standard practice
for banks, physicians, attorneys, and other entities where trust between
the provider of a service and its customers is important. By
"customers", I would include both subscribers (notified by the old
owner) and end-users (notified here in mozilla.dev.security.policy).






smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Peter Kurrasch]

‎Further to David's points, I'm wondering how far Mozilla would be willing to 
go when a controversial transfer is proposed. Is removal from the trust store 
on the table? 

For example suppose DigiNotar wants to get back in the cert business and buys 
up GoDaddy, what would we do then?


  Original Message  
From: David E. Ross‎
Sent: Tuesday, June 2, 2015 4:32 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy about root cert transfers

On 6/2/2015 10:44 AM, Kathleen Wilson wrote:
> 
> I've re-written the "Change in Legal Ownership" section. Please send me 
> feedback on the new version, and let me know if this is heading in the 
> right direction.
> 
> https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership
> 
> Thanks,
> Kathleen
> 
> 

That section does not address the case when ownership of the
organization changes with the new owner retaining the old owner's
physical facilities and personnel but with new organizational policies.
My 40+ years as a computer programmer and a software test engineer
(prior to retirement) shows that this is a very real situation; I
experienced this more than once.

If the organization's policies change, that might include the CP/CPS.
Even if those two documents do not change, higher-level organizational
policy changes might impact adherence to the CP/CPS. Thus, a change of
ownership of either the certification authority or a root certificate
requires some review by Mozilla beyond what is proposed.

Furthermore, I do think customers of the old certification authority
must be informed of the change of ownership. This is standard practice
for banks, physicians, attorneys, and other entities where trust between
the provider of a service and its customers is important. By
"customers", I would include both subscribers (notified by the old
owner) and end-users (notified here in mozilla.dev.security.policy).

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[David E. Ross]

On 6/2/2015 10:44 AM, Kathleen Wilson wrote:
> 
> I've re-written the "Change in Legal Ownership" section. Please send me 
> feedback on the new version, and let me know if this is heading in the 
> right direction.
> 
> https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership
> 
> Thanks,
> Kathleen
> 
> 

That section does not address the case when ownership of the
organization changes with the new owner retaining the old owner's
physical facilities and personnel but with new organizational policies.
 My 40+ years as a computer programmer and a software test engineer
(prior to retirement) shows that this is a very real situation; I
experienced this more than once.

If the organization's policies change, that might include the CP/CPS.
Even if those two documents do not change, higher-level organizational
policy changes might impact adherence to the CP/CPS.  Thus, a change of
ownership of either the certification authority or a root certificate
requires some review by Mozilla beyond what is proposed.

Furthermore, I do think customers of the old certification authority
must be informed of the change of ownership.  This is standard practice
for banks, physicians, attorneys, and other entities where trust between
the provider of a service and its customers is important.  By
"customers", I would include both subscribers (notified by the old
owner) and end-users (notified here in mozilla.dev.security.policy).

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Kathleen Wilson]

On 6/1/15 4:13 PM, David E. Ross wrote:

On 6/1/2015 2:45 PM, Kathleen Wilson wrote:

On 5/29/15 4:55 PM, David E. Ross wrote:

On 5/29/2015 2:16 PM, Kathleen Wilson wrote:

On 5/28/15 7:53 PM, David E. Ross wrote:

I have started the wiki page for this, and I will appreciate your
feedback on it.

https://wiki.mozilla.org/CA:RootTransferPolicy

Thanks,
Kathleen







I've re-written the "Change in Legal Ownership" section. Please send me 
feedback on the new version, and let me know if this is heading in the 
right direction.


https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership

Thanks,
Kathleen


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

Re: Policy about root cert transfers

[David E. Ross]

On 6/1/2015 2:45 PM, Kathleen Wilson wrote:
> On 5/29/15 4:55 PM, David E. Ross wrote:
>> On 5/29/2015 2:16 PM, Kathleen Wilson wrote:
>>> On 5/28/15 7:53 PM, David E. Ross wrote:
> I have started the wiki page for this, and I will appreciate your
> feedback on it.
>
> https://wiki.mozilla.org/CA:RootTransferPolicy
>
> Thanks,
> Kathleen
>


 Does the line beginning "In all of these cases, the CA should take ..."
 apply only to Physical Relocation?  If not, the section beginning with
 that line should have its own section header.

 It appears that some of the numbered items apply only to Physical
 Relocation while others also apply to Change in Legal Ownership.  This
 appears implied by the statement under Personnel Changes.  All of this
 is confusing.

>>>
>>> I updated the wiki page to hopefully make it more clear.
>>>
>>> Thanks,
>>> Kathleen
>>>
>>
>> Under "Change in Legal Ownership", how will Mozilla assure its users
>> that the new owner is competent to operate as a certification authority?
>>   How quickly will Mozilla assure itself and its users that the new owner
>> is at least as trustworthy as the old owner?  How quickly will users be
>> informed of the change of ownership?
>>
> 
> 
> The "Change in Legal Ownership" section is short because a change in 
> ownership in itself is not particularly interesting to me. It becomes 
> interesting to me if the change in ownership means that the root 
> certificate's private key will be physically moved, and/or that the 
> organization (people) operating the root certificate and hierarchy will 
> change.
> 
> So, in answer to your questions...
> 
>>> Under "Change in Legal Ownership", how will Mozilla assure its users
>>> that the new owner is competent to operate as a certification authority?
>>> How quickly will Mozilla assure itself and its users that the new owner
>>> is at least as trustworthy as the old owner?
> 
> See the "Personnel Changes" section:
> "the CA who is transferring the operation of the PKI must ensure that 
> the transfer recipient is able to fully comply with Mozilla’s CA 
> Certificate Policy. The original CA will continue to be responsible for 
> the root certificate until the new organization has provided Mozilla 
> with their Primary Point of Contact, CP/CPS documentation, and audit 
> statement confirming successful transfer of the root."
> 
>>> How quickly will users be
>>> informed of the change of ownership?
> 
> Not sure what you're asking for here...
> 
> Are you saying we should add a requirement for the CAs to notify their 
> customers?
> 
> Or are you asking that there be an announcement in 
> mozilla.dev.security.policy whenever such a change has happened?
> 
> Kathleen
> 
> 
> 

No, I disagree that a change of ownership is a change of personnel.  I
have worked as an employee through three changes in the ownership of my
employer without seeing a change in the technical personnel.  However,
each change of ownership involved wholesale changes in policies and
practices.  In one other case, I worked for a software contractor at a
NASA facility where all the contracting companies were terminated; but
some of the contractor's employees immediately went to work directly for
NASA.  Thus, changing ownership of a certification authority (an
organization) or of a root certificate is not necessarily covered by
Personnel Changes.

Now that I think of it, any of the three -- Change in Legal Ownership,
Physical Relocation, and Personnel Changes -- should indeed be announced
here in mozilla.dev.security.policy; this is where individual who might
be concerned about such a change or know of an adverse impact from the
change would be a subscriber.  Furthermore, since any such change might
mean different costs for subscribers to renew a certificate, different
domains for E-mail and downloading intermediate certificates, different
technical help contacts, or a conflict of business interests, the (old)
certification authority should indeed notify its customers.

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Kathleen Wilson]

On 5/29/15 4:55 PM, David E. Ross wrote:

On 5/29/2015 2:16 PM, Kathleen Wilson wrote:

On 5/28/15 7:53 PM, David E. Ross wrote:

I have started the wiki page for this, and I will appreciate your
feedback on it.

https://wiki.mozilla.org/CA:RootTransferPolicy

Thanks,
Kathleen




Does the line beginning "In all of these cases, the CA should take ..."
apply only to Physical Relocation?  If not, the section beginning with
that line should have its own section header.

It appears that some of the numbered items apply only to Physical
Relocation while others also apply to Change in Legal Ownership.  This
appears implied by the statement under Personnel Changes.  All of this
is confusing.



I updated the wiki page to hopefully make it more clear.

Thanks,
Kathleen



Under "Change in Legal Ownership", how will Mozilla assure its users
that the new owner is competent to operate as a certification authority?
  How quickly will Mozilla assure itself and its users that the new owner
is at least as trustworthy as the old owner?  How quickly will users be
informed of the change of ownership?




The "Change in Legal Ownership" section is short because a change in 
ownership in itself is not particularly interesting to me. It becomes 
interesting to me if the change in ownership means that the root 
certificate's private key will be physically moved, and/or that the 
organization (people) operating the root certificate and hierarchy will 
change.


So, in answer to your questions...


Under "Change in Legal Ownership", how will Mozilla assure its users
that the new owner is competent to operate as a certification authority?
How quickly will Mozilla assure itself and its users that the new owner
is at least as trustworthy as the old owner?


See the "Personnel Changes" section:
"the CA who is transferring the operation of the PKI must ensure that 
the transfer recipient is able to fully comply with Mozilla’s CA 
Certificate Policy. The original CA will continue to be responsible for 
the root certificate until the new organization has provided Mozilla 
with their Primary Point of Contact, CP/CPS documentation, and audit 
statement confirming successful transfer of the root."



How quickly will users be
informed of the change of ownership?


Not sure what you're asking for here...

Are you saying we should add a requirement for the CAs to notify their 
customers?


Or are you asking that there be an announcement in 
mozilla.dev.security.policy whenever such a change has happened?


Kathleen



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

Re: Policy about root cert transfers

[Wayne Thayer]

I agree with Peter that the policy shouldn’t detail the steps for Physical 
Relocation. As written, it seems to confuse offline roots with online 
issuing CAs that are typically housed in a data center. Moving a CA’s 
online operations to a new data center is quite different from moving 
parts of an offline root from one location to another, the latter being 
something that happens regularly for the purposes of signing new issuing 
CAs, CRLs, etc.




On 5/30/15, 8:25 AM, "Peter Bowen"  wrote:

>On Thu, May 28, 2015 at 7:53 PM, David E. Ross  
>wrote:
>> On 5/28/2015 4:32 PM, Kathleen Wilson wrote:
>>> I have started the wiki page for this, and I will appreciate your
>>> feedback on it.
>>>
>>> https://wiki.mozilla.org/CA:RootTransferPolicy
>>
>> It appears that some of the numbered items apply only to Physical
>> Relocation while others also apply to Change in Legal Ownership.  This
>> appears implied by the statement under Personnel Changes.  All of this
>> is confusing.
>
>Separately there is transport of the "physical" embodiment of the CA
>-- that is transport of the private key between locations.  This could
>occur due to a transfer of the CA or due to normal operations of the
>CA.
>
>WebTrust for CAs requires "the storage of required cryptographic
>materials (i.e., secure cryptographic device and activation materials)
>at an alternate location" for business continuity purposes, so every
>WebTrust CA will at some point have to transport the private key
>between locations.  I suspect ETSI has a similar requirement.
>
>With this requirement in mind, I don't think it makes sense for
>Mozilla to specify a transport procedure or process in detail.
>Rather, I would simply focus on the fact that the WebTrust (or ETSI)
>requirements apply at all times, even during transport.  So the CA
>must ensure that "physical access to CA [...] equipment is limited to
>authorized individuals",the equipment "is operated under multiple
>person (at least dual custody) control", and "unauthorized CA system
>usage is [able to be] detected" at all times.  The auditor must
>confirm that there are appropriate procedures in place ensure that the
>requirements are met and those procedures are followed.  This is
>already required by the overall Mozilla CA policy, so I don't think a
>supplemental policy is needed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Peter Bowen]

On Thu, May 28, 2015 at 7:53 PM, David E. Ross  wrote:
> On 5/28/2015 4:32 PM, Kathleen Wilson wrote:
>> I have started the wiki page for this, and I will appreciate your
>> feedback on it.
>>
>> https://wiki.mozilla.org/CA:RootTransferPolicy
>
> It appears that some of the numbered items apply only to Physical
> Relocation while others also apply to Change in Legal Ownership.  This
> appears implied by the statement under Personnel Changes.  All of this
> is confusing.

I agree it is confusing.  I've read it several times and am still not clear.

I think one of the reasons that it is not clear is that the term "CA"
gets used for multiple things:
1) The entity that operates one or more CAs
2) A single CA which has policies, practices, procedures
3) The key pair and Distinguished Name of the single CA

The concept of a "root transfer" could include transferring one, two,
or three of these things.

In one case, control of the entity that operates CAs is transferred as
a whole.  This could be due to corporate sale or due to reorganization
of a larger entity (e.g. a Government operated CA moves from one
ministry or department to another ministry or department).  The
existing entity does not change.

In a second case, the entity currently operating the CA decides to no
longer operate the CA and transfers the whole thing (policies,
practices, procedures and keys) to a new entity.  The original entity
continues to exist and carry out other business, which may or may not
include operating other CAs.

In the third case, the entity currently operating the CA decides to
transfer the key and right to the Distinguished Name (and possibly
right to the policy object identifier for EV policies) to another
entity.  The new entity establishes its own policies, practices, and
procedures.

The last two cases could be seen as the same thing, as a CA can change
their policies, practices, and procedures at any time, so the last
case could be the second case with an immediate change in policy.

This is where I would focus the root transfer policy.  When legal
control of a given CA changes, what is required?  Must the entity that
formerly controlled the CA notify Mozilla?  Must the new entity notify
Mozilla?  How must the notification be provided?  What information
must be provided?  What information must be public and what
information is held confidential by Mozilla?  I don't see these
covered in the wiki and these seem like critical items for the policy.


Separately there is transport of the "physical" embodiment of the CA
-- that is transport of the private key between locations.  This could
occur due to a transfer of the CA or due to normal operations of the
CA.

WebTrust for CAs requires "the storage of required cryptographic
materials (i.e., secure cryptographic device and activation materials)
at an alternate location" for business continuity purposes, so every
WebTrust CA will at some point have to transport the private key
between locations.  I suspect ETSI has a similar requirement.

With this requirement in mind, I don't think it makes sense for
Mozilla to specify a transport procedure or process in detail.
Rather, I would simply focus on the fact that the WebTrust (or ETSI)
requirements apply at all times, even during transport.  So the CA
must ensure that "physical access to CA [...] equipment is limited to
authorized individuals",the equipment "is operated under multiple
person (at least dual custody) control", and "unauthorized CA system
usage is [able to be] detected" at all times.  The auditor must
confirm that there are appropriate procedures in place ensure that the
requirements are met and those procedures are followed.  This is
already required by the overall Mozilla CA policy, so I don't think a
supplemental policy is needed.

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

Re: Policy about root cert transfers

[David E. Ross]

On 5/29/2015 2:16 PM, Kathleen Wilson wrote:
> On 5/28/15 7:53 PM, David E. Ross wrote:
>>> I have started the wiki page for this, and I will appreciate your
>>> feedback on it.
>>>
>>> https://wiki.mozilla.org/CA:RootTransferPolicy
>>>
>>> Thanks,
>>> Kathleen
>>>
>>
>>
>> Does the line beginning "In all of these cases, the CA should take ..."
>> apply only to Physical Relocation?  If not, the section beginning with
>> that line should have its own section header.
>>
>> It appears that some of the numbered items apply only to Physical
>> Relocation while others also apply to Change in Legal Ownership.  This
>> appears implied by the statement under Personnel Changes.  All of this
>> is confusing.
>>
> 
> I updated the wiki page to hopefully make it more clear.
> 
> Thanks,
> Kathleen
> 

Under "Change in Legal Ownership", how will Mozilla assure its users
that the new owner is competent to operate as a certification authority?
 How quickly will Mozilla assure itself and its users that the new owner
is at least as trustworthy as the old owner?  How quickly will users be
informed of the change of ownership?

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Kathleen Wilson]

On 5/28/15 7:53 PM, David E. Ross wrote:

I have started the wiki page for this, and I will appreciate your
feedback on it.

https://wiki.mozilla.org/CA:RootTransferPolicy

Thanks,
Kathleen




Does the line beginning "In all of these cases, the CA should take ..."
apply only to Physical Relocation?  If not, the section beginning with
that line should have its own section header.

It appears that some of the numbered items apply only to Physical
Relocation while others also apply to Change in Legal Ownership.  This
appears implied by the statement under Personnel Changes.  All of this
is confusing.



I updated the wiki page to hopefully make it more clear.

Thanks,
Kathleen

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

Re: Policy about root cert transfers

[David E. Ross]

On 5/28/2015 4:32 PM, Kathleen Wilson wrote:
> On 5/6/15 11:58 AM, Kathleen Wilson wrote:
>> On 4/23/15 4:21 PM, Kathleen Wilson wrote:
>>> All,
>>>
>>> It has been brought to my attention that we do not have a documented
>>> procedure or policy about how to transfer a root certificate from one CA
>>> to another.
>>>
>>> Do we need to add expectations about root cert transfers to Mozilla's CA
>>> Certificate Policy?
>>>
>>> I think, at the minimum, we should add information about our
>>> expectations to one of our process wiki pages, or maybe this needs its
>>> own wiki page?
>>>
>>
>> Thanks to all of you who have contributed to this discussion so far. You
>> have given me a lot to think about, so it will take me a bit longer to
>> respond with a proposal.
>>
>> I am currently thinking that we should have a separate wiki page about
>> this topic. The page should outline the different ways the ownership of
>> a root certificate may change, and our expectations.
>>
>> Thanks,
>> Kathleen
>>
> 
> 
> I have started the wiki page for this, and I will appreciate your 
> feedback on it.
> 
> https://wiki.mozilla.org/CA:RootTransferPolicy
> 
> Thanks,
> Kathleen
> 


Does the line beginning "In all of these cases, the CA should take ..."
apply only to Physical Relocation?  If not, the section beginning with
that line should have its own section header.

It appears that some of the numbered items apply only to Physical
Relocation while others also apply to Change in Legal Ownership.  This
appears implied by the statement under Personnel Changes.  All of this
is confusing.

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Kathleen Wilson]

On 5/6/15 11:58 AM, Kathleen Wilson wrote:

On 4/23/15 4:21 PM, Kathleen Wilson wrote:

All,

It has been brought to my attention that we do not have a documented
procedure or policy about how to transfer a root certificate from one CA
to another.

Do we need to add expectations about root cert transfers to Mozilla's CA
Certificate Policy?

I think, at the minimum, we should add information about our
expectations to one of our process wiki pages, or maybe this needs its
own wiki page?



Thanks to all of you who have contributed to this discussion so far. You
have given me a lot to think about, so it will take me a bit longer to
respond with a proposal.

I am currently thinking that we should have a separate wiki page about
this topic. The page should outline the different ways the ownership of
a root certificate may change, and our expectations.

Thanks,
Kathleen




I have started the wiki page for this, and I will appreciate your 
feedback on it.


https://wiki.mozilla.org/CA:RootTransferPolicy

Thanks,
Kathleen

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

Re: Policy about root cert transfers

[Kathleen Wilson]

On 4/23/15 4:21 PM, Kathleen Wilson wrote:

All,

It has been brought to my attention that we do not have a documented
procedure or policy about how to transfer a root certificate from one CA
to another.

Do we need to add expectations about root cert transfers to Mozilla's CA
Certificate Policy?

I think, at the minimum, we should add information about our
expectations to one of our process wiki pages, or maybe this needs its
own wiki page?



Thanks to all of you who have contributed to this discussion so far. You 
have given me a lot to think about, so it will take me a bit longer to 
respond with a proposal.


I am currently thinking that we should have a separate wiki page about 
this topic. The page should outline the different ways the ownership of 
a root certificate may change, and our expectations.


Thanks,
Kathleen

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

Re: Policy about root cert transfers

[David E. Ross]

I forgot to include the following point.

On 4/24/2015 11:32 PM, David E. Ross wrote:
> 
> However, all certification authorities whose root certificates are in
> the NSS database have indeed undergone community review.  

How else can you explain that a single request to Mozilla from a
certification authority can encompass more than a single root of that
authority?  I have been following the reviews of such requests for a
number of years.  A certification authority owning more than one root
does not submit a separate request for each root; only a single
bugzilla.mozilla.org bug report is submitted.  The review is collective,
covering the overall certification authority and its multiple roots.
Furthermore, the audit reports required by Mozilla address the entire
certification authority.

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[David E. Ross]

On 4/24/2015 10:14 PM, Ryan Sleevi wrote:
> On Fri, April 24, 2015 7:52 pm, David E. Ross wrote:
>>  If a root has already been added to the NSS database, we must assume
>>  that it has undergone the Mozilla process for that inclusion.  The
>>  process involves looking not only at the root but also at the
>>  certification authority; at least that is what appears in both the
>>  public discussion of the request to add the root and in the stream of
>>  comments in the bugzilla.mozilla.org bug report that initiates the
>>  request.
>>
>>  If a root in the NSS database is transferred to a new owner and that new
>>  owner already has roots in the NSS database, I assert the new owner has
>>  already undergone sufficient scrutiny.  I limit my assertion, however,
>>  to cases where the transferred root has characteristics (e.g., trust
>>  bits, EV status) in common with roots already owned by the new owner.
>>  That is for example, I would not accept EV status on a transferred root
>>  if none of the other roots of the new owner have EV status.
>>
>>  We trusted the old owner of the root and we trust the new owner.  Thus,
>>  we can trust the transferred root to the minimum level we trusted the
>>  two owners.  In the environment of OpenPGP, this is analogous to the Web
>>  of Trust.
> 
> I know this is how you want it to work, and how people naively think it
> works, but it isn't how it works.
> 
> I tried to make the logical reasoning as explicit as possible:
> 
> - If a root is added to the Mozilla store, it is because it wants to issue
> publicly trusted certs.
> - The community cares about the entities issuing publicly trusted certs.
> - However, not all organizations that can issue publicly trusted certs go
> through community review.
> - Therefore, there are organizations who can issue publicly trusted certs
> that do not go through community review.
> 
> Thus any argument that says "All organizations that issue publicly trusted
> certs are community reviewed" is false, both demonstrably and in practice,
> and arguments predicated on this can be shown to be based on a mistaken
> assumption.
> 
> Your ascription of trust to the organization, rather than the root, also
> mistakenly understands what the community review process does. The *WHO*
> of the organization is entirely irrelevant, according to the policy. It is
> the *WHAT* they're doing that matters. If the WHAT does not change, then
> it should not matter that the WHO changes.
> 
> Again, I thought this was spelled out, but the community review is of
> policies and practices, not people. We don't keep the brown-eyed CAs out
> to the benefit of the blue-eyed CAs, we don't keep the non-American out
> for the American, we don't take the brands we use every day versus the
> brands we've never heard of. That's not the community review. It may be
> how you review, but it just means that those arguments are ignored,
> because that's not how the policy works.
> 
> If you find this still unsettling or uncomfortable, then the exercise is
> what I asked of you originally - demonstrate how this functionally differs
> from a root that signs an intermediate with "CA:TRUE" capability.
> 
> Under the current policy, the root is required to:
> 1) Disclose the intermediate
> 2) Disclose the CP/CPS
> 3) Disclose the audit, which they must have
> 
> That is the current standard for what "Capable of issuing trusted
> certificates" must meet. How does this differ - purely on a technical
> level? It doesn't.
> 

However, all certification authorities whose root certificates are in
the NSS database have indeed undergone community review.  My assertion
about trusting the new owner of a transferred root that is already in
the NSS database is limited to a new owner whose other roots are also in
the NSS database.

I already indicated that, if the new owner does not already have roots
in the NSS database, the transferred root should not be trusted.  I also
indicated that, if the new owner already has roots in the NSS database
but the transferred root has higher trust settings than any of the other
roots of the new owner, then the transferred root can have only trust
settings not greater than the new owner's other roots.

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Ryan Sleevi]

On Fri, April 24, 2015 7:52 pm, David E. Ross wrote:
>  If a root has already been added to the NSS database, we must assume
>  that it has undergone the Mozilla process for that inclusion.  The
>  process involves looking not only at the root but also at the
>  certification authority; at least that is what appears in both the
>  public discussion of the request to add the root and in the stream of
>  comments in the bugzilla.mozilla.org bug report that initiates the
>  request.
>
>  If a root in the NSS database is transferred to a new owner and that new
>  owner already has roots in the NSS database, I assert the new owner has
>  already undergone sufficient scrutiny.  I limit my assertion, however,
>  to cases where the transferred root has characteristics (e.g., trust
>  bits, EV status) in common with roots already owned by the new owner.
>  That is for example, I would not accept EV status on a transferred root
>  if none of the other roots of the new owner have EV status.
>
>  We trusted the old owner of the root and we trust the new owner.  Thus,
>  we can trust the transferred root to the minimum level we trusted the
>  two owners.  In the environment of OpenPGP, this is analogous to the Web
>  of Trust.

I know this is how you want it to work, and how people naively think it
works, but it isn't how it works.

I tried to make the logical reasoning as explicit as possible:

- If a root is added to the Mozilla store, it is because it wants to issue
publicly trusted certs.
- The community cares about the entities issuing publicly trusted certs.
- However, not all organizations that can issue publicly trusted certs go
through community review.
- Therefore, there are organizations who can issue publicly trusted certs
that do not go through community review.

Thus any argument that says "All organizations that issue publicly trusted
certs are community reviewed" is false, both demonstrably and in practice,
and arguments predicated on this can be shown to be based on a mistaken
assumption.

Your ascription of trust to the organization, rather than the root, also
mistakenly understands what the community review process does. The *WHO*
of the organization is entirely irrelevant, according to the policy. It is
the *WHAT* they're doing that matters. If the WHAT does not change, then
it should not matter that the WHO changes.

Again, I thought this was spelled out, but the community review is of
policies and practices, not people. We don't keep the brown-eyed CAs out
to the benefit of the blue-eyed CAs, we don't keep the non-American out
for the American, we don't take the brands we use every day versus the
brands we've never heard of. That's not the community review. It may be
how you review, but it just means that those arguments are ignored,
because that's not how the policy works.

If you find this still unsettling or uncomfortable, then the exercise is
what I asked of you originally - demonstrate how this functionally differs
from a root that signs an intermediate with "CA:TRUE" capability.

Under the current policy, the root is required to:
1) Disclose the intermediate
2) Disclose the CP/CPS
3) Disclose the audit, which they must have

That is the current standard for what "Capable of issuing trusted
certificates" must meet. How does this differ - purely on a technical
level? It doesn't.

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

Re: Policy about root cert transfers

[David E. Ross]

On 4/24/2015 8:58 AM, Ryan Sleevi wrote [in part]:
> On Fri, April 24, 2015 8:20 am, I previously wrote [also in part]:
>>  2.  If the new owner is a certification authority whose root
>>  certificates already exist in the NSS database, that root will continued
>>  to be considered trusted.  However, trust bits and EV status of the
>>  transferred root cannot exceed the collective trust and EV status of the
>>  other roots of the new owner.  The audit cycle for the transferred root
>>  will be changed to match that of its new owner.
> 
> This, of course, makes no sense, as this is not how audits or trust bits
> work. Trust bits are not granted to the organization, they're granted on
> the contingency of the CP, CPS, and certificate.
> 
> An organization can have a DV and EV root. That doesn't mean new
> certificates they acquire are automatically EV, nor does it mean that if
> they only have a DV root, they cannot concurrently operate an EV root.
> 
> I strongly suggest this suggestion be ignored.
> 

If a root has already been added to the NSS database, we must assume
that it has undergone the Mozilla process for that inclusion.  The
process involves looking not only at the root but also at the
certification authority; at least that is what appears in both the
public discussion of the request to add the root and in the stream of
comments in the bugzilla.mozilla.org bug report that initiates the
request.

If a root in the NSS database is transferred to a new owner and that new
owner already has roots in the NSS database, I assert the new owner has
already undergone sufficient scrutiny.  I limit my assertion, however,
to cases where the transferred root has characteristics (e.g., trust
bits, EV status) in common with roots already owned by the new owner.
That is for example, I would not accept EV status on a transferred root
if none of the other roots of the new owner have EV status.

We trusted the old owner of the root and we trust the new owner.  Thus,
we can trust the transferred root to the minimum level we trusted the
two owners.  In the environment of OpenPGP, this is analogous to the Web
of Trust.

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Moudrick M. Dadashov]

Ok, probably many CAs would be happy with something like this:

1. If a Root cert transfer creates a new "CA", follow: 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/;
2. If a Root cert transfer doesn't create a new CA but results in 
creation of an Issuing CA (s), p. 8, 9 and 10 of the Root inclusion 
policy apply.


Would it be sufficient?

Thanks,
M.D.

On 4/24/2015 7:19 PM, Ryan Sleevi wrote:

On Fri, April 24, 2015 8:39 am, Moudrick M. Dadashov wrote:

  So I thought everybody "standing under the umbrella" is treated the same
  way.

My point is that they aren't, and they never have.


  Cross-signing scenarios may or may not result in creation of a new CA,
  probably this is the most noticeable difference.

Sure. I'm using cross-signing interchangably with "signing an
unconstrained intermediate", since they are procedurally identical from
the point of view of the issuing CA (that is, you're signing a certificate
with CA:TRUE), but not all certificates with "CA:TRUE" are treated equally
by Mozilla, which is the point I made.


  Whatever they do, a Mozilla applicant must be a CA by definition, right?
  Therefore the clarification of HOWs below is definitely useful in the
  process of transferring-gaining the "new CA" status but shouldn't be
  considered as an alternative Root inclusion option.

Yes, all Mozilla applicants must be CAs.
My point is that not all CAs must be Mozilla applicants.

Having an existing CA sign your "CA:TRUE" certificate is a way to avoid
becoming a Mozilla applicant, and that has always been true, and,
honestly, I think that's actually OK.

Ergo, acquiring a "CA:TRUE" certificate, provided that the controls
required for all "CA:TRUE" certificates are met, shouldn't intrinsically
mean you must now become a Mozilla applicant.






smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Ryan Sleevi]

On Fri, April 24, 2015 8:39 am, Moudrick M. Dadashov wrote:
>  So I thought everybody "standing under the umbrella" is treated the same
>  way.

My point is that they aren't, and they never have.

>  Cross-signing scenarios may or may not result in creation of a new CA,
>  probably this is the most noticeable difference.

Sure. I'm using cross-signing interchangably with "signing an
unconstrained intermediate", since they are procedurally identical from
the point of view of the issuing CA (that is, you're signing a certificate
with CA:TRUE), but not all certificates with "CA:TRUE" are treated equally
by Mozilla, which is the point I made.

>  Whatever they do, a Mozilla applicant must be a CA by definition, right?
>  Therefore the clarification of HOWs below is definitely useful in the
>  process of transferring-gaining the "new CA" status but shouldn't be
>  considered as an alternative Root inclusion option.

Yes, all Mozilla applicants must be CAs.
My point is that not all CAs must be Mozilla applicants.

Having an existing CA sign your "CA:TRUE" certificate is a way to avoid
becoming a Mozilla applicant, and that has always been true, and,
honestly, I think that's actually OK.

Ergo, acquiring a "CA:TRUE" certificate, provided that the controls
required for all "CA:TRUE" certificates are met, shouldn't intrinsically
mean you must now become a Mozilla applicant.

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

Re: Policy about root cert transfers

[Ryan Sleevi]

On Fri, April 24, 2015 8:20 am, David E. Ross wrote:
>  2.  If the new owner is a certification authority whose root
>  certificates already exist in the NSS database, that root will continued
>  to be considered trusted.  However, trust bits and EV status of the
>  transferred root cannot exceed the collective trust and EV status of the
>  other roots of the new owner.  The audit cycle for the transferred root
>  will be changed to match that of its new owner.

This, of course, makes no sense, as this is not how audits or trust bits
work. Trust bits are not granted to the organization, they're granted on
the contingency of the CP, CPS, and certificate.

An organization can have a DV and EV root. That doesn't mean new
certificates they acquire are automatically EV, nor does it mean that if
they only have a DV root, they cannot concurrently operate an EV root.

I strongly suggest this suggestion be ignored.

>  3.  If the new owner does not already have root certificates in the NSS
>  database, the transferred root must be immediately marked as untrusted
>  until the new owner undergoes the existing process for adding new roots
>  to the NSS database.  Provision should be made for initiating that
>  process for the new owner prior to the transfer in order to avoid any
>  hiatus in the transferred root's trust, including giving priority in
>  consideration ahead of other roots in the pipeline.  However, the
>  prospective new owner -- not Mozilla -- is responsible for initiating
>  the process.

This equally does not make sense, as I addressed elsewhere on the list.


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

Re: Policy about root cert transfers

[Moudrick M. Dadashov]

On 4/24/2015 5:30 PM, Ryan Sleevi wrote:

On Fri, April 24, 2015 6:34 am, Moudrick M. Dadashov wrote:

  Kathleen, wouldn't be it easier to apply the transferred CA the same
  requirements as to any other? That means the new CA must have its
  operations audited under its ***fully completed transfer*** operations.

  The root and all associated intermediates must pass audit against
  ***then applicable*** requirements only after having the CP/CPS clearly
  disclosing the details/nature of the transfer.

When you say "the same requirements as any other" - are there
fundamentally any differences here than a CA cross-signing a new root
certificate?
Ryan, I don't know how fundamentally different those CAs are but we all 
have agreed that CA is "An organization that is responsible for the 
creation, issuance, revocation, and management of Certificates. The term 
applies equally to both Roots CAs and Subordinate CAs".


So I thought everybody "standing under the umbrella" is treated the same 
way.


Cross-signing scenarios may or may not result in creation of a new CA, 
probably this is the most noticeable difference.



Are there fundamentally ay differences here than a CA signing a new
unconstrained intermediate?

I think that is truly the crux of the question, and frankly, I don't think
there is. We have two standards for "organizations capable of causing
certificate issuance"

- Those who apply to Mozilla and wish to be single-handedly responsible
for their destiny.
- Those who find another CA who will sign their certificate, and thus
avoid Mozilla review.
Whatever they do, a Mozilla applicant must be a CA by definition, right? 
Therefore the clarification of HOWs below is definitely useful in the 
process of transferring-gaining the "new CA" status but shouldn't be 
considered as an alternative Root inclusion option.


Thanks,
M.D.



In exchange for not having to do the Mozilla process (or any other root
processes), they lose their independence. For example, their "partner CA"
may decide a year later to charge them 10X what they originally stated,
and there's nothing the CA can do, other than accept their "partner CAs"
extortion (er, contract renegotiation based on changing business
conditions). No business likes having that sword hanging over their head,
but at the same time, it's "nice" to not have to rely on the unreliable
Mozilla community to do a timely review.

Similarly, the "partner CA" takes on risk that by allowing the CA to avoid
Mozilla review, the CA may botch things, and that will cause the "partner
CA" to suffer.

So it's a set of trade-offs, but it's unquestionably a double standard.

J don't see having the double standards as necessarily a bad thing either
- it recognizes the business realities, such that no organization likes to
wait on 30 different root stores and 30 different timeframes before they
can conduct business. On the Mozilla side, being volunteer driven, the
timelines vary wildly, and the thoroughness of review varies wildly. I
think in recent months, we've all become more attune to the thoroughness,
but I know I personally still greatly struggle with the timeliness.
Kathleen's the one consistent performer through all of this, which is
necessary, but not sufficient.

This is the long-winded way of saying I think Kathleen's proposals make
perfect sense. I don't think it introduces any new risks to the community
that are not inherently there, while offering a sensible path forward that
recognizes the tradeoffs.

As the community and process approves, and things like "disclosed sub-CA"
becomes some thing maintained automatically by CAs, we'll be in a better
place to align the two processes. Then, if someone wants to start a CA,
they can either block on the community review (new CA) or the community
can rely on an external party (the "partner CA") to do the initial review,
knowing their financially incentivized to do it 'right', and then the
community can review "after the fact" and take appropriate action.

In either event, full transparency is there, and full review is possible
at any time, so I don't think there's any harm Kathleen's proposal. At
best, for those nervous about the "community review" phase, we could just
tack on an added "Oh, and you have to tell moz.dev.security.policy after
you did this, rather than just updating your URL with the disclosure", and
we can go on our merry way at our leisure.

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





smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[David E. Ross]

On 4/23/2015 4:21 PM, Kathleen Wilson wrote:
> All,
> 
> It has been brought to my attention that we do not have a documented 
> procedure or policy about how to transfer a root certificate from one CA 
> to another.
> 
> Do we need to add expectations about root cert transfers to Mozilla's CA 
> Certificate Policy?
> 
> I think, at the minimum, we should add information about our 
> expectations to one of our process wiki pages, or maybe this needs its 
> own wiki page?
> 
> Here's what I usually tell CAs when they ask:
> 
> 1) I recommend creating a transfer agreement and have it reviewed by the 
> auditors for both the current and the new CA.
> 
> 2) New cert issuance (at the current CA's site) should be stopped before 
> the transfer begins.
> 
> 3) There should be an audit performed at the current CA's site to 
> confirm when the root certificates is ready for transfer.
> 
> 4) Before the new CA begins issuing certs in the transferred CA cert 
> hierarchy, there should be an audit performed at the new CA's site to 
> confirm that the transfer was successful and that the root cert is ready 
> to resume issuance.
> 
> 5) The regular annual audit statements are still expected to happen 
> within a timely manner, or the root cert may be removed.
> 
> 6) Keep the Mozilla CA Certificate Module Owner appraised of the status 
> of these steps, and inform immediately if a problem occurs.
> 
> 
> I will appreciate your thoughtful and constructive input on this topic.
> 
> Kathleen
> 

If "transfer" involves a change of ownership, whether the new owner is
trustworthy must be the first consideration.  Thus, I suggest any policy
provide:

1.  Mozilla must be informed of any change of ownership of a root
certificate before any new intermediate or subscriber certificates are
signed such they chain to that root.

2.  If the new owner is a certification authority whose root
certificates already exist in the NSS database, that root will continued
to be considered trusted.  However, trust bits and EV status of the
transferred root cannot exceed the collective trust and EV status of the
other roots of the new owner.  The audit cycle for the transferred root
will be changed to match that of its new owner.

3.  If the new owner does not already have root certificates in the NSS
database, the transferred root must be immediately marked as untrusted
until the new owner undergoes the existing process for adding new roots
to the NSS database.  Provision should be made for initiating that
process for the new owner prior to the transfer in order to avoid any
hiatus in the transferred root's trust, including giving priority in
consideration ahead of other roots in the pipeline.  However, the
prospective new owner -- not Mozilla -- is responsible for initiating
the process.

-- 
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Policy about root cert transfers

[Ryan Sleevi]

On Fri, April 24, 2015 7:25 am, Ben Wilson wrote:
>  Kathleen,
>  I think we need to drill down into what is meant by "audit".  Also, I
>  don't
>  think a CA who is under ongoing audit obligations should have a special
>  "audit" just for a root transfer.  Neither should the current CA that is
>  operating under audit be required to have a special audit.  If two
>  entities
>  (A and B), operating CAs under the WebTrust requirements and both approved
>  as operators by Mozilla transfer root key from A to B, then the only thing
>  required should be documented custody and procedural controls that are
>  audited.  So one audit - that A and B observed stated custody controls and
>  security procedures when they effectuated the transfer from one location
>  to
>  another.  Also, let's assume, for the sake of discussion, that the root
>  key
>  transfer can be done through a secure VPN tunnel in an encrypted and
>  controlled fashion with an out-of-band transfer of activation data for the
>  encapsulated key, such that the key moves halfway around the world without
>  physical courier.  What then?
>  Ben

Just trying to combine the points raised from many threads (and I think
you've got good points here, Ben), let's see if we've got the permutations
of concerns covered.

Note - many of these dimensions are not *presently* things that factor in
to the Mozilla policy, but it's clear that some people in the list wish to
at least discuss whether or not they're worth distinguishing, so trying to
cover for completeness.

Dimension 1 - Who currently holds the key?
- Existing CA with a current audit
- Existing CA with an out of date audit, but within the 'grace' window
that is implicitly allowed but explicitly discouraged

Dimension 2 - What is the state of the current key holder?
- Currently practicing business
- Business in some form sale
- Business in some form of liquidation / receivership
- Business in the process of being acquired
- Business that has been acquired
- Out of business [is this possible while still holding assets?]

Dimension 3 - Who is the organization receiving the key?
- Entity that operationally controls an existing CA recognized by Mozilla
   - And has a current audit
   - And has an expired audit
- Entity that has no pre-existing relationship with Mozilla

Dimension 4 - Who operates the organization receiving the key?
- Government entity
- Incorporated business nominally controlled by government entity
- Independent business
[Not sure if we can actually make the distinctions, but it's come up in
the past CA policy discussions]

Dimension 5 - How will the key be delivered?
- Physical transfer of existing HSM
- FIPS 140 Level 3 compliant key wrapping, single-delivery
- FIPS 140 Level 3 compliant key wrapping, multi-party
- Non-FIPS 140 Level 3 compliant key wrapping

Dimension 6 - Who will oversee the execution of the transfer? [which is
really like 3 or 4 dimensions, but bear with me]
- Nobody; no ceremony documented not recorded
- Nobody; no ceremony documented, but recorded
- Nobody; ceremony documented, but not witnessed
- Nobody; ceremony documented and recorded, but not witnessed
- Auditors; no ceremony documented, but witnessed
- Auditors, ceremony documented and witnessed

Are there more nuances? I don't know. Should Mozilla policy cover what to
do in all these cases? I should hope not. Are there things we should
mandate? Maybe. Are there principals we can take away from these? I should
hope so.

FWIW, my own take would be the transfer ceremony would have a documented
ceremony and witnessed by auditors AND recorded (for posterity), with a
physical exchange of the HSM and a physical exchange of the multi-party
authorization keys.

Regardless of whether it's an existing CA or a new CA, I would want a
PITRA for the new holder.

If the existing audit has lapsed, then I consider it game over for that
root - you cannot execute a transfer; the existing holder MUST bring their
audit current, MUST notify Mozilla, and MUST have the lapse evaluated
according to the existing guidelines BEFORE executing such a transfer.

I think the biggest challenge here is the "physical exchange" requirement.
This is inherently a violation of the BR + Network Security requirements
on physical access controls, as the HSM is in-transit away from a secure
facility. I suspect there's some possible provision to be made here. I
consider a key-wrap solution to be undesirable, because of unknown
eavesdropping that cannot be quantified (no matter how many MPLS+VPNs you
make, Five Eyes is watching you). Are the auditors supposed to ride across
the country / across the world in an armored vehicle carrying the HSM? I
don't know.


Of course, the alternative to this degree of complexity is to not treat it
as an exchange of the existing key, but a key rollover-like event. Rather
than transferring the HSM, the existing holder signs a certificate for the
new holder (with the new holder having done all the appropriate ceremonies
an

RE: Policy about root cert transfers

[Brown, Wendy (10421)]

Kathleen -
I agree with the others who have requested you define the meaning of "root cert 
transfer" first.  Because if it is physical relocation, but the management 
remains the same and the CA/PKI is under annual audit this should be part of 
what is covered by the next audit.

This is very different from a management change due to new ownership, but the 
same technical management of a CA continues vs other types of transfer.

Thanks,
Wendy

Wendy Brown
Protiviti Government Services
703-299-4705 (office)703-965-2990 (cell)

wendy.br...@protiviti.com



NOTICE: Protiviti is a global consulting and internal audit firm composed of 
experts specializing in risk and advisory services. Protiviti is not licensed 
or registered as a public accounting firm and does not issue opinions on 
financial statements or offer attestation services. This electronic mail 
message is intended exclusively for the individual or entity to which it is 
addressed. This message, together with any attachment, may contain confidential 
and privileged information. Any views, opinions or conclusions expressed in 
this message are those of the individual sender and do not necessarily reflect 
the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, 
printing, copying, retention, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please immediately 
advise the sender by reply email message to the sender and delete all copies of 
this message. Thank you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Ryan Sleevi]

On Fri, April 24, 2015 6:34 am, Moudrick M. Dadashov wrote:
>  Kathleen, wouldn't be it easier to apply the transferred CA the same
>  requirements as to any other? That means the new CA must have its
>  operations audited under its ***fully completed transfer*** operations.
>
>  The root and all associated intermediates must pass audit against
>  ***then applicable*** requirements only after having the CP/CPS clearly
>  disclosing the details/nature of the transfer.

When you say "the same requirements as any other" - are there
fundamentally any differences here than a CA cross-signing a new root
certificate?

Are there fundamentally ay differences here than a CA signing a new
unconstrained intermediate?

I think that is truly the crux of the question, and frankly, I don't think
there is. We have two standards for "organizations capable of causing
certificate issuance"

- Those who apply to Mozilla and wish to be single-handedly responsible
for their destiny.
- Those who find another CA who will sign their certificate, and thus
avoid Mozilla review.

In exchange for not having to do the Mozilla process (or any other root
processes), they lose their independence. For example, their "partner CA"
may decide a year later to charge them 10X what they originally stated,
and there's nothing the CA can do, other than accept their "partner CAs"
extortion (er, contract renegotiation based on changing business
conditions). No business likes having that sword hanging over their head,
but at the same time, it's "nice" to not have to rely on the unreliable
Mozilla community to do a timely review.

Similarly, the "partner CA" takes on risk that by allowing the CA to avoid
Mozilla review, the CA may botch things, and that will cause the "partner
CA" to suffer.

So it's a set of trade-offs, but it's unquestionably a double standard.

J don't see having the double standards as necessarily a bad thing either
- it recognizes the business realities, such that no organization likes to
wait on 30 different root stores and 30 different timeframes before they
can conduct business. On the Mozilla side, being volunteer driven, the
timelines vary wildly, and the thoroughness of review varies wildly. I
think in recent months, we've all become more attune to the thoroughness,
but I know I personally still greatly struggle with the timeliness.
Kathleen's the one consistent performer through all of this, which is
necessary, but not sufficient.

This is the long-winded way of saying I think Kathleen's proposals make
perfect sense. I don't think it introduces any new risks to the community
that are not inherently there, while offering a sensible path forward that
recognizes the tradeoffs.

As the community and process approves, and things like "disclosed sub-CA"
becomes some thing maintained automatically by CAs, we'll be in a better
place to align the two processes. Then, if someone wants to start a CA,
they can either block on the community review (new CA) or the community
can rely on an external party (the "partner CA") to do the initial review,
knowing their financially incentivized to do it 'right', and then the
community can review "after the fact" and take appropriate action.

In either event, full transparency is there, and full review is possible
at any time, so I don't think there's any harm Kathleen's proposal. At
best, for those nervous about the "community review" phase, we could just
tack on an added "Oh, and you have to tell moz.dev.security.policy after
you did this, rather than just updating your URL with the disclosure", and
we can go on our merry way at our leisure.

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

RE: Policy about root cert transfers

[Ben Wilson]

Kathleen,
I think we need to drill down into what is meant by "audit".  Also, I don't
think a CA who is under ongoing audit obligations should have a special
"audit" just for a root transfer.  Neither should the current CA that is
operating under audit be required to have a special audit.  If two entities
(A and B), operating CAs under the WebTrust requirements and both approved
as operators by Mozilla transfer root key from A to B, then the only thing
required should be documented custody and procedural controls that are
audited.  So one audit - that A and B observed stated custody controls and
security procedures when they effectuated the transfer from one location to
another.  Also, let's assume, for the sake of discussion, that the root key
transfer can be done through a secure VPN tunnel in an encrypted and
controlled fashion with an out-of-band transfer of activation data for the
encapsulated key, such that the key moves halfway around the world without
physical courier.  What then?
Ben

>
>-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Kurt Roeckx
Sent: Friday, April 24, 2015 1:37 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy about root cert transfers
>
>On 2015-04-24 01:21, Kathleen Wilson wrote:
>>
>> 4) Before the new CA begins issuing certs in the transferred CA cert 
>> hierarchy, there should be an audit performed at the new CA's site to 
>> confirm that the transfer was successful and that the root cert is 
>> ready to resume issuance.
>
>Would this be a point in time readiness audit, like we expect any new root
to be audited?
>
>
>Kurt
>
>


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Moudrick M. Dadashov]

Kathleen, wouldn't be it easier to apply the transferred CA the same 
requirements as to any other? That means the new CA must have its 
operations audited under its ***fully completed transfer*** operations.


The root and all associated intermediates must pass audit against 
***then applicable*** requirements only after having the CP/CPS clearly 
disclosing the details/nature of the transfer.


Thanks,
M.D.

On 4/24/2015 3:49 PM, Peter Kurrasch wrote:

I don't think a transfer action by a CA should be treated as an automatic 
accept ‎by the security community. The purpose of the root certs and thus the 
CA program is to establish and maintain trust in an organization and it's 
policies and procedures. From my perspective this means the transfer recipient 
first must establish that trust and, second, must provide evidence that the 
transfer itself will be performed in a secure and/or trustworthy manner.

As has already been pointed out there are different types of transfers to 
consider, each with its own conditions and concerns:

 a) legal ownership transfer, such as when one company buys out another. 
For example, if Symantec were to assign ownership of all their roots to the US 
military, is it reasonable that we be expected to transfer the trust we'd 
previously extended to Symantec?

 b) physical relocation. For example, if the plan is to drop the private 
keys in a FedEx envelope and send it across the country we have every reason to 
expect the NSA to intercept that package.

 c) changes in "key personnel". For example if the head of the new 
organization previously ran a sausage factory and has no experience in PKI, I don't think 
we'd necessarily want to trust that transfer.


So, just some thoughts to get the conversation going. I don't so much have a 
problem with what you've suggested, Kathleen, but I think it's worth taking a 
step back first and identify the cases we even want to address.


   Original Message
From: Kathleen Wilson
Sent: Thursday, April 23, 2015 6:38 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy about root cert transfers

On 4/23/15 4:21 PM, Kathleen Wilson wrote:

All,

It has been brought to my attention that we do not have a documented
procedure or policy about how to transfer a root certificate from one CA
to another.

Do we need to add expectations about root cert transfers to Mozilla's CA
Certificate Policy?

I think, at the minimum, we should add information about our
expectations to one of our process wiki pages, or maybe this needs its
own wiki page?

Here's what I usually tell CAs when they ask:

1) I recommend creating a transfer agreement and have it reviewed by the
auditors for both the current and the new CA.

2) New cert issuance (at the current CA's site) should be stopped before
the transfer begins.

3) There should be an audit performed at the current CA's site to
confirm when the root certificates is ready for transfer.

4) Before the new CA begins issuing certs in the transferred CA cert
hierarchy, there should be an audit performed at the new CA's site to
confirm that the transfer was successful and that the root cert is ready
to resume issuance.

5) The regular annual audit statements are still expected to happen
within a timely manner, or the root cert may be removed.

6) Keep the Mozilla CA Certificate Module Owner appraised of the status
of these steps, and inform immediately if a problem occurs.


I will appreciate your thoughtful and constructive input on this topic.

Kathleen


Things to add:

7) The new CA must follow Mozilla's policy, and provide public-facing
CP/CPS documentation and audit statements. So, the new CA has to send
Mozilla the URLs to those.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

8) The agreement between the current and new CAs should take the trust
bit settings into account (Websites (SSL/TLS), Email (S/MIME), and Code
Signing), and the current and new CAs should inform Mozilla's CA
Certificate Module Owner if one or more of the trust bits should be
turned off. Of course, to turn a trust bit on requires the new CA to go
through Mozilla's root change process -
https://wiki.mozilla.org/CA:How_to_apply#Enable_Additional_Trust_Bits_for_an_included_root

Kathleen




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





smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy about root cert transfers

[Peter Kurrasch]

I don't think a transfer action by a CA should be treated as an automatic 
accept ‎by the security community. The purpose of the root certs and thus the 
CA program is to establish and maintain trust in an organization and it's 
policies and procedures. From my perspective this means the transfer recipient 
first must establish that trust and, second, must provide evidence that the 
transfer itself will be performed in a secure and/or trustworthy manner.

As has already been pointed out there are different types of transfers to 
consider, each with its own conditions and concerns:

    a) legal ownership transfer, such as when one company buys out another. For 
example, if Symantec were to assign ownership of all their roots to the US 
military, is it reasonable that we be expected to transfer the trust we'd 
previously extended to Symantec? 

    b) physical relocation. For example, if the plan is to drop the private 
keys in a FedEx envelope and send it across the country we have every reason to 
expect the NSA to intercept that package.

    c) changes in "key personnel". For example if the head of the new 
organization previously ran a sausage factory and has no experience in PKI, I 
don't think we'd necessarily want to trust that transfer.


So, just some thoughts to get the conversation going. I don't so much have a 
problem with what you've suggested, Kathleen, but I think it's worth taking a 
step back first and identify the cases we even want to address.


  Original Message  
From: Kathleen Wilson
Sent: Thursday, April 23, 2015 6:38 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy about root cert transfers

On 4/23/15 4:21 PM, Kathleen Wilson wrote:
> All,
>
> It has been brought to my attention that we do not have a documented
> procedure or policy about how to transfer a root certificate from one CA
> to another.
>
> Do we need to add expectations about root cert transfers to Mozilla's CA
> Certificate Policy?
>
> I think, at the minimum, we should add information about our
> expectations to one of our process wiki pages, or maybe this needs its
> own wiki page?
>
> Here's what I usually tell CAs when they ask:
>
> 1) I recommend creating a transfer agreement and have it reviewed by the
> auditors for both the current and the new CA.
>
> 2) New cert issuance (at the current CA's site) should be stopped before
> the transfer begins.
>
> 3) There should be an audit performed at the current CA's site to
> confirm when the root certificates is ready for transfer.
>
> 4) Before the new CA begins issuing certs in the transferred CA cert
> hierarchy, there should be an audit performed at the new CA's site to
> confirm that the transfer was successful and that the root cert is ready
> to resume issuance.
>
> 5) The regular annual audit statements are still expected to happen
> within a timely manner, or the root cert may be removed.
>
> 6) Keep the Mozilla CA Certificate Module Owner appraised of the status
> of these steps, and inform immediately if a problem occurs.
>
>
> I will appreciate your thoughtful and constructive input on this topic.
>
> Kathleen


Things to add:

7) The new CA must follow Mozilla's policy, and provide public-facing 
CP/CPS documentation and audit statements. So, the new CA has to send 
Mozilla the URLs to those.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

8) The agreement between the current and new CAs should take the trust 
bit settings into account (Websites (SSL/TLS), Email (S/MIME), and Code 
Signing), and the current and new CAs should inform Mozilla's CA 
Certificate Module Owner if one or more of the trust bits should be 
turned off. Of course, to turn a trust bit on requires the new CA to go 
through Mozilla's root change process - 
https://wiki.mozilla.org/CA:How_to_apply#Enable_Additional_Trust_Bits_for_an_included_root

Kathleen




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

Re: Policy about root cert transfers

[Gervase Markham]

On 24/04/15 08:17, Man Ho (Certizen) wrote:
> The term "transfer" a root certificate is new to me. What are the
> rationale of such transferal? Move from one location to another
> location, or from one HSM to another HSM? Ownership of the CA had
> changed from one organization to another organization?

It's normally due to the latter (ownership change), and so may involve
the first (location move). I believe it's unlikely to involve the second
(HSM change), as roots are sold "HSM included" :-)

Gerv

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

Re: Policy about root cert transfers

[Kurt Roeckx]

On 2015-04-24 01:21, Kathleen Wilson wrote:


4) Before the new CA begins issuing certs in the transferred CA cert
hierarchy, there should be an audit performed at the new CA's site to
confirm that the transfer was successful and that the root cert is ready
to resume issuance.


Would this be a point in time readiness audit, like we expect any new 
root to be audited?



Kurt

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

Re: Policy about root cert transfers

[Man Ho (Certizen)]

On 4/24/2015 7:21 AM, Kathleen Wilson wrote:
> how to transfer a root certificate from one CA to another
The term "transfer" a root certificate is new to me. What are the
rationale of such transferal? Move from one location to another
location, or from one HSM to another HSM? Ownership of the CA had
changed from one organization to another organization?

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

RE: Policy about root cert transfers

[Yuhong Bao]

> On 4/23/15 4:21 PM, Kathleen Wilson wrote:
> > All,
> >
> > It has been brought to my attention that we do not have a documented
> > procedure or policy about how to transfer a root certificate from one CA
> > to another.
> >
> > Do we need to add expectations about root cert transfers to Mozilla's CA
> > Certificate Policy?
> >
> > I think, at the minimum, we should add information about our
> > expectations to one of our process wiki pages, or maybe this needs its
> > own wiki page?
> >
> > Here's what I usually tell CAs when they ask:
> >
> > 1) I recommend creating a transfer agreement and have it reviewed by the
> > auditors for both the current and the new CA.
> >
> > 2) New cert issuance (at the current CA's site) should be stopped before
> > the transfer begins.
> >
> > 3) There should be an audit performed at the current CA's site to
> > confirm when the root certificates is ready for transfer.
> >
> > 4) Before the new CA begins issuing certs in the transferred CA cert
> > hierarchy, there should be an audit performed at the new CA's site to
> > confirm that the transfer was successful and that the root cert is ready
> > to resume issuance.
> >
> > 5) The regular annual audit statements are still expected to happen
> > within a timely manner, or the root cert may be removed.
> >
> > 6) Keep the Mozilla CA Certificate Module Owner appraised of the status
> > of these steps, and inform immediately if a problem occurs.
> >
> >
> > I will appreciate your thoughtful and constructive input on this topic.
> >
> > Kathleen
> 
> 
> Things to add:
> 
> 7) The new CA must follow Mozilla's policy, and provide public-facing 
> CP/CPS documentation and audit statements. So, the new CA has to send 
> Mozilla the URLs to those.
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
> 
> 8) The agreement between the current and new CAs should take the trust 
> bit settings into account (Websites (SSL/TLS), Email (S/MIME), and Code 
> Signing), and the current and new CAs should inform Mozilla's CA 
> Certificate Module Owner if one or more of the trust bits should be 
> turned off. Of course, to turn a trust bit on requires the new CA to go 
> through Mozilla's root change process - 
> https://wiki.mozilla.org/CA:How_to_apply#Enable_Additional_Trust_Bits_for_an_included_root
> 
> Kathleen
Also I am thinking to make sure the key material is properly secured when the 
root is being transferred.

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

Re: Policy about root cert transfers

[Kathleen Wilson]

On 4/23/15 4:21 PM, Kathleen Wilson wrote:

All,

It has been brought to my attention that we do not have a documented
procedure or policy about how to transfer a root certificate from one CA
to another.

Do we need to add expectations about root cert transfers to Mozilla's CA
Certificate Policy?

I think, at the minimum, we should add information about our
expectations to one of our process wiki pages, or maybe this needs its
own wiki page?

Here's what I usually tell CAs when they ask:

1) I recommend creating a transfer agreement and have it reviewed by the
auditors for both the current and the new CA.

2) New cert issuance (at the current CA's site) should be stopped before
the transfer begins.

3) There should be an audit performed at the current CA's site to
confirm when the root certificates is ready for transfer.

4) Before the new CA begins issuing certs in the transferred CA cert
hierarchy, there should be an audit performed at the new CA's site to
confirm that the transfer was successful and that the root cert is ready
to resume issuance.

5) The regular annual audit statements are still expected to happen
within a timely manner, or the root cert may be removed.

6) Keep the Mozilla CA Certificate Module Owner appraised of the status
of these steps, and inform immediately if a problem occurs.


I will appreciate your thoughtful and constructive input on this topic.

Kathleen



Things to add:

7) The new CA must follow Mozilla's policy, and provide public-facing 
CP/CPS documentation and audit statements. So, the new CA has to send 
Mozilla the URLs to those.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

8) The agreement between the current and new CAs should take the trust 
bit settings into account (Websites (SSL/TLS), Email (S/MIME), and Code 
Signing), and the current and new CAs should inform Mozilla's CA 
Certificate Module Owner if one or more of the trust bits should be 
turned off. Of course, to turn a trust bit on requires the new CA to go 
through Mozilla's root change process - 
https://wiki.mozilla.org/CA:How_to_apply#Enable_Additional_Trust_Bits_for_an_included_root


Kathleen




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