as my understanding, one of LCAs of KISA was audited by WebTrust regulations.
CrossCert, they have partnership with Verisign and also they are LCA of KISA. I think, at least one of LCAs is enough to be included into Mozilla Root Repository. 2014년 3월 5일 수요일 오전 4시 38분 24초 UTC+9, Kathleen Wilson 님의 말: > 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
