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: DigiCert Request to Include Renewed Roots
On 3/4/14, 2:51 PM, Kathleen Wilson wrote: On 1/28/14, 4:25 PM, Kathleen Wilson wrote: DigiCert has applied to include 5 new root certificates that will eventually replace the 3 DigiCert root certificates that were included in NSS via bug #364568. The request is to turn on all 3 trust bits and enable EV for all of the new root certs. 1) DigiCert Assured ID Root G2 -- This SHA-256 root will eventually replace the SHA-1 “DigiCert Assured ID Root CA” certificate. 2) DigiCert Assured ID Root G3 -- The ECC version of the Assured ID root. 3) DigiCert Global Root G2 -- This SHA-256 root will eventually replace the SHA-1 “DigiCert Global Root CA” certificate. 4) DigiCert Global Root G3 -- The ECC version of the Global root. 5) DigiCert Trusted Root G4 -- This SHA-384 root will eventually replace the SHA-1 “DigiCert High Assurance EV Root CA” certificate. DigiCert is a US-based commercial CA with headquarters in Utah. DigiCert provides digital certification and identity assurance services internationally to a variety of sectors including business, education, and government. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=908827 Thank you to those of you who have reviewed and commented on this request from DigiCert. Does anyone have any further questions about this request, or feel that there is anything left to resolve from this discussion (regarding this specific request)? If not, I will close this discussion, and recommend that this request be approved after I have confirmed receipt of DigiCert's BR audit statement. Thanks, Kathleen Thank you to those of you who reviewed and contributed to this discussion about the request from DigiCert to include 5 new root certificates that will eventually replace the 3 DigiCert root certificates that are currently included in NSS. The request is to turn on all 3 trust bits and enable EV for all of the new root certs. I believe that the concerns about this request that were raised during this discussion have been addressed. I am closing this discussion, and I will recommend approval in the bug, with actual inclusion on hold pending confirmation of the upcoming BR audit statement. https://bugzilla.mozilla.org/show_bug.cgi?id=908827 Any further follow-up on this request should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Actalis Request to Enable EV Treatment
Actalis has applied to enable EV treatment for the “Actalis Authentication Root CA” root certificate that was included in NSS via bug #520557. Actalis is a public CA offering PKI services to a wide number of customers, mainly banks and local government. Actalis is a Qualified certification service provider according to the EU Signature Directive (Directive 1999/93/EC). Actalis designs, develops, delivers and manages services and solutions for on-line security, digital signatures and document certification; develops and offers PKI-enabling components, supplies complete digital signature and strong authentication kits (including hardware and software), delivers ICT security consultancy and training. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=957548 And in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/ Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8382446 Noteworthy points: * The primary documents are the CPS for SSL and Code Signing Certs provided in both English and Italian. http://portal.actalis.it/Info/cmsContent?cmsRef=actalis/Info/Manuali CPS for SSL and Code Signing Certs (English): http://portal.actalis.it/cms/translations/en/actalis/Info/Solutions/Documents/CPS_SSLServer_CodeSigning_v2.2.5_EN.pdf * CA Hierarchy: The Actalis Authentication Root CA currently has one subordinate CA that is internally-operated. * The websites and code signing trust bits are enabled for this root. This request is to enable EV treatment. ** CPS section 1.3.3: Certificate Owners or Subscribers are organizations or agencies requesting an SSL Server certificate or Code Signing certificate and holding the corresponding private key. … Actalis issues certificates to following types of organizations: Private Organization, Government Entity … In all cases the certificate Owner shall be an organization, not a natural person. ** CPS section 3.2.2 and 3.2.3 describe authentication of organization and individual identity. ** CPS section 3.3.1: For SSL Server certificates, the CA verifies that all Internet domains and IP address to be included in the certificate are under the direct control of the applicant organization. These checks are carried out through WHOIS queries and/or reverse DNS lookups, or by querying the relevant governmental do-main registration agencies, as appropriate. Should one or more of those domains and/or IP addresses be managed by an entity other than the applicant, this latter is required to provide evidence to the CA that they have been formally delegated by the legitimate owner to manage those domains and/or IP addresses. ** CPS section 3.3.2 For EV-class certificates For private organizations, the CA also collects and evaluates the following information: - address of registered office - starting date of organization’s activity - business purpose (objects) - board members - proprietor(s) or shareholders - transfers of property or shares - powers and representatives - protests, insolvency or other negative facts For government entities, the CA also collects and evaluates the following information: - address of main office - names and roles of top managers In both cases, the CA verifies that the certificate application was authorized by a manager of the applicant with adequate powers of attorney. The CA also verifies that all the address components (country, stateOrProvince, locality, streetAddress) to be included in the certificate match the address where the registered office of the applicant organization is actually located. All the above checks are carried out by querying the relevant chamber of commerce database (for private organizations) or the appropriate governmental database (for governmental entities). * EV Policy OID: 1.3.159.1.17.1 * Test Website: https://ssltest-a.actalis.it:8443 * OCSP http://portal.actalis.it/VA/AUTH-ROOT http://ocsp03.actalis.it/VA/AUTH-G2 OCSP responses have an expiration time of 1 day * Audit: Annual audits are performed by IMQ (http://www.imq.it/) according to the ETSI TS 102 042 criteria, V2.2.1 with reference to EV Guidelines v1.3. http://portal.actalis.it/cms/translations/en/actalis/Info/Solutions/Documents/ActalisCA_Audit_Statement.pdf (2013.10.18) In the audit statement: “During the Certification Authority audit it was also verified that the above-mentioned certification services meet the requirements of the following specification: “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”, v.1.1…” * Potentially Problematic Practices – None Noted (http://wiki.mozilla.org/CA:Problematic_Practices) This begins the discussion of the request from Actalis to enable EV treatment for the “Actalis Authentication Root CA” root certificate. At the conclusion of this discussion I will provide a summary of issues noted and action items. If
Re: Question about BR audit
On 3/3/14, 10:33 AM, Kathleen Wilson wrote: All, I received the following question from an auditor, and would appreciate hearing your opinions on it. This question is in regards to a new CA inclusion request. New CAs are frequently not members of the CA/Browser Forum, so they tend to find out about the Baseline Requirements audit when they apply for inclusion. For those CA who have done the compliance with the Baseline Requirements for the first time, will your root certificate program accept a point-in-time readiness assessment audit against the WebTrust Baseline Requirements Program? For reference, our documented expectations are here: https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria Thanks, Kathleen Based on the discussion so far, it appears that folks are OK with new CAs getting a point-in-time readiness assessment audit the first time they get a Baseline Requirements audit, as long as the CA has also been getting the other audits (WebTrust CA or ETSI TS 102 042) done annually. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy Currently says: "Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 of Mozilla's CA Certificate Policy." Mozilla's CA Certificate Policy version 2.1 and later requires a BR audit, but doesn't say anything about a point-in-time readiness audit. How about if I update the wiki page as follows? "Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. Note that the CA's first Baseline Requirements audit may be a Point in Time audit." 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
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
