Seeking guidance on proceeding with KISA root inclusion request

[Kathleen Wilson]

All,

I will appreciate your input on how to proceed with the KISA root
inclusion request.

My personal preference is to proceed with the process to approve/include
the KISA root under the condition that Mozilla would constrain the CA
hierarchy to *.kr. However, KISA does not want to constrain their CA
hierarchy to *.kr. I have also suggested that KISA have each subCA apply
for inclusion as separate trust anchors, but KISA does not want to take
that approach either.

The following is my understanding of this CA.

Inclusion Request Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=335197
CA Information Document:
https://bugzilla.mozilla.org/attachment.cgi?id=727859
KISA document repository:
http://www.rootca.or.kr/kor/accredited/accredited02.jsp
CPS (English):
http://www.rootca.or.kr/kor/down/cps16(en).pdf

Korea Information Security Agency (KISA) is the Electronic Signature
Authorization Management Center for South Korea. The Korean
Certification Authority Central (KCAC) of KISA issues certificates to
intermediate CAs (licensed CAs = LCAs), which then issue end-entity
certificates to Korean citizens, businesses, and other organizations.
The LCAs are private organizations (not government organizations).

The LCAs are listed in Korean at
http://www.rootca.or.kr/kor/accredited/accredited02.jsp
They are:
Korea Information Certificate Authority Inc (KICA), http://www.signgate.com
KICA CPS (Korean): http://www.signgate.com/customer/cus_cps.sg
Korea Securities Computer Corporation (KOSCOM), http://www.signkorea.com
KOSCOM CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479655
Korea Electronic Certification Authority Inc (CrossCert),
http://gca.crosscert.com
CrossCert CPS (English):
https://bugzilla.mozilla.org/attachment.cgi?id=479658
KTNET ("TradeSign" or "KITA"), http://www.tradesign.net/
TradeSign CPS (English):
https://bugzilla.mozilla.org/attachment.cgi?id=479659
Korea Financial Telecommunications (KFTC), http://www.yessign.or.kr
(non-profit)
KFTC CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=479657

Deloitte completed a WebTrust audit of KISA’s operation of the root, but
the subordinate CAs (LCAs) are not WebTrust audited. The LCAs are
regulated by the Korean Electronic Signature Act, and the law requires
that KISA does the actual examination of the LCAs and report their
findings to the government. The evaluation (audit) criteria are attached
to the Bugzilla bug.
Electronic Signature Act:
https://bugzilla.mozilla.org/attachment.cgi?id=594638
Enforcement Decree:
https://bugzilla.mozilla.org/attachment.cgi?id=594639
Enforcement Regulations:
https://bugzilla.mozilla.org/attachment.cgi?id=594640

The LCAs are annually audited and are not allowed to change anything
(system, h/w, s/w) without reporting to the government, and any
mis-issuance of certificates would lead to penalty by the Act.

The Korean government controls the policies and technical standards
under the Electronic Signature Act. Although the actual auditing is done
by KISA, all the results are reported to the ministry (currently the
Ministry of Science, ICT and future Planning). KISA is an expert group
to help the ministry for the actual examination and other expertise for
the national PKI. KISA is an affiliated organization of the ministry,
and is run by the government. All the orders to control the LCAs are
from the ministry.

Note that KISA is also the National Internet resources Center of Korea,
http://krnic.kisa.or.kr/jsp/english/krnic/intro.jsp

We need to take into account sections 8 through 14 of Mozilla's CA
Certificate Inclusion Policy:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Section 10 says that if the subordinate CA certificate is not
technically constrained (as described in section 9) then the subordinate
CA must be audited according to sections 11 through 14. So, according to
section 11 the subordinate CA operations must be audited according to
the WebTrust CA or ETSI TS 102 042 criteria, and must also be audited
according to the Baseline Requirements (the websites trust bit is
requested).

My questions…

How would we know that the criteria that KISA uses to audit their LCAs
is inclusive of the versions of the WebTrust or ETSI criteria that
Mozilla's policy requires?

How would we know that the criteria that KISA uses to audit their LCAs
is inclusive of the Baseline Requirements audit criteria that Mozilla
requires?

Based on the above information, is there sufficient evidence to assert
that the people within KISA who are performing the audits of the LCAs
are qualified to do so, and are acting as an independent party as
described in sections 13 and 14 of Mozilla’s CA Certificate Inclusion
Policy?

If KISA's root was to be included, should Mozilla products constrain the
KISA hierarchy to *.kr? Why? Why not?

I will greatly appreciate your thoughtful input into how to proceed with
this CA’s root inclusion request.

Kathleen

[Kurt Roeckx]

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

> My questions...

>
> How would we know that the criteria that KISA uses to audit their
> LCAs is inclusive of the versions of the WebTrust or ETSI criteria
> that Mozilla's policy requires?
>
> How would we know that the criteria that KISA uses to audit their
> LCAs is inclusive of the Baseline Requirements audit criteria that
> Mozilla requires?
>
> Based on the above information, is there sufficient evidence to
> assert that the people within KISA who are performing the audits of
> the LCAs are qualified to do so, and are acting as an independent
> party as described in sections 13 and 14 of Mozilla's CA Certificate
> Inclusion Policy?
>
> If KISA's root was to be included, should Mozilla products constrain
> the KISA hierarchy to *.kr? Why? Why not?
>
> I will greatly appreciate your thoughtful input into how to proceed
> with this CA's root inclusion request.
>
> Kathleen
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[David E. Ross]

Minuimally, KISA should publish (make public) the audit criteria KISA
uses when auditing the subordinate CAs. This should be done prior to
concluding the review of KISA for inclusion in the NSS database. The
review of KISA should then include a review of those criteria.

Furthermore, it should become a standing requirement on KISA that, when
KISA itself is audited, there must be a review by its auditors on how
thorough KISA audits those subordinate CAs and whether KISA indeed
applies all the published criteria.

--

David E. Ross
<http://www.rossde.com/>

On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.

[Eddy Nigg]

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: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[mou...@paygate.net]

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 님의 말:

[Kathleen Wilson]

On 3/4/14, 4:00 PM, mou...@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

[Kurt Roeckx]

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

[spar...@gmail.com]

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 님의 말:

[Kurt Roeckx]

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

[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.
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.

[spar...@gmail.com]

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.

[Eddy Nigg]

On 03/07/2014 07:10 AM, From spar...@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.

[spar...@gmail.com]

2014년 3월 11일 화요일 오전 8시 6분 55초 UTC+9, Eddy Nigg 님의 말:

> On 03/07/2014 07:10 AM, From spar...@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.

[박순태 선임연구원]

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 <abil...@mozilla.com>:

> On 3/10/14, 6:58 PM, spar...@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

[Kurt Roeckx]

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 <abil...@mozilla.com>:
>
> > On 3/10/14, 6:58 PM, spar...@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

[keecha...@gmail.com]

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.

[Kathleen Wilson]

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

[Man Ho (Certizen)]

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
>
>
>
>

[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

[Kathleen Wilson]

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

[spar...@gmail.com]

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 님의 말: