335197 - Add KISA root CA Certificate

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task, P2)

Description

[ikjeun]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

Please add Korea Information Security Agency(KISA) root CA certificates to your certificate store.

KISA was established by the Informaton Facilitation ACT No.14 in April, 1996
and it is operation the Supreme Authorizing Organization, the Electronic Signature Authorization Management Center, for making up safe and trustful environments of using electronic signature.

We currently have been accepted by Microsoft and our root CA certificate was included in Window XP in the Feb 24 2006.
To to this, we passed the WebTrust CA Audit last year.
You can test our certificate from this root certificate in :
 https://www.rootca.or.kr/mark/rootca.html

We wants to submit 3 root CA certificates.

Our certificates, CRLs and Certificate Practice Statement can be obtained here ;


Cert1 ==> ldap://dirsys.rootca.or.kr:389/CN=CertRSA01,OU=ROOTCA,O=KISA,C=KR
          (SHA-1 thumbprint : f5 c2 7c f5 ff f3 02 9a cf 1a 1a 4b ec 7e e1 96 4c 77 d7 84)
Cert2 ==> http://www.rootca.or.kr/certs/root-rsa-3280.der
	  (SHA-1 thumbprint : 02 72 68 29 3e 5f 5d 17 aa a4 b3 c3 e6 36 1e 1f 92 57 5e aa)
Cert3 ==> ldap://dirsys.rootca.or.kr:389/cn=KISA RootCA 3, ou=Korea Certification Authority Central, o=KISA, c=KR
          (SHA-1 thumbprint : 5f 4e 1f cf 31 b7 91 3b 85 0b 54 f6 e5 ff 50 1a 2b 6f c6 cf)

CRL of Cert1 ==> ldap://dirsys.rootca.or.kr:389/CN=ROOT-RSA-CRL,OU=ROOTCA,O=KISA,C=KR
CRL of Cert2 ==> http://www.rootca.or.kr/certs/root-rsa-3280.crl
CRL of Cert3 ==> http://www.rootca.or.kr/certs/root-wrsa.crl

CPS ==> http://www.kisa.or.kr/kisae/kcac/jsp/kcac_70_30.jsp

KISA hopes that extended key usages of our certificate would be "Code signing","Timestamping","Server authentication",
"Client authentication","Secure Email","OCSP".

If you need any more information, please contact me :
  Inkyung Jeun([e-mail])
  Korea Information Security Agency(www.kisa.or.kr)
  82-2-405-5426
  
  

Reproducible: Always

Comment 1

[Channy Yun [:channy]]

This is Channy Yun of a korean community. Inkyung requested follow-up of this bug. Please confirm and assign to Frank. And Inkyung must prepare more informations as like #289077. Note that our current policy requires that CAs have completed a WebTrust for CAs audit or equivalent third-party audit. We have a newer policy in draft form, but it's not yet in effect; see

  http://www.hecker.org/mozilla/ca-certificate-policy

for more information.

Comment 2

[Frank Hecker]

Thank you for your interest in Mozilla. I have some questions about KISA and its root CAs:

1. Based on my reading of the KISA web site, it appears that the KISA root CAs do not issue certificates directly to end entities; instead they issue certificates only to subordinate CAs ("licensed CAs" or LCAs), and the LCAs then issue end-entity certificates. Is this correct?

2. The current list of LCAs appears to be as follows (from the web page <http://www.kisa.or.kr/kisae/kcac/jsp/kcac_80_10.jsp>):

  - Korea Information Certificate Authority Inc (KICA)
    http://www.signgate.com
  - Korea Securities Computer Corporation (KOSCOM)
    http://www.signkorea.com
  - Korea Financial Telecommunications (KFTC)
    http://www.yessign.or.kr
  - National Computerization Agency (NCA)
    http://sign.nca.or.kr
  - Korea Electronic Certification Authority Inc ("CrossCert")
    http://gca.crosscert.com
  - KTNET ("TradeSign" or "KITA")
    http://www.tradesign.net/

Is this the complete list of LCAs?

3. On the page <http://www.kisa.or.kr/kisae/kcac/jsp/kcac_70_10_list.jsp> there is a list of various CA certificates, some of which are for KISA root CAs and some of which are for LCAs. You have submitted three root CA certificates. Of these, the first root CA certificate appears to correspond to certificate number 2 in the list ("Certificate of the KCAC - RSA1") and the third certificate appears to correspond to certificate number 4 in the list ("Certificate of the KCAC - Wireless RSA"). Is the second root certificate ("root-rsa-3280.der") in the list on that web page? I cannot find it.

These are my questions thus far. I will have more questions once I have time to investigate further.

Comment 3

[ikjeun]

(In reply to comment #2)
Thank you for your advisor.
This is answer of your questions.

> 1. Based on my reading of the KISA web site, it appears that the KISA root CAs
> do not issue certificates directly to end entities; instead they issue
> certificates only to subordinate CAs ("licensed CAs" or LCAs), and the LCAs
> then issue end-entity certificates. Is this correct?
===> Correct. KISA issue certificates only to LCAs.
 
> 2. The current list of LCAs appears to be as follows (from the web page
> <http://www.kisa.or.kr/kisae/kcac/jsp/kcac_80_10.jsp>):
> 
>   - Korea Information Certificate Authority Inc (KICA)
>     http://www.signgate.com
>   - Korea Securities Computer Corporation (KOSCOM)
>     http://www.signkorea.com
>   - Korea Financial Telecommunications (KFTC)
>     http://www.yessign.or.kr
>   - National Computerization Agency (NCA)
>     http://sign.nca.or.kr
>   - Korea Electronic Certification Authority Inc ("CrossCert")
>     http://gca.crosscert.com
>   - KTNET ("TradeSign" or "KITA")
>     http://www.tradesign.net/
> 
> Is this the complete list of LCAs?
==> Correct. We have 6 LCAs.


> 3. On the page <http://www.kisa.or.kr/kisae/kcac/jsp/kcac_70_10_list.jsp> there
> is a list of various CA certificates, some of which are for KISA root CAs and
> some of which are for LCAs. You have submitted three root CA certificates. Of
> these, the first root CA certificate appears to correspond to certificate
> number 2 in the list ("Certificate of the KCAC - RSA1") and the third
> certificate appears to correspond to certificate number 4 in the list
> ("Certificate of the KCAC - Wireless RSA"). Is the second root certificate
> ("root-rsa-3280.der") in the list on that web page? I cannot find it.
==> The seconde root certificate appears to correspond to the first certificate("Certificate of the KCAC-RSA2").

If you have more questions, please do not hesitate to contact me.

Comment 4

[Frank Hecker]

(In reply to comment #3)
> ==> The seconde root certificate appears to correspond to the first
> certificate("Certificate of the KCAC-RSA2").

You are correct. For some reason when I first looked at the second root certificate I thought that its SHA-1 fingerprint did not match the fingerprint for certificate number 1 in the list at <http://www.kisa.or.kr/kisae/kcac/jsp/kcac_70_10_list.jsp>. I just looked at the two certificates again and the fingerprints do match.

So, based on the DN in the second root certificate, it appears that the certificate at <http://www.rootca.or.kr/certs/root-rsa-3280.der> can also be obtained from your directory at the following URL:

ldap://dirsys.rootca.or.kr:389/cn=KISA RootCA 1, ou=Korea
Certification Authority Central, o=KISA, c=KR 

Is this correct?

Also, do you have regular http (not ldap) URLs for the first and third root certificates?

Comment 5

[ikjeun]

(In reply to comment #4)

The second certificate(Cert2) is published only using http (http://www.rootca.or.kr/certs/root-rsa-3280.der), because we move our directory server from ldap to http server.

And,the first and third certificates can be ontained from http.
It's http url is
Cert1 : http://www.rootca.or.kr/certs/root-rsa.der
Cert3 : http://www.rootca.or.kr/certs/root-wrsa.der

Thank you.

Comment 6

[Frank Hecker]

I have been investigating the six LCAs (subordinate CAs of the KISA root CAs). Here is what I have found thus far.

* Korean Information Certificate Authority (KICA). This LCA appears to offer certificates to both individuals and organizations, including email certificates to individuals and SSL server certificates to organizations or individuals. Verification procedures for applications are as given at:

http://www.signgate.com/eng/e_support/e_sup0204.htm

and appear to require both individuals and organizations to prove their identity using government-issued documents and by other means.

* SignKorea (operated by KOSCOM). This LCA appears to offer certificates to both individuals and organizations, with a focus on supporting exchange of e-commerce documents. Verification procedures for applications are as given at:

http://www.signkorea.com/eng/05_customer/01_customer02.php#4

and appear to require both individuals and organizations to prove their identity using government-issued documents and by other means.

* Yessign (operated by KFTC). This LCA appears to offer certificates related to financial transactions; however what appears to be the CPS

http://www.yessign.or.kr/custom/sub1.htm

appears to be available only in Korean.

* National Computerization Agency (NCA). I couldn't find out anything about this LCA because the web site <http://sign.nca.or.kr> wouldn't respond.

* Korea Electronic Certification Authority Inc ("CrossCert"). There didn't appear to be an English version of the web site <http://gca.crosscert.com>, so I don't know anything more about this LCA.

* KTNET ("TradeSign" or "KITA"). There didn't appear to be an English version of the web site <http://www.tradesign.net/>, so I don't know anything more about this LCA.

Comment 7

[Frank Hecker]

At this point I have two major questions relating to KISA:

1. How do the LCAs verify the identity of applicants for certificates? I have answers for KICA and SignKorea/KOSCOM, but not for the other LCAs.

2. Where is the information on the WebTrust or other audits of KISA and/or the LCAs. I couldn't find any information about this.

I need the answers to these questions in order to approve KISA's request to have its root certificates included in Mozilla products.

Comment 8

[ikjeun]

Attachment: Korea Electronic Signature Act

Comment 9

[ikjeun]

Attachment: Korea Electronic Signature Act Enforcement Regulations

Comment 10

[ikjeun]

Sorry for late response.
> 1. How do the LCAs verify the identity of applicants for certificates? I have
> answers for KICA and SignKorea/KOSCOM, but not for the other LCAs.

LCA(Accredited CAs)s in Korea were audited and accredited by Ministry of Information and Communication(MIC) according to Article 4 of the Electronic Signature Act. Article 13.2 and Article 13.3 of the Electronic Signature Act Enforcement Regulations defines the standard method of verify the identity and the identity verification proof. And the LCAs shall faithfully abide by the articles. You can find the verification process of applicants for certificates in our regulation.

> 2. Where is the information on the WebTrust or other audits of KISA and/or the
> LCAs. I couldn't find any information about this.
 

The LCAs are audited every year by KISA according to the article 25 of the Electronic Signature Act.

And,MIC has supervised and audited every year that KISA develop his technical and physical security plans of the critical information infrastructure(CII) according to Article 6 of the Information Infrastructure Protection Act. Also, MIC has supervised that KISA faithfully implement the accredited certification practice statement. But, the security plans of CII and the audit reports about a CII can't be open to the third party, so we'd like to ask for your understanding. 
  
To install our root CA certificate to MS Windows, we submit an official document of MIC about that KISA's security plans of the CII and certificate practice are sufficient to meet those criteria of WebTrust, instead of WebTrust Audit.

For your convenient, I attached the Electronic Signature Act and Requlations.

Comment 11

[Jungshik Shin]

(In reply to comment #5)
 
> The second certificate(Cert2) is published only using http
> (http://www.rootca.or.kr/certs/root-rsa-3280.der), because we move our
> Cert1 : http://www.rootca.or.kr/certs/root-rsa.der
> Cert3 : http://www.rootca.or.kr/certs/root-wrsa.der

I'm sorry for going a bit tangential here...

Will you please 'fix' your web server configuration so that it emits the 'correct' Content-Type header field for CA certificates ('der' files). Curerntly, it's emitting 'Content-Type: text/plain', which makes it  rather inconvenient to add your ROOT CAs to firefox (instead of just clicking on their urls, I have to save them first before importing them.) . It should emit 'application/x-x509-ca-cert'. Of course, there will be no need to add them once they're included in next (major) release of firefox by default (as far as firefox users are concerned). Nonetheless,  KISA wants to be a good citizen of the Internet, doesn't it?

Comment 12

[ikjeun]

(In reply to comment #11)
Thank you for your comments.
We fixed our seb server as you said.
You can find it's modification as contect our web server.
Sincerely.

Inkyung.

Comment 13

[Channy Yun [:channy]]

Is there any update?

Comment 14

[Gervase Markham [:gerv]]

Mr Jeun,

There are a large number of outstanding CA requests, and it will take me some time to work through them. You can, should you wish, speed up the processing of your request by providing the following data in the following format, as a *plain text comment* in this bug. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates.

Some of the information may already be present in, or calculable from, data in this bug or other Mozilla-maintained documents. However, having it all in one place in a standard plain format for each request will save me a great deal of time, and help me to make everyone happier quicker. :-)

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):
  
Certificate Details
-------------------
(To be completed once for each certificate)
  
Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy
Certificate HTTP URL (on CA website):
Version:
SHA1 Fingerprint:
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL HTTP URL:
OCSP URL:
Class (domain-validated, identity-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):

Thanks for your help in this matter. :-)

Gerv

Comment 15

[Jonghyun Baek]

(In reply to comment #14)

Dear Markham,
This is Jonghyun Baek who take charge of this project from Jeun.
Thanks for your information and I send answers of your questions as follows,

CA Details 
------------------- 
CA Name: KISA Root CA
Website: http://www.rootca.or.kr
General nature: Government
Primary geographical area(s) served: Republic of Korea
Number and type of subordinate CAs: 6 CAs / Commercial (KICA, KOSCOM, Crosscert, Tradesign) and nonprofit (KFTC, NIA)
Audit Type (WebTrust, ETSI etc.): N/A
Auditor: MIC
Auditor Website: www.mic.go.kr
Audit Document URL(s): N/A
Please reference the comment #10 for audit information. 

Certificate Details 
------------------- 

1. Certificate 1
Certificate Name: CertRSA01 
Summary Paragraph, including the following: KISA issue certificates only to 6 LCAs(Licensed CAs) not for end entity
Certificate HTTP URL (on CA website): http://www.rootca.or.kr/certs/root-rsa.der 
Version: V3 
SHA1 Fingerprint: f5 c2 7c f5 ff f3 02 9a cf 1a 1a 4b ec 7e e1 96 4c 77 d7 84 
MD5 Fingerprint: N/A 
Modulus Length (a.k.a. "key length"): 2048 bits 
Valid From (YYYY-MM-DD): 2000-03-03 
Valid To (YYYY-MM-DD): 2010-03-03 
CRL HTTP URL: http://www.rootca.or.kr/certs/root-rsa-2459.crl 
OCSP URL: N/A 
Class (domain-validated, identity-validated or EV): Both Domain-Validated and Identity-Validated 
Certificate Policy URL: http://www.rootca.or.kr/kisae/kcac/jsp/kcac_70_30.jsp 
CPS URL: http://www.rootca.or.kr/kisae/kcac/jsp/kcac_70_30.jsp 
Requested Trust Indicators (email and/or SSL and/or code): Code signing, Timestamping, Server authentication, Client authentication, Secure Email, OCSP 

------------------- 
2. Certificate 2
Certificate Name: KISA RootCA 1
Summary Paragraph, including the following: KISA issue certificates only to 6 LCAs(Licensed CAs) not for end entity
 - End entity certificate issuance policy 
Certificate HTTP URL (on CA website): http://www.rootca.or.kr/certs/root-rsa.der 
Version: V3 
SHA1 Fingerprint: 02 72 68 29 3e 5f 5d 17 aa a4 b3 c3 e6 36 1e 1f 92 57 5e aa 
MD5 Fingerprint: N/A 
Modulus Length (a.k.a. "key length"): 2048 bits 
Valid From (YYYY-MM-DD): 2005-08-24 
Valid To (YYYY-MM-DD): 2025-08-24 
CRL HTTP URL: http://www.rootca.or.kr/certs/root-rsa-3280.crl 
OCSP URL: N/A 
Class (domain-validated, identity-validated or EV): Both Domain-Validated and Identity-Validated
Certificate Policy URL: http://www.rootca.or.kr/kisae/kcac/jsp/kcac_70_30.jsp 
CPS URL: http://www.rootca.or.kr/kisae/kcac/jsp/kcac_70_30.jsp 
Requested Trust Indicators (email and/or SSL and/or code): Code signing, Timestamping, Server authentication, Client authentication, Secure Email, OCSP 

------------------- 
3. Certificate 3
Certificate Name: KISA RootCA 3
Summary Paragraph, including the following: KISA issue certificates only to 6 LCAs(Licensed CAs) not for end entity
 - End entity certificate issuance policy 
Certificate HTTP URL (on CA website): http://www.rootca.or.kr/certs/root-rsa.der 
Version: V3 
SHA1 Fingerprint: 5f 4e 1f cf 31 b7 91 3b 85 0b 54 f6 e5 ff 50 1a 2b 6f c6 cf 
MD5 Fingerprint: N/A 
Modulus Length (a.k.a. "key length"): 2048 bits 
Valid From (YYYY-MM-DD): 2004-11-19 
Valid To (YYYY-MM-DD): 2014-11-19 
CRL HTTP URL: http://www.rootca.or.kr/certs/root-wrsa.crl 
OCSP URL: N/A 
Class (domain-validated, identity-validated or EV): Both Domain-Validated and Identity-Validated 
Certificate Policy URL: http://www.rootca.or.kr/kisae/kcac/jsp/kcac_70_30.jsp 
CPS URL: http://www.rootca.or.kr/kisae/kcac/jsp/kcac_70_30.jsp 
Requested Trust Indicators (email and/or SSL and/or code): Code signing, Timestamping, Server authentication, Client authentication, Secure Email, OCSP 

Jonghyun Baek.

Comment 16

[Gervase Markham [:gerv]]

Mr Baek,

You have given the same Certificate HTTP URL for all three certificates. I suspect it's the second and third ones which are wrong. Could you provide the correct URLs?

Also, I don't quite understand your certificate structure. If all you do is issue intermediate certificates to your six LCAs, why do you need three roots rather than one?

Thanks,

Gerv

Comment 17

[Jonghyun Baek]

(In reply to comment #16)
> You have given the same Certificate HTTP URL for all three certificates. I
> suspect it's the second and third ones which are wrong. Could you provide the
> correct URLs?

I'm sorry that i sent a wrong information.The second and third certificate URLs are as follows,
The second certificate URL: http://www.rootca.or.kr/certs/root-rsa-3280.der
The third certificate URL: http://www.rootca.or.kr/certs/root-wrsa.der

> Also, I don't quite understand your certificate structure. If all you do is
> issue intermediate certificates to your six LCAs, why do you need three roots
> rather than one?

Actually, National PKI in korea have a two kind of PKI domains. One is the wired PKI domain, another is the wireless PKI domain.
And, the wired PKI domain had a Root CA key update last year because of the certificate validity(RootCA cert validity : by 2010, LCA cert validity : 5 years) that's why we need the certificate 1 and the certificate 2. 
And, third certificate(certificate 3) is only for the wireless PKI domain in Korea. 

Thanks,

Jonghyun.

Comment 18

[Gervase Markham [:gerv]]

Mr Baek,

Mr Jeun said:

> To install our root CA certificate to MS Windows, we submit an official
> document of MIC about that KISA's security plans of the CII and certificate
> practice are sufficient to meet those criteria of WebTrust, instead of WebTrust
> Audit.

Is that document available? Can it be attached here?

We are currently debating how to handle the question of CAs whose audit documents are classified because the audit was performed by a government. You will understand that it is problematic for us to make it so that every Firefox user trusts the Government of Korea, without any published evidence of their certificate management practices. 

One option is to use technical means to restrict that CA to signing certificates for websites in the domain of that country (in your case, ".kr"). That way, only Korean citizens must trust the Korean Government - which presumably they already do. 

Would that be in principle acceptable to you?

Gerv

Comment 19

[Jonghyun Baek]

Attachment: MIC Letter about KISA Root CA Audit

Comment 20

[Jonghyun Baek]

(In reply to comment #18)

> Is that document available? Can it be attached here?

I attached an official document of MIC above comment #19.

> One option is to use technical means to restrict that CA to signing
> certificates for websites in the domain of that country (in your case, ".kr").
> That way, only Korean citizens must trust the Korean Government - which
> presumably they already do. 
> Would that be in principle acceptable to you?

Thank you for your kind response and suggestion.

First of all, I'd like to let you know why we wanna install the KISA certificates in Firefox browser.
Actually, almost korean people use a MS IE when they using a internet service so par, but the Korean government wanna promote the usage of various web-browser on the internet such as Firefox, Sapari, Opera, etc. And, one of the killer application on the internet is the electronic transaction services with KISA certificate(subscriber : 15 million) such as internet banking, online stock, online shopping mall, and so on. That's why we wanna install the KISA certificates in Firefox browser.

Also, the websites in our domain are not only ".kr" but also ".com", ".net", "org" and so on. So, if the Firefox accept the KISA certificate only for ".kr" websites, the websites which are using a ".com", ".net", "org" domain face up to the trouble.
I will be so appriciate if you will install the KISA certificates in Firefox for all of Korean websites.

Thank you.

Jonghyun.

Comment 21

[Gervase Markham [:gerv]]

I have gathered together all the information you have provided, and placed it
in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/

Please confirm that the information for your CA is correct, and add a comment
to this bug to that effect. Once you have done that, your application will turn
"green" and be ready for consideration. [Note: I know the question about limiting the scope is still outstanding.]

If your CA or certificate does not have a summary paragraph, please feel free
to provide one. Note: these paragraphs are not supposed to be marketing
statements :-)

Gerv

Comment 22

[Jonghyun Baek]

The information for KISA RootCA is corret.

But i have a question about "Type" category.
What is the different between OV and IV? I answered that question("type") to DV and IV in comment #15 but your information is DV and OV. Also, i'd like to know the meaning of DV, OV and IV.

Thank you,

Jonghyun. 

Comment 23

[Gervase Markham [:gerv]]

Thanks for the confirmation.

DV: domain-validated
IV: identity-validated
OV: organizationally-validated

I tend to use IV and OV interchangeably.

Gerv

Comment 24

[Gervase Markham [:gerv]]

Jonghyun,

Can you please give me an example of a public website which uses a KISA certificate which is not under ".kr"?

Thanks,

Gerv

Comment 25

[Jonghyun Baek]

(In reply to comment #24)

I'm so sorry that i sent a response lately. I just came back from business trip today.

Until now, no other web site except the ones using .kr domain name used KISA certificate. Since web browsers without KISA certificate shows warning messages to the users when using the web sites, it wasn't used a lot.

If the KISA certificate will be loaded in many web browsers(IE, FF, Safari, Opera, etc.) and when there are no problems using KISA certificate, this will be used in many websites such as web portal, Internet shopping malls, public institutions and so on where private information protection is necessary. 

o Examples of that websites are as follows,

- Web portal website
  www.daum.net, www.naver.com, www.nate.com, www.paran.com, etc.

- Stock Trading
  www.priden.com, www.iprovest.com, www.goodi.com, www.bestez.com, www.myasset.com, www.sogeko.com, www.imeritz.com, www.miraeasset.com, etc.

- Internet shopping mall : www.cjmall.com, www.mple.com, www.interpark.com, www.hmall.com, www.dnshop.com, www.lotte.com, etc.

- Internet Banking 
  Kookmin Bank(www.kbstar.com), Woori Bank(www.wooribank.com), Nonghyup Bank(www.nonghyup.com), etc.

- Media 
  MBC(www.imbc.com), www.chosun.com, www.ohmynews.com, www.pressian.com, www.joins.com, www.segye.com, etc.

- Game company
  www.hangame.com, www.gamepop.com, www.ninebrothers.com, www.playforum.net, www.pspgate.com, www.60frame.com, etc.

- Education 
  ti.tradecampus.com, www.nftekorea.com, www.skwinwin.com, www.kookbi.net, www.edpolicy.net, www.dsure.org, edu.kelia.org, etc.

- Culture
  www.igong.org, www.yeazin.com, www.artdb.org, www.cdcia.net, www.kocla.org, www.partykorea.net, etc.

Thanks,

Jonghyun.

Comment 26

[Gervase Markham [:gerv]]

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv

Comment 27

[Jonghyun Baek]

Dear Gervase,

I'd like to know how's the progress of adding a KISA root CA Certificate to Firefox browser going on.

Actually, there is no bug report after last month.

I'm sorry but could you give me a information about that? 

Thanks,

Jonghyun.

Comment 28

[Gervase Markham [:gerv]]

I have begun this evaluation, and have some questions:

- Is your CPS (http://www.kisa.or.kr/kisae/kcac/jsp/kcac_70_30_03.jsp) available in a more concrete form than a set of web pages (e.g. a word processor document or a PDF)? Does it have a version number? Does it live under change control?

- Section 7 of our policy lists some minimum checks that CAs must do before issuing email or SSL certificates. They must check ownership of the specified email address or domain name. Section 4.2 of your CPS lists the checks that you do on certificate issuance, and these things are not among them. Do you, in fact, do these checks? If so, we would need the CPS updated to state this explicitly.

- In order for us to consider the MIC assertion of WebTrust audit equivalence, we would need a public assertion by the MIC that they had done such an audit. A copy of their letter, as attached, is not sufficient, because it cannot be authenticated. A copy of the letter posted to us is also not sufficient, because it is not public - and we require information on which we take decisions about CAs to be public, so other people can check our work and make their own assessments.

Would it be possible for the MIC to post on their website either a copy of that letter or another assertion to the effect that they have audited KISA to a WebTrust standard?

- With what frequency are CRLs issued for end entity certificates issued by your sub-CAs?

Thanks,

Gerv

Comment 29

[Jonghyun Baek]

Attachment: Certification Practice Statement v1.1

Comment 30

[Jonghyun Baek]

Attachment: MIC official document for Root CA Audit(Korean & English version)

Comment 31

[Jonghyun Baek]

(In reply to comment #28)
> I have begun this evaluation, and have some questions:
> - Is your CPS (http://www.kisa.or.kr/kisae/kcac/jsp/kcac_70_30_03.jsp)
> available in a more concrete form than a set of web pages (e.g. a word
> processor document or a PDF)? Does it have a version number? Does it live under
> change control?

CPS is posted with PDF format in our web pages. You can download it but i attached that file in an Attachements. This document version is 1.1. But We have version 1.4 CPS document with Korean. If you want version 1.4 CPS document, we can translate it into English.
 All CPS version is managed by MIC. All changes are recorded and all version of CPS is posted in our web pages.

> - Section 7 of our policy lists some minimum checks that CAs must do before
> issuing email or SSL certificates. They must check ownership of the specified
> email address or domain name. Section 4.2 of your CPS lists the checks that you
> do on certificate issuance, and these things are not among them. Do you, in
> fact, do these checks? If so, we would need the CPS updated to state this
> explicitly.

Complying with Korea Electronic Signature Act(Article 15) and Korea Electronic Signature Act Enforcement Regulations(Article 13.2), the applicants who desire to be issued an accredited certificate should be verified the identification by sub-CAs with the identification procedure and method. 
Also, Sub-CA should check a ownership of the specified email address or the domain name for the email or SSL certification by the KISA Guideline based on the identification procedure and method for user certificate.

> - In order for us to consider the MIC assertion of WebTrust audit equivalence,
> we would need a public assertion by the MIC that they had done such an audit. A
> copy of their letter, as attached, is not sufficient, because it cannot be
> authenticated. A copy of the letter posted to us is also not sufficient,
> because it is not public - and we require information on which we take
> decisions about CAs to be public, so other people can check our work and make
> their own assessments.
> Would it be possible for the MIC to post on their website either a copy of that
> letter or another assertion to the effect that they have audited KISA to a
> WebTrust standard?

I attached the official document which was sent from MIC to MS.  This official document shows that MIC has supervised and audited KISA Root CA's technical and physical security every year.

> - With what frequency are CRLs issued for end entity certificates issued by
> your sub-CAs?

CRLs for end entity certificates are issued within 24 hours, there are some difference depending on the sub-CAs.

> Thanks,
> Gerv

Comment 32

[Gervase Markham [:gerv]]

Please can I have the URL for your latest Korean and latest English versions of your CPS, in PDF format? 

> Also, Sub-CA should check a ownership of the specified email address or the
> domain name for the email or SSL certification by the KISA Guideline based on
> the identification procedure and method for user certificate.

I'm afraid I don't quite follow that. :-( Can you explain exactly how you check ownership of email addresses and domain names? And what section of your CPS explains the procedure?

> I attached the official document which was sent from MIC to MS.  This official
> document shows that MIC has supervised and audited KISA Root CA's technical 
> and physical security every year.

Yes, but we have no way of verifying that MIC wrote that document. :-( And the letter is addressed to Microsoft, not to us. I don't know if we could legally rely on it. What is needed is for MIC (your auditor) to make a public statement that you have been audited in conformance with one of our acceptable sets of audit criteria. This is what we require of other CAs that we include.

Gerv

Comment 33

[이상원(Sangwon Lee)]

Since Jonghyun is on vacation I am answering instead of him.

(In reply to comment #32)
> Please can I have the URL for your latest Korean and latest English versions of
> your CPS, in PDF format? 
> > Also, Sub-CA should check a ownership of the specified email address or the
> > domain name for the email or SSL certification by the KISA Guideline based on
> > the identification procedure and method for user certificate.

KISA CPS URLs 
With English
- 1.1 : http://www.kisa.or.kr/kisae/kcac/down/e-cps.pdf

Win Korean
- 1.0 : http://www.kisa.or.kr/kisa/kcac/down/cps10.pdf
- 1.1 : http://www.kisa.or.kr/kisa/kcac/down/cps11.pdf
- 1.2 : http://www.kisa.or.kr/kisa/kcac/down/cps12.pdf
- 1.3 : http://www.kisa.or.kr/kisa/kcac/down/cps13.pdf

> I'm afraid I don't quite follow that. :-( Can you explain exactly how you check
> ownership of email addresses and domain names? And what section of your CPS
> explains the procedure?
> > I attached the official document which was sent from MIC to MS.  This official
> > document shows that MIC has supervised and audited KISA Root CA's technical 
> > and physical security every year.

The KISA Guideline based on checking the ownership of email addresses and domain names for user certificate is posted in KISA web page. We have only Korean version. We will translate it into English as soon as possible. If it is completed, we will attach it.

[Guideline for the Web server security, Code Signing and Secure e-mail Certificate issuing procedure(Korean), http://www.kisa.or.kr/kisa/kcac/down/7-Digital%20Signature%20Certificate%20Issuing%20Procedure%20Guideline%20for%20SSL,%20CodeSigning,%20and%20Secure%20e-Mail.pdf]

CPS does not include this guideline yet. If the inclusion of KISA root CA certificates in the web browser is completed, Sub-CAs will start their business seriously and modify CPS to include the above guideline.

> Yes, but we have no way of verifying that MIC wrote that document. :-( And the
> letter is addressed to Microsoft, not to us. I don't know if we could legally
> rely on it. What is needed is for MIC (your auditor) to make a public statement
> that you have been audited in conformance with one of our acceptable sets of
> audit criteria. This is what we require of other CAs that we include.

Please assign your recipient. We can send the official document that MIC has supervised and audited KISA Root CA 

> Gerv

Thanks,

Sangwon.

Comment 34

[이상원(Sangwon Lee)]

Attachment: Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail(Korean)

Comment 35

[Gervase Markham [:gerv]]

Sangwon,

> CPS does not include this guideline yet. If the inclusion of KISA root CA
> certificates in the web browser is completed, Sub-CAs will start their 
> business seriously and modify CPS to include the above guideline.

I'm afraid we cannot include root certificates until the procedures associated with them meet our minimum requirements, as set out in our policy.

> Please assign your recipient. We can send the official document that MIC has
> supervised and audited KISA Root CA 

We would very much prefer a *public* statement (e.g. on their website) rather than a letter to just ourselves. We feel it's an important principle that information we use to make decisions about roots to include is public information, so anyone else can see what we've done and why.

Gerv

Comment 36

[이상원(Sangwon Lee)]

Attachment: Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail(English)

Guideline for issuing procedure of web server security, code signing, secure e-mail certificates

Comment 37

[이상원(Sangwon Lee)]

Gerv,

(In reply to comment #35)
> I'm afraid we cannot include root certificates until the procedures associated
> with them meet our minimum requirements, as set out in our policy.


Guideline for issuing procedure of web server security, code signing, secure e-mail certificates is attached and we will post it in the our web page. 


> We would very much prefer a *public* statement (e.g. on their website) rather
> than a letter to just ourselves. We feel it's an important principle that
> information we use to make decisions about roots to include is public
> information, so anyone else can see what we've done and why.


There is no case in Korea where this kind of document is posted on a web site other than sending an official document. Act and Act enforcement are posted on the web site, but the official documents about the inspection activities are not posted and currently there is no category on the web site to post the documents.

We will keep finding the way to post the inspection documents on the web site. But first, please consider about the following instructions. First, MIC itself sending  the official documents through the e-mail or fax. Second, FireFox Korean Contributor can check the MIC official documents and than sending the confirm. We also will work on to find a way to verify the inspection activities. 

Thanks,

Sangwon.

Comment 38

[Gervase Markham [:gerv]]

(In reply to comment #37)
> Guideline for issuing procedure of web server security, code signing, secure
> e-mail certificates is attached and we will post it in the our web page. 

That's great. Once this is done, please let me know what the URL is.

> There is no case in Korea where this kind of document is posted on a web site
> other than sending an official document. Act and Act enforcement are posted on
> the web site, but the official documents about the inspection activities are
> not posted and currently there is no category on the web site to post the
> documents.

So how does anyone know that it is true that MIC has audited KISA, if MIC does not say so officially somewhere?

> We will keep finding the way to post the inspection documents on the web site.
> But first, please consider about the following instructions. First, MIC itself
> sending  the official documents through the e-mail or fax. Second, FireFox
> Korean Contributor can check the MIC official documents and than sending the
> confirm. 

The problem with these ideas is that it is hard for other people to "follow in our footsteps". If someone is shipping a browser based on our code, and wants to do their own evaluations of what certificates to include, then they need access to the same information we have in order to make their decisions. If this information is sent only to us, then they don't have access to it.

This is why we require a public statement from the auditor.

If you take the example of normal WebTrust audits, the details of exactly who has passed an audit, and who did the audit, are available from webtrust.org. Here is an example:
https://cert.webtrust.org/ViewSeal?id=208
(Note: you may have to copy and paste that URL into a new window, rather than clicking it, to avoid getting an error.)
This is the sort of thing we are looking for.

Gerv

Comment 39

[Jonghyun Baek]

(In reply to comment #38)

I just came back from honeymoon this week. That's why I could not answer to you during the last few weeks. Actually, I'd like to thanks to your kind responses.

You can find a guideline in our web pages by clicking this URL.
http://www.rootca.or.kr/kisa/kcac/down/Digital Signature Certificate Issuing Procedure Guideline(EN).pdf

> So how does anyone know that it is true that MIC has audited KISA, if MIC does
> not say so officially somewhere?

KISA Root CA is designated to a critical information infrastructure by MIC in Dec. 2001. Therefore, KISA Root CA must perform a vulnerability analysis and assessment every year based on Article 9 of Information Infrastructure Protection Act. 
You can verify that KISA Root CA is the Critical Information Infrastructure based on the Information Infrastructure Protection Act by MIC announcement. This announcement is posted in MIC web site. However, because this homepage is composed in Korean, it will be inconvenient for foreigners. I will attached a document which is help to find a KISA Root CA designation information in the MIC announcement. 
MIC announcement URLs are as follows; 

- URL of the MIC announcement posted in MIC web site : 
http://www.mic.go.kr/user.tdf?a=user.board.BoardApp&c=2002&board_id=P_03_04_04&seq=207&mc=P_03_04_04, 

- URL of the PDF File : 
http://www.mic.go.kr/secureDN.tdf?seq=207&idx=1&board_id=P_03_04_04

Also, The related Article is as follows;

-------------------------------------------------------------------------------
Article 9 (Vulnerability Analysis and Assessment) ① According to the Presidential Decree, the president of the authority which is designate to a critical information infrastructure(hereinafter "management authority") should periodically analyze and assess the vulnerability of the Critical Information Infrastructure(hereinafter "CII") 

② to perform the assessment and the analyzation of the vulnerability under the paragraph 1, the president of the management authority should organize the Task Force Team to analyze and evaluate the vulnerability by the Presidential Decree. 

③ to perform the assessment and the analyzation of the vulnerability under the paragraph 1, the president of the management authority can let the organization related to following categories to evaluate and analyze the vulnerability of the CII. However, in this case, the exclusive team won't be necessary. 

1. Korea Information Security Agency under the Article 52 of the Act on Promotion of Information & Communication Network Utilization and Information Protection
2. Information Share & Analyze Center under the Article 16
3. Information Security Consulting Company under the Article 17
4. Electronic and Telecommunications Research Institute under the Article 8 of Act on the Establishment, Operation and Fosterage of Government Invested Research Institutions

④ the minister of the ministry of information and communication can negotiate with the president of the related central administration office and the NIS(National Information Security) to decide the criteria of the vulnerability assessment and analyzation and should report the result to the related central administration office. 

⑤ all of the methods and procedures for the vulnerability analyzation and assessment of the CII are made by the Presidential Decree.  
-------------------------------------------------------------------------------

The official document which was sent from MIC to MS is also posted in MIC web site. You can verify it by comparing with attached document(MIC Letter about KISA Root CA Audit). This MIC web pages are also composed in Korean. 
Attached document will be help that you find a official document in MIC web site.

Thank you.

Jonghyun

Comment 40

[Jonghyun Baek]

Attachment: Reference document for MIC announcement in the web site

Comment 41

[Gervase Markham [:gerv]]

Jonghyun,

I think we are going round in circles a little bit here :-(

What we need is "a public written statement from MIC that they have audited KISA to a WebTrust-equivalent standard".

1) public - because we and everyone else has to be able to see it and rely on it. So it can't be private, and it can't really be a letter addressed "Dear Microsoft". "To whom it may concern" would be fine (this is an English expression meaning "to anyone who is reading".)

2) written - again, so anyone can access it and read it

3) from MIC - because they are the auditor

4) to a WebTrust-equivalent standard - the statement must explicitly say that they have done the audit to this level (or to the level of another of the standards we accept).

Even in all that you have said, I cannot see where to find a statement from MIC that has all those four ingredients. If there is such a statement (even if it is in Korean), can you provide the URL?

With regard to procedures, this document:
http://www.rootca.or.kr/kisa/kcac/down/Digital Signature Certificate Issuing
Procedure Guideline(EN).pdf
looks good. I have only one question: what does:
"Certificate authorities shall verify the validity of e-mail address"
mean? How is this done? The document doesn't seem to give any details. Does that mean just checking that it works? Or does it mean actually checking that the applicant owns it?

Also, this document is called "Guideline" - is it compulsory that it is followed in all cases, for all certificates issued by KISA?

Gerv

Comment 42

[Jonghyun Baek]

(In reply to comment #41)
> Even in all that you have said, I cannot see where to find a statement from MIC
> that has all those four ingredients. If there is such a statement (even if it
> is in Korean), can you provide the URL?

In case that organizations or companies designated to a critical information infrastructure based on Information Infrastructure Protection Act, they must be audited by MIC every year after designation.
(MIC is the government that decide the policy relevant with National PKI in korea and supervised a KISA Root CA. Also they designate a Critical Information Infrastructure and audit it periodically.)

KISA Root CA system was legally designated to a Critical Information Infrastructure by MIC in Dec 2001. You can confirm the designation with "Designation of the Critical Information Infrastructure" notification which is public written legal document from MIC. That's why I sent that informations in previous reply. (I understood your request before but there is no any other statements for KISA RootCA audit in MIC homepage) 
Unfortunately, it is not easy that we notify a public written statement in government(MIC) homepage because it can not be notified with our willing. 

Anyway, KISA will strongly ask MIC that post the public written statement on MIC homepage. However, I'd like to know that our statement which is referenced here is enough to your request, and your audit for adding a KISA certificates to your browser will be finished if MIC post the statement on MIC homepage. 
According to your audit process, if you need more requests to us, please let me know about it first. 

> "Certificate authorities shall verify the validity of e-mail address"
> mean? How is this done? The document doesn't seem to give any details. Does
> that mean just checking that it works? Or does it mean actually checking that
> the applicant owns it?

Because the method of verify the e-mail address validation is various and every Accredited CA can use different methods, this guideline did not mentioned about e-mail address validation method. 

However, Accredited CA must check the e-mail address validity using own method such as "reference number/password" before issuing a secure e-mail certificate. 

> Also, this document is called "Guideline" - is it compulsory that it is
> followed in all cases, for all certificates issued by KISA?

“Web server security, Code Signing and Secure e-mail certificate issuance administration Guideline" is the guideline that is developed by mutual agreement among KISA and Accredited CAs. Therefore, all of the Accredite CA should comply with this guideline when they issue relevant certificates.
(As a Root CA of NPKI(National PKI), KISA issues certificates for only 6 Accredited CAs. All user's certificate is issued by Accredited CAs.)

Thanks,

Jonghyun

Comment 43

[Jonghyun Baek]

Attachment: MIC statement about KISA Root CA Audit

Comment 44

[Gervase Markham [:gerv]]

I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(

Gerv

Comment 45

[Gervase Markham [:gerv]]

Jonghyun: Yes, as far as I can see at the moment, the audit requirement is the only one remaining. However, once I have finished my analysis, there is a public comment period, and that might turn up something I've missed - I don't know.

Remember, the MIC statement must meet all four points in comment #41. Note that the statement doesn't have to be on their home page, it can be anywhere on their website.

> Therefore, all of the Accredite CA
> should comply with this guideline when they issue relevant certificates.

You say "should". Do you mean "must"? Or do they have an option not to follow the Guidelines? To put it another way, have they signed a contract saying they will follow them?

Gerv

Comment 46

[Jonghyun Baek]

(In reply to comment #45)

Thanks for your kind reply.

> Remember, the MIC statement must meet all four points in comment #41. 

I attached a MIC statement document(i.e, "MIC statement about KISA Root CA Audit") which will be posted on MIC homepage in my privous reply. It will be very appreciated if you will confirm the statement to meet all four points in comment #41. If we need the MIC statement revision, we will revise the statement and will post the reviced statement on MIC homepage. Also, we will send that URL to you.

> > Therefore, all of the Accredite CA
> > should comply with this guideline when they issue relevant certificates.
> You say "should". Do you mean "must"? Or do they have an option not to follow
> the Guidelines?

Yes, it mean "must".

Thank you.

Jonghyun.

Comment 47

[Gervase Markham [:gerv]]

The "MIC statement about KISA Root CA Audit" would meet all four points in comment #41 if it were posted on the MIC website.

Gerv

Comment 48

[이상원(Sangwon Lee)]

MIC posted the statement document about KISA Root CA Audit in their homepage.
(www.mic.go.kr -> English -> Resources -> Statement)

You can find the statement by clicking this URL.
http://eng.mic.go.kr/eng/user.tdf?a=common.HtmlApp&c=1001&page=resources/resources_f_01.html&mc=E_04_06

Thank you,

Sangwon.

Comment 49

[Jonghyun Baek]

Have you seen the MIC web site that MIC posted documents related to the KISA Root CA audit at September 20th? 

Actually, We would like to know the current status of KISA certificate including.

Moreover, We would like to know when you will completed the KISA certificate including in Firefox and which version of Firefox can be included.

i will be very appreciate if you give a information to me soon.

Always, thank you.

Jonghyun.

Comment 50

[Jonghyun Baek]

I'm sorry and i know you are so busy. 

However, Would you let me know the current status of KISA Root CA certificate including process?

And Will KISA Root CA certificate be included in Firefox v3?

Always thanks for your help and it will be very appreciate that i have a response from you soon.

Thank you so much.

Jonghyun.

Comment 51

[Jonghyun Baek]

We sent a several comments about KISA Root CA certificate including in Firefox as above and we also poested the document for KISA Root CA audit on the MIC website at September 20th.

Therefore, I really would like to know when KISA Root CA certificate can be included in Firefox.

if you let me know what you need more, i will send that ASAP. 

Thank you so much and i will waiting your response soon.

Jonghyun.

Comment 52

[Jonghyun Baek]

I'm sorry to bother you but could you let me know what is the current status for KISA RootCA certificate including in Firefox. 

I strongly wish that KISA RootCA certificates are included in Firefox by end of this year. Actually, i believe that i accomplished my job for KISA RootCA certificate including in Firefox over 2 months ago. 

Therefore, I kindly ask you to close this bug report soon later please. 

Thank you and regards,

Jonghyun.

Comment 53

[Jonghyun Baek]

I'm sorry to bother you but could you let me know the current status of KISA RootCA certificate including in Firefox. 

Please checking my previous commnets and response to me soon.

Thank you and regards,

Jonghyun.

Comment 54

[Gervase Markham [:gerv]]

Frank Hecker is now dealing with CA root applications.

Gerv

Comment 55

[Jonghyun Baek]

I'm so happy to see you again :)

Actually, we almost doing everything for including the KISA RootCA Certificate in Firefox v3.0 (Please check our previous comments above)

If you need more information, please let me know. i will response that ASAP.

Always Thank you and regards,

Jonghyun.

Comment 56

[Jonghyun Baek]

I'm sorry to bother you but could you let me know the current status of KISA
RootCA certificate including in Firefox v3. 

I wish to know when KISA RootCA cab be included in Firefox so much.

Thank you and regards,

Jonghyun.

Comment 57

[Park Soon Tae]

Hello.

I would like to know when KISA RootCA can be included in FireFox so much.

If possible, can I get an e-mail about the process.

Thank you and regards,

Samuel, Park. 

Comment 58

[Frank Hecker]

(In reply to comment #57)
> I would like to know when KISA RootCA can be included in FireFox so much.
> 
> If possible, can I get an e-mail about the process.

I am sorry for the delay. I am looking at this application now. It appears from reading Gerv Markham's comments above that we are very close to having the information we need. I do have one question: I tried to access the URL

http://eng.mic.go.kr/eng/user.tdf?a=common.HtmlApp&c=1001&page=resources/resources_f_01.html&mc=E_04_06

mentioned in comment #48. The web server is apparently not configured correctly, so I just see the underlying HTML, not the web page as it was intended to be viewed. This is probably a similar problem to the one mentioned in comment #12: the web site is sending the page as content type "text/plain", but it should be sending it as "text/html". I can view the page in Safari, and I suspect it works in IE as well, but it does not work in Firefox. Note that this problem will not affect this application, but it is annoying nonetheless. 

Comment 59

[Park Soon Tae]

I am sorry for your annoyance. 
I immediately requested for the correction and we are working on it.
Please let me know if any other problem appears or other information is needed additively.
Because of its delay, I must make a report to the superior office.
May I know when KISA RootCA can be included in FireFox?

Once again I am sorry to bother you. 

Thank you and reagrds.

Samuel.

Comment 60

[Frank Hecker]

(In reply to comment #59)
> I am sorry for your annoyance. 
> I immediately requested for the correction and we are working on it.

The page in question appears to be fixed now; thank you for resolving this issue. I have updated the pending certificates list

  http://www.mozilla.org/projects/security/certs/pending/#KISA

to reflect the latest information.

See also my next comment.

Comment 61

[Frank Hecker]

I've completed my review of the application of the Korea Certification Authority Central (KCAC) of the Korean Information Security Administration (KISA), as per sections 1, 5 and 15 of the official Mozilla CA policy at:

  http://www.mozilla.org/projects/security/certs/policy/

I apologize for any delays on my part in completing the review. (And I thank Gerv Markham, who was the primary person responsible for processing the application.)

Here follows my assessment. If anyone sees any factual errors, please point them out. The documents referenced are linked to from KISA's entry in the pending certificates list:

http://www.mozilla.org/projects/security/certs/pending/#KISA

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by KISA/KCAC, or of instances where KISA/KCAC or its LCAs have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. KISA/KCAC appears to provide a service relevant to Mozilla users: it is a government-run CA providing services to Korean citizens, businesses, and other organizations. KISA/KCAC itself is a root CA only; the actual end entity certificates are issued by subordinate CAs ("licensed CAs" or LCAs) under policies set by KISA/KCAC. Its policies (for itself and the LCAs) are documented in the documents published on its website and listed in the entry on the pending applications list:

Section 7 [Validation]. KISA/KCAC and its LCAs appear to meet the minimum requirements for subscriber verification, as follows:

* Email: For S/MIME certificates issued by the various LCAs, the LCAs verify identity of the applicant and validity of the associated email address referenced in the certificate. (See chapter 2, article 6 in "Web Server Security, Code-Signing, Secure E-mail Certificates Issuance Administration Guideline".)

* SSL: For SSL certificates the LCAs verify the identity of the applicant and his or her authorization to request the certificate. (See chapter 2, article 4 in the afore-mentioned document.)

* Code: For code signing certificates the LCAs verify identity of the applicant. (See chapter 2, article 5 in the afore-mentioned document.)

Section 8-10 [Audit]. KISA/KCAC has successfully completed a WebTrust-equivalent audit by the Korean Ministry of Information and Communication (MIC); MIC has issued a public statement on its web site to this effect.

Section 13 [Certificate Hierarchy]. KISA/KCAC has three different root certificates, with multiple subordinates (LCAs) under each root, as explained in this bug (see in particular comment #17). Of the three roots, the first two (CertRSA01 and KISA RootCA 1) are associated with the standard PKI, and the third (KISA RootCA 3) is associated with the PKI for wireless applications; CertRSA01 is in the process of being replaced by KISA RootCA 1.

Other: The LCAs issue CRLs for end entity certificates on a 24-hour schedule.

Based on the above information, I intend to approve the inclusion of the three
KISA/KCAC root CAs (CertRSA01, RootCA 1, and RootCA 3) in NSS and thence in Firefox and other Mozilla-based products. Before I do this I'm opening up a period of public discussion of this request. I'll post in the news://news.mozilla.org/mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period is two weeks, unless issues are brought forth that warrant further discussion.

Comment 62

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #61)
> Section 4 [Technical]. I'm not aware of any technical issues with 
> certificates issued by KISA/KCAC, [snip]. If anyone knows of any such 
> issues or instances, please note them in this bug report.

I have no objection to the inclusion of the approved KISA roots in any future 
version of NSS (e.g. 3.11.x used in FF2 or 3.12.x used in FF3), but there ARE
some technical issues of which I think readers should be aware.

About 25 months ago, we received reports that a significant number of the 
CAs subordinate to KISA were routinely issuing certs with critical policy 
extensions.  (See Bug 321765).  Even when Mozilla browser users added the 
South Korean root certs to their browsers' cert databases, they were unable
to connect to SSL servers whose certs were issued by some of those 
subordinate CAs, because those certs had critical policy extensions.  
NSS was forced to dishonor those certs because NSS could not process those 
critical policy extensions.  That situation persists to this day.

If there still exist certs with critical policy extensions, those certs will still not work with FF2 browsers.  Adding the KISA root CA cert to FF's built-in list of root CAs will not change that.  Users should not expect that the addition of the KISA roots to FF's built-in root list will increase the number of South Korean SSL servers that work with FF (as compared with the number of such servers that work when the KISA roots have been manually added to FF's cert DB.  The results will be the same as if they had manually added the KISA roots to their cert DBs.

Comment 63

[Frank Hecker]

One question that's come up during the public comment period: MIC stated that KISA/KCAC was audited against WebTrust-equivalent criteria. Did MIC just use the WebTrust criteria unchanged, or did it have its own criteria? If the latter, are the MIC criteria publicly available? Could we get a list of the differences, if any, between the WebTrust criteria and the MIC criteria?

Comment 64

[Park Soon Tae]

Beside some criteria that corrupts with KISA's certificate policy statement, Korea electronic signature act and etc, MIC audit criteria WebTrust audit criteria is satisfied. But this is just because KISA is a root CA organization. For example we don't have any RAs, but all our subordinate CAs satisfy the WebTrust audit criteria.

Comment 65

[Park Soon Tae]

(In reply to comment #62)
> (In reply to comment #61)

KISA's user certificates no longer use critical policy extension field.

Comment 66

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #65)
> KISA's user certificates no longer use critical policy extension field.
What about server and CA certs?

Comment 67

[Park Soon Tae]

(In reply to comment #63)
> One question that's come up during the public comment period: MIC stated that
> KISA/KCAC was audited against WebTrust-equivalent criteria. Did MIC just use
> the WebTrust criteria unchanged, or did it have its own criteria? If the
> latter, are the MIC criteria publicly available? Could we get a list of the
> differences, if any, between the WebTrust criteria and the MIC criteria?

MIC has audited KCAC based on KCAC's certification practice statement and KCAC's security plans of CII every year. You can refer to KCAC's certification practice statement attached above. 
MIC letter about KISA Root CA Audit (attached above) also shows that "MIC determined that such security requirements as the KCAC's security plans of the CII and the KCAC's accredited certification practice are sufficient to meet those criteria of WebTrust. "  

Comment 68

[Eddy Nigg (StartCom)]

(In reply to comment #67)
> 
> MIC has audited KCAC based on KCAC's certification practice statement and
> KCAC's security plans of CII every year. You can refer to KCAC's certification
> practice statement attached above. 
> MIC letter about KISA Root CA Audit (attached above) also shows that "MIC
> determined that such security requirements as the KCAC's security plans of the
> CII and the KCAC's accredited certification practice are sufficient to meet
> those criteria of WebTrust. "  
> 

Park Soon Tae, I'm sorry, but you are repeating the statements which we can read by ourselves. I request kindly if you or somebody else can answer the questions Frank asked? Thanks a lot!

Comment 69

[Park Soon Tae]

(In reply to comment #66)
> (In reply to comment #65)
> > KISA's user certificates no longer use critical policy extension field.
> What about server and CA certs?

KISA sets certificate policy extension as non-critical in server certificates, and sets certificate policy extension field as critical in CA certificates. And we have tested that even if CA certificate's certificate policy extension field is set critical, we were able to connect to SSL servers. 

Comment 70

[Park Soon Tae]

Attachment: The Mapping Table between WebTrust Audit Criteria and KISA's Certification Practice Statements

Comment 71

[Park Soon Tae]

As you can see from MIC letter attached above, "MIC has supervised that KCAC faithfully implemented the accredited certification practice statement." I have attached the mapping table between Webtrust audit criteria and KISA's Certification Practice Statement. Here you will be able to find the list of differences Frank requested. Thank you.

Comment 72

[Frank Hecker]

(In reply to comment #71)
> As you can see from MIC letter attached above, "MIC has supervised that KCAC
> faithfully implemented the accredited certification practice statement." I have
> attached the mapping table between Webtrust audit criteria and KISA's
> Certification Practice Statement.

Thank you for providing this document. I will review it and determine it is suitable for our purposes.

Comment 73

[Frank Hecker]

(In reply to comment #71)
> As you can see from MIC letter attached above, "MIC has supervised that KCAC
> faithfully implemented the accredited certification practice statement." I have
> attached the mapping table between Webtrust audit criteria and KISA's
> Certification Practice Statement.

Thank you for providing this document. I will review it and determine if it is suitable for our purposes.

Comment 74

[Park Soon Tae]

Hello
Thank you for your concerns about including RootCA certificate in FireFox. 
Because it's been 3~4 weeks since the last response, I would like to know the current status and how the including is going on.
Once again thank you very much.

Comment 75

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/
as of this date, this request is in "public discussion" state

Comment 76

[Park Soon Tae]

Hello
Thank you for your concerns about including RootCA certificate in FireFox. 
3~4 weeks have passed since our request has been updated to public discussion state. 
I would like to know the current status and how the including is going on.
Once again thank you very much.

Comment 77

[Frank Hecker]

(In reply to comment #71)
> As you can see from MIC letter attached above, "MIC has supervised that KCAC
> faithfully implemented the accredited certification practice statement." I have
> attached the mapping table between Webtrust audit criteria and KISA's
> Certification Practice Statement. Here you will be able to find the list of
> differences Frank requested. Thank you.

My apologies for the delay in resuming work on this application. I have now reviewed this document and compared it to the WebTrust criteria. The document appears to provide a complete mapping for all the WebTrust for CAs criteria in section 1 ("business disclosures"); however it does not provide a mapping for sections 2 ("service integrity") and 3 ("environmental controls"). Based on a quick comparison of the WebTrust document and the CPS, I suspect that the CPS also has provisions corresponding to the WebTrust section 2 and 3 criteria as well; however I do not have time right now to create a complete mapping between sections 2 and 3 and the CPS. If you can provide these additional mappings I would very much appreciate it; otherwise I'll have to investigate this later myself.

Note that at present this issue appears to be the only issue holding up approval of KISA's request.

Comment 78

[Park Soon Tae]

Attachment: updated mapping table, web trust criteria and KISA

Comment 79

[Park Soon Tae]

Attachment: MIC notification

Comment 80

[Park Soon Tae]

I have attached the updated mapping table between Web Trust Audit Criteria and KISA which includes chapter 2 and 3 of Web Trust criteria. I also attached MIC notifications, which explains the act specifically. This notification has legal effects on Accredited Certification Authority. 

These are the lists of the MIC notifications which are included in the mapping table. 
<MIC Notification>
- 2002-48th : Rules on Accredited Certification Authoritys ProtectiveMeasures
- 2003-51th : Guideline on Electronic Signature Certification Practices
- 2003-53th : Rules on Accredited Certification Authoritys Facilities and Equipments

 Thank you.

Comment 81

[Park Soon Tae]

Hello, 

I wonder if the data I have posted on the bulletin, a month ago, meets your requirements for the approval of our request.
And I'll be appreciated if you let me know the current status of adding KISA rootCA certificates.

Once again thank you very much.

Comment 82

[Park Soon Tae]

Hello,

Have you finished reviewing the mapping table between Web Trust Audit Criteria and KISA's Certification Practice Statement which includes chapter 2 and 3 of Web Trust criteria? I was informed that the public discussion period is 2weeks but it has been over two months since I have attached the requested mapping table and I really want to know the causes for the delay in "the public discussion " state. I'll be appreciated if you let me know the current status of adding KISA rootCA certificates and how long it will take until the actual inclusion. We've been looking forward to include KISA certificates in the Firefox v.3. Is it possible to include KISA certificates in the Firefox v.3? Or is there any other way to include KISA certificate in the Firefox v.3?  

Thank you very much.

Comment 83

[Channy Yun [:channy]]

Frank, It's so late response. Is there anything to be discussed more? It already was installed the latest IE, Opera and Safari browser. Please let us know your plan for future. 

Comment 84

[Park Soon Tae]

Dear Mr. Hecker

Would you let me know how the inclusion of KISA certificate is going on?
There have been no progresses made ever since this March.
May I ask you what's keeping the matter so long?
I'll be appreciated if the inclusion is finished by the end of this year. 
Thank you for your concerns.

Comment 85

[Gen Kanai [:gen]]

Mr. Park, I will not answer for Frank directly but he has provided some guidance on schedules publicly in the dev-tech-crypto mailing list here:

http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/84ebbf39d5322e16#

KISA is listed in the "high priority" group.

https://wiki.mozilla.org/CA:Schedule

As soon as KISA's review period is scheduled, I believe Frank will post here or in dev-tech-crypto.

Comment 86

[Park Soon Tae]

Thank you for informing me about the current status of KISA certificate inclusion and I appreciate that KISA is listed on the "high-priority" group. I really look forward to seeing the inclusion of KISA certificate in FireFox by the end of this year. Once again thank you very much.

Comment 87

[Park Soon Tae]

Would you let me know kow the inclusion of KISA certificate is going on?
Public Comments for KISA's certificate was scheduled from 12/5 so I was wondering how the things are going on and if this inclusion can be completed by the end of this year. If anything comes up or needed please don't hesitate to ask.
Thank you for your concerns.

Comment 88

[David E. Ross]

In comment #64, I read "we don't have any RAs"; I also see mention of subordinate CAs.  

Where in your formal documents (English translations please) do you explicitly state there are no RAs?  

Where in your formal documents (English translations please) do you address the following with respect to subordinate CAs:  
(1)  how they are authorized by KISA
(2)  how they are to verify subscriber identities
(3)  how they are to verify that an individual is authorized to represent an organizational subscriber
     and
(4)  how KISA verifies that they are indeed operating in conformance with KISA policies and procedures.

Comment 89

[Park Soon Tae]

(In reply to comment #88)
> In comment #64, I read "we don't have any RAs"; I also see mention of
> subordinate CAs.  
> 
> Where in your formal documents (English translations please) do you explicitly
> state there are no RAs?  

 
KISA directly operates registration facilities to identify a certificate applicant through an face to face interview. Subordinate CAs must visit KISA to identify themselves and to collect the certificates according to Certification Practice Statement chapter 3.1. 


> Where in your formal documents (English translations please) do you address the
> following with respect to subordinate CAs:  
> (1)  how they are authorized by KISA

The body that authorize subordinate CAs is not KISA but Government Ministry., you can refer to Electronic Signature Act chapter 2, article 4.
KISA's role is to check if their facilities and equipment used for certification services are qualified according to Electronic Signature Act chapter 4, article 19.  

> (2)  how they are to verify subscriber identities

Subordinate CAs(Accredited CAs) verify subscriber identities face to face.
According to Article 4 of the Electronic Signature Act. Article 13.2 and Article 13.3 of the Electronic Signature Act Enforcement Regulations defines the standard method of verify the identity and the identity verification proof. And the subordinate CAs shall faithfully abide by the articles. You can find the verification process of applicants for certificates in our regulation.


> (3)  how they are to verify that an individual is authorized to represent an
> organizational subscriber and

For the identification proof of juridical person and organization(not jurdical person), you can refer to Electronic Signature Act Enforcement Regulations Article 13.3


> (4)  how KISA verifies that they are indeed operating in conformance with KISA
> policies and procedures.

Every year, KISA audits subordinate CAs(accredited CAs) according to the article 25 of the Electronic Signature Act.

Comment 90

[Kathleen Wilson]

Attachment: Information Gathering Document

This document summarizes the information that has been gathered and verified as per the Information Gathering and Verification section of https://wiki.mozilla.org/CA:How_to_apply

Within the document the items needing further information are highlighted in yellow.
They are:
1) Further review of the sub-CAs (see next attachment, 335197-subCA-review.pdf)
2) The link in http://www.mozilla.org/projects/security/certs/pending/#KISA to the public statement by MIC in regards to the KISA/KCAC audit is no longer working. We will need a statement about an audit performed in 2008, which includes the requirements of a WebTrust CA audit.
3) For testing purposes, we will also need URLs to websites whose certs chain up to 
CertRSA01 and KISA RootCA 3. These can be test sites.

Comment 91

[Kathleen Wilson]

Attachment: Review of Subordinate CAs

This document summarizes the information that I was able to find for the sub-CAs. Please see the items highlighted in yellow within the document to see the information that still needs to be provided as per https://wiki.mozilla.org/CA:SubordinateCA_checklist

The first thing we’ll need is CPSs in English for all of the sub-CAs. (have 3, need the other 3).

For all of the sub-CA CPSs the issuance practices for end-entity certificates must satisfy section 7 of 
http://www.mozilla.org/projects/security/certs/policy/ in regards to demonstrating that reasonable measures are taken to verify the ownership/control of the domain name and the email address. 

Audit statements will also be critical in evaluation of the sub-CAs. Since KISA performs the annual audits for the sub-CAs, perhaps KISA can provide an official statement for each sub-CA that is similar to a typical WebTrust for CAs report, such that it includes:
a) The name of the person/organization who performed the audit
b) What the criteria were. (eg WebTrust equivalence)
c) The date the audit was completed, and the time frame that the audit covers.
d) Statement that problems found have been corrected, or that no problems were found.

Comment 92

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #90)
> The link in http://www.mozilla.org/projects/security/certs/pending/#KISA to
> the public statement by MIC in regards to the KISA/KCAC audit is no longer
> working. 

This has been a recurrent problem with CA requests, historically.  Therefore,
I request that, going forward, copies of documents upon which Mozilla relies 
for evaluating CA cert requests should be attached to the relevant bugs, and 
links in other documents (such as the "pending" document) should link to the
attachment rather than to the original URL.  This is because attachments 
never seem to expire, and so provide a good archive of the material supporting
a decision.

Comment 93

[Gervase Markham [:gerv]]

Nelson: the only disadvantages of that are that if the document is on the CA's site, you can confirm that they own and approve it. And if a CA's policy changes, people using the attached version might be looking at out-of-date information.

If we change to this method, we at least need to permit only trusted people to copy documents into the system, and we need to keep track of where each one came from.

Gerv

Comment 94

[SH.Park]

(In reply to comment #90)
> Created an attachment (id=357185) [details]
> Information Gathering Document
> This document summarizes the information that has been gathered and verified as
> per the Information Gathering and Verification section of
> https://wiki.mozilla.org/CA:How_to_apply
> Within the document the items needing further information are highlighted in
> yellow.
> They are:
> 1) Further review of the sub-CAs (see next attachment, 335197-subCA-review.pdf)
> 2) The link in http://www.mozilla.org/projects/security/certs/pending/#KISA to
> the public statement by MIC in regards to the KISA/KCAC audit is no longer
> working. We will need a statement about an audit performed in 2008, which
> includes the requirements of a WebTrust CA audit.
> 3) For testing purposes, we will also need URLs to websites whose certs chain
> up to 
> CertRSA01 and KISA RootCA 3. These can be test sites.

KISA is preparing for what you have requested.
However, I'm sorry that you requested the new audit statement for 2008. We have been informed for long that KISA RootCA certificate would be almost on the the final test stages, with your audit requirements regarding WebTrust requirements verified at the initial stages, in 2007. But you requested the WebTrust audit requirement statement once again, which is meant to go backward to the initial stage. We've requested so far you to proceed KISA's status on and off, however there have been no responses from you even for one year in 2008. I think that you delayed KISA's status due to your internal matters. I'd like to strongly request that your requests for the new audit statement is replaced with the one we submitted ever. The links are moved to other web pages. I'll let you know where soon. In order for us to prepare the statement again, we have to persude Korea Government to issue it, but it's not reasonable and available for Korea Government to issue it once again for this matter. The other items you have requested are under being reviewed now.

Comment 95

[Kathleen Wilson]

We do apologize for the delay. We are now systematically working through the backlog of requests. However, due to the backlog and delay, we have to request updated information from the CAs.

What is the frequency of the audits for the operations of KISA Root CA?

Comment 96

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she's the person actively working on it.

Comment 97

[SH.Park]

Sorry for the late information.

KISA gets the operation audit from the government every year.

I'd like to ask you the status of inclusion of KISA certifiate.

Comment 98

[Kathleen Wilson]

I’m still waiting for the information that I requested in Comment #90 and Comment #91.

Comment 99

[Mountie Lee]

Attachment: Critical Extension Problem screenshot

(In reply to comment #69)
> (In reply to comment #66)
> > (In reply to comment #65)
> > > KISA's user certificates no longer use critical policy extension field.
> > What about server and CA certs?
> 
> KISA sets certificate policy extension as non-critical in server certificates,
> and sets certificate policy extension field as critical in CA certificates. And
> we have tested that even if CA certificate's certificate policy extension field
> is set critical, we were able to connect to SSL servers.

Hi. I'm Mountie Lee 
as a Korean Citizen, let me comment something.
currently the LCA certificates issued by KISA has critical extension that cause "unknown critical extension" error in many common browsers like firefox, chrome, safari except MSIE. (I attached screenshot of chrome that has already KISA root ca installed)

another point is
Mozilla need proof that KISA was audited by WebTrust-equivalent criteria.
public audit check list is required.
the check list must be equivalent to WebTrust criteria.
the check list itself is not confidential.

and MIC(?) announce that KISA was audited by the check list.

I hope to see KISA root ca in Firefox built-in keystore.

Comment 100

[Mountie Lee]

Attachment: Critical Extension Error screenshot in Firefox

I tested with Firefox.
KISA Root CA was manually added.
the sub-ca certificate issued by KISA has critical extensions that cause ssl connection error.

we all know KISA is valid trusted Root CA established by Korea Electronic Signature Act.
but KISA have to provide evidences that they were audited by Technical Expert by the checklists equvalent to WebTrust criteria.

registering RootCA to Firefox impact not just for Korean users, but for entire international firefox users.
so I think Mozilla want public evidences.

Comment 101

[Channy Yun [:channy]]

Is there any following up from KISA people? Kathleen still waited for the information of Comment #90 and Comment #91.

Comment 102

[Woncheol Lee]

Attachment: MOPAS statement about KISA Root CA Audit

Comment 103

[Mountie Lee]

(In reply to comment #102)
> Created attachment 479645 [details]
> MOPAS statement about KISA Root CA Audit

I think Mozila want the list of audit item and the result
the list of audit item must be equivalent to WebTrust criteria

Comment 104

[Woncheol Lee]

Attachment: KOSCOM CPS(English Version)

Certification Practice Statement of KOSCOM LCA

Comment 105

[Woncheol Lee]

Attachment: KFTC CPS(English Version)

Certification Practice Statement of KFTC LCA

Comment 106

[Woncheol Lee]

Attachment: CrossCert CPS(English Version)

Certification Practice Statement of CrossCert LCA

Comment 107

[Woncheol Lee]

Attachment: TradeSign CPS(English Version)

Certification Practice Statement of TradeSign LCA

Comment 108

[Woncheol Lee]

(In reply to comment #103)
> (In reply to comment #102)
> > Created attachment 479645 [details] [details]
> > MOPAS statement about KISA Root CA Audit
> I think Mozila want the list of audit item and the result
> the list of audit item must be equivalent to WebTrust criteria

MOPAS audits whether KISA follows its CPS.
So you can refer to attached document above, "updated mapping table, web trust criteria and KISA"

Comment 109

[Mountie Lee]

(In reply to comment #108)
> (In reply to comment #103)
> > (In reply to comment #102)
> > > Created attachment 479645 [details] [details] [details]
> > > MOPAS statement about KISA Root CA Audit
> > I think Mozila want the list of audit item and the result
> > the list of audit item must be equivalent to WebTrust criteria
> 
> MOPAS audits whether KISA follows its CPS.
> So you can refer to attached document above, "updated mapping table, web trust
> criteria and KISA"

now one of the remaining things is
"Unknown Critical Extension" mentioned at #99, #100

as an user, 
if this problem is not solved, registering KISA root CA has no meaning.

Comment 110

[Woncheol Lee]

(In reply to comment #90)
> Created attachment 357185 [details]
> Information Gathering Document
> This document summarizes the information that has been gathered and verified as
> per the Information Gathering and Verification section of
> https://wiki.mozilla.org/CA:How_to_apply
> Within the document the items needing further information are highlighted in
> yellow.
> They are:
> 1) Further review of the sub-CAs (see next attachment, 335197-subCA-review.pdf)
> 2) The link in http://www.mozilla.org/projects/security/certs/pending/#KISA to
> the public statement by MIC in regards to the KISA/KCAC audit is no longer
> working. We will need a statement about an audit performed in 2008, which
> includes the requirements of a WebTrust CA audit.
> 3) For testing purposes, we will also need URLs to websites whose certs chain
> up to 
> CertRSA01 and KISA RootCA 3. These can be test sites.

refer to the attached document "MOPAS statement about KISA Root CA Audit" and "updated mapping table, web trust criteria and KISA" for the comment #90's 2)

Comment 111

[Woncheol Lee]

(In reply to comment #91)
> Created attachment 357188 [details]
> Review of Subordinate CAs
> This document summarizes the information that I was able to find for the
> sub-CAs. Please see the items highlighted in yellow within the document to see
> the information that still needs to be provided as per
> https://wiki.mozilla.org/CA:SubordinateCA_checklist
> The first thing we’ll need is CPSs in English for all of the sub-CAs. (have 3,
> need the other 3).
> For all of the sub-CA CPSs the issuance practices for end-entity certificates
> must satisfy section 7 of 
> http://www.mozilla.org/projects/security/certs/policy/ in regards to
> demonstrating that reasonable measures are taken to verify the
> ownership/control of the domain name and the email address. 
> Audit statements will also be critical in evaluation of the sub-CAs. Since KISA
> performs the annual audits for the sub-CAs, perhaps KISA can provide an
> official statement for each sub-CA that is similar to a typical WebTrust for
> CAs report, such that it includes:
> a) The name of the person/organization who performed the audit
> b) What the criteria were. (eg WebTrust equivalence)
> c) The date the audit was completed, and the time frame that the audit covers.
> d) Statement that problems found have been corrected, or that no problems were
> found.

I have attached CPS of LCAs(KOSCOM, KFTC, CrossCert, TradeSign), so refer to the "KOSCOM CPS(English Version)", "KFTC CPS(English Version)", "CrossCert CPS(English Version)", "TradeSign CPS(English Version)"

and, KICA's CPS is being translated right now and NCA have closed the buisness since 2008.6.

LCAs follow the KISA's guideline (“Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail(English)”) for the SSL, Code sign, secure e-mail certificate issuance.
and, LCAs do not issue EV certificate. 

Here are the auditors for the LCA for the comment #91's a)
- Kang Pil-Yong (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Fellow Researcher)
- Lim Jin-Soo (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Fellow Researcher)
- Kim Jung-hee (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Fellow Researcher)
- Lee Won-Cheol (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Fellow Researcher)
- Lee Sang-Won (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Senior Researcher)
- Kim Young-Jun (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Senior Researcher)
- Park Jun-Sung (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Research Associate)
- Park Soon-Tae (Korea Internet & Security Agency, Electronic Signature & Authentication Team, Research Associate)


For comment #91's b), the criteria of the audit for the LCAs, supported by the Digital Signature Act. article 19.2 whether the LCAs operate the facilities and devices safely, is as follows.
 - Digital Signature act article 8, whether the CPS is followed
 - Digital Signature act article 13.4 whether the countermeasures are followed

audit lists above are equivalent lists that MOPAS use to audit KISA, and LCAs must follow the notice for CPS writing standard from MOPAS. 
Therfore, LCA audit lists is equivalent as the webtrust CA audit criteria.
(refer to the “updated mapping table, web trust criteria and KISA”)


for the comment #91's c), the date the audit was completed is as follows and the audit for this year(2010) is now in progress.
 - name of LCA : the date the audit was completed(2009)
 - KICA : 2009. 7. 6
 - KOSCOM : 2009. 12. 3
 - KFTC : 2009. 7. 23
 - CrossCert : 2009. 9. 11
 - TradeSign : 2009. 10. 9

also, The time frame that the audit covers is as follows(regular audit time table)
 - opening meeting (1 day) : regular audit opening meeting
 - document audit (1 week) : reviewing LCAs operation status and the audit documents
 - on the spot audit(1~2 week) : actual on the spot auditing
 - result review(1 week) : request for demand supplement and result review 
 - writing result(1~2 week) : writing the audit result
 - closing meeting(1 day) : regular audit closing meeting

comment #91's d) the problems found from 2009 regular audit were corrected.
the actual contents of the problems are classified issues due to business matters and also for security matters.

Comment 112

[Woncheol Lee]

(In reply to comment #109)
> (In reply to comment #108)
> > (In reply to comment #103)
> > > (In reply to comment #102)
> > > > Created attachment 479645 [details] [details] [details] [details]
> > > > MOPAS statement about KISA Root CA Audit
> > > I think Mozila want the list of audit item and the result
> > > the list of audit item must be equivalent to WebTrust criteria
> > 
> > MOPAS audits whether KISA follows its CPS.
> > So you can refer to attached document above, "updated mapping table, web trust
> > criteria and KISA"
> now one of the remaining things is
> "Unknown Critical Extension" mentioned at #99, #100
> as an user, 
> if this problem is not solved, registering KISA root CA has no meaning.

The cause of error metioned at comment #99 and #100 was because the sub-ca certificate's , issued by KISA, Certificate policies extionsions and Policy Contraints extension field was set critical and Firefox does not recognize the OID in extension field. (according to RFC 5280 and other standards, the critical settings of Certificate Policies extensions fields is not mentioned.)  

Therefore KISA changed the profile standard for certificate for SSL, CodeSigning, and Secure e-Mail, so that the Certificate Policies extensions are set non-critical, and by re-issuing LCA's certificates the SSL connection errors does not occur from then. The certificates which were already issued are being changed by re-issuance.

you can check from our website for the comment #90's 3)
https://www.kisa.or.kr/main.jsp

Comment 113

[Kathleen Wilson]

Thank you for the information. I have begun sorting through it.

The original request was for the inclusion of three roots:
1) CertRSA01 (expired 2010-03-03)
2) KISA RootCA 1 (valid to 2025-08-24)
3) KISA RootCA 3 (valid to 2014-11-19)

Are #2 and #3 the roots that you would like to continue with in regards to this root inclusion request?

Comment 114

[Kathleen Wilson]

As per comment #112, I tried browsing to https://www.kisa.or.kr/main.jsp, but it times out.

Comment 115

[Woncheol Lee]

Attachment: Review of Subordinate CAs(update)

Review of Subordinate CAs(update)

Comment 116

[Woncheol Lee]

(In reply to comment #113)
> Thank you for the information. I have begun sorting through it.
> The original request was for the inclusion of three roots:
> 1) CertRSA01 (expired 2010-03-03)
> 2) KISA RootCA 1 (valid to 2025-08-24)
> 3) KISA RootCA 3 (valid to 2014-11-19)
> Are #2 and #3 the roots that you would like to continue with in regards to this
> root inclusion request?

Yes, KISA would like to continue with #2 and #3 the roots certificates.

and, Update "Review of Subordinate CAs" for comment #90's 1)

for comment #112, can you give us screen shot about "times out error on https://www.kisa.or.kr/main.jsp"

Comment 117

[Gen Kanai [:gen]]

Attachment: Screen shot 2010-10-12 at 5.07.55 PM

Screen shot showing no connection.

Comment 118

[Woncheol Lee]

Attachment: Certification Practice Statement v1.5

KISA's Certification Practice Statement v1.5

Comment 119

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 120

[김기창]

As Gen commented with a screen shot, the technical specs of KISA seem to produce connection errors with most browsers except IE.  I HOPE THIS IS FIXED.

Comment 121

[Mountie Lee]

(In reply to comment #112)
> (In reply to comment #109)
> > (In reply to comment #108)
> > > (In reply to comment #103)
> > > > (In reply to comment #102)
> > > > > Created attachment 479645 [details] [details] [details] [details] [details]
> > > > > MOPAS statement about KISA Root CA Audit
> > > > I think Mozila want the list of audit item and the result
> > > > the list of audit item must be equivalent to WebTrust criteria
> > > 
> > > MOPAS audits whether KISA follows its CPS.
> > > So you can refer to attached document above, "updated mapping table, web trust
> > > criteria and KISA"
> > now one of the remaining things is
> > "Unknown Critical Extension" mentioned at #99, #100
> > as an user, 
> > if this problem is not solved, registering KISA root CA has no meaning.
> 
> The cause of error metioned at comment #99 and #100 was because the sub-ca
> certificate's , issued by KISA, Certificate policies extionsions and Policy
> Contraints extension field was set critical and Firefox does not recognize the
> OID in extension field. (according to RFC 5280 and other standards, the
> critical settings of Certificate Policies extensions fields is not mentioned.)  
> 
> Therefore KISA changed the profile standard for certificate for SSL,
> CodeSigning, and Secure e-Mail, so that the Certificate Policies extensions are
> set non-critical, and by re-issuing LCA's certificates the SSL connection
> errors does not occur from then. The certificates which were already issued are
> being changed by re-issuance.
> 
> you can check from our website for the comment #90's 3)
> https://www.kisa.or.kr/main.jsp

I verified. it is now solved.
when I add KISA RootCA 1 (Serial No : 04) certificate to firefox manually
I can access to https://www.kisa.or.kr/main.jsp without any warning.

another question is

the CPS URL inside of "CrossCert Class 1 Server CA" certificate is

http://www.rootca.or.kr/rca/cps.html

when I access it. 404 not found error occured.

Comment 122

[Woncheol Lee]

(In reply to comment #121)
> (In reply to comment #112)
> > (In reply to comment #109)
> > > (In reply to comment #108)
> > > > (In reply to comment #103)
> > > > > (In reply to comment #102)
> > > > > > Created attachment 479645 [details] [details] [details] [details] [details] [details]
> > > > > > MOPAS statement about KISA Root CA Audit
> > > > > I think Mozila want the list of audit item and the result
> > > > > the list of audit item must be equivalent to WebTrust criteria
> > > > 
> > > > MOPAS audits whether KISA follows its CPS.
> > > > So you can refer to attached document above, "updated mapping table, web trust
> > > > criteria and KISA"
> > > now one of the remaining things is
> > > "Unknown Critical Extension" mentioned at #99, #100
> > > as an user, 
> > > if this problem is not solved, registering KISA root CA has no meaning.
> > 
> > The cause of error metioned at comment #99 and #100 was because the sub-ca
> > certificate's , issued by KISA, Certificate policies extionsions and Policy
> > Contraints extension field was set critical and Firefox does not recognize the
> > OID in extension field. (according to RFC 5280 and other standards, the
> > critical settings of Certificate Policies extensions fields is not mentioned.)  
> > 
> > Therefore KISA changed the profile standard for certificate for SSL,
> > CodeSigning, and Secure e-Mail, so that the Certificate Policies extensions are
> > set non-critical, and by re-issuing LCA's certificates the SSL connection
> > errors does not occur from then. The certificates which were already issued are
> > being changed by re-issuance.
> > 
> > you can check from our website for the comment #90's 3)
> > https://www.kisa.or.kr/main.jsp
> I verified. it is now solved.
> when I add KISA RootCA 1 (Serial No : 04) certificate to firefox manually
> I can access to https://www.kisa.or.kr/main.jsp without any warning.
> another question is
> the CPS URL inside of "CrossCert Class 1 Server CA" certificate is
> http://www.rootca.or.kr/rca/cps.html
> when I access it. 404 not found error occured.

(In reply to comment #119)
> Created attachment 484145 [details]
> Updated Information Gathering Document
> The attached document summarizes the information that has been gathered and
> verified.
> The items highlighted in yellow indicate where further information or
> clarification is needed. Please review the full document for accuracy and
> completeness.

(In reply to comment #114)
> As per comment #112, I tried browsing to https://www.kisa.or.kr/main.jsp, but
> it times out.


about comment 121, not able to connect to CPS URL (http://www.rootca.or.kr/rca/cps.html) is because
KISA recently modified the site due to the unification of the company, we've corrected the link. 

we are preparing for the comment 119

about comment 114, the reply time is quite long but maybe it's because of the network problem.
if you are using a WIFI network, pleases check the network line.
or check DNS setting, etc.

Comment 123

[Jungshik Shin]

> we are preparing for the comment 119

What's the status of KISA's response to Kathleen (comment 119)? 

As for http://www.kisa.or.kr, it times out for me, too (Other Korean web sites just get loaded fine. ). Hmm..... this is not good.  The root CA whose web site times out frequently?

Comment 124

[Park Soon Tae]

first of all, sorry for the late response.

#for your question #119, 

1.It is true that KISA RootCA3 expires relatively soon, but we still want this one to be included. Since there are lots of users based on this certificate.

2. for the SSL test site, you can refer to https://www.kisa.or.kr/main.jsp 
   you may be able to check the SSL cert chains up to this root

3. it is stated at each LCAs CPS that LCAs should update CRL every 24 hours.

4. you can find the KISA CPS at http://www.rootca.or.kr/rca/cps.html, and the URL redirects to  http://www.rootca.or.kr/kor/accredited/accredited02.jsp 

5. It is stated at the Electronic Signgature act(19.2) that the LCAs must at a minimum perform the verification procedure described in guideline  and it is audited by KISA during the anual audit.

6. for the identity verification, LCAs follow the Korea electronic signature act enforcement regulations 13.2

7. no external RA is allowed to validate for end-entity certs.

8. we not only issue for the internal domains but for the international domains also.

9. critical CIDP Extention problems listed at #99 and #100 is fixed as stated at #121

If you have any more questions, I'll be happy to give answers ASAP, please let us know.

Thank you.

Comment 125

[Kathleen Wilson]

I am having difficult with the test websites that have been provided...

> https://www.rootca.or.kr/mark/rootca.html
When I try to browse to this site I get the error:
“www.rootca.or.kr uses an invalid security certificate.
The certificate is only valid for *.kisa.or.kr
The certificate expired on 1/7/12 6:59 AM. The current time is 1/26/12 2:46 PM.
(Error code: ssl_error_bad_cert_domain)”

> https://www.kisa.or.kr/main.jsp
When I try to browse to this website I get the error: “www.kisa.or.kr uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)”

Please note that intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates.

Comment 126

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #125)
> > https://www.kisa.or.kr/main.jsp
> When I try to browse to this website I get the error: “www.kisa.or.kr uses
> an invalid security certificate.
> The certificate is not trusted because no issuer chain was provided.
> (Error code: sec_error_unknown_issuer)”
> 

Well, I just tried again, and it worked. However, the cert chains to "KISA RootCA 1".

I also need a test website whose SSL cert chains up to "KISA RootCA 3".

Comment 127

[Park Soon Tae]

Here are the websites whose SSL cert chains up to "KISA RootCA 3"

https://www.kumsung.co.kr/
https://www.okcc.co.kr/join.asp

If there is anything else you need, please let me know.

Thank you for your support.

Comment 128

[Kathleen Wilson]

> Here are the websites whose SSL cert chains up to "KISA RootCA 3"
> https://www.kumsung.co.kr/
> https://www.okcc.co.kr/join.asp

I don't see "CRL Distribution Points" or "Authority Information Access" extensions in either of the SSL certs for these two websites.  This is problematic; at least one of CRL or OCSP must be present, and work correctly in Mozilla products. Does KISA policy require CRL Distribution Points in all end-entity certs? For CRL Distribution Point, Mozilla products require an HTTP URL.


If you haven't already done so, please see the CA/Browser Forum Baseline Requirements, http://www.cabforum.org/. 


Please also provide URLs to the current versions of:
Electronic Signature Act
Electronic Signature Act Enforcement Regulations
Issuing Procedure Guidelines

I understand that you wish to include the "KISA RootCA 3" root certificate, even though it expires in 2014. Have you already created the new root that customers of the "KISA RootCA 3" will transition to? If yes, please provide the information for that root. It will be better to consider inclusion of both roots at the same time.

Comment 129

[Park Soon Tae]

We had some discussions regarding KISA RootCA 3 certificate and made final decision not to add KISA RootCA 3 certificate.
Therefore we will be concentrating on KISA RootCA 1 certificate to be added.
Certificates already issued by KISA RootCA 3 will be changed to certificates issued by KISA RootCA 1 when they expire.

The current version of Electronic Signature Act and etc. are being prepared and will be posted as soon as possible. (probably next weak)

Thank you

Comment 130

[이상원(Sangwon Lee)]

Attachment: Electronic Signature Act

Comment 131

[이상원(Sangwon Lee)]

Attachment: Electronic Signature Act Enforcement Decree

Comment 132

[이상원(Sangwon Lee)]

Attachment: Electronic Signature Act Enforcement Regulations

Comment 133

[이상원(Sangwon Lee)]

Attachment: Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail

Comment 134

[Kathleen Wilson]

(In reply to Park Soon Tae from comment #129)
> We had some discussions regarding KISA RootCA 3 certificate and made final
> decision not to add KISA RootCA 3 certificate.
> Therefore we will be concentrating on KISA RootCA 1 certificate to be added.
> Certificates already issued by KISA RootCA 3 will be changed to certificates
> issued by KISA RootCA 1 when they expire.

I'll update my notes accordingly.


> The current version of Electronic Signature Act and etc. are being prepared
> and will be posted as soon as possible. (probably next weak)

Thanks for attaching them to the bug, but would you also please provide the URLs where these documents may be found?

Comment 135

[Park Soon Tae]

(In reply to Kathleen Wilson from comment #134)
> (In reply to Park Soon Tae from comment #129)
> > We had some discussions regarding KISA RootCA 3 certificate and made final
> > decision not to add KISA RootCA 3 certificate.
> > Therefore we will be concentrating on KISA RootCA 1 certificate to be added.
> > Certificates already issued by KISA RootCA 3 will be changed to certificates
> > issued by KISA RootCA 1 when they expire.
> 
> I'll update my notes accordingly.
> 
> 
> > The current version of Electronic Signature Act and etc. are being prepared
> > and will be posted as soon as possible. (probably next weak)
> 
> Thanks for attaching them to the bug, but would you also please provide the
> URLs where these documents may be found?

Electronic Signature Act, Electronic Signature Act Enforcement Decree, Electronic Signature Act Enforcement Regulations are posted at the National Legal Information Center(http://www.law.go.kr/) operated by the Ministry of Government Legislation(http://www.moleg.go.kr/english/). Unfortunately, these documents and sites are not in english.

here are the URLs for the Electronic Signature Act and Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail.

Electronic Signature Act URL :
http://www.law.go.kr/lsSc.do?menuId=0&p1=&subMenu=1&nwYn=1&query=%EC%A0%84%EC%9E%90%EC%84%9C%EB%AA%85%EB%B2%95&x=0&y=0#liBgcolor0

Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail URL : 
http://www.rootca.or.kr/kor/standard/standard02.jsp

Comment 136

[Mountie Lee]

I think the online document must be prepared in english.
because
the root certificates are applicable to all firefox users in the world.

KISA root certificate was initiated by the Act of Korea.
but Adding root certificate to firefox trust CA list means
the territory is expanded to worldwide.

(In reply to Park Soon Tae from comment #135)
> (In reply to Kathleen Wilson from comment #134)
> > (In reply to Park Soon Tae from comment #129)
> > > We had some discussions regarding KISA RootCA 3 certificate and made final
> > > decision not to add KISA RootCA 3 certificate.
> > > Therefore we will be concentrating on KISA RootCA 1 certificate to be added.
> > > Certificates already issued by KISA RootCA 3 will be changed to certificates
> > > issued by KISA RootCA 1 when they expire.
> > 
> > I'll update my notes accordingly.
> > 
> > 
> > > The current version of Electronic Signature Act and etc. are being prepared
> > > and will be posted as soon as possible. (probably next weak)
> > 
> > Thanks for attaching them to the bug, but would you also please provide the
> > URLs where these documents may be found?
> 
> Electronic Signature Act, Electronic Signature Act Enforcement Decree,
> Electronic Signature Act Enforcement Regulations are posted at the National
> Legal Information Center(http://www.law.go.kr/) operated by the Ministry of
> Government Legislation(http://www.moleg.go.kr/english/). Unfortunately,
> these documents and sites are not in english.
> 
> here are the URLs for the Electronic Signature Act and Digital Signature
> Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure
> e-Mail.
> 
> Electronic Signature Act URL :
> http://www.law.go.kr/lsSc.
> do?menuId=0&p1=&subMenu=1&nwYn=1&query=%EC%A0%84%EC%9E%90%EC%84%9C%EB%AA%85%E
> B%B2%95&x=0&y=0#liBgcolor0
> 
> Digital Signature Certificate Issuing Procedure Guideline for SSL,
> CodeSigning, and Secure e-Mail URL : 
> http://www.rootca.or.kr/kor/standard/standard02.jsp

Comment 137

[Park Soon Tae]

it's been a while since the last response and I was wondering if there is anything more to be prepared?
(or if there is something we are missing?)
And what might be the next step or procedure?
please let me know if any thing comes up or if there is anything KISA has to prepare.
Thank you very much.
All the best.

Comment 138

[Kathleen Wilson]

I don't see a response to this:
(Comment #128)
> I don't see "CRL Distribution Points" or "Authority Information Access"
> extensions in either of the SSL certs for these two websites.  This is
> problematic; at least one of CRL or OCSP must be present, and work correctly
> in Mozilla products. Does KISA policy require CRL Distribution Points in all
> end-entity certs? For CRL Distribution Point, Mozilla products require an
> HTTP URL.



Also, please provide KISA's responses to the action items of the previous two CA Communications:
1) https://wiki.mozilla.org/CA:Communications#February_17.2C_2012
2) https://wiki.mozilla.org/CA:Communications#September_8.2C_2011

Comment 139

[Kathleen Wilson]

I just imported the root into my Firefox browser, using
http://www.rootca.or.kr/certs/root-rsa-3280.der

Then I tried to browse to the test website:
https://www.kisa.or.kr/main.jsp

I got the following error:
www.kisa.or.kr uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

Comment 140

[Kathleen Wilson]

(In reply to Mountie Lee from comment #136)
> I think the online document must be prepared in english.

Document Repository: http://www.rootca.or.kr/kor/accredited/accredited02.jsp
CPS (Korean): http://www.rootca.or.kr/kor/down/cps15.pdf
CPS (English): http://www.rootca.or.kr/kor/down/cps15(en).pdf 


Additionally, the Electronic Signature Act documentation has been translated into English and attached to this bug. 

Here's what I think the list is of the original (Korean) documents, and the corresponding translations into English. Please let me know if any of the following list is incorrect.

Electronic Signature Act (English): 
https://bugzilla.mozilla.org/attachment.cgi?id=594638 
Electronic Signature Act (Korean): 
http://www.law.go.kr/lsSc.do?menuId=0&p1=&subMenu=1&nwYn=1&query=%EC%A0%84%EC%9E%90%EC%84%9C%EB%AA%85%EB%B2%95&x=0&y=0#liBgcolor0 

Electronic Signature Act Enforcement Decree (English): 
https://bugzilla.mozilla.org/attachment.cgi?id=594639 
Electronic Signature Act Enforcement Decree (Korean): 
http://www.law.go.kr/

Electronic Signature Act Enforcement Regulations (English): https://bugzilla.mozilla.org/attachment.cgi?id=594640 
Electronic Signature Act Enforcement Regulations (Korean): 
http://www.law.go.kr/

Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail (English):
https://bugzilla.mozilla.org/attachment.cgi?id=594641 
Digital Signature Certificate Issuing Procedure Guideline for SSL, CodeSigning, and Secure e-Mail (Korean):
http://www.rootca.or.kr/kor/standard/standard02.jsp

Comment 141

[Kathleen Wilson]

(In reply to Woncheol Lee from comment #115)
> Created attachment 482457 [details]
> Review of Subordinate CAs(update)

I just reviewed this document in detail and noticed that the LCAs use delta CRLs, which are not supported in NSS. 
https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

Comment 142

[김기창]

KISA claims that "MOPAS audits whether KISA follows its CPS". (See comment No. 108). But I am afraid MOPAS (Ministry of Public Administration and Security) has no expertise to conduct security audit. The public servants working in MOPAS have very little or virtually no knowledge of certificate technology. They rely entirely on KISA in matters relating to certification service.

In short, KISA's claim is more or less that it audits itself. I do hope that KISA accepts to subject itself to a proper, independent security audit.

At a minimum, I wish to see professional credentials of the person from MOPAS who produced an undated statement that MOPAS conducts audits of the CAs under KISA.

Comment 143

[Park Soon Tae]

(In reply to Kathleen Wilson from comment #138)
> I don't see a response to this:
> (Comment #128)
> > I don't see "CRL Distribution Points" or "Authority Information Access"
> > extensions in either of the SSL certs for these two websites.  This is
> > problematic; at least one of CRL or OCSP must be present, and work correctly
> > in Mozilla products. Does KISA policy require CRL Distribution Points in all
> > end-entity certs? For CRL Distribution Point, Mozilla products require an
> > HTTP URL.
> 
It is true LCAs and the end-entities are using partitioned CRL, but is willing to change it to the full CRL soon. I will be able to offer you the URL for the test page soon.
> 
> 
> Also, please provide KISA's responses to the action items of the previous
> two CA Communications:
> 1) https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

1) subordinate CAs chaining to KISA(5 at the moment) are audited every year, there is no possibility that the certificates issued are being used as MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. The subordinate CAs are accredited by the government, any action of illegal(dangerous) use of certificate would be accreditation will be cancelled.
KISA issues the certificate only to the accredited subCAs and not to the third parties. And the accredited subCAs restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.

2) KISA does not issue certificates to third parties. KISA only issues to the accredited CAs only.

3) At the moment KISA does not issue EV SSL certificates.

4) no certificates chaining to KISA certificate have MD5 algorithms or RSA keys shorter than 1024 bits long.


> 2) https://wiki.mozilla.org/CA:Communications#September_8.2C_2011

1) KISA audits the subordinate CAs every year, if any action of intrusion or compromise will be handled right away.

2) no certificates are cross-signed with KISA certificate

3) the certificate issuance procedure is audited by the KISA every year and the application forms are examined. The issuance procedure is stated at the KISA's guideline and the multi-factor is requested for the authentication.

4) the subordinateCAs must examine the application form in off-line procedure and the procedure is audited every year by the KISA.

5) in order to issue certificate one has to visit the subordinate CA and must present one's identification card also the application form requiring the data that website or IP is under control. In case of any dangers or the black lists sites requring the certificate will be automatically denied.

Comment 144

[Park Soon Tae]

(In reply to Kathleen Wilson from comment #139)
> I just imported the root into my Firefox browser, using
> http://www.rootca.or.kr/certs/root-rsa-3280.der
> 
> Then I tried to browse to the test website:
> https://www.kisa.or.kr/main.jsp
> 
> I got the following error:
> www.kisa.or.kr uses an invalid security certificate.
> The certificate is not trusted because no issuer chain was provided.
> (Error code: sec_error_unknown_issuer)

It is working fine, could you try again?

Comment 145

[Park Soon Tae]

As I've mentioned above, I will be offering with the new test URL as soon as the test is done.(about CRL distribution issue)
Since all the LCA's are supportive, it won't take long.

If this problem is solved, is there any more issue left?

Please let me know. 

Thank you very much!

Comment 146

[Kathleen Wilson]

I apologize for the delay in my response. My work on root inclusion requests was postponed for a while.

I have successfully browsed to the test website:
https://www.kisa.or.kr/main.jsp

I need to go back through this bug and update my notes to make sure I have the current information. I have added this to my to-do list.

In the meantime, please provide a response to the recent CA Communication.

https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

Comment 147

[Park Soon Tae]

Thank you for your support. :)

We've reviewed the recent CA communication you mentioned, and

for 1),  a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.

for 2), a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.

for 3), a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.

for 4), a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.

and for 5), I have sent you the URL before(https://www.kisa.or.kr/main.jsp), is this alright?

Comment 148

[Kathleen Wilson]

Attachment: Review of Subordinate CAs

Comment 149

[Kathleen Wilson]

Attachment: Updated Information Gathering Document 2013

Comment 150

[Kathleen Wilson]

(In reply to Park Soon Tae from comment #145)
> As I've mentioned above, I will be offering with the new test URL as soon as
> the test is done.(about CRL distribution issue)
> Since all the LCA's are supportive, it won't take long.
> 
> If this problem is solved, is there any more issue left?
> 

The documents that I just attached to this bug are my current notes on this request. The items highlighted in yellow indicate where clarification or more information is needed. Please also let me know if anything else in the documents needs to be updated.

Comment 151

[Park Soon Tae]

1. for the LADP, we are currently testing the HTTP URL as cRLDistributionPonits.
  - test certificate and the url will be provided soon

2. KISA's subordinate certificates and the subscriber's certificate meets the requirements of the #13.2.2.
    subscriber certificate CRL is updated every 24hours, and the subordinate CA certificate is updated every week.
    
3. about official document, as you may already know, Korean president has changed and due to the change of president the change of the government authorities are happening right now. Therefore as soon as the government authority settles, the information will be provided

4. the person from government who manages the certification process is the computer based chief-official. These government officials are required to pass the computer based state administrator examination. These officials are required to manage the policies and acts regarding IT areas of Korea. With out expert knowledge based on Information security nor PKI they won't be able be a computer based chief-official.

5. last year's audit was completed as follows.
- KICA : 2012. 12. 4
- KOSCOM : 2012. 12. 11
- KFTC : 20012. 12. 30
- CrossCert : 2012. 12. 13
- TradeSign : 2012. 12. 28

these LCA audits meet the baseline requirement #17.5

6. KISA and LCAs has to follow the guideline of Web Server Security, Code-Signing, Secure E-mail Certificate Issuance Administration Guideline. In the article 2, it is stated that the "Domain registration certificate" is requested to the subscribers. KISA and the LCAs meet Baseline requirements #11.1.1 and  #11.1.2.

7. about internal domains, as you can see from my reply, I thought this meant the national domains and international domains. That's why I mentioned International domains. (my apologies)  As you can see from my answer 6, the user must present the "domain registration certificate" in order to get SSL certificate, meaning internal domains (unable to present the "domain registration certificate) can't get issued.

I think the current issues you've mentioned are all answered.If these issues are all solved, would this be all?

(In reply to Kathleen Wilson from comment #150)
> (In reply to Park Soon Tae from comment #145)
> > As I've mentioned above, I will be offering with the new test URL as soon as
> > the test is done.(about CRL distribution issue)
> > Since all the LCA's are supportive, it won't take long.
> > 
> > If this problem is solved, is there any more issue left?
> > 
> 
> The documents that I just attached to this bug are my current notes on this
> request. The items highlighted in yellow indicate where clarification or
> more information is needed. Please also let me know if anything else in the
> documents needs to be updated.

Comment 152

[Adam Langley]

An intermediate from this root ("CrossCert Class 1 Server CA") appears to be run with buggy software :(

It's issuing certificates with negative serial numbers because it doesn't know how to encode ASN.1 integers correctly. Indeed, the certificate for https://www.kisa.or.kr has this problem:

$ openssl s_client -tls1 -connect www.kisa.or.kr:443 2>&1 | openssl x509 -text | grep Serial
        Serial Number: -5897026209493011275 (-0x51d67217ffffcb4b)

That such a basic and obvious bug exists is troubling because most problems can't be so easily seen.

Comment 153

[김기창]

Attempting to connect to https://www.kisa.or.kr/main.jsp with Chrome or with Firefox on Linux, I got connection errors.

It is plainly embarrassing for a National Root CA to be unable to ensure that its sub-ordinate CAs are at least technically capable of issuing server certificates which are functional.

If KISA or its subordinate CAs still cannot manage to create a 'functioning' server certificate (after so many years and so many user reports regarding faulty connections, observable in this thread), why would KISA seek to be 'trusted' by web browsers.

I find it intriguing.

(In reply to Kathleen Wilson from comment #146)
...
> 
> I have successfully browsed to the test website:
> https://www.kisa.or.kr/main.jsp
> 
> I need to go back through this bug and update my notes to make sure I have
> the current information. I have added this to my to-do list.
> 
> In the meantime, please provide a response to the recent CA Communication.
> 
> https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

Comment 154

[Park Soon Tae]

We've checked all the subordinate CAs and found that the subordinate CA which issued to the https://www.kisa.or.kr was the only CA with such kind of error. I am sending other URLs for the test URL(one with other subordinate CA certificates) which has no such error.

 https://www.forme.or.kr/nieweb/user/login.aspx
 https://www.ktl.re.kr/?c=member/member_join_tab01
 https://www.neodin.com/

The errors will be fixed right away, and the certificate will be reissued and will be applied to the site(https://www.kisa.or.kr) today.

(In reply to Adam Langley from comment #152)
> An intermediate from this root ("CrossCert Class 1 Server CA") appears to be
> run with buggy software :(
> 
> It's issuing certificates with negative serial numbers because it doesn't
> know how to encode ASN.1 integers correctly. Indeed, the certificate for
> https://www.kisa.or.kr has this problem:
> 
> $ openssl s_client -tls1 -connect www.kisa.or.kr:443 2>&1 | openssl x509
> -text | grep Serial
>         Serial Number: -5897026209493011275 (-0x51d67217ffffcb4b)
> 
> That such a basic and obvious bug exists is troubling because most problems
> can't be so easily seen.

Comment 155

[김기창]

https://www.kisa.or.kr still has a connection failure when I attempt to connect it with Opera (on Windows as well as on Linux). It is simply incredible that KISA still cannot get this right!

http://opennet.or.kr/wp-content/uploads/2013/04/Screenshot-from-2013-04-13-191611.png 

I wonder how they actually manage to do this.

Comment 156

[김기창]

A number of KISA employees have repeatedly claimed that the relevant Minister (it used to be MIC, MOPAS, now Minister of Science, ICT and Future Planning) audits KISA. In fact, however, there is no legal ground for the Minister to conduct an audit of KISA. As far as I know, KISA is not audited by the relevant Minister and the Ministry has no officers who have the required expertise to conduct such an audit.

The Information Infrastructure Protection Act, Article 9 merely stipulates that the head of an organisation designated as a critical IT infrastructure must conduct vulnerability test. KISA could conduct such a test on behalf of such an organisation. In short, KISA may conduct an audit; KISA itself is not audited by any entity (refer to Comment 39 above)

The E-Signature Act also clearly stipulates that KISA 'conducts' audit of approved CAs on behalf of the Minister (Art. 19, Paras. 2 and 3). This is simply because the Ministry has no expertise in certificate technology. 

KISA, of course, is also deemed to be an "approved CA" and must therefore abide by provisions of the E-Signature Act applicable to approved CAs (Art. 25). But Art. 25 of the E-Signature Act carefully avoids circularity by excluding Art. 19 Paras. 2 and 3 from being applicable to KISA.

Approved CAs must be audited by KISA (Art. 19, Paras 2 and 3). KISA is also deemed to be an approved CA (Art. 25). But KISA is not audited by KISA (because Art 25 does not apply to Art. 19, Paras 2 and 3). In short, KISA is audited by no one. If someone did audit KISA, it must be on the basis of a voluntary contract (of which we have seen no evidence). The Minister has no power to audit KISA under the relevant Korean statutes. 

Keechang Kim, Professor of Law, Korea University Law School

Comment 157

[김기창]

I understand that Windows Root Certificate Program includes 6 Root CA certificates from "Government of Korea".
http://social.technet.microsoft.com/wiki/contents/articles/14217.windows-and-windows-phone-8-ssl-root-certificate-program-april-2012-e-g.aspx 

These six Root CA Certificates are from two different CAs: KISA and MOPAS.

MOPAS is the government CA intended primarily for government to government transactions in Korea. Government workers have a client certificate issued by MOPAS CA (GPKI) and use it for G2G transactions. Although some public bodies in Korea run their website (open to private citizens) secured by a server certificate issued by MOPAS CA (see https://www.open.go.kr/ , for example), I understand that MOPAS CA is a "government CA" as explained in http://technet.microsoft.com/en-us/library/cc751157.aspx#EGAA because it is *primarily* intended for G2G transactions.

However, KISA is different. Although KISA is a root CA set up by the Korean government, its sub-ordinate CAs are all private companies (there are 5 of them at the moment), who issue certificates to private citizens. Client certificates issued by KISA's subordinate CAs may *not* be used for G2G transactions. KISA's subordinate CAs issue certificates which are mainly for private e-commerce transactions (banking, shopping, etc.). Although these certificates are also used for citizen to government (e-government) transactions as well, these certificates cannot by any means be characterised as "primarily" for government transactions. Certificates issued by KISA's sub CAs are primarily for e-commerce transactions between private parties.

Indeed, the Korean Electronic Financial Transactions Act and the relevant Regulations 'require' that e-finance transactions between *private* citizens must be authenticated with certificates issued by sub CAs of KISA.

I would therefore expect that Microsoft would require KISA to submit audit results to Microsoft every twelve (12) months (as explained in http://technet.microsoft.com/en-us/library/cc751157.aspx#EIAA ). But this does not appear to be the case.

KISA submitted to Microsoft a statement issued by the Ministry of Information and Communication (MIC) on 23 May 2005, which vaguely suggested that KISA is audited annually by MIC according to a standard equivalent to WebTrust. (See https://bugzilla.mozilla.org/show_bug.cgi?id=335197#c30 and the file attached therewith). But I am of the view that this was an inaccurate and misleading statement. MIC does not have the statutory power (nor technical expertise) to audit KISA. I explained this point in https://bugzilla.mozilla.org/show_bug.cgi?id=335197#c156 . (Comment 156)

I have checked with the Ministry of Science, ICT and Future Planning (MSIP, who currently oversees KISA). The MSIP confirms that since the MIC statement of 23 May 2005, the relevant ministries (MIC, MOPAS, MSIP) have never issued a similar letter again.  Mr Jaegon Lee of MSIP can confirm this. [e-mail]

KISA also openly admits that it has never been audited by any third party. Indeed, KISA strenuously asserts that it has not and will not accept any third party audit. You may confirm this with Mr Wontae Sim, who is currently the director of KISA Root CA [e-mail]

I express my concern regarding the confidence of Windows Root Certificate Program. KISA Root CA is 'primarily' intended for *private* e-commerce transactions. It is therefore not a government CA (MOPAS CA is the government CA in Korea). I would expect that Microsoft takes annual audit requirement seriously for KISA root CA whose sub CAs issue certificates to private citizens and companies who use them for all sorts of private transactions.

I would appreciate it if Microsoft reviews the applications for inclusion to their Root CA Program in a transparent manner (like Mozilla) which would allow a more robust scrutiny and accountability. 

The problem would be even more acute if government controlled CAs attempt to be included as trusted root CA with a somewhat opaque statement from government officials which turns out to be less than accurate.

Keechang Kim 
Professor of Law, Korea University Law School

Comment 158

[김기창]

I am told that KISA is now going through an audit by a WebTrust practitioner. The local media reports that sometime in the first half of 2014, KISA expects to complete the audit. 

Meanwhile, there is another technical issue. Even when I import and trust a subordinate CA ("yessign CA", for example) of KISA (as well as having explicitly trusted KISA RootCA), if I view the sub CA certificate, Firefox says "Could not verify this certificate for unknown reasons". "Yessign CA" is the biggest sub CA of KISA in Korea. Almost all banking transaction users have their client certificate issued by yessign CA.

Because Yessign CA certificate somehow fails to be verified by Firefox, I cannot use signText function of Firefox with a client certificate issued by Yessign CA. Please have a look at "Signing with Javascript Only" demo site at http://opennet.or.kr/signer/ff.html It does not work even if I import my personal certificate (issued by Yessign CA) to Firefox and explicitly trust Yessign CA as well as KISA RootCA.

I hope this "failure to verify" subordinate CAs of KISA gets fixed before KISA is trusted by Firefox. Otherwise, it would be pointless to trust KISA. KISA does not issue client certificate or server certificate. It is KISA's sub CAs who issue client certificates or server certificates.

I have tested with KISA RootCA certificate and yessign CA certificate downloadable from the bottom of my demo site http://opennet.or.kr/signer/ff.html KISA Root CA does not have this problem. It gets verified OK (once you explicitly trust it).

Comment 159

[김기창]

Attachment: KISA root CA certificates and five subCA certificates whose keyUsage is wrongly asserted

KISA issued CA certificates to its subCAs with keyUsage wrongly asserted as "digitalSignature". As a result, none of the client certificates issued by KISA's subCAs are verifiable by Firefox. A CA certificate must have "keyCertSign" included in its keyUsage.

Comment 160

[김기창]

It seems that KISA asserted the wrong keyUsage extension when it issued CA certificates to its subordinate CAs (such as Yessign CA). All 5 sub CAs of KISA have been issued CA certificates with keyUsage set to "digitalSignature" only. This is plainly wrong. Such keyUsage bit ("digitalSignature") is appropriate only for client certificates. CA certificates must have "keyCertSign" asserted as keyUsage to indicate that the subject public key is used for verifying signatures on public key certificates.

Comment 161

[김기창]

Attachment: Ubuntu file view (GUI) reports keyUsage wrongly in the case of subCAs of KISA

My earlier comments were made in reliance of Ubuntu view file (GUI), which reports the keyUsage to be digitalSignature. Command line examination (openssl x509 -in yessignCAClass1_4099-2048.crt  -noout -text -purpose) reports that the keyUsage are keyCertSign and cRLSign. But Firefox's own cert manager fails to verify this CA certificate (for any purpose). Opera's cert manager flatly refuses to import this CA certificate (import failure). Something must be wrong with this CA certificate.

Comment 162

[Park Soon Tae]

KISA accepted WebTrust seal last month, Jan. 10th.
(https://cert.webtrust.org/ViewSeal?id=1622)

At present we are amending the technical standard and guideline to technically constrain the subordinate CAs according to Mozilla's CA certificate policy.
(just adding several terms that are not that critical issue)
And we are working on LDAP and OCSP responder issue with our CAs right now.
I believe we can attach the amended standard and guideline in a week.

and for the July 30, 2013 ca communication, 
our response is 
a) no action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla's program.

Therefore would like to ask you to review all the requests and catch up, and inform us if there is any more issue.

Thanks.

Comment 163

[김기창]

Well done! I am pleased that KISA has completed an independent audit.

I hope that the technical issue I raised in my previous comments (Comment 158 - Comment 161) will soon be resolved so that CA certificates of KISA's 5 sub-CAs can at least be verifiable by Firefox's cert manager. 

As Mr Park Soon Tae confirmed again in Comment 162, KISA itself does not issue SSL certificates or client certificates. KISA only issues CA certificates for its 5 sub-CAs. SSL certificates and client certificates are issued by these sub-CAs of KISA. Because these sub-CAs' CA certificates are currently "unverifiable" (even if one imports KISA Root and trusts it explicitly), the problem is not trivial.

I am curious whether other Root CAs have similar technical issues (ie., Root CA issuing CA certificates for its sub-CAs which are, for some unaccountable technical reasons, unverifiable by Firefox's cert manager)...

Comment 164

[Kathleen Wilson]

(In reply to 김기창 from comment #163)
> As Mr Park Soon Tae confirmed again in Comment 162, KISA itself does not
> issue SSL certificates or client certificates. KISA only issues CA
> certificates for its 5 sub-CAs. SSL certificates and client certificates are
> issued by these sub-CAs of KISA. Because these sub-CAs' CA certificates are
> currently "unverifiable" (even if one imports KISA Root and trusts it
> explicitly), the problem is not trivial.

It sounds like KISA functions as a super CA in that the subordinate CAs (externally-operated, commercial CAs) have their own policies according to the types of certificates they issue and their own audits. And KISA's policy documentation and the audit of the KISA site only apply to the root certificate in its issuance of subordinate CA certificates. 

If that is correct, then we should take the same approach with this CA as we have with other super-CAs, such as Venezuela’s national government CA (SUSCERTE, bug #489240) and India’s national government CA (CCA, bug #557167). For those super-CAs we had the subordinate CAs apply for inclusion separately, by filing separate bugs. Then the subordinate CA's certificates get included as trust anchors.

Of course, each subordinate CA who applies for inclusion will need to demonstrate compliance with Mozilla’s CA Certificate Policy and the CA/Browser Forum’s Baseline Requirements (if requesting the websites trust bit). But that would have to be established anyways, unless each of the SubCA's certificates are technically constrained by having EKU and Name Constraints in the intermediate certificates.

If you are planning to technically constrain all subordinate CAs as described in items 8 and 9 of http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
then please provide more information about the exact constraints that will be created, and the verification and issuance policies that apply to those subordinate CAs.

Otherwise, please have each subordinate CA file a Bugzilla bug to request inclusion of their subordinate CA certificate as a trust anchor.
https://wiki.mozilla.org/CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request

Comment 165

[Kathleen Wilson]

I have started a discussion about how to proceed with this root inclusion request:

https://groups.google.com/d/msg/mozilla.dev.security.policy/VqlFn61Xr0k/5qCCYrKEdc0J

Comment 166

[Mountie Lee]

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 CA Repository.

Comment 167

[Mountie Lee]

I found the evidence link of CrossCert WebTrust Certificate
https://cert.webtrust.org/ViewSeal?id=1541

I'm not sure this certificate cover the entire operations of CrossCert as LCA of KISA and Verisign.

but the fact is they are audited by WebTrust regulations.

Comment 168

[Kathleen Wilson]

This inclusion request and the topic of Super-CAs has been discussed in mozilla.dev.security.policy.
https://groups.google.com/d/msg/mozilla.dev.security.policy/VqlFn61Xr0k/5qCCYrKEdc0J
https://groups.google.com/d/msg/mozilla.dev.security.policy/oZE1hNEY16w/nrecA1vOakgJ

The conclusion of those discussions is that the KISA CA is a Super-CA, so the following applies:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs
"Such signing CAs are called Super-CAs, and their subordinate CAs must apply for inclusion of their own certificates until the following has been established and demonstrated: ..."

Therefore, this request for inclusion of the KISA root will be on hold, pending inclusion of KISA's subordinate CAs. The subordinate CAs should create separate Bugzilla bugs and apply for inclusion themselves as separate trust anchors, https://wiki.mozilla.org/CA:How_to_apply.

Comment 169

[Kathleen Wilson]

I am closing old requests that are for inclusion of super-CA root certificates.

This CA may re-apply for inclusion of their root certificate when they meet all of the requirements listed here:

https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs

Until then, this CA's (first-level) subordinate CAs may apply for inclusion of their certificate as a trust anchor, as described here:

https://wiki.mozilla.org/CA/Application_Process