Re: Seeking guidance on proceeding with KISA root inclusion request
We are willing to prove that KISA audit criteria fulfills the Mozilla's requirements and CA browser forum requirement. And also to confirm the comparison by a third-party audit practitioner(such as Deloitte). If what KISA audits fulfills the requirements, would that be all? 2014년 4월 2일 수요일 오전 1시 10분 59초 UTC+9, Kurt Roeckx 님의 말: > On Tue, Apr 01, 2014 at 11:27:53AM +0800, Man Ho (Certizen) wrote: > > > Hi All, > > > > > > In this discussion of KISA CA, it seems to conclude that KISA root > > > certificate should not be included in Mozilla trust list AND the > > > subordinate CAs should apply for inclusion themselves. On the other > > > hand, in the discussion regarding "Super CA", Mozilla seems to accept > > > inclusion of "Super CA" by saying that their subordinate CAs must apply > > > for inclusion of their own certificate until certain criteria are satisfied. > > > > > > It is very confusing what position Mozilla will take. Does the > > > subordinate CAs required to apply for inclusion themselves? It looks > > > like that KISA CA is by definition also a "Super CA", isn't it? > > > > It looks to me that after repeated request for more information, > > KISA has failed to meet the requirements as discussed in the Super > > CA thread, and so the LCAs should apply themself. > > > > > > Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 3/31/14, 8:27 PM, Man Ho (Certizen) wrote: Hi All, In this discussion of KISA CA, it seems to conclude that KISA root certificate should not be included in Mozilla trust list AND the subordinate CAs should apply for inclusion themselves. On the other hand, in the discussion regarding "Super CA", Mozilla seems to accept inclusion of "Super CA" by saying that their subordinate CAs must apply for inclusion of their own certificate until certain criteria are satisfied. It is very confusing what position Mozilla will take. Does the subordinate CAs required to apply for inclusion themselves? It looks like that KISA CA is by definition also a "Super CA", isn't it? regards Man You are correct. I wrote my response to this before I drafted the new proposed text for Super CAs. I agree with you, that the best approach will be to finalize the Super CA text, and then apply that to the KISA CA. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On Tue, Apr 01, 2014 at 11:27:53AM +0800, Man Ho (Certizen) wrote: > Hi All, > > In this discussion of KISA CA, it seems to conclude that KISA root > certificate should not be included in Mozilla trust list AND the > subordinate CAs should apply for inclusion themselves. On the other > hand, in the discussion regarding "Super CA", Mozilla seems to accept > inclusion of "Super CA" by saying that their subordinate CAs must apply > for inclusion of their own certificate until certain criteria are satisfied. > > It is very confusing what position Mozilla will take. Does the > subordinate CAs required to apply for inclusion themselves? It looks > like that KISA CA is by definition also a "Super CA", isn't it? It looks to me that after repeated request for more information, KISA has failed to meet the requirements as discussed in the Super CA thread, and so the LCAs should apply themself. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
Hi All, In this discussion of KISA CA, it seems to conclude that KISA root certificate should not be included in Mozilla trust list AND the subordinate CAs should apply for inclusion themselves. On the other hand, in the discussion regarding "Super CA", Mozilla seems to accept inclusion of "Super CA" by saying that their subordinate CAs must apply for inclusion of their own certificate until certain criteria are satisfied. It is very confusing what position Mozilla will take. Does the subordinate CAs required to apply for inclusion themselves? It looks like that KISA CA is by definition also a "Super CA", isn't it? regards Man On 4/1/2014 6:26 AM, Kathleen Wilson wrote: > On 3/4/14, 11:38 AM, Kathleen Wilson wrote: >> All, >> >> I will appreciate your input on how to proceed with the KISA root >> inclusion request. >> > > > All, > > Thank you for your thoughtful and constructive input. > > I believe that there is consensus on the following three points. > > 1) The KISA CA does not issue end-entity certificates for websites > (SSL/TSL), Code Signing, or email (S/MIME), so there is no need for > Mozilla to include the KISA root certificate. > > 2) LCAs are CAs who are licensed by KISA to operate in Korea, and they > issue certificates for websites, code signing, and/or email. LCAs > should apply for inclusion themselves and be audited annually > according to Mozilla's CA Certificate Policy. (sections 11 through 14 > of > http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/) > > 3) Mozilla's policy requires audits that incorporate certain audit > criteria, including the CA/Browser Forum's Baseline Requirements. KISA > may incorporate this audit criteria into their annual audits of their > LCAs, and demonstrate this audit criteria to Mozilla. Or the LCAs may > get another audit from another organization according to this audit > criteria. > > Please let me know if I've missed anything. > > Thanks, > Kathleen > > > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 3/4/14, 11:38 AM, Kathleen Wilson wrote: All, I will appreciate your input on how to proceed with the KISA root inclusion request. All, Thank you for your thoughtful and constructive input. I believe that there is consensus on the following three points. 1) The KISA CA does not issue end-entity certificates for websites (SSL/TSL), Code Signing, or email (S/MIME), so there is no need for Mozilla to include the KISA root certificate. 2) LCAs are CAs who are licensed by KISA to operate in Korea, and they issue certificates for websites, code signing, and/or email. LCAs should apply for inclusion themselves and be audited annually according to Mozilla's CA Certificate Policy. (sections 11 through 14 of http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/) 3) Mozilla's policy requires audits that incorporate certain audit criteria, including the CA/Browser Forum's Baseline Requirements. KISA may incorporate this audit criteria into their annual audits of their LCAs, and demonstrate this audit criteria to Mozilla. Or the LCAs may get another audit from another organization according to this audit criteria. Please let me know if I've missed anything. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
As Kathleen explained, KISA does not issue any end-entity certificate (no SSL cert, no client cert issued by KISA). KISA issues only 5 CA certificates and no more. Perhaps WebTrust criteria have not envisaged this kind of 'Super CA', whose role is merely administrative and somewhat 'abstract'. It is true that KISA was audited regarding certificate issuance, renewal, revocation, distribution, etc. But it was with regard to "only 5 certificates" issued and maintained by KISA. KISA is not a CA in the usual sense. A sensible approach would be that each LCA (who is a real CA issuing end entity certificates) should be audited according to the standard satisfactory to Mozilla before it is trusted by Mozilla. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
They way I see it there are basically 2 cases: 1) The root CA and the other CAs are not related. Those other CAs are *not* Sub-CAs, they are CAs on their own and are independent of the root CA. 2) The root CA and *all* Sub-CAs are the same organization. What I see here being argued is that KISA should fall under 1). And I have no problem seeing KISA as being independent here, since I understand that they are so under the law. But this would mean the following for me: - The other CAs need to have an audit at least every year to check for compliance with *our* requirements, not the requirements from the Korean law. That is, we might have more requirements than the Korean law, and they need to be checked too. - There is no need for us to accept the KISA root CA, since they don't sign end user certificates and the LCAs need to have an audit anyway. We can just accept the LCAs that request it based on KISA's audits, assuming that they meet all the requirements. But I have yet to see that KISA has been audited to comply with all our requirements. Nothing in here says that KISA has been audited for compliance with the CA/Browser forum Baseline Requirements. There has been no clear indication what the Korean law now asks you to audit in the LCAs and whether that's equivalent to any of those audits we now accept. It's also not clear that all are requirements are being audited in those LCAs. I'm still of the opinion that we should not add KISA and that the LCAs should instead apply themself. I see no problem with KISA doing the audits. If they do not audit all our requirements some or all of those might need to be audited by an other independent party. Kurt On Tue, Mar 11, 2014 at 11:12:20AM +0900, ??? ? wrote: > there was no and is no on-going financial relationship between KISA and all > the Sub-CAs. > (and of course there will be no) > > > 2014-03-11 11:04 GMT+09:00 Al Billings : > > > On 3/10/14, 6:58 PM, spark0...@gmail.com wrote: > > > This might be a normal case for CA and Sub-CA in the business and that's > > why I am mentioning Korea Electronic Signature Act. > > > I do understand why BR is requesting for 'independency' of the auditor, > > but because KISA is designated by law to audit the accredited CAs, our > > relationship is clear(no corruption or mis-audit can happen). It is between > > the auditor and auditee. We also do not have any conflict of interest > > between KISA and Sub-CAs because we do not make any profit from the sub-CAs. > > > > The reasoning here is that there should be no ongoing financial > > relationship causing a conflict of interest, I believe. > > > > Al > > > > -- > > Program Manager > > Firefox Platform Security Team > > > > > > > > > -- > ? > ??? ?(G-ISMS, K-ISMS, ISO-27001) > 138-950 ??? ??? ??? 135 IT > Phone: (02)405-5434 > Fax: (02)405-5249 > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
there was no and is no on-going financial relationship between KISA and all the Sub-CAs. (and of course there will be no) 2014-03-11 11:04 GMT+09:00 Al Billings : > On 3/10/14, 6:58 PM, spark0...@gmail.com wrote: > > This might be a normal case for CA and Sub-CA in the business and that's > why I am mentioning Korea Electronic Signature Act. > > I do understand why BR is requesting for 'independency' of the auditor, > but because KISA is designated by law to audit the accredited CAs, our > relationship is clear(no corruption or mis-audit can happen). It is between > the auditor and auditee. We also do not have any conflict of interest > between KISA and Sub-CAs because we do not make any profit from the sub-CAs. > > The reasoning here is that there should be no ongoing financial > relationship causing a conflict of interest, I believe. > > Al > > -- > Program Manager > Firefox Platform Security Team > > > -- 한국인터넷진흥원 전자인증팀 박순태 선임연구원(G-ISMS, K-ISMS, ISO-27001) 138-950 서울시 송파구 중대로 135 IT벤처타워 Phone: (02)405-5434 Fax: (02)405-5249 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Seeking guidance on proceeding with KISA root inclusion request
Hi Eddy. Yes, this is true... unless the SubCA is technically constrained. In that case the auditing is less restrictive so that the CA can audit and should audit the SubCA for compliance and quality. The constraints provide protection but don't solve best practice such as key size, SAN inclusion etc so these need to be flowed down and monitored as per the amendments to the BR guidelines in ballot 105 last July. Steve > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign@lists.mozilla.org] On Behalf Of Eddy > Nigg > Sent: 10 March 2014 23:07 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Seeking guidance on proceeding with KISA root inclusion request > > On 03/07/2014 07:10 AM, From spark0...@gmail.com: > > According to Mozilla's definition of independent party, KISA is > > independent organization from Sub-CAs(not employees nor director) > > The minute a CA signs a certificate of/for another CA, it's not independent at all. In > fact a tight relationship exists between the two parties and a CA can't audit > another CA. For this the BR sets forth a requirement for an independent audit by a > (different) auditing firm than the CA signer/issuer, in order to avoid any conflict of > interests. > > -- > Regards > > Signer: Eddy Nigg, StartCom Ltd. > XMPP:start...@startcom.org > Blog: http://blog.startcom.org/ > Twitter: http://twitter.com/eddy_nigg > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 3/10/14, 6:58 PM, spark0...@gmail.com wrote: > This might be a normal case for CA and Sub-CA in the business and that's why > I am mentioning Korea Electronic Signature Act. > I do understand why BR is requesting for 'independency' of the auditor, but > because KISA is designated by law to audit the accredited CAs, our > relationship is clear(no corruption or mis-audit can happen). It is between > the auditor and auditee. We also do not have any conflict of interest between > KISA and Sub-CAs because we do not make any profit from the sub-CAs. The reasoning here is that there should be no ongoing financial relationship causing a conflict of interest, I believe. Al -- Program Manager Firefox Platform Security Team smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
2014년 3월 11일 화요일 오전 8시 6분 55초 UTC+9, Eddy Nigg 님의 말: > On 03/07/2014 07:10 AM, From spark0...@gmail.com: > > > According to Mozilla's definition of independent party, KISA is > > > independent organization from Sub-CAs(not employees nor director) > > > > The minute a CA signs a certificate of/for another CA, it's not > > independent at all. In fact a tight relationship exists between the two > > parties and a CA can't audit another CA. For this the BR sets forth a > > requirement for an independent audit by a (different) auditing firm than > > the CA signer/issuer, in order to avoid any conflict of interests. This might be a normal case for CA and Sub-CA in the business and that's why I am mentioning Korea Electronic Signature Act. I do understand why BR is requesting for 'independency' of the auditor, but because KISA is designated by law to audit the accredited CAs, our relationship is clear(no corruption or mis-audit can happen). It is between the auditor and auditee. We also do not have any conflict of interest between KISA and Sub-CAs because we do not make any profit from the sub-CAs. > > > > -- > > Regards > > > > Signer: Eddy Nigg, StartCom Ltd. > > XMPP:start...@startcom.org > > Blog: http://blog.startcom.org/ > > Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 03/07/2014 07:10 AM, From spark0...@gmail.com: According to Mozilla's definition of independent party, KISA is independent organization from Sub-CAs(not employees nor director) The minute a CA signs a certificate of/for another CA, it's not independent at all. In fact a tight relationship exists between the two parties and a CA can't audit another CA. For this the BR sets forth a requirement for an independent audit by a (different) auditing firm than the CA signer/issuer, in order to avoid any conflict of interests. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
Hello, 2014년 3월 6일 목요일 오후 9시 12분 25초 UTC+9, Erwann Abalea 님의 말: > Bonjour Samuel, > > > > Le jeudi 6 mars 2014 10:37:30 UTC+1, spar...@gmail.com a écrit : > > > Let me start with the Webtrust audit the Crosscert got. > > > > > > The Webtrust audit Crosscert received is for the Verisign service they are > > offering. > > > > > > For your information, Crosscert is also a sub-CA of Verisign. However, two > > systems(KISA and Verisign) are seperately operated and the audit does not > > cover the area of KISA's certificates. This is Crosscert's business to > > operate Verisign service so KISA does not care about it as long as it does > > not effect KISA's certificates. > > > > So, "Crosscert" has at least 2 different CAs, one signed by VeriSign and > audited to be conformant with WebTrust (for CA/EV? which version?), the other > one signed by KISA and audited by KISA. Yes, it is Webtrust for CA, not EV. > > This second audit doesn't satisfy the Mozilla criteria *at all*: independant > auditor, audit criteria among the accepted ones, and, reading the long > ticket, competent party. According to Mozilla's definition of independent party, KISA is independent organization from Sub-CAs(not employees nor director), also not compensated financially and also bounded by the law and government regulation to do the auditing. In what reason are you saying that we are not satisfied *at all*? have you gone through our act, decree and ordinance which lead to audit criteria and compared it with webtrust? at the bugzilla we already posted CPSs of the sub-CAs and under electronic signature act regulation article 13.5 KISA audits whether sub-CAs are operated as their CPS is published every year. > > > > > KISA is designated by law to do the actual auditing of CAs(for the KISA's > > certificates) and the audit criteria are all from the act, decree, > > ordinance and regulations from them(Korea Electronic Signature Act). I > > believe for several years what KISA was convincing Mozilla was that how > > KISA audits the sub-CAs and the Mozilla's request was KISA getting a > > Webtrust. Now we got a webtrust > > (https://cert.webtrust.org/ViewSeal?id=1622). > > > > But you got a Webtrust for a CA that isn't concerned by the request. > > > > > If you are requesting for the Sub-CAs Webtrust now, it will be very > > disappointing issue to delay the entire time-line we were expecting(since > > we were trying to include KISA certificate from 2006). > > > > A quick Google search for old versions of Mozilla Policy brings this link: > > http://www-archive.mozilla.org/projects/security/certs/policy/ > > This is the version 1.2 of the policy, dated 2008. It wasn't perfect, some > gray areas were present, but at least, in this policy, the "independant, > competent, criteria" principles were already written, and KISA didn't reply > to any of them. This isn't new. the point I am trying to make is that there was no mentioning from Mozilla (at the bugzilla) that we should reply to them. meaning we understood since there was no mentioning, we believed KISA's audit is accepted by Mozilla. > > > > >As you may or may not know every accredited CA in Korea is strictly ruled by > >the government.(that's why they are designated 'accredited').Any accident or > >security matter, Korean government will respond directly. > > > > And Mozilla policy doesn't take that into account. A CA can be covered by > several audits if necessary. I am not saying that we should be accepted just because we are controlled by the government. I am just saying the audit KISA is doing to the Sub-CA is clear as any other disclosed audits, since it is run by government(by law). criteria is from the act, decree, ordinance which is publicly disclosed and KISA will be questioned by national assembly and congressman if we do not perform our audit clearly. I don't see any reason why KISA's auditing is not acceptable. > > > > > And for your information, KISA's certificate is already included at MS IE, > > APLLE Safari, OPERA and also Android OS several years ago. > > > That's not an argument. > > > > And of course, Korea electronic signature act, decree, ordinance and > > regulations fulfill the Mozilla's requirements(I believe that's what we > > were trying to convince Mozilla through bugzilla ever since year 2006). > > > > I'm not convinced. The example certificates I've seen so far don't contain an > HTTP URL for a CRL, don't contain an OCSP URL, and contain a bad subject. At > least. You can see from the bugzilla that we are aware of this and changing them right now, if the issue above (about accepting KISA's audit) is solved, I assure you this can be handled right away. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
Bonjour Samuel, Le jeudi 6 mars 2014 10:37:30 UTC+1, spar...@gmail.com a écrit : > Let me start with the Webtrust audit the Crosscert got. > > The Webtrust audit Crosscert received is for the Verisign service they are > offering. > > For your information, Crosscert is also a sub-CA of Verisign. However, two > systems(KISA and Verisign) are seperately operated and the audit does not > cover the area of KISA's certificates. This is Crosscert's business to > operate Verisign service so KISA does not care about it as long as it does > not effect KISA's certificates. So, "Crosscert" has at least 2 different CAs, one signed by VeriSign and audited to be conformant with WebTrust (for CA/EV? which version?), the other one signed by KISA and audited by KISA. This second audit doesn't satisfy the Mozilla criteria *at all*: independant auditor, audit criteria among the accepted ones, and, reading the long ticket, competent party. > KISA is designated by law to do the actual auditing of CAs(for the KISA's > certificates) and the audit criteria are all from the act, decree, ordinance > and regulations from them(Korea Electronic Signature Act). I believe for > several years what KISA was convincing Mozilla was that how KISA audits the > sub-CAs and the Mozilla's request was KISA getting a Webtrust. Now we got a > webtrust (https://cert.webtrust.org/ViewSeal?id=1622). But you got a Webtrust for a CA that isn't concerned by the request. > If you are requesting for the Sub-CAs Webtrust now, it will be very > disappointing issue to delay the entire time-line we were expecting(since we > were trying to include KISA certificate from 2006). A quick Google search for old versions of Mozilla Policy brings this link: http://www-archive.mozilla.org/projects/security/certs/policy/ This is the version 1.2 of the policy, dated 2008. It wasn't perfect, some gray areas were present, but at least, in this policy, the "independant, competent, criteria" principles were already written, and KISA didn't reply to any of them. This isn't new. >As you may or may not know every accredited CA in Korea is strictly ruled by >the government.(that's why they are designated 'accredited').Any accident or >security matter, Korean government will respond directly. And Mozilla policy doesn't take that into account. A CA can be covered by several audits if necessary. > And for your information, KISA's certificate is already included at MS IE, > APLLE Safari, OPERA and also Android OS several years ago. That's not an argument. > And of course, Korea electronic signature act, decree, ordinance and > regulations fulfill the Mozilla's requirements(I believe that's what we were > trying to convince Mozilla through bugzilla ever since year 2006). I'm not convinced. The example certificates I've seen so far don't contain an HTTP URL for a CRL, don't contain an OCSP URL, and contain a bad subject. At least. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
Dear Samuel,
What is important for us is that both KISA and all it's SubCAs comply
with the CA/Browser baseline requirements. Please see
https://cabforum.org/baseline-requirements/
Can you confirm that there is an audit that checks those requirements?
Or confirm that there is no such audit?
Kurt
On 2014-03-06 10:37, spark0...@gmail.com wrote:
Let me start with the Webtrust audit the Crosscert got.
The Webtrust audit Crosscert received is for the Verisign service they are
offering.
For your information, Crosscert is also a sub-CA of Verisign. However, two
systems(KISA and Verisign) are seperately operated and the audit does not cover
the area of KISA’s certificates. This is Crosscert’s business to operate
Verisign service so KISA does not care about it as long as it does not effect
KISA’s certificates.
KISA is designated by law to do the actual auditing of CAs(for the KISA’s
certificates) and the audit criteria are all from the act, decree, ordinance
and regulations from them(Korea Electronic Signature Act). I believe for
several years what KISA was convincing Mozilla was that how KISA audits the
sub-CAs and the Mozilla’s request was KISA getting a Webtrust. Now we got a
webtrust (https://cert.webtrust.org/ViewSeal?id=1622). If you are requesting
for the Sub-CAs Webtrust now, it will be very disappointing issue to delay the
entire time-line we were expecting(since we were trying to include KISA
certificate from 2006). As you may or may not know every accredited CA in Korea
is strictly ruled by the government.(that’s why they are designated
’accredited’).Any accident or security matter, Korean government will respond
directly. And for your information, KISA’s certificate is already included at
MS IE, APLLE Safari, OPERA and also Android OS several years ago. A
nd of c
ourse, Korea electronic signature act, decree, ordinance and regulations
fulfill the Mozilla’s requirements(I believe that's what we were trying to
convince Mozilla through bugzilla ever since year 2006).
Samuel
2014년 3월 5일 수요일 오전 4시 38분 24초 UTC+9, Kathleen Wilson 님의 말:
All,
I will appreciate your input on how to proceed with the KISA root
inclusion request.
My personal preference is to proceed with the process to approve/include
the KISA root under the condition that Mozilla would constrain the CA
hierarchy to *.kr. However, KISA does not want to constrain their CA
hierarchy to *.kr. I have also suggested that KISA have each subCA apply
for inclusion as separate trust anchors, but KISA does not want to take
that approach either.
The following is my understanding of this CA.
Inclusion Request Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=335197
CA Information Document:
https://bugzilla.mozilla.org/attachment.cgi?id=727859
KISA document repository:
http://www.rootca.or.kr/kor/accredited/accredited02.jsp
CPS (English):
http://www.rootca.or.kr/kor/down/cps16(en).pdf
Korea Information Security Agency (KISA) is the Electronic Signature
Authorization Management Center for South Korea. The Korean
Certification Authority Central (KCAC) of KISA issues certificates to
intermediate CAs (licensed CAs = LCAs), which then issue end-entity
certificates to Korean citizens, businesses, and other organizations.
The LCAs are private organizations (not government organizations).
The LCAs are listed in Korean at
http://www.rootca.or.kr/kor/accredited/accredited02.jsp
They are:
Korea Information Certificate Authority Inc (KICA), http://www.signgate.com
KICA CPS (Korean): http://www.signgate.com/customer/cus_cps.sg
Korea Securities Computer Corporation (KOSCOM), http://www.signkorea.com
KOSCOM CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479655
Korea Electronic Certification Authority Inc (CrossCert),
http://gca.crosscert.com
CrossCert CPS (English):
https://bugzilla.mozilla.org/attachment.cgi?id=479658
KTNET ("TradeSign" or "KITA"), http://www.tradesign.net/
TradeSign CPS (English):
https://bugzilla.mozilla.org/attachment.cgi?id=479659
Korea Financial Telecommunications (KFTC), http://www.yessign.or.kr
(non-profit)
KFTC CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479657
Deloitte completed a WebTrust audit of KISA’s operation of the root, but
the subordinate CAs (LCAs) are not WebTrust audited. The LCAs are
regulated by the Korean Electronic Signature Act, and the law requires
that KISA does the actual examination of the LCAs and report their
findings to the government. The evaluation (audit) criteria are attached
to the Bugzilla bug.
Electronic Signature Act:
https://bugzilla.mozilla.org/attachment.cgi?id=594638
Enforcement Decree:
https://bugzilla.mozilla.org/attachment.cgi?id=594639
Enforcement Regulations:
https://bugzilla.mozilla.org/attachment.cgi?id=594640
The LCAs are annually audited and are not allowed to change anything
(system, h/w, s/w) without reporting to the government, and any
mis-issuance of certificate
Re: Seeking guidance on proceeding with KISA root inclusion request
Let me start with the Webtrust audit the Crosscert got.
The Webtrust audit Crosscert received is for the Verisign service they are
offering.
For your information, Crosscert is also a sub-CA of Verisign. However, two
systems(KISA and Verisign) are seperately operated and the audit does not cover
the area of KISA’s certificates. This is Crosscert’s business to operate
Verisign service so KISA does not care about it as long as it does not effect
KISA’s certificates.
KISA is designated by law to do the actual auditing of CAs(for the KISA’s
certificates) and the audit criteria are all from the act, decree, ordinance
and regulations from them(Korea Electronic Signature Act). I believe for
several years what KISA was convincing Mozilla was that how KISA audits the
sub-CAs and the Mozilla’s request was KISA getting a Webtrust. Now we got a
webtrust (https://cert.webtrust.org/ViewSeal?id=1622). If you are requesting
for the Sub-CAs Webtrust now, it will be very disappointing issue to delay the
entire time-line we were expecting(since we were trying to include KISA
certificate from 2006). As you may or may not know every accredited CA in Korea
is strictly ruled by the government.(that’s why they are designated
’accredited’).Any accident or security matter, Korean government will respond
directly. And for your information, KISA’s certificate is already included at
MS IE, APLLE Safari, OPERA and also Android OS several years ago. And of
course, Korea electronic signature act, decree, ordinance and regulations
fulfill the Mozilla’s requirements(I believe that's what we were trying to
convince Mozilla through bugzilla ever since year 2006).
Samuel
2014년 3월 5일 수요일 오전 4시 38분 24초 UTC+9, Kathleen Wilson 님의 말:
> All,
>
>
>
> I will appreciate your input on how to proceed with the KISA root
>
> inclusion request.
>
>
>
> My personal preference is to proceed with the process to approve/include
>
> the KISA root under the condition that Mozilla would constrain the CA
>
> hierarchy to *.kr. However, KISA does not want to constrain their CA
>
> hierarchy to *.kr. I have also suggested that KISA have each subCA apply
>
> for inclusion as separate trust anchors, but KISA does not want to take
>
> that approach either.
>
>
>
> The following is my understanding of this CA.
>
>
>
> Inclusion Request Bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=335197
>
> CA Information Document:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=727859
>
> KISA document repository:
>
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
>
> CPS (English):
>
> http://www.rootca.or.kr/kor/down/cps16(en).pdf
>
>
>
> Korea Information Security Agency (KISA) is the Electronic Signature
>
> Authorization Management Center for South Korea. The Korean
>
> Certification Authority Central (KCAC) of KISA issues certificates to
>
> intermediate CAs (licensed CAs = LCAs), which then issue end-entity
>
> certificates to Korean citizens, businesses, and other organizations.
>
> The LCAs are private organizations (not government organizations).
>
>
>
> The LCAs are listed in Korean at
>
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
>
> They are:
>
> Korea Information Certificate Authority Inc (KICA), http://www.signgate.com
>
> KICA CPS (Korean): http://www.signgate.com/customer/cus_cps.sg
>
> Korea Securities Computer Corporation (KOSCOM), http://www.signkorea.com
>
> KOSCOM CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479655
>
> Korea Electronic Certification Authority Inc (CrossCert),
>
> http://gca.crosscert.com
>
> CrossCert CPS (English):
>
> https://bugzilla.mozilla.org/attachment.cgi?id=479658
>
> KTNET ("TradeSign" or "KITA"), http://www.tradesign.net/
>
> TradeSign CPS (English):
>
> https://bugzilla.mozilla.org/attachment.cgi?id=479659
>
> Korea Financial Telecommunications (KFTC), http://www.yessign.or.kr
>
> (non-profit)
>
> KFTC CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479657
>
>
>
> Deloitte completed a WebTrust audit of KISA’s operation of the root, but
>
> the subordinate CAs (LCAs) are not WebTrust audited. The LCAs are
>
> regulated by the Korean Electronic Signature Act, and the law requires
>
> that KISA does the actual examination of the LCAs and report their
>
> findings to the government. The evaluation (audit) criteria are attached
>
> to the Bugzilla bug.
>
> Electronic Signature Act:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=594638
>
> Enforcement Decree:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=594639
>
> Enforcement Regulations:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=594640
>
>
>
> The LCAs are annually audited and are not allowed to change anything
>
> (system, h/w, s/w) without reporting to the government, and any
>
> mis-issuance of certificates would lead to penalty by the Act.
>
>
>
> The Korean government controls the po
Re: Seeking guidance on proceeding with KISA root inclusion request
On 2014-03-05 01:21, Kathleen Wilson wrote: On 3/4/14, 4:00 PM, moun...@paygate.net wrote: 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 Repository. That is interesting. If one of the LCAs gets a WebTrust audit, then it would stand to reason that the rest of them could get WebTrust audits too. So it's my understanding that KISA is required to audit them, because they are licensed, but that nothing stops them from getting an additional audit for which we are sure that they are checked to be complying with the requirements we have. So unless KISA can guarantee that they do an audit to check compliance with the requirements I suggest the LCAs apply directly instead. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 3/4/14, 4:00 PM, moun...@paygate.net wrote: 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 Repository. That is interesting. If one of the LCAs gets a WebTrust audit, then it would stand to reason that the rest of them could get WebTrust audits too. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
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
Repository.
2014년 3월 5일 수요일 오전 4시 38분 24초 UTC+9, Kathleen Wilson 님의 말:
> All,
>
>
>
> I will appreciate your input on how to proceed with the KISA root
>
> inclusion request.
>
>
>
> My personal preference is to proceed with the process to approve/include
>
> the KISA root under the condition that Mozilla would constrain the CA
>
> hierarchy to *.kr. However, KISA does not want to constrain their CA
>
> hierarchy to *.kr. I have also suggested that KISA have each subCA apply
>
> for inclusion as separate trust anchors, but KISA does not want to take
>
> that approach either.
>
>
>
> The following is my understanding of this CA.
>
>
>
> Inclusion Request Bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=335197
>
> CA Information Document:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=727859
>
> KISA document repository:
>
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
>
> CPS (English):
>
> http://www.rootca.or.kr/kor/down/cps16(en).pdf
>
>
>
> Korea Information Security Agency (KISA) is the Electronic Signature
>
> Authorization Management Center for South Korea. The Korean
>
> Certification Authority Central (KCAC) of KISA issues certificates to
>
> intermediate CAs (licensed CAs = LCAs), which then issue end-entity
>
> certificates to Korean citizens, businesses, and other organizations.
>
> The LCAs are private organizations (not government organizations).
>
>
>
> The LCAs are listed in Korean at
>
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
>
> They are:
>
> Korea Information Certificate Authority Inc (KICA), http://www.signgate.com
>
> KICA CPS (Korean): http://www.signgate.com/customer/cus_cps.sg
>
> Korea Securities Computer Corporation (KOSCOM), http://www.signkorea.com
>
> KOSCOM CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479655
>
> Korea Electronic Certification Authority Inc (CrossCert),
>
> http://gca.crosscert.com
>
> CrossCert CPS (English):
>
> https://bugzilla.mozilla.org/attachment.cgi?id=479658
>
> KTNET ("TradeSign" or "KITA"), http://www.tradesign.net/
>
> TradeSign CPS (English):
>
> https://bugzilla.mozilla.org/attachment.cgi?id=479659
>
> Korea Financial Telecommunications (KFTC), http://www.yessign.or.kr
>
> (non-profit)
>
> KFTC CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479657
>
>
>
> Deloitte completed a WebTrust audit of KISA’s operation of the root, but
>
> the subordinate CAs (LCAs) are not WebTrust audited. The LCAs are
>
> regulated by the Korean Electronic Signature Act, and the law requires
>
> that KISA does the actual examination of the LCAs and report their
>
> findings to the government. The evaluation (audit) criteria are attached
>
> to the Bugzilla bug.
>
> Electronic Signature Act:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=594638
>
> Enforcement Decree:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=594639
>
> Enforcement Regulations:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=594640
>
>
>
> The LCAs are annually audited and are not allowed to change anything
>
> (system, h/w, s/w) without reporting to the government, and any
>
> mis-issuance of certificates would lead to penalty by the Act.
>
>
>
> The Korean government controls the policies and technical standards
>
> under the Electronic Signature Act. Although the actual auditing is done
>
> by KISA, all the results are reported to the ministry (currently the
>
> Ministry of Science, ICT and future Planning). KISA is an expert group
>
> to help the ministry for the actual examination and other expertise for
>
> the national PKI. KISA is an affiliated organization of the ministry,
>
> and is run by the government. All the orders to control the LCAs are
>
> from the ministry.
>
>
>
> Note that KISA is also the National Internet resources Center of Korea,
>
> http://krnic.kisa.or.kr/jsp/english/krnic/intro.jsp
>
>
>
> We need to take into account sections 8 through 14 of Mozilla's CA
>
> Certificate Inclusion Policy:
>
> http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>
>
>
> Section 10 says that if the subordinate CA certificate is not
>
> technically constrained (as described in section 9) then the subordinate
>
> CA must be audited according to sections 11 through 14. So, according to
>
> section 11 the subordinate CA operations must be audited according to
>
> the WebTrust CA or ETSI TS 102 042 criteria, and must also be audited
>
> according to the Baseline Requirements (the websites trust bit is
>
> requested).
>
>
>
> My questions…
>
>
>
> How would we know that the criteria that KISA uses to audit th
Re: Seeking guidance on proceeding with KISA root inclusion request
On 03/04/2014 09:38 PM, From Kathleen Wilson: My personal preference is to proceed with the process to approve/include the KISA root under the condition that Mozilla would constrain the CA hierarchy to *.kr. However, KISA does not want to constrain their CA hierarchy to *.kr. I have also suggested that KISA have each subCA apply for inclusion as separate trust anchors, but KISA does not want to take that approach either. I think the BR and Mozilla's own policy has set the proper requirements defined for any CA operating under another CA (root). This should apply here too which excludes the CA performing a (self) audit for the sub ordinate CAs for example. In respect to limiting issuance to a TLD, Mozilla might have to set a criteria for it first. Being a national (local) CA could be such a criteria. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 3/4/2014 11:38 AM, Kathleen Wilson wrote:
> All,
>
> I will appreciate your input on how to proceed with the KISA root
> inclusion request.
>
> My personal preference is to proceed with the process to approve/include
> the KISA root under the condition that Mozilla would constrain the CA
> hierarchy to *.kr. However, KISA does not want to constrain their CA
> hierarchy to *.kr. I have also suggested that KISA have each subCA apply
> for inclusion as separate trust anchors, but KISA does not want to take
> that approach either.
>
> The following is my understanding of this CA.
>
> Inclusion Request Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=335197
> CA Information Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=727859
> KISA document repository:
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
> CPS (English):
> http://www.rootca.or.kr/kor/down/cps16(en).pdf
>
> Korea Information Security Agency (KISA) is the Electronic Signature
> Authorization Management Center for South Korea. The Korean
> Certification Authority Central (KCAC) of KISA issues certificates to
> intermediate CAs (licensed CAs = LCAs), which then issue end-entity
> certificates to Korean citizens, businesses, and other organizations.
> The LCAs are private organizations (not government organizations).
>
> The LCAs are listed in Korean at
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
> They are:
> Korea Information Certificate Authority Inc (KICA), http://www.signgate.com
> KICA CPS (Korean): http://www.signgate.com/customer/cus_cps.sg
> Korea Securities Computer Corporation (KOSCOM), http://www.signkorea.com
> KOSCOM CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479655
> Korea Electronic Certification Authority Inc (CrossCert),
> http://gca.crosscert.com
> CrossCert CPS (English):
> https://bugzilla.mozilla.org/attachment.cgi?id=479658
> KTNET ("TradeSign" or "KITA"), http://www.tradesign.net/
> TradeSign CPS (English):
> https://bugzilla.mozilla.org/attachment.cgi?id=479659
> Korea Financial Telecommunications (KFTC), http://www.yessign.or.kr
> (non-profit)
> KFTC CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479657
>
> Deloitte completed a WebTrust audit of KISA’s operation of the root, but
> the subordinate CAs (LCAs) are not WebTrust audited. The LCAs are
> regulated by the Korean Electronic Signature Act, and the law requires
> that KISA does the actual examination of the LCAs and report their
> findings to the government. The evaluation (audit) criteria are attached
> to the Bugzilla bug.
> Electronic Signature Act:
> https://bugzilla.mozilla.org/attachment.cgi?id=594638
> Enforcement Decree:
> https://bugzilla.mozilla.org/attachment.cgi?id=594639
> Enforcement Regulations:
> https://bugzilla.mozilla.org/attachment.cgi?id=594640
>
> The LCAs are annually audited and are not allowed to change anything
> (system, h/w, s/w) without reporting to the government, and any
> mis-issuance of certificates would lead to penalty by the Act.
>
> The Korean government controls the policies and technical standards
> under the Electronic Signature Act. Although the actual auditing is done
> by KISA, all the results are reported to the ministry (currently the
> Ministry of Science, ICT and future Planning). KISA is an expert group
> to help the ministry for the actual examination and other expertise for
> the national PKI. KISA is an affiliated organization of the ministry,
> and is run by the government. All the orders to control the LCAs are
> from the ministry.
>
> Note that KISA is also the National Internet resources Center of Korea,
> http://krnic.kisa.or.kr/jsp/english/krnic/intro.jsp
>
> We need to take into account sections 8 through 14 of Mozilla's CA
> Certificate Inclusion Policy:
> http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>
> Section 10 says that if the subordinate CA certificate is not
> technically constrained (as described in section 9) then the subordinate
> CA must be audited according to sections 11 through 14. So, according to
> section 11 the subordinate CA operations must be audited according to
> the WebTrust CA or ETSI TS 102 042 criteria, and must also be audited
> according to the Baseline Requirements (the websites trust bit is
> requested).
>
> My questions…
>
> How would we know that the criteria that KISA uses to audit their LCAs
> is inclusive of the versions of the WebTrust or ETSI criteria that
> Mozilla's policy requires?
>
> How would we know that the criteria that KISA uses to audit their LCAs
> is inclusive of the Baseline Requirements audit criteria that Mozilla
> requires?
>
> Based on the above information, is there sufficient evidence to assert
> that the people within KISA who are performing the audits of the LCAs
> are qualified to do so, and are acting as an independent party as
> described in sections 13 and 14 of Mozilla
Re: Seeking guidance on proceeding with KISA root inclusion request
So I understand:
- KISA itself operates the South Korean governement CA
- There other CAs in Korea (LCAs), and they are private
organizations that are audited and signed by KISA.
- Those LCAs are not audited to comply with the baseline
requirements, or it's at least not clear they are.
I see no reason to accept it if they're not required to
comply with the baseline requirements.
I really suggest those LCAs should instead apply for inclusion
themself.
About the contraining to *.kr. I don't see why you want to do
that. I understand that anybody can go to a one of those LCAs
and ask for a certificate for anything, and that it doesn't have
anything to do with the governement. So I fail to see why that
certificate should be for .kr.
Kurt
On Tue, Mar 04, 2014 at 11:38:24AM -0800, Kathleen Wilson wrote:
> All,
>
> I will appreciate your input on how to proceed with the KISA root
> inclusion request.
>
> My personal preference is to proceed with the process to
> approve/include the KISA root under the condition that Mozilla would
> constrain the CA hierarchy to *.kr. However, KISA does not want to
> constrain their CA hierarchy to *.kr. I have also suggested that
> KISA have each subCA apply for inclusion as separate trust anchors,
> but KISA does not want to take that approach either.
>
> The following is my understanding of this CA.
>
> Inclusion Request Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=335197
> CA Information Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=727859
> KISA document repository:
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
> CPS (English):
> http://www.rootca.or.kr/kor/down/cps16(en).pdf
>
> Korea Information Security Agency (KISA) is the Electronic Signature
> Authorization Management Center for South Korea. The Korean
> Certification Authority Central (KCAC) of KISA issues certificates
> to intermediate CAs (licensed CAs = LCAs), which then issue
> end-entity certificates to Korean citizens, businesses, and other
> organizations. The LCAs are private organizations (not government
> organizations).
>
> The LCAs are listed in Korean at
> http://www.rootca.or.kr/kor/accredited/accredited02.jsp
> They are:
> Korea Information Certificate Authority Inc (KICA), http://www.signgate.com
> KICA CPS (Korean): http://www.signgate.com/customer/cus_cps.sg
> Korea Securities Computer Corporation (KOSCOM), http://www.signkorea.com
> KOSCOM CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479655
> Korea Electronic Certification Authority Inc (CrossCert),
> http://gca.crosscert.com
> CrossCert CPS (English):
> https://bugzilla.mozilla.org/attachment.cgi?id=479658
> KTNET ("TradeSign" or "KITA"), http://www.tradesign.net/
> TradeSign CPS (English):
> https://bugzilla.mozilla.org/attachment.cgi?id=479659
> Korea Financial Telecommunications (KFTC), http://www.yessign.or.kr
> (non-profit)
> KFTC CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479657
>
> Deloitte completed a WebTrust audit of KISA's operation of the root,
> but the subordinate CAs (LCAs) are not WebTrust audited. The LCAs
> are regulated by the Korean Electronic Signature Act, and the law
> requires that KISA does the actual examination of the LCAs and
> report their findings to the government. The evaluation (audit)
> criteria are attached to the Bugzilla bug.
> Electronic Signature Act:
> https://bugzilla.mozilla.org/attachment.cgi?id=594638
> Enforcement Decree:
> https://bugzilla.mozilla.org/attachment.cgi?id=594639
> Enforcement Regulations:
> https://bugzilla.mozilla.org/attachment.cgi?id=594640
>
> The LCAs are annually audited and are not allowed to change anything
> (system, h/w, s/w) without reporting to the government, and any
> mis-issuance of certificates would lead to penalty by the Act.
>
> The Korean government controls the policies and technical standards
> under the Electronic Signature Act. Although the actual auditing is
> done by KISA, all the results are reported to the ministry
> (currently the Ministry of Science, ICT and future Planning). KISA
> is an expert group to help the ministry for the actual examination
> and other expertise for the national PKI. KISA is an affiliated
> organization of the ministry, and is run by the government. All the
> orders to control the LCAs are from the ministry.
>
> Note that KISA is also the National Internet resources Center of
> Korea, http://krnic.kisa.or.kr/jsp/english/krnic/intro.jsp
>
> We need to take into account sections 8 through 14 of Mozilla's CA
> Certificate Inclusion Policy:
> http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>
> Section 10 says that if the subordinate CA certificate is not
> technically constrained (as described in section 9) then the
> subordinate CA must be audited according to sections 11 through 14.
> So, according to section 11 the subordinate CA operations must be
> audited according to the WebTrust CA or ETSI TS 102
