Closed Bug 518503 Opened 16 years ago Closed 14 years ago

Add TWCA Root Certificate

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: brian.hsiung, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: Included in FF 6.0.2)

Attachments

(13 files, 2 obsolete files)

TWCA Root CA_2048.crt
1.24 KB, application/x-x509-ca-cert
Details
Initial Information Gathering Document
19.54 KB, application/pdf
Details
TWCA Root CA Certificate with 4096 key length.
1.91 KB, application/octet-stream
Details
TWCA PKI certificate policy in English
246.41 KB, application/pdf
Details
TWCA Root CA certification practice statement in English
159.08 KB, application/pdf
Details
Response for Information Gathering Requirement
115.00 KB, application/msword
Details
CA Hierarchy Diagram
17.98 KB, application/pdf
Details
TWCA SSL certificate chain issued under 2048 bits Root CA
2.95 KB, application/octet-stream
Details
TWCA UCA CPS translation(some parts)
254.50 KB, application/msword
Details
TWCA sub-CA CPS English Version
473.26 KB, application/x-pdf
Details
Updated Information Gathering Document
120.54 KB, application/pdf
Details
Completed Information Gathering Document
127.67 KB, application/pdf
Details
Update TWCA UCA CPS, SSL and SIME information must be verified before issuance of certificate.
435.79 KB, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: CA Name: TWCA Root Certification Authority Website: www.twca.com.tw One Paragraph Summary of CA, including the following: - General nature (e.g., commercial, government, academic/research, nonprofit) commercial - Primary geographical area(s) served Taiwan - Number and type of subordinate CAs 4 subordinate CAs Audit Type (WebTrust, ETSI etc.): WebTrust Auditor: SunRise CPAs’ Firm, a member firm of DFK international. Auditor Website: http://www.dfk.com/ Audit Document URL(s): (WebTrust for CA audit report URL) https://cert.webtrust.org/ViewSeal?id=900 Certificate Details (To be completed once for each certificate) Certificate Name: TWCA Root Certification Authority Summary Paragraph, including the following: - End entity certificate issuance policy, i.e. what you plan to do with the root Issue Sub-CA certificate for our certification service. Certificate HTTP URL (on CA website): http://www.twca.com.tw/picture/file/20090114-112955156.zip Version: X.509 V3 SHA1 Fingerprint: cf 9e 87 6d d3 eb fc 42 26 97 a3 b5 a3 7a a0 76 a9 06 23 48 MD5 Fingerprint: N/A Modulus Length (a.k.a. "key length"): 2048 Valid From (YYYY-MM-DD): 2008/8/28 PM 03:24:33(GMT+8) Valid To (YYYY-MM-DD): 2030/12/31 PM 11:59:59(GMT+8) CRL HTTP URL: http://RootCA.twca.com.tw/TWCARCA/revoke_2048.crl OCSP URL: N/A Class (domain-validated, identity/organisationally-validated or EV): domain-validated, identity/organisationally-validated Certificate Policy URL: http://www.twca.com.tw/picture/file/20090403-113227911.pdf (Traditional Chinese Version Only) CPS URL: http://www.twca.com.tw/picture/file/20090114-11212952.pdf (Traditional Chinese Version Only) Requested Trust Indicators (email and/or SSL and/or code): email, SSL and Code Reproducible: Always
Accepting this bug. I will begin the information gathering and verification phase as described in https://wiki.mozilla.org/CA:How_to_apply.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: TWCA Root Certificates Inclusion. → Add TWCA Root Certificate
Attached file TWCA Root CA_2048.crt —
The attached document summarizes the information that has been gathered and verified for this request. The items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness.
Besides the 2048-key-length certificate previously provided, TWCA Root CA wants also to include its 4096-key-length certificate in Mozilla root program. Anyone can download the two certificates and related information from its Repository. The address of the two certificates in TWCA Repository is "http://www.twca.com.tw/picture/file/20090114-112955156.zip", and related information of the two certificates is in "http://www.twca.com.tw/picture/file/20090114-113117755.pdf".
Have you successfully imported the 4096-bit root into Firefox? I have successfully imported the 2048-bit root into Firefox, but I cannot import the 4096-bit root.
Is there any issue with the 4096-bit root? It's the same root with two different key-length root certificates.
(In reply to comment #6) > Is there any issue with the 4096-bit root? It's the same root with two > different key-length root certificates. Umm, yes. You used exactly the same issuer DN and serial number for both certificates - which is a relatively bad idea (see e.g. RFC 5280, section 4.1.2.2. regarding uniqueness requirements). While Microsoft's CryptoAPI apparently handles this situation (both certs are currently being distributed as part of the Windows Root Certificate Program), NSS does not... you will run into various nasty problems if you try to do so, see e.g. bug 312732 and bug 435013 for more information/discussion.
Thanks for acknowledgements. I'll discuss the issue of the 4096-bit root certificate with TWCA technical staff. BTW, since you have imported the 2048-bit root certificate into Firefox, could you provide a hint about when will the root certificate show up in end-user's installed Firefox?
We're working on the yellow labels of the initial information gathering documents.
> BTW, since you have imported the 2048-bit root certificate > into Firefox, could you provide a hint about when will the > root certificate show up in end-user's installed Firefox? I apologize for the confusion. When I said that I had imported the 2048-bit root into Firefox, I meant only into my browser for verification purposes. Please see https://wiki.mozilla.org/CA:How_to_apply for a description of the complete root inclusion process, and an approximate timeline. This request is in the Information Gathering and Verification phase.
Whiteboard: information incomplete
Add TWCA certificate policy English vertion and TWCA Root CA CPS for the information. Please download from following links: TWCA CP: http://www.twca.com.tw/picture/file/20100114-180619944.pdf TWCA RCA CPS: http://www.twca.com.tw/picture/file/20100114-180956726.pdf
Thank you for translating these documents into English. Is the purpose of the “TWCA PKI certificate policy” document to establish overall guidelines and policies for the overall hierarchy? Is the purpose of the “TWCA Root CA certification practice statement” document to establish the policies for applying, verifying, issuing, and maintaining subordinate CAs? What document describes the policies for applying, verifying, issuing, and maintaining end-entity certificates?
(In reply to comment #14) > Thank you for translating these documents into English. > > Is the purpose of the “TWCA PKI certificate policy” document to establish > overall guidelines and policies for the overall hierarchy? > > Is the purpose of the “TWCA Root CA certification practice statement” document > to establish the policies for applying, verifying, issuing, and maintaining > subordinate CAs? > > What document describes the policies for applying, verifying, issuing, and > maintaining end-entity certificates? "TWCA PKI certificate policy" is the guidelines and policies for our overall hierarchy. All sub-CAs, RAs, subscribers and relying parties have to follow this CP. “TWCA Root CA certification practice statement” is the Root CA operation guideline which also include the procedure to verify and issuing the sub-CA certificate. The sub-CA operation must follow the rule which describe in CP. The common policy for applying, verifying, issuing, and maintaining end-entity certificates was describe in CP. It described the rule to verify the identity, authentication criteria for end entity. All sub-CA must follow the CP to do identification and authentication when end entity is applying the certificate. End entity are including the individual and organization.
>Is the purpose of the “TWCA PKI certificate policy” document to establish >overall guidelines and policies for the overall hierarchy? Yes. All sub-CAs shall comply with the rules in the CP to define their CPS and shall not have conflicts with the CP in their CPS. >Is the purpose of the “TWCA Root CA certification practice statement” >document >to establish the policies for applying, verifying, issuing, and maintaining >subordinate CAs? Yes. In the section "1.3.3 Subscriber" of the CPS: "The subscriber is the individual specified in the certificate subject and the holder of the private key corresponding to the certificate public key. The subscriber of this RCA shall be the Organization applying for becoming a Sub-CA or the Sub-CA established by the TWCA." And in the section "4. Certificate Life-Cycle Operational Requirements" of the CPS, policies and procedures are defined for sub-CAs' certificates management in the hierachy. > What document describes the policies for applying, verifying, issuing, and > maintaining end-entity certificates? As mentioned above, all sub-CAs shall comply with the rules in the CP to define their own CPS and follow the rules in their own CPS for operations. So all sub-CAs operations shall not have conflicts with the rules in the CP. The CP defines policies and procedures for applying, verifying, issuing, and maintaining end-entity certificates in the section "4. Certificate Life-Cycle Operational Requirement" The above for further explanations.
How does TWCA verify that "all sub-CAs shall comply with the rules in the CP"? Is there a periodic third-party audit of the sub-CAs? Does TWCA periodically review the operations of the sub-CAs?
TWCA conduct internal audits regularly following its management system rule(at least annually) to make sure all sub-CAs operated by TWCA comply with the CP and their CPS. Besides, all sub-CAs(whether operated by TWCA or not) of TWCA root shall have third-party audits and send reports to TWCA for examination. TWCA has not signed any sub-CA yet.
Thank you for the clarification about the CP/CPS documents. Comment #8: "I'll discuss the issue of the 4096-bit root certificate with TWCA technical staff." Has TWCA reached a decision? Will this current request be only for the 2048-bit root? Comment #9: "We're working on the yellow labels of the initial information gathering documents." Any updates in regards to the other items that are highlighted in yellow in the Initial Information Gathering Document?
Required Information from TWCA. We are working on the public SSL certificate test site and it will be opened before the end of this month.
Attached file CA Hierarchy Diagram —
Thank you for the information. I have a few follow-up questions. In regards to Comment #7 and Comment #8, my current assumption is that we'll proceed with the root inclusion request for the 2048-bit root. If the issues with the 4096-bit root are resolved such that it can also be imported into Firefox, then we can either add it back into this request or you can create a new bug. > TWCA SSL certificate is issued under assurance level/class 2 Where is this documented? > The extra control of SSL certificate: > When verify the ownership of domain name, we will query the domain name > registration management organization in Taiwan to verify the domain was > legally use by subscriber. If that domain is not owned by subscriber, but > subscriber claims they have the right to use, the authorization letter from > the domain name owner must provided. Where is this documented? > TWCA has issued some S/MIME certificates for special customized application. > The control process is same as SSL certificate (assurance level 2) except > subscriber must proof the mail address is correct, or they will not able to > use the certificate to do transaction. > The general S/MIME certificate is issued under assurance level 1, subscribers > must provide the mail address in the registration form allow RA operator can > communicate with them. > If subscribers provide the wrong mail address, they have to revoke the > certificate than re-apply certificate to correct the mail address since the > certificate will not be able to use. Does the RA perform some check to verify that the email address that they are using to communicate with the subscriber is the same as the email address to be included in the certificate? Eg is there any check before issuing the certificate to truly verify ownership/control of the email address to be included in the certificate? If yes, where is this documented? > Currently, TWCA has not provide code signing certificate but plan to provide > the code signing certificate service. Once TWCA start to issue code signing > certificate, the authentication requirement shall follow the CP section 3.2.2 > and 3.2.3. My recommendation is that you don’t request the Code Signing trust bit at this time. When you update your policies to add information about Code Signing certificates, and start applying those policies, and those practices have been audited, then you may open a new bug requesting that the code signing trust bit be enabled. > TWCA issued some wildcard SSL certificates. Before TWCA issue wildcard > certificate, it must be verified the ownership of the domain. The issuance of > wildcard SSL certificate without organization verification is not allowed. Where is this documented?
(In reply to comment #22) > Thank you for the information. I have a few follow-up questions. > > In regards to Comment #7 and Comment #8, my current assumption is that we'll > proceed with the root inclusion request for the 2048-bit root. If the issues > with the 4096-bit root are resolved such that it can also be imported into > Firefox, then we can either add it back into this request or you can create a > new bug. TWCA decides to go for only 2048-bit certificate with Mozilla now. The 4096-bit certificate will be postponed after the serial number and the related issues solved internally. > > > TWCA SSL certificate is issued under assurance level/class 2 > > Where is this documented? It's documented in the section 1.2 "Certificates Level of Assurance and Applicability" in TWCA UCA CPS(page 9). You can get the CPS document published online in the url : http://www.twca.com.tw/picture/file/20090724-110350827.pdf The CPS has been sent to the local authority and got approved officially. The SSL certificate is under assurance level 2(EC certificates) > > The extra control of SSL certificate: > > When verify the ownership of domain name, we will query the domain name > > registration management organization in Taiwan to verify the domain was > > legally use by subscriber. If that domain is not owned by subscriber, but > > subscriber claims they have the right to use, the authorization letter from > > the domain name owner must provided. > > Where is this documented? It's documented in the section 2.2.1.1 "Level of Assurance" in TWCA UCA CPS(page 11). TWCA SSL certificates are class 2 certificates. > > TWCA has issued some S/MIME certificates for special customized application. > > The control process is same as SSL certificate (assurance level 2) except > > subscriber must proof the mail address is correct, or they will not able to > > use the certificate to do transaction. > > The general S/MIME certificate is issued under assurance level 1, subscribers > > must provide the mail address in the registration form allow RA operator can > > communicate with them. > > If subscribers provide the wrong mail address, they have to revoke the > > certificate than re-apply certificate to correct the mail address since the > > certificate will not be able to use. > > Does the RA perform some check to verify that the email address that they are > using to communicate with the subscriber is the same as the email address to be > included in the certificate? > Eg is there any check before issuing the certificate to truly verify > ownership/control of the email address to be included in the certificate? > If yes, where is this documented? TWCA will send a notification to the subscriber via the email address provided by the subscriber for registraqtion and the certificate will only be issued after TWCA gets an acknowledgement from the subscriber via the same email address. It's documented in the section 2.2.1.1 "Level of Assurance" in TWCA UCA CPS(page 11). > > Currently, TWCA has not provide code signing certificate but plan to provide > > the code signing certificate service. Once TWCA start to issue code signing > > certificate, the authentication requirement shall follow the CP section 3.2.2 > > and 3.2.3. > > My recommendation is that you don’t request the Code Signing trust bit at this > time. When you update your policies to add information about Code Signing > certificates, and start applying those policies, and those practices have been > audited, then you may open a new bug requesting that the code signing trust bit > be enabled. Thanks for your suggestion. TWCA will enable the trust bit only after commensurate policies and procedures followed. > > TWCA issued some wildcard SSL certificates. Before TWCA issue wildcard > > certificate, it must be verified the ownership of the domain. The issuance of > > wildcard SSL certificate without organization verification is not allowed. > > Where is this documented? It's documented in the section 2.2.1.1 "Level of Assurance" in TWCA UCA CPS(page 11). TWCA will check with domain name management org such as TWNIC or similar foreign agengy for confirmation.
I am trying to find the correlation between the documents provided in this bug and the documents posted in the repository of the TWCA website: http://www.twca.com.tw/Portal/save/save.html … TWCA PKI CP (Traditional Chinese): http://www.twca.com.tw/picture/file/20090403-113227911.pdf -- is http://www.twca.com.tw/picture/file/20090806-171745500.pdf an updated version of this 2090403-11327911 document? TWCA PKI CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=422485 -- is this the same as http://www.twca.com.tw/picture/file/20100114-180619944.pdf ? TWCA Root CA CPS (Traditional Chinese): http://www.twca.com.tw/picture/file/20090114-11212952.pdf TWCA Root CA CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=422486 -- is this the same as http://www.twca.com.tw/picture/file/20100114-180956726.pdf ? TWCA UCS CPS (Traditional Chinese): http://www.twca.com.tw/picture/file/20090724-110350827.pdf -- is there an English translation of this document? If not, please provide one. Please explain the relationship of the TWCA UCS CPS document to the TWCA PKI CP and TWCA Root CA CPS documents.
(In reply to comment #24) > I am trying to find the correlation between the documents provided in this bug > and the documents posted in the repository of the TWCA website: > http://www.twca.com.tw/Portal/save/save.html … > > TWCA PKI CP (Traditional Chinese): > http://www.twca.com.tw/picture/file/20090403-113227911.pdf > -- is http://www.twca.com.tw/picture/file/20090806-171745500.pdf an updated > version of this 2090403-11327911 document? Yes, it is the updated version of our CP. The version update from 1.4 to 1.5. > TWCA PKI CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=422485 > -- is this the same as > http://www.twca.com.tw/picture/file/20100114-180619944.pdf ? > CP English version is map to Chinese CP version 1.5. > TWCA Root CA CPS (Traditional Chinese): > http://www.twca.com.tw/picture/file/20090114-11212952.pdf > > TWCA Root CA CPS (English): > https://bugzilla.mozilla.org/attachment.cgi?id=422486 > -- is this the same as > http://www.twca.com.tw/picture/file/20100114-180956726.pdf ? Yes, it is. > TWCA UCS CPS (Traditional Chinese): > http://www.twca.com.tw/picture/file/20090724-110350827.pdf > -- is there an English translation of this document? If not, please provide > one. > > Please explain the relationship of the TWCA UCS CPS document to the TWCA PKI CP > and TWCA Root CA CPS documents. TWCA UCA CPS must follow the policy specified in TWCA PKI CP. The reference is the CP OID. When issue the certificate, Sub-CAs described in TWCA UCA CPS must include the CP OID specified in TWCA PKI CP in the certificate. For example, the Sub-CA will issue the test class of certificate whose CP OID will include the CP OID described in TWCA PKI CP page 11 to 12.
Our SSL test site: https://ssldemo.twca.com.tw/index.html SSL site for browser test. The certificate of this site is issued under 2048 root CA. Some images may not show since it has some break hyper-link. For SSL test only.
For certificate chain test.
Additional information about TWCA Root CA: TWCA root only sign sub-CA only.
(In reply to comment #24) > TWCA UCS CPS (Traditional Chinese): > http://www.twca.com.tw/picture/file/20090724-110350827.pdf > -- is there an English translation of this document? If not, please provide > one. No, we don't have the English version of the UCA CPS. Is it a must to have the whole UCA CPS document translated into English? Since we're applying for the Root of TWCA, is it possible to have partials of the UCA CPS and the related internal operation SOP documents you need translated into English? We have offered the English version of the Root CPS.
Thanks for the clarification about the documents. >> Test website Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. That is required by SSL/TLS. Certificate authorities must advise their subscribers that all intermediate certificates should instead be installed in the servers containing the dependent subscriber certificates. Please respond in this bug when the test website has been updated. >> Translations of TWCA UCA CPS I don't need the entire document translated, just certain sections. Please translate the sections about verification of certificate subscriber identity, ownership/control of the domain name, ownership/control of the email address, and verification of any other information to be contained in the certificate. Also, any sections related to the potentially problematic practices. I also noticed the mention of cross-signing, so I will need to understand if there is any cross-signing with other roots -- perhaps a translation of the CA hierarchy diagram and description would be useful. >> Answers in Comment #23 In regards to verification of certificate subscriber identity, ownership/control of the domain name, and ownership/control of the email address... It needs to be confirmed that sufficient process is in place and required for all end-entity certs that do or will chain up to the root. If the answers only apply to one of the sub-CAs, then that won't be sufficient unless that sub-CA is the only one that can issue SSL and S/MIME certs.
(In reply to comment #30) > Thanks for the clarification about the documents. > > >> Test website > > Intermediate CA certificates are expected to be distributed to the certificate > subjects (the holders of the private keys) together with the subjects' own > certificates. Those subject parties (e.g. SSL servers) are then expected to > send out the intermediate CA certificates together with their own certificates > whenever they are asked to send out their certificates. That is required by > SSL/TLS. > > Certificate authorities must advise their subscribers that all intermediate > certificates should instead be installed in the servers containing the > dependent subscriber certificates. > > Please respond in this bug when the test website has been updated. The test web site has been fixed. Our engineer did not put the sub-CA certificate in the Web Server, so the intermediate CA certificate did not send to firefox while doing SSL hand-shaking.
> The test web site has been fixed. Thanks!
(In reply to comment #30) > Thanks for the clarification about the documents. > > >> Test website > > Intermediate CA certificates are expected to be distributed to the certificate > subjects (the holders of the private keys) together with the subjects' own > certificates. Those subject parties (e.g. SSL servers) are then expected to > send out the intermediate CA certificates together with their own certificates > whenever they are asked to send out their certificates. That is required by > SSL/TLS. > > Certificate authorities must advise their subscribers that all intermediate > certificates should instead be installed in the servers containing the > dependent subscriber certificates. > > Please respond in this bug when the test website has been updated. > > >> Translations of TWCA UCA CPS > > I don't need the entire document translated, just certain sections. Please > translate the sections about verification of certificate subscriber identity, > ownership/control of the domain name, ownership/control of the email address, > and verification of any other information to be contained in the certificate. > Also, any sections related to the potentially problematic practices. I also > noticed the mention of cross-signing, so I will need to understand if there is > any cross-signing with other roots -- perhaps a translation of the CA hierarchy > diagram and description would be useful. > > >> Answers in Comment #23 > > In regards to verification of certificate subscriber identity, > ownership/control of the domain name, and ownership/control of the email > address... It needs to be confirmed that sufficient process is in place and > required for all end-entity certs that do or will chain up to the root. If the > answers only apply to one of the sub-CAs, then that won't be sufficient unless > that sub-CA is the only one that can issue SSL and S/MIME certs. Add new attachment for CPS translation and some information about CA and sub-CA. Please notify me if you need other informations.
Thank you for the information. In regards to the domain control and email control verification procedures that you provided from your internal SOP documents, could you add that information into your TWCA UCS CPS? We need the information that satisfies section 7 of the Mozilla CA Certificate Policy to be in a public and audited document. I’m not sure I understand the diagrams in the attachment correctly, so I’ll write my interpretation here. Please let me know if this is correct: The “TaiCA Information Policy CA” and the “TaiCA Finance CA” subCAs are cross-signed by a TWCA Policy CA that is currently in operation and this new “TWCA Root Certification Authority” root certificate. The “TaiCA Secure CA” subCAs for SSL and S/MIME are cross-signed by a TWCA UCA that is currently in operation and this new “TWCA Root Certification Authority” root certificate.
(In reply to comment #35) > Thank you for the information. > > In regards to the domain control and email control verification procedures that > you provided from your internal SOP documents, could you add that information > into your TWCA UCS CPS? We need the information that satisfies section 7 of the > Mozilla CA Certificate Policy to be in a public and audited document. > > I’m not sure I understand the diagrams in the attachment correctly, so I’ll > write my interpretation here. Please let me know if this is correct: > The “TaiCA Information Policy CA” and the “TaiCA Finance CA” subCAs are > cross-signed by a TWCA Policy CA that is currently in operation and this new > “TWCA Root Certification Authority” root certificate. > The “TaiCA Secure CA” subCAs for SSL and S/MIME are cross-signed by a TWCA UCA > that is currently in operation and this new “TWCA Root Certification Authority” > root certificate. Sorry for the late response. The external audit covers the organization authentication procedure state in UCA CPS section 2.2.1.1, the URL and mailbox must be verified. When auditing, the domain name and mailbox identity control will be include. About the diagram, it means “TaiCA Secure CA” will be separate to 2 sub-CAs, one is for S/MIME and another is for SSL, because of the CRL download performance issue. The 2 sub-CAs were certified by “TWCA Root Certification Authority”, not cross-signed by other UCA. The arrow symbol in the diagram means that we will change the CA hierarchy, not the cross-signed activity.
This request has been added to the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion Now that you have a request in the Queue for Public Discussion, you are directly impacted by the time it takes to work through the queue. The goal is to have each discussion take about one week. However, that time varies dramatically depending on the number of reviewers contributing to the discussion, and the types of concerns that are raised. If no one reviews and contributes to a discussion, then a request may sit in the discussion for weeks. When there are not enough people contributing to the discussions ahead of yours, then your request will sit in the queue longer. How can you help reduce the time that your request sits in the queue? You can help by reviewing and providing your feedback in the public discussions of root inclusion requests, or by asking a knowledgeable colleague to do so. Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: information incomplete → Information confirmed complete
The WebTrust seal / audit report has been renew. Please visit https://cert.webtrust.org/ViewSeal?id=900 to view the new Audit Report. The next audit will be scheduled in the next year.
This request is nearing the top of the queue for discussion. As such, I am re-reviewing the information. My notes refer to a document called "TWCA UCA CPS" TWCA UCA CPS (Chinese): http://www.twca.com.tw/picture/file/20090724-110350827.pdf Parts of TWCA UCA CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=437191 My notes indicate that there are specific CPS documents for each sub-CA. My notes also indicate that the “TWCA Root Certification Authority” root certificate has signed the following 4 sub-CAs: 1) CN=TaiCA Secure CA, OU=SSL Certification Service Provider -- This sub-CA signs SSL certificates. The liability and applicable limitation depends on the assurance level. 2) CN=TaiCA Secure CA, OU=Certification Service Provider – This sub-CA signs certificates for the identity for on-line commerce transactions, such as the stock trading, or email security, depending on the assurance level. 3) CN=TaiCA Information Policy CA, OU = Policy CA – This sub-CA signs the following sub-CA: CN=TaiCA Information User CA, OU = User CA – This sub-CA signs certificates for identity for on-line taxation, e-Government or e-Commerce transactions. The liability and applicable limitation depends on the assurance level. 4) CN=TaiCA Finance CA, OU = Policy CA – This sub-CA signs the following sub-CA: *** CN=TaiCA Finance User CA, OU = User CA – This sub-CA signs certificates for identity for on-line fund transfer, e-Finance or e-Banking transactions. The liability and applicable limitation depends on the assurance level. Which of these 4 sub-CAs must follow the policies documented in the "TWCA UCA CPS" document?
Add TWCA UCA(sub-CA) CPS English version for root certificate inclusion discussion.
TWCA UCA(sub-CA) CPS English version also can be download from following link: http://www.twca.com.tw/picture/file/20110216-181032496.pdf
By now, TWCA root has signed only one sub-CA of the four you mentioned. Only the second sub-CA(the EC+) on your list has got signed last year. The others are supposed to be signed in the future.
However, the four CAs on your list must follow TWCA UCA CPS mentioned above to conduct their operations, and these four CAs accept independent 3rd-party audit against the TWCA UCA CPS annually.
Please review the attached document to make sure that all of the information in it is current and correct. Please post corrections in this bug. Also note that there are about 5 items highlighted in yellow, where I have questions, and post your response/clarification in this bug.
Robin, please respond to Comment #45.
(In reply to comment #45) > Created attachment 513536 [details] > Updated Information Gathering Document > > Please review the attached document to make sure that all of the information in > it is current and correct. Please post corrections in this bug. Also note that > there are about 5 items highlighted in yellow, where I have questions, and post > your response/clarification in this bug. Hi Kathleen, About your question, our response as fallow: 1. I'm confused about the differences in Class levels between the CP and the TWCA UCA CPS documents. Is the information below all correct? Do you think that the descriptions from the different documents are in sync? Ans: Yes. TWCA UCA do not issue class level 4 assurance level EE certificate. 2. The information that appears to be in the internal SOP documents is really what we need to see in public documentation in regards to verification of ownership/control of the domain name to be included in the certificate. Please see sections 6, 7, 8, and 14 of http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Ans: We will mosdify TWCA UCA CPS to include the information verification requirement and publish to our Web site. 3. is same as 2. 4. Not applicable. When I read the TWCA UCA CPS it appears that this is accounted for. Are UCA's and RA's always going to be TWCA employees? Or will TWCA eventually use third parties to do the verification of subscriber information? Ans: Yes, for SSL and SMIME certificate, TWCA's employee is responsible for subscriber information verification. 5. Not applicable. When I read the TWCA UCA CPS I get the impression that this will be allowed in the future even though it is not currently in practice Correct? Ans: Currently, TWCA do not issue sub-CA certificate to 3rd party because of no business value and the risk must be under control. If we have to issue sub-CA certificate to other 3rd party, we will follow TWCA Root CA CPS to do the following control: 1. 3rd party information verification including organization and representative person information. 2. Certificate life cycle management. 3. sub-CA must follow TWCA PKI CP to do the CA practice audit including the CP, sub-CA CPS and sub-CA compliance with CP.
Hi Kathleen, We will keep you posted once the modified UCA CPS available online soon(expected in a week).Any other issues, please let us know. Regards, Brian
I understand your answers in Comment #47, and I will review the corresponding sections of the updated UCA CPS when it is made available. I have no other questions at this time.
The domain name verification method is described in TWCA UCA CPS 5.1, section (2)SSL server certificate. The email verification method is described in TWCA UCA CPS 5.1, section C. Application for CXML certificates. The CPS is also available on TWCA website, the download URL is: http://www.twca.com.tw/picture/file/20110315-113121435.pdf
This request is next in the queue for public discussion. https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion I will post a comment in this bug when I start the discussion.
Attachment #444490 - Attachment is obsolete: true
Robin, Please view the document links on the pending page at http://www.mozilla.org/projects/security/certs/pending/#TWCA and let me know which of the links need to be updated.
Thanks Kathleen, we're re-checking the links. And, the SSL UCA is preparing for the audit against the WTCA EV criteria. It's expected to be accomplished before the 3rd quarter of this year. It's not an issue directly related with the root, but we still would like to let you know.
(In reply to comment #52) > Robin, Please view the document links on the pending page at > http://www.mozilla.org/projects/security/certs/pending/#TWCA > and let me know which of the links need to be updated. Hi Kathleen, I have checked the links again. The documents links to our web site are correct.
Thanks for checking. I hope to start this discussion soon, and I will post a comment in this bug when that happens.
I am now opening the first public discussion period for this request from Taiwan Certification Authority (TWCA) to add the “TWCA Root Certification Authority” root certificate and enable the Websites and Email trust bits. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list. http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy The discussion thread is called “TWCA Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of TWCA must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
I will probably have to re-start this discussion because it got buried in the flurry of activity in the m.d.s.policy forum. The original discussion is here: http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/5714c0dbd203059b# In the meantime, one person did review and comment on the request here: http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/1d7b66386a8d203b# Please respond in the discussion to their question.
The updated UCA CPS described "All assurance levels of SSL server certificates shall use following procedure to verify subscriber’s information." and "All assurance levels of CXML certificates shall use following procedure to verify subscriber’s information." This means there is no non-verified domain name and email will be put in the certificate contents.
Attachment #519822 - Attachment is obsolete: true
This request has been evaluated as per the Mozilla CA Certificate Policy at http://www.mozilla.org/projects/security/certs/policy/ Here follows a summary of the assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for the request from TWCA to add the “TWCA Root Certification Authority” root certificate and enable the Websites and Email trust bits. Section 4 [Technical]. I am not aware of any technical issues with certificates issued by TWCA, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. Section 6 [Relevancy and Policy]. TWCA appears to provide a service relevant to Mozilla users: It is a commercial CA that provides a consolidated on-line financial security certificate service and a sound financial security environment, to ensure the security of on-line finance and electronic commercial trade in Taiwan. TWCA is a joint-venture company formed by Taiwan Stock Exchange Corporation (TWSE), Taiwan Depository and Clearing Corporation (TDCC) Financial Information Service Corporation (FISC), and HiTrust Inc (HiTrust). Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CP and CPS, which are provided in English. TWCA UCA CPS English: http://www.twca.com.tw/picture/file/20110523-180517756.pdf Chinese: http://www.twca.com.tw/picture/file/20110610-162851208.pdf The User Certification Authority (UCA) issues, manages and delivers the RA and subscriber certificates according to the TWCA UCA CPS. TWCA PKI CP English: http://www.twca.com.tw/picture/file/20100910-115805367.pdf Chinese: http://www.twca.com.tw/picture/file/20090806-171745500.pdf All sub-CAs shall comply with the rules in the TWCA PKI CP to define their own CPS and follow the rules in their own CPS for operations. TWCA Root CA CPS English: http://www.twca.com.tw/picture/file/20100114-180956726.pdf Chinese: http://www.twca.com.tw/picture/file/20090114-11212952.pdf This document establishes the policies for applying, verifying, issuing, and maintaining subordinate CAs. Section 7 [Validation]. TWCA appears to meet the minimum requirements for subscriber verification, as follows: * SSL: SSL certificates are issued under assurance level class 2 or 3. TWCA verifies the legal existence of the organization requesting the certificate, the identity and authorization of the certificate subscriber, and that the certificate subscriber has the exclusive right to use the domain name(s) to be listed in the certificate. This is documented in sections 2.2.1.1, 3.2.2, and 5.1 of the TWCA UCA CPS. * Email: S/MIME certificates are issued under assurance level class 1, 2, or 3. TWCA verifies the identity and PIN of the subscriber, verifies the domain name ownership of the email address to be listed in the certificate, and exchanges email with the subscriber to confirm the application request. This is documented in sections 2.2.1.1, 3.2, and 5.1 of the TWCA UCA CPS. * Code: Not Applicable. TWCA is not requesting the Code Signing trust bit at this time. * EV Policy OID: TWCA is not requesting EV treatment at this time. Section 15 [Certificate Hierarchy]. * The “TWCA Root Certification Authority” root certificate has 4 internally-operated subordinate CAs. Only level 1 or level 2 sub-CAs may sign end-entity certificates. All of the sub-CAs must follow the TWCA UCA CPS to conduct their operations, and these sub-CAs accept independent 3rd-party audit against the TWCA UCA CPS annually. Other: * CRL: http://RootCA.twca.com.tw/TWCARCA/revoke_2048.crl ** TWCA Root CA CPS section 2.1.5: The publication of the CRL is scheduled, at least once in every week. The TWCA CA will immediately update and publish CRL after Suspension/Revocation of DSCs * OCSP: Not provided. Section 8-10 [Audit]. * An annual audit is performed by SunRise CPAs’ Firm (a member firm of DFK International http://www.dfk.com) according to the WebTrust CA criteria. The audit report is posted on the cert.webtrust.org website: https://cert.webtrust.org/ViewSeal?id=900 Based on this assessment I intend to approve this request from TWCA to add the “TWCA Root Certification Authority” root certificate and enable the Websites and Email trust bits.
Whiteboard: In public discussion → Pending Approval
To the representatives of TWCA: Thank you for your cooperation and your patience. To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request. As per the summary in Comment #59, and on behalf of Mozilla I approve this request from TWCA to include the following root certificate in Mozilla: ** TWCA Root Certification Authority (websites, email) I will file the NSS bug to effect the approved changes.
Whiteboard: Pending Approval → Approved - awaiting NSS
Depends on: 666681
I have filed bug #666681 against NSS for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → Included in FF 6.0.2
In response to https://wiki.mozilla.org/CA:Communications#May_13.2C_2014 5) A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy. http://www.twca.com.tw/Portal/english/coporate_profile/Repository.html EVSSL CA CPS Chinese Version https://www.twca.com.tw/picture/file/12171427-%E5%84%B2%E5%AD%98%E5%BA%AB%E8%87%BA%E7%81%A3%E7%B6%B2%E8%B7%AF%E8%AA%8D%E8%AD%89%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8EV%20SSL%E6%86%91%E8%AD%89%E7%AE%A1%E7%90%86%E4%B8%AD%E5%BF%83%E6%86%91%E8%AD%89%E5%AF%A6%E5%8B%99%E4%BD%9C%E6%A5%AD%E5%9F%BA%E6%BA%96.pdf EVSSL CA CPS English Version https://www.twca.com.tw/picture/file/12261742-TWCA-EVSSL-CPS-EN.pdf Global CA CPS Chinese Version https://www.twca.com.tw/picture/file/01301201-TWCA-GLOBAL-CPS.pdf Global CA CPS English Version https://www.twca.com.tw/picture/file/01301630-TWCA-GLOBAL-CPS-EN.pdf EVSSL CA certificate in ZIP format https://www.twca.com.tw/Portal/save/EVSSLUCA.zip Global CA certificate in ZIP format https://www.twca.com.tw/picture/file/10121131-%E5%84%B2%E5%AD%98%E5%BA%AB%E8%B3%87%E5%AE%89%E7%94%A8%E6%88%B6%E6%86%91%E8%AD%89%E7%AE%A1%E7%90%86%E4%B8%AD%E5%BF%83%E6%86%91%E8%AD%89%E8%B3%87%E8%A8%8A.zip We are plan to issue new sub-CA certificate with SHA2 algorithm. We will send the update information to Mozilla when new certificate have been signed.
WebTrust Audit Renew: EV https://cert.webtrust.org/ViewSeal?id=1694 WTCA(including sub-CA's audit report) https://cert.webtrust.org/ViewSeal?id=1695
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: