On 3/4/2014 11:38 AM, 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 >
Minuimally, KISA should publish (make public) the audit criteria KISA uses when auditing the subordinate CAs. This should be done prior to concluding the review of KISA for inclusion in the NSS database. The review of KISA should then include a review of those criteria. Furthermore, it should become a standing requirement on KISA that, when KISA itself is audited, there must be a review by its auditors on how thorough KISA audits those subordinate CAs and whether KISA indeed applies all the published criteria. -- David E. Ross <http://www.rossde.com/> On occasion, I filter and ignore all newsgroup messages posted through GoogleGroups via Google's G2/1.0 user agent because of spam, flames, and trolling from that source. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
