Dear Samuel,
What is important for us is that both KISA and all it's SubCAs comply
with the CA/Browser baseline requirements. Please see
https://cabforum.org/baseline-requirements/
Can you confirm that there is an audit that checks those requirements?
Or confirm that there is no such audit?
Kurt
On 2014-03-06 10:37, [email protected] wrote:
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. A
nd of c
ourse, 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
