On Mon, October 26, 2015 11:55 pm, mycho...@gmail.com wrote: > Korea has e-signature Act, Decree and Ordinance. E-Signature act also > contains several administration rules and one of administration rules is a > âguideline for CPSâ. Root CA/Sub-CAs controlled by government has to > follow the 'guideline for CPS' when build or revise its CPS. > > So, structure of contents in CPS is different from RFC 3647, however, all > contents required by RFC 3647 are contained. > > Minyoun
It seems worthwhile to separate this out a little. You have a CA hierarchy, of which some CAs are subject to local law that conflicts with the Baseline Requirements and Mozilla CA policy. These CAs are not essential to your application - that is, there is no business reason or need for your e-signature intermediate to be included or recognized as trusted by Mozilla. Indeed, it would seem that, given the conflict, it would be desirable for your e-signature CA NOT to be trusted (transitively/indirectly), given that there are conflicting requirements. There seem to be two options to resolve this conflict: A) Mozilla accepts your local laws as superceding those of the Baseline Requirements and Mozilla Policy B) You adjust your application to only be for that of your SSL/website CA, rather than your root CA (government operated), which transitively includes your e-signature intermediate (subject to local laws regarding CPS structure) Option A has a number of downsides for Mozilla and the community that relies upon the Mozilla Trust Store. The most obvious is that it sets a framework for local jurisdictions to set requirements counter to Mozilla and that being acceptable. I would say that would significantly undermine trust in general in the Mozilla Root Store and its policies, so that would not be a desirable outcome. However, it also puts the burden of work on the Mozilla user community to review your application. While I'm sure there is genuine good faith belief that your CPS covers all of the necessary requirements of RFC 3647, that's a claim that will need to be independently evaluated by anyone who wishes to review your policy for conformance to the Baseline Requirements and to Mozilla policy. That is traditionally a significant amount of work, so it's somewhat of an unreasonable request for the community. Option B appears not to have been fully explored yet, so I'd like to spell out how that could look. This works by shifting the burden of work from the community (to map your CPS back to 3647) to your CA. Rather than applying for inclusion of your root (which is governed by your countries e-signature law), you should instead apply for inclusion of your SSL intermediate, treating it 'as if' it was a root that was cross-signed but otherwise independent. In doing so, you would also develop a separate CP/CPS for this intermediate. This CP/CPS would be in the form of RFC 3647, and would fully conform to the Baseline Requirements. When your CA is audited, you would have your e-signature root and intermediates audited to your e-signature requirements, and your SSL intermediate audited to your SSL CP/CPS (aka the Baseline Requirements and Mozilla Policy). Further, the onus of transliteration of your policies would shift from the community to you, as you would need to demonstrate to your auditor and the supervisors of the e-signature program that your RFC 3647-compliant policy is consistent with the overarching policies of your government-operated root. Option B is not a new option for CAs; indeed, it's what is practiced whenever a CA operates both public and private CA hierarchies that have different business needs/requirements, and arguably is quite similar to how commercial cross-signatures work, since multiple CPSes are in play, and each subordinate CPS needs to be consistent with the cross-signer's main CPS. It would be helpful to know why Option B would not be viable, or, if it is, why it wouldn't be desirable. It's understandable that we're talking about a spectrum of cost, and who bears that cost - whether the relying parties who participate in the maintenance of the Mozilla Root Store, or whether it's borne by the CA applying for inclusion. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
