So I understand: - KISA itself operates the South Korean governement CA - There other CAs in Korea (LCAs), and they are private organizations that are audited and signed by KISA. - Those LCAs are not audited to comply with the baseline requirements, or it's at least not clear they are.
I see no reason to accept it if they're not required to comply with the baseline requirements. I really suggest those LCAs should instead apply for inclusion themself. About the contraining to *.kr. I don't see why you want to do that. I understand that anybody can go to a one of those LCAs and ask for a certificate for anything, and that it doesn't have anything to do with the governement. So I fail to see why that certificate should be for .kr. Kurt On Tue, Mar 04, 2014 at 11:38:24AM -0800, Kathleen Wilson wrote: > All, > > I will appreciate your input on how to proceed with the KISA root > inclusion request. > > My personal preference is to proceed with the process to > approve/include the KISA root under the condition that Mozilla would > constrain the CA hierarchy to *.kr. However, KISA does not want to > constrain their CA hierarchy to *.kr. I have also suggested that > KISA have each subCA apply for inclusion as separate trust anchors, > but KISA does not want to take that approach either. > > The following is my understanding of this CA. > > Inclusion Request Bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=335197 > CA Information Document: > https://bugzilla.mozilla.org/attachment.cgi?id=727859 > KISA document repository: > http://www.rootca.or.kr/kor/accredited/accredited02.jsp > CPS (English): > http://www.rootca.or.kr/kor/down/cps16(en).pdf > > Korea Information Security Agency (KISA) is the Electronic Signature > Authorization Management Center for South Korea. The Korean > Certification Authority Central (KCAC) of KISA issues certificates > to intermediate CAs (licensed CAs = LCAs), which then issue > end-entity certificates to Korean citizens, businesses, and other > organizations. The LCAs are private organizations (not government > organizations). > > The LCAs are listed in Korean at > http://www.rootca.or.kr/kor/accredited/accredited02.jsp > They are: > Korea Information Certificate Authority Inc (KICA), http://www.signgate.com > KICA CPS (Korean): http://www.signgate.com/customer/cus_cps.sg > Korea Securities Computer Corporation (KOSCOM), http://www.signkorea.com > KOSCOM CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479655 > Korea Electronic Certification Authority Inc (CrossCert), > http://gca.crosscert.com > CrossCert CPS (English): > https://bugzilla.mozilla.org/attachment.cgi?id=479658 > KTNET ("TradeSign" or "KITA"), http://www.tradesign.net/ > TradeSign CPS (English): > https://bugzilla.mozilla.org/attachment.cgi?id=479659 > Korea Financial Telecommunications (KFTC), http://www.yessign.or.kr > (non-profit) > KFTC CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479657 > > Deloitte completed a WebTrust audit of KISA's operation of the root, > but the subordinate CAs (LCAs) are not WebTrust audited. The LCAs > are regulated by the Korean Electronic Signature Act, and the law > requires that KISA does the actual examination of the LCAs and > report their findings to the government. The evaluation (audit) > criteria are attached to the Bugzilla bug. > Electronic Signature Act: > https://bugzilla.mozilla.org/attachment.cgi?id=594638 > Enforcement Decree: > https://bugzilla.mozilla.org/attachment.cgi?id=594639 > Enforcement Regulations: > https://bugzilla.mozilla.org/attachment.cgi?id=594640 > > The LCAs are annually audited and are not allowed to change anything > (system, h/w, s/w) without reporting to the government, and any > mis-issuance of certificates would lead to penalty by the Act. > > The Korean government controls the policies and technical standards > under the Electronic Signature Act. Although the actual auditing is > done by KISA, all the results are reported to the ministry > (currently the Ministry of Science, ICT and future Planning). KISA > is an expert group to help the ministry for the actual examination > and other expertise for the national PKI. KISA is an affiliated > organization of the ministry, and is run by the government. All the > orders to control the LCAs are from the ministry. > > Note that KISA is also the National Internet resources Center of > Korea, http://krnic.kisa.or.kr/jsp/english/krnic/intro.jsp > > We need to take into account sections 8 through 14 of Mozilla's CA > Certificate Inclusion Policy: > http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ > > Section 10 says that if the subordinate CA certificate is not > technically constrained (as described in section 9) then the > subordinate CA must be audited according to sections 11 through 14. > So, according to section 11 the subordinate CA operations must be > audited according to the WebTrust CA or ETSI TS 102 042 criteria, > and must also be audited according to the Baseline Requirements (the > websites trust bit is requested). > > My questions... > > How would we know that the criteria that KISA uses to audit their > LCAs is inclusive of the versions of the WebTrust or ETSI criteria > that Mozilla's policy requires? > > How would we know that the criteria that KISA uses to audit their > LCAs is inclusive of the Baseline Requirements audit criteria that > Mozilla requires? > > Based on the above information, is there sufficient evidence to > assert that the people within KISA who are performing the audits of > the LCAs are qualified to do so, and are acting as an independent > party as described in sections 13 and 14 of Mozilla's CA Certificate > Inclusion Policy? > > If KISA's root was to be included, should Mozilla products constrain > the KISA hierarchy to *.kr? Why? Why not? > > I will greatly appreciate your thoughtful input into how to proceed > with this CA's root inclusion request. > > 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
