Let me start with the Webtrust audit the Crosscert got. The Webtrust audit Crosscert received is for the Verisign service they are offering. For your information, Crosscert is also a sub-CA of Verisign. However, two systems(KISA and Verisign) are seperately operated and the audit does not cover the area of KISA’s certificates. This is Crosscert’s business to operate Verisign service so KISA does not care about it as long as it does not effect KISA’s certificates.
KISA is designated by law to do the actual auditing of CAs(for the KISA’s certificates) and the audit criteria are all from the act, decree, ordinance and regulations from them(Korea Electronic Signature Act). I believe for several years what KISA was convincing Mozilla was that how KISA audits the sub-CAs and the Mozilla’s request was KISA getting a Webtrust. Now we got a webtrust (https://cert.webtrust.org/ViewSeal?id=1622). If you are requesting for the Sub-CAs Webtrust now, it will be very disappointing issue to delay the entire time-line we were expecting(since we were trying to include KISA certificate from 2006). As you may or may not know every accredited CA in Korea is strictly ruled by the government.(that’s why they are designated ’accredited’).Any accident or security matter, Korean government will respond directly. And for your information, KISA’s certificate is already included at MS IE, APLLE Safari, OPERA and also Android OS several years ago. And of course, Korea electronic signature act, decree, ordinance and regulations fulfill the Mozilla’s requirements(I believe that's what we were trying to convince Mozilla through bugzilla ever since year 2006). Samuel 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
