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
