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
