TWCA Root Inclusion Request
Kathleen Wilson
certificate and enable the Websites and Email trust bits.
Taiwan Certification Authority (TWCA) 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).
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=518503
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#TWCA
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=520022
Noteworthy points:
* The CP and CPS documents are provided in English.
TWCA UCA CPS: http://www.twca.com.tw/picture/file/20110315-113121435.pdf
The User Certification Authority (UCA) issues, manages and delivers the
RA and subscriber certificates according to the TWCA UCA CPS.
TWCA PKI CP: http://www.twca.com.tw/picture/file/20100910-115805367.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:
http://www.twca.com.tw/picture/file/20100114-180956726.pdf
This document establishes the policies for applying, verifying, issuing,
and maintaining subordinate CAs.
* The “TWCA Root Certification Authority” root certificate has 4
internally-operated subordinate CAs. The root does not sign end-entity
certificates directly. Only level 1 or level 2 sub-CAs may sign
end-entity certificates. The sub-CAs are as follows:
** 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.
** CN=TaiCA Secure CA, OU=Certification Service Provider – This sub-CA
signs certificates for identity for use in on-line commerce
transactions, such as stock trading, or email security, depending on the
assurance level.
** 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 use in on-line taxation, e-Government or
e-Commerce transactions. The liability and applicable limitation depends
on the assurance level.
** 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 use in on-line fund transfer, e-Finance or
e-Banking transactions. The liability and applicable limitation depends
on the assurance level.
* All of these 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.
* The request is to enable the Websites and Email trust bits.
* Comment #47: for SSL and SMIME certificate, TWCA's employee is
responsible for subscriber information verification.
* TWCA UCA CPS section 2.2.1.1: Level of Assurance:
** Testing Certificates: intended for testing purpose and neither the
UCA nor the RA will run any identity authentication. Therefore, they
cannot be used in any applications or businesses.
** Class 1: The user certification authority (UCA) or RA only conducts
limited verification of the user account (ID, such as personal name,
registered company name or universal resource location (URL)) and e-mail
account through simple procedures. The UCA and RA only assure the
uniqueness of the user account and e-mail account in the database, and
all other information related to the user is considered as unverified.
** Class 2: Apart from checking the personal name, registered company
name or URL, and the general relevant information, subscribers shall
provide legal and correct identity documents (e.g. the photocopy of the
citizen identity card or the profit business registration of company)
during the registration which can be applied for by an agent. The UCA or
RA will verify the identity of the applicant either by phone or through
other means (e.g. a third-party database).
** Class 3: Apart from checking the information specified in Class 2,
the subscriber shall personally apply for the registration. A legal
person or corporate subscriber shall apply for registration through an
agent holding valid authorization documents and documents that can
identify his/her identity (e.g. citizen identity card or passport with a
photo of the agent).
* TWCA PKI CP section 3.2.2: When authenticating the status of
organizations, the organization shall submit documents issued by the
competent authorities or other certifications proving its existence. The
identity and authorization of its statutory representative shall be
verified. If the application is made by the authorized agent of an
organization, this agent shall also submit his/her identify
certifications. All documents and/or certifications shall be submitted
in writing or carried to the count by the agent in person. … CAs shall
verify registration data with methods corresponding to the assurance
level of certificates being applied for. The verification methods shall
include, but not limited to, the methods specified in this part for
authenticating the identity or the digital signature of subscribers
(signature certificates shall be issued according to this CP).
* TWCA UCA CPS section 5.1.B.2: SSL server certificates
1. Subscribers shall prepare the “photocopy of the profit business
registration”; “domain name authorization”; “ SSL Server Digital
Certificate Application Form”; and the check or draft of the service
fees; and send them to the RA to apply for the SSL server certificate.
2. After entering the SSL server certificate application website via the
Internet, subscribers shall generate the subscriber certificate
application file according to the regulations for SSL server certificate
application and registration. Then, subscribers shall complete the
information of the technical contact person, business contact person and
accounting contact person based on the information completed in the “SSL
Server Digital Certificate Application Form” and the password to
complete the certificate application.
3. If the domain name is registered in Taiwan (*.com.tw), RA must query
the TWNIC WHOIS database to verify the ownership of domain name which
filled in the certificate application form. If the domain name is not
registered in Taiwan, RA must use the global WHOIS service (Network
Solutions or others) to verify the ownership of the domain name.
4. After checking the subscriber’s application documents and certificate
application message, operators shall issue the subscriber certificate if
there is no error and deliver a notice to the subscriber to download the
certificate from the TWCA website by e-mail.
* TWCA UCA CPS section 5.1.C: Application for CXML certificates
1. After completing at least the identity verification and PIN
verification procedures, subscribers may register to the RA and sign the
certificate application message generated with their private key before
delivering the message to the RA.
2. After verifying the subscriber identity identification code and PIN
and the integrity of subscriber certificate application message, the RA
shall sign the subscriber certificate application message with the RA
private key if there is no error. After encrypting the message with the
server, the RA shall deliver the subscriber certificate application
message to the UCA.
3. If certificate applicant applies the S/MIME certificate, RA must
verify the applicant’s email address. When verify the email address of
S/MIME certificate, RA must verify the domain name ownership of mail
address which is filled in certificate application form. After verify
the ownership of domain name, RA operator will manually send email to
applicant’s mailbox to notify the certificate applying procedure is
under process, and ask subscriber to reply to verify that the email
address is correct and subscriber did do the certificate application. If
certificate applicant replies using the same mail address and confirms
the certificate application request, the verification of email address
will be success, otherwise it will be fail.
4. After checking the subscriber certificate application message
delivered from the RA, the legitimacy of the RA and subscriber identity,
and the integrity of message, the UCA shall issue the certificate and
deliver it to the RA if there is no error.
5. After checking the legitimacy and integrity of the subscriber
certificate reply message from the UCA, the RA shall deliver the
certificate to the applicant if there is no error.
* EV Policy OID: Not requesting EV treatment at this time.
* Test Website: https://ssldemo.twca.com.tw/index.html
* Root Cert: https://bugzilla.mozilla.org/attachment.cgi?id=402647
* 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.
* 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 (2010.03.13)
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* Wildcard DV SSL certificates
** SSL certs are OV
** From TWCA: 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.
* Allowing external entities to operate unconstrained subordinate CAs
** The TWCA UCA CPS includes provisions for externally operated sub-CAs
if needed in the future. However, TWCA has not accepted any 3rd party
as a sub-CA and currently does not plan to do this type of business.
** Comment #47: 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:
*** 3rd party information verification including organization and
representative person information.
*** Certificate life cycle management.
*** 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.
* Certificates referencing hostnames or private IP addresses
** From TWCA: The SSL certificate issued by TWCA must use DNS name as
the CN part of subjectDN, the IP address is not allowed. In some
application servers, they use subjectAlterName to identify themselves,
such as Microsoft Exchange Server 2007. TWCA will issue the SSL
certificate with subjectAlterName contains the NETBIOS hostname or IP
address for such applications.
This begins the discussion of the request from TWCA to add the “TWCA
Root Certification Authority” root certificate and enable the Websites
and Email trust bits. At the conclusion of this discussion, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may be
needed as follow-up.
Kathleen
Kathleen Wilson
All, Would at least two people please review and comment on this root
inclusion request from TWCA?
Kathleen
Jesús
in the UCA CPS is stated that the PKI services include a low-assurance
type of certificates, referred as Level 0 or Class 0 certificates. It
is also stated that the CP's of several sub-cas must include especific
info in order to provide valuable data to relying parties according to
the PKI framework and TWCA PKI CP.
Having a look at the CP I wonder how many mechanisms are provided to
distinguish a test certificate from the others (Class 1 to 3). I mean,
I understood that test certificates are issued with a sepecific OID
but, are there other ways to identify these type of certificates, e.g.
a special tag in the CN such as "TESTING PURPOSE" ...?
Thanks in advance for your comments.
Regards
> Kathleen- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
Robin Lin
The test certificates are all issued by the CA with the following
subject DN:
CN = TaiCA Secure CA -Evaluation Only
OU = SSL Certification Service Provider-Evaluation Only
O = TAIWAN-CA.COM Inc.
C = TW
Relying party may use this information to identify the test
certificate.
Thanks and Regards,
Robin Lin
Eddy Nigg
> Hi,
> The test certificates are all issued by the CA with the following
> subject DN:
>
> CN = TaiCA Secure CA -Evaluation Only
> OU = SSL Certification Service Provider-Evaluation Only
> O = TAIWAN-CA.COM Inc.
> C = TW
Just for the record, but I believe the new Mozilla policy forbids such
content in certificates entirely. If you got those and other phrases
besides verified content in certificate, you should get rid of it now.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Robin Lin
> On 05/05/2011 05:02 AM, From Robin Lin:
>
> > Hi,
> > The test certificates are all issued by the CA with the following
> > subject DN:
>
> > CN = TaiCA Secure CA -Evaluation Only
> > OU = SSL Certification Service Provider-Evaluation Only
> > O = TAIWAN-CA.COM Inc.
> > C = TW
>
> Just for the record, but I believe the new Mozilla policy forbids such
> content in certificates entirely. If you got those and other phrases
> besides verified content in certificate, you should get rid of it now.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
Hi Eddy,
Sorry, I don't understand why new policy did not allow this type of
name. In subject DN, the O, OU and CN is meaningful and can be use to
identify our company name and service type.
Will that cause some problem?
Robin Lin
Eddy Nigg
> Sorry, I don't understand why new policy did not allow this type of
> name. In subject DN, the O, OU and CN is meaningful and can be use to
> identify our company name and service type.
> Will that cause some problem?
It's my understanding that the new policy doesn't allow it anymore. Only
validated content can be used in those fields.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Kathleen Wilson
All, thank you for your feedback on TWCA's root inclusion request. Other
than the issue of the test certificates, are there any other questions,
comments, or concerns about this request?
Robin, Please see the Mozilla CA Certificate Policy, in particular
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
-- 4th bullet under #6: "verify that all of the information that is
included in SSL certificates remains current and correct at time
intervals of thirty-nine months or less;"
-- 1st bullet under #7: "all information that is supplied by the
certificate subscriber must be verified by using an independent source
of information or an alternative communication channel before it is
included in the certificate;"
-- 3rd bullet under #7: "for a certificate to be used for SSL-enabled
servers, the CA takes reasonable measures to verify that the entity
submitting the certificate signing request has registered the domain(s)
referenced in the certificate or has been authorized by the domain
registrant to act on the registrant's behalf;"
I had interpreted the table in CPS section 1.2 to mean that SSL certs
were only issued under Level 2 and Level 3. It is now clear that SSL
certificates are also issued under Level 0 (testing). This is indeed a
problem, because the testing certificates do not appear to meet the
requirements of the Mozilla CA Certificate Policy. The solution is
either to not issue testing certificates in the hierarchy of a root to
be included in NSS, or to add sufficient verification procedures to meet
the requirements of the Mozilla CA Certificate Policy. This wiki page
may be of help:
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
Are SSL certs also issued under Level 1 assurance?
Kathleen
Robin Lin
> -- 4th bullet under #6: "verify that all of the information that is
> included in SSL certificates remains current and correct at time
> intervals of thirty-nine months or less;"
> -- 1st bullet under #7: "all information that is supplied by the
> certificate subscriber must be verified by using an independent source
> of information or an alternative communication channel before it is
> included in the certificate;"
> -- 3rd bullet under #7: "for a certificate to be used for SSL-enabled
> servers, the CA takes reasonable measures to verify that the entity
> submitting the certificate signing request has registered the domain(s)
> referenced in the certificate or has been authorized by the domain
> registrant to act on the registrant's behalf;"
>
> I had interpreted the table in CPS section 1.2 to mean that SSL certs
> were only issued under Level 2 and Level 3. It is now clear that SSL
> certificates are also issued under Level 0 (testing). This is indeed a
> problem, because the testing certificates do not appear to meet the
> requirements of the Mozilla CA Certificate Policy. The solution is
> either to not issue testing certificates in the hierarchy of a root to
> be included in NSS, or to add sufficient verification procedures to meet
> the requirements of the Mozilla CA Certificate Policy. This wiki page
>
> Are SSL certs also issued under Level 1 assurance?
>
> Kathleen
Hi Kathleen,
1. Our SSL certificate did not issue under level 1 assurance.
2. The test certificate application is using the same procedure in
CPS, both organization and domain name verification.
3. The test certificate is short validity(14 days).
Only the certificate with verified information can chain to this root.
Robin Lin
Kathleen Wilson
I'm still confused about the following...
> 2. The test certificate application is using the same procedure in
> CPS, both organization and domain name verification.
In UCA CPS section 2.2.1.1 it says: "Testing certificates are intended
for testing purpose and neither the UCA nor the RA will run any identity
authentication. Therefore, they cannot be used in any applications or
businesses."
I interpret this to mean that no verification is done on the subscriber
identity for the testing cert.
However, a few lines down it says: "Used by UCA-authorized subscribers
for testing only."
This could mean that testing certs are only issued to a subscriber whose
identity and authority has already been verified.
Also, I am not able to find in the UCA CPS where it says that domain
name verification is done for test certs. I only see domain name
verification in UCA CPS section 5.1 in regards to EC+ certificates and
CXML certificates.
Kathleen
Robin Lin
SSL certificate application procedure is described in EC+ certificate
(2) SSL server certificate section.
S/MIME certificate application procedure is described in in C.
Application for CXML certificates section .
However, the CPS is not described the test certificate application
requirement, even the verification process had done before the SSL
certificate issuance.
Do we have to modify our CPS to include this requirement statement?
Robin Lin
Kathleen Wilson
Yes. If you plan to continue issuing test certs within this hierarchy,
then the CP/CPS must also describe the associated subscriber
verification process. The verification process for the test certs must
meet the requirements of the Mozilla CA Certificate Policy and must also
be included in the annual audit.
Kathleen
Robin Lin
Since we have the same procedure to verify the information of test SSL
and S-MIME certificates.
We will not issue test class certificate for SSL and S-MIME, because
it's have possible risk to our relying party.
The TWCA UCA CPS needs update to describe that we did not provide test
class SSL and S-MIME certificates.
We will soon publish the updated CPS on our web site and post the
download link here.
Robin Lin
Kathleen Wilson
>
> Since we have the same procedure to verify the information of test SSL
> and S-MIME certificates.
> We will not issue test class certificate for SSL and S-MIME, because
> it's have possible risk to our relying party.
> The TWCA UCA CPS needs update to describe that we did not provide test
> class SSL and S-MIME certificates.
> We will soon publish the updated CPS on our web site and post the
> download link here.
>
> Robin Lin
This is the only action item that I am aware of that resulted from this
discussion.
We will wait for you to publish the updated CPS and post the new urls here.
Thanks,
Kathleen
Robin Lin
The TWCA UCA CPS have been updated.
We add one statement to enhance our procedure to validate the
information on SSL and SMIME certificate.
For SSL:
"All assurance levels of SSL server certificates shall use following
procedure to verify subscriber’s
information."
For SMIME:
"All assurance levels of CXML certificates shall use following
procedure to verify subscriber’s
information."
This means that we will not issue certificate with none-verified
information to chain to TWCA Root CA. We decide to do this because
this can reduce our operational risk.
This CPS can be download from following link:
http://www.twca.com.tw/picture/file/20110523-180517756.pdf
Thanks a lot!
Robin Lin
Kathleen Wilson
I see the changes on page 42, but I'm not sure how the new text relates
to the information about test certificates on page 12. Do the new
statements mean that test certs cannot be issued for SSL and CXML? Or
does it mean that if test certs are issued for SSL or CXML, then those
verification procedures must be followed?
Kathleen
Robin Lin
Yes, it means if test certs are issued for SSL or CXML, then those
verification procedures must be followed.
Robin Lin
Kathleen Wilson
Then perhaps this statement on page 12 needs to be modified?
"Testing certificates are intended for testing purpose and neither the
UCA nor the RA will run any identity authentication."
Kathleen
Robin Lin
1. Our policy have been changed to disallow to issue test class
certificates, that can be chain up to TWCA Root CA(since it have been
distributed with some browser/operating system). In Section 5.1, it
described there is no test certificate for SSL, SMIME and other type
of certificates that chain to TWCA Root CA.
2. Since we have other UCA described in the CPS which is not chain to
TWCA Root CA, we wish to keep that statement.
Robin Lin
Kathleen Wilson
Which document is this in?
Are the urls for the documents listed on the pending page correct?
http://www.mozilla.org/projects/security/certs/pending/#TWCA
If not, please provide current urls.
Robin Lin
> If not, please provide current urls.
>
>
>
>
>
>
>
> > 2. Since we have other UCA described in the CPS which is not chain to
> > TWCA Root CA, we wish to keep that statement.
>
> > Robin Lin
The URI of the document in the pending list is still the old version.
I have update the attachment in the Bug 518503 to include new UCA CPS
document.
The download link should be as follow.
http://www.twca.com.tw/picture/file/20110523-180517756.pdf
Please help us to update the URL in the pending list.
Robin Lin
Kathleen Wilson
On page 12 of the UCA CPS it says: "Testing certificates are intended
for testing purpose and neither the UCA nor the RA will run any identity
authentication."
Then in section 5.1 of the UCA CPS it says: "All assurance levels of SSL
server certificates shall use following procedure to verify subscriber’s
information."
Folks reading this discussion, Is it clear to you that this is saying
that test certs cannot be issued for SSL?
>> Are the urls for the documents listed on the pending page correct?http://www.mozilla.org/projects/security/certs/pending/#TWCA
>> If not, please provide current urls.
>
> The URI of the document in the pending list is still the old version.
> I have update the attachment in the Bug 518503 to include new UCA CPS
> document.
> The download link should be as follow.
> http://www.twca.com.tw/picture/file/20110523-180517756.pdf
The pending page also has links to the corresponding documents in Chinese.
Kathleen
Robin Lin
The page 8 also described the certificate types. The SSL Server
Certificate is assurance level 2 certificate type.
Robin Lin
Kathleen Wilson
Upon further thought about this, I believe the statements that were
added to the SSL and CXML sections are sufficient in resolving the
concerns about test certs for SSL and SMIME.
Will you also be updating the Chinese version of the UCA CPS?
Kathleen
Robin Lin
Yes, we will update the Chinese version of the UCA CPS, because the
CPS management procedure have be audit by external auditing firm.
Robin Lin
Kathleen Wilson
>>
>>>>>>> 1. Our policy have been changed to disallow to issue test class
>>>>>>> certificates, that can be chain up to TWCA Root CA(since it have been
>>>>>>> distributed with some browser/operating system). In Section 5.1, it
>>>>>>> described there is no test certificate for SSL, SMIME and other type
>>>>>>> of certificates that chain to TWCA Root CA.
>>
>>
>>
>>
>> Kathleen
>
> Yes, we will update the Chinese version of the UCA CPS, because the
> CPS management procedure have be audit by external auditing firm.
>
> Robin Lin
OK. Please let us know the url of the new Chinese version of the UCA CPS
when it has been updated.
All, This is the last call for comments/concerns/questions about this
request from TWCA to add the “TWCA Root Certification Authority” root
certificate and enable the Websites and Email trust bits.
I will close this discussion if there are no further comments. Then I
will recommend approval after I have confirmed that the Chinese version
of the UCA CPS has been updated.
Kathleen
Robin Lin
The Chinese Version of TWCA UCA CPS has been update and approved by
our PMA.
The CPS can download from our website.
The download link is as below:
http://www.twca.com.tw/picture/file/20110610-162851208.pdf
Thanks,
Robin Lin
Kathleen Wilson
I confirm that the changes are in this version of the file.
Is the new file also on the Download or Repository page?
http://www.twca.com.tw/Portal/download/download.aspx
http://www.twca.com.tw/Portal/save/save.html
Kathleen
Robin Lin
Kathleen Wilson
> certificate and enable the Websites and Email trust bits.
>
> 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).
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=518503
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#TWCA
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=520022
>
Thank you to those of you who reviewed this root inclusion request from
TWCA and contributed to this discussion. The result of this discussion
is that TWCA will no longer issue test class certificates for SSL and
S-MIME within the hierarchy of this root. The TWCA UCA CPS documentation
has been updated to reflect this change.
This concludes the public discussion about TWCA's request to add the
�TWCA Root Certification Authority� root certificate and enable the
Websites and Email trust bits.
I will post my recommendation for approval of this request in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=518503
All follow-up on this request should be posted directly in the bug.
Thanks again to all of you who have participated in this discussion.
Kathleen