Re: Policy about root cert transfers
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 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
I misspoke, go daddy. On Tue, Jun 23, 2015, 12:30 PM Robin Alden ro...@comodo.com 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
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
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
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
Re: Policy about root cert transfers
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
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
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
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 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
Re: Policy about root cert transfers
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 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
Re: Policy about root cert transfers
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 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
Re: Policy about root cert transfers
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
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
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 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
Re: Policy about root cert transfers
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 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
Re: Policy about root cert transfers
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
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
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 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
Re: Policy about root cert transfers
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
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
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
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 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
Re: Policy about root cert transfers
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
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
