TWCA Request to enable EV and turn on Code Signing trust bit

[Kathleen Wilson]

TWCA applied to turn on the Code Signing trust bit and enable EV for the
�TWCA Root Certification Authority� root certificate that was included
in NSS per bug #518503.

Taiwan CA. Inc. (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. Taiwan-CA INC. (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=745671

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

Noteworthy points:

* The primary documents are the CP and CPS documents, which are
translated into English.

Repository (English):
http://www.twca.com.tw/Portal/english/coporate_profile/Repository.html
On this page there are links to: CPS, CP, EV CPS, and sub-CA CPS.

This root has internally-operated subordinate CAs, and no
externally-operated subordinate CAs. All of the subCAs must follow TWCA
UCA CPS to conduct their operations.
The sub-CAs are:
1. CN=TaiCA Secure CA, OU=SSL Certification Service Provider,
O=TAIWAN-CA.COM Inc., C=TW
The certificate issued by this sub-CA is used to be the identity of Web
or Application Server. (SSL certificate) The liability and applicable
limitation depends on the assurance level.
2. CN=TaiCA Secure CA, OU=Certification Service Provider,
O=TAIWAN-CA.COM Inc., C=TW
The certificate issued by this sub-CA is used to be the identity for
on-line commerce transactions, such as the stock trading, or email
security, depends on the assurance level. The liability and applicable
limitation also depends on the assurance level.
3. CN=TaiCA Information Policy CA, OU = Policy CA, O = TaiCA, C =TW ;
CN=TaiCA Information User CA, OU = User CA, O = TaiCA, C = TW
The certificate issued by this sub-CA is used to be the 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, O = TaiCA, C =TW ;
CN=TaiCA Finance User CA, OU = User CA, O = TWCA, C = TW
The certificate issued by this sub-CA is used to be the identity for
on-line fund transfer, e-Finance or e-Banking transactions. The
liability and applicable limitation depends on the assurance level.
5. CN = TWCA EVSSL Certification Authority, OU = EVSSL Sub-CA, O =
TAIWAN-CA, C = TW
Issues EV SSL certs.

Currently the websites and email trust bits are enabled. This request is
to also enable the code signing trust bit.

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 and 5.1 of the CPS.

S/MIME certificates are issued under assurance level class 1, 2, or 3.
TWCA verifies the identity 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 and 5.1 of the CPS.

TWCA code signing certificate will only issue to organization, the
authentication requirement is described in the CPS.

CPS section 4.1.8, Authentication of Organization Identity
If a company registers its level of assurance to Class 3, when TWCA and
the RA verify its registration status and DN, this company shall provide
the relevant supporting documents (the company stamp and signature of
the statutory representative shall appear in each photocopy) issued by
the competent authorities or legally authorized units or the relevant
legal documents if it is an overseas company. If the registration is
made by an agent, the agent shall apply for the registration in person.
Also, the identity documents of this agent shall be verified. The level
of assurance for registration is specified in �Level of Assurance,
Clause 2.2.1.1.�

CPS section 4.1.9, Authentication of Individual Identity
If individual registers his/her level of assurance to Class 3, this
individual shall apply for registration in person and submit the
relevant identity documents (an ID or passport with his/her photo) for
the RA to verify. No application shall be made by an agent. When the
applicant is an alien, the verification shall be conducted according to
the relevant business regulations (e.g. verification of passport with
photo). The level of assurance for registration is specified in �Level
of Assurance, Clause 2.2.1.1.�


This request is to also enable EV.

* EV Policy OID 2.16.886.3.1.6.5

EV CPS Section 1.2: This CA operates according to Assurance Level 4
specified in the TWCA PKI CP and issues Class 3 certificates specified
in the CP to EV SSL certificate subscribers
Section 3.2.2.1: When authenticating the identity of an organization,
documents issued by the competent authorities or other documents proven
the existence of such organization shall be verified. Also, the identity
of its statutory representative shall be authenticated. Application
documents and identity documents can be delivered either over the
counter or by mail.
In addition to verifying the documents submitted by subscribers,
information shall be verified according to the identity identification
and authentication requirements specified in the EV SSL Guidelines. At
least the following actions shall be taken to verify the identity of an
organization:
(1) Private organization: To check if the contents contained in the
documents submitted by the organization match with the contents
registered to the competent authorities with the open information
provided by the competent authorities.
(2) Public organization: The legal reference for formation of public
organizations shall be verified. Public organizations shall be requested
to submit the application in an official document, and the name appeared
in the official seal affixed to the document must be identical to the
organization name indicated. The identification information provided for
the application must match with the information published in the
government organization database.

EV CPS section 3.2.2.2 Internet Host Authentication Procedure
(1) Private organizations: To validate in the database of the
administration unit of public Internet domain name that the domain name
used by the Internet host name provided by a private organization in the
initial registration is managed and used by that private organization.
(2) Public organizations: To validate the domain name of public
organizations at the government�s public directory service and verify
that the domain name used by the Internet host name provided in the
initial registration exists, and the name of the user unit is identical
to the public organization validated in 3.2.2.1.

* Test Website: https://evssldemo.twca.com.tw/index.html

* CRL
http://RootCA.twca.com.tw/TWCARCA/revoke_2048.crl
http://sslserver.twca.com.tw/sslserver/EVSSL_Revoke_2011.crl
CPS section 5.4.9: CRL issuance frequency shall be 24 hours.

* OCSP: http://evssl_ocsp.twca.com.tw/

* Audit: Annual audits are performed by SunRise CPAs� Firm, a member
firm of DFK, according to the WebTrust CA and WebTrust EV criteria and
posted on the webtrust.org website.
https://cert.webtrust.org/ViewSeal?id=1322
https://cert.webtrust.org/ViewSeal?id=1323

* Potentially Problematic Practices � None noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from TWCA to turn on the Code
Signing trust bit and enable EV for the �TWCA Root Certification
Authority� root certificate that is currently included in NSS. At the
conclusion of this discussion I will provide a summary of issues noted
and action items. If there are outstanding issues, then an additional
discussion may be needed as follow-up. If there are no outstanding
issues, then I will recommend approval of this request in the bug.

Kathleen

[Erwann Abalea]

Le mardi 2 octobre 2012 22:02:40 UTC+2, Kathleen Wilson a écrit :

> * OCSP: http://evssl_ocsp.twca.com.tw/

The underscore character can be used in some DNS resources, but not in a hostname.

The "www.twca.com.tw" URI referred to in your certificatePolicies extension is not a standard URI (it lacks the scheme, see RFC3986); the website shows an error "Bad Request (Invalid Hostname)", I guess it's temporary.

The subjectAlternativeName of your OCSP responder certificate contains an email address with "@@" only.

The serial Number of your OCSP responder doesn't contain 20 bits of entropy, and yet it's produced by your CA.

Your OCSP responder certificate doesn't contain the ocspNoCheck extension, mandatory for CABForum (see Baseline requirements).

Your OCSP service correctly replies to POST requests, but not to GET requests; the served result is declared as "text/html", and is a 0 byte length.

Looking at your EV subCA, it seems the other produced certificates' serial numbers are also sequential.

[Robin Lin]

Erwann Abalea於 2012年10月5日星期五UTC+8下午6時23分44秒寫道：

-->We can re-configured the hostname. Will it will cause the wrong action for NSS?

The "www.twca.com.tw" URI referred to in your certificatePolicies extension is not a standard URI (it lacks the scheme, see RFC3986); the website shows an error "Bad Request (Invalid Hostname)", I guess it's temporary.

-->We will use http://www.twca.com.tw/ to instead.

The subjectAlternativeName of your OCSP responder certificate contains an email address with "@@" only.

-->We will remove this extension after the OCSP certificate is renew.

The serial Number of your OCSP responder doesn't contain 20 bits of entropy, and yet it's produced by your CA.

-->Our system was update to use random serial on the end of June, 2012. It will be random serial after the OCSP certificate renew.

Your OCSP responder certificate doesn't contain the ocspNoCheck extension, mandatory for CABForum (see Baseline requirements).

--> Same as random serial number It will be include after the OCSP certificate after renew.

Your OCSP service correctly replies to POST requests, but not to GET requests; the served result is declared as "text/html", and is a 0 byte length.

-->Currently, our OCSP software do not correctly response if client using GET method. We will upgrade the software on the end of November.

Looking at your EV subCA, it seems the other produced certificates' serial numbers are also sequential.

--> Our system was update to use random serial on the end of June, 2012. It will be random serial after the OCSP certificate renew.

[Robin Lin]

Erwann Abalea於 2012年10月5日星期五UTC+8下午6時23分44秒寫道：

-->We can re-configured the hostname. Will it will cause the wrong action for NSS?

The "www.twca.com.tw" URI referred to in your certificatePolicies extension is not a standard URI (it lacks the scheme, see RFC3986); the website shows an error "Bad Request (Invalid Hostname)", I guess it's temporary.

-->We will use http://www.twca.com.tw/ to instead.

The subjectAlternativeName of your OCSP responder certificate contains an email address with "@@" only.

-->We will remove this extension after the OCSP certificate is renew.

The serial Number of your OCSP responder doesn't contain 20 bits of entropy, and yet it's produced by your CA.

-->Our system was update to use random serial on the end of June, 2012. It will be random serial after the OCSP certificate renew.

Your OCSP responder certificate doesn't contain the ocspNoCheck extension, mandatory for CABForum (see Baseline requirements).

--> Same as random serial number It will be include after the OCSP certificate after renew.

Your OCSP service correctly replies to POST requests, but not to GET requests; the served result is declared as "text/html", and is a 0 byte length.

-->Currently, our OCSP software do not correctly response if client using GET method. We will upgrade the software on the end of November.

Looking at your EV subCA, it seems the other produced certificates' serial numbers are also sequential.

[Kathleen Wilson]

On 10/2/12 1:02 PM, Kathleen Wilson wrote:
> TWCA applied to turn on the Code Signing trust bit and enable EV for the

> “TWCA Root Certification Authority” root certificate that was included

> in NSS per bug #518503.
>
> Taiwan CA. Inc. (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. Taiwan-CA INC. (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=745671
>
> 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=667122
>
> Noteworthy points:
>
> * The primary documents are the CP and CPS documents, which are
> translated into English.
>
> Repository (English):
> http://www.twca.com.tw/Portal/english/coporate_profile/Repository.html
> On this page there are links to: CPS, CP, EV CPS, and sub-CA CPS.
>
> This root has internally-operated subordinate CAs, and no
> externally-operated subordinate CAs. All of the subCAs must follow TWCA
> UCA CPS to conduct their operations.
>

Thank you Erwann for reviewing and commenting on this request.

Would at least one more person please review and comment on this request?

Thanks,
Kathleen

[Kathleen Wilson]

All,

The action items resulting from this discussion are as follows.

ACTION TWCA: Fix hostname to remove underscore character.

ACTION TWCA: Fix URI in certificatePolicies extension to be RFC 3986
compliant.

ACTION TWCA: Fix issues with OCSP certificate: email address in
subjectAlternativeName, entropy, ocspNoCheck extension.

ACTION TWCA: Support OCSP GET

In my opinion, these action items may be tracked separately in the bug.

Therefore, if there are no objections, I will close this discussion and
track the action items in the bug. Then (after closure of the action
items) I will recommend approval in the bug.

Thanks,
Kathleen

[Kathleen Wilson]

All,

TWCA has asked if they can update this request to included two EV OIDs,
instead of one...

https://bugzilla.mozilla.org/show_bug.cgi?id=745671#c27
"May we request one more EV OID: 2.16.158.3.1.6.5 We need 2 EV OIDs,
2.16.886.3.1.6.5
2.16.158.3.1.6.5
The reason is the historical political problem in Taiwan."

Does anyone have concerns or questions about this change?

Thanks,
Kathleen

[Erwann Abalea]

Le mercredi 31 octobre 2012 21:32:39 UTC+1, Kathleen Wilson a écrit :
> All,
>
> TWCA has asked if they can update this request to included two EV OIDs,
> instead of one...
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=745671#c27
> "May we request one more EV OID: 2.16.158.3.1.6.5 We need 2 EV OIDs,
>
> 2.16.886.3.1.6.5
> 2.16.158.3.1.6.5
>
> The reason is the historical political problem in Taiwan."
>
> Does anyone have concerns or questions about this change?

I hadn't checked the OID arcs. That's a nice remainder.

http://oid-info.com/get/2.16.886
says that TWCA doesn't have the right to use this arc, and that everything should be transferred to 2.16.158 (which is assigned to Taiwan).
So the question really is: can a 2.16.886.* OID be used by TWCA?

[Robin Lin]

Erwann Abalea於 2012年11月1日星期四UTC+8下午8時06分21秒寫道：

Hi,

As my understanding, Taiwan government change to use the OID from 158 to 886 for about 40 years ago after ROC is out from United Nation.
The OID '886' is locally used in Taiwan... We also need to use it.
For international commercial use, the 158 must be used because the first OID used in FEDI system, the 158 indicates Taiwan.

Robin Lin

[Robin Lin]

Erwann Abalea於 2012年11月1日星期四UTC+8下午8時06分21秒寫道：

[Erwann Abalea]

Le vendredi 2 novembre 2012 02:34:48 UTC+1, Robin Lin a écrit :
> Erwann Abalea於 2012年11月1日星期四UTC+8下午8時06分21秒寫道：
> > Le mercredi 31 octobre 2012 21:32:39 UTC+1, Kathleen Wilson a écrit :
> > > All,
>
> > > TWCA has asked if they can update this request to included two EV OIDs,
> > > instead of one...
>
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=745671#c27
>
> > > "May we request one more EV OID: 2.16.158.3.1.6.5 We need 2 EV OIDs,
> > > 2.16.886.3.1.6.5
> > > 2.16.158.3.1.6.5
> > > The reason is the historical political problem in Taiwan."
>
> > > Does anyone have concerns or questions about this change?
>
> > I hadn't checked the OID arcs. That's a nice remainder.
>
> > http://oid-info.com/get/2.16.886
>
> > says that TWCA doesn't have the right to use this arc, and that everything should be transferred to 2.16.158 (which is assigned to Taiwan).
>
> > So the question really is: can a 2.16.886.* OID be used by TWCA?
>
> Hi,
>
> As my understanding, Taiwan government change to use the OID from 158 to 886 for about 40 years ago after ROC is out from United Nation.

Taiwan government cannot change this by itself, it must be validated by who governs the 2.16 arc.

The exposed timeframe also seems incorrect, the principle of OID was formalized by first version of ASN.1 in 1984 (28 years ago). The oldest version I can get is the X.208 one, published in 1988 (24 years ago).
Oldest version of X.660 (1992/09) states that the numbers directly under 2.16 arc are the ISO3166 numeric-3 codes.
Taiwan ISO3166 numeric-3 code seems to be 158 since the first version of this code, in 1974 (though it's hard to be authoritative). 886 was assigned to Yemen, which merged with Republic of Yemen in 1990 and were assigned 887.

> The OID '886' is locally used in Taiwan... We also need to use it.

886 is Taiwan telephone country code, and it's not related in any way to the ISO country code.

[Erwann Abalea]

Looking again at this OID, I consulted the OID repository (www.oid-info.com), and 2.16.158.3 seems also to have been improperly used.

I then sent an email to the registered owner of 2.16.158 arc, as found in the repository, in the hope of authoritative answers regarding 2.16.158.3.* OIDs and "Taiwan CA, Inc".

[Erwann Abalea]

Le mardi 6 novembre 2012 17:51:08 UTC+1, Erwann Abalea a écrit :
> I then sent an email to the registered owner of 2.16.158 arc, as found in the repository, in the hope of authoritative answers regarding 2.16.158.3.* OIDs and "Taiwan CA, Inc".

Only answer I got so far is a "no route to host" from the MTA (Google), it will be retried for 2 more days.

[Erwann Abalea]

I can safely say the mail won't go anywhere.

"Taiwan Registration and Certification Authority" is the last known authority of 2.16.158 arc, but they don't have any internet connectivity (unreachable DNS, no MX). I tried to phone call them and only got a chinese message saying the number wasn't attributed anymore. They just disappeared between 2008 and now.

SG17 OID project leader has been contacted (he's the www.oid-info.com maintainer), gave me another person to get in touch with, and a final procedure involving ITU-T.

In the meantime, I think it's unsafe to allow use of those OIDs for EV. As unsafe as allowing 2.23.140.* (CABForum), or 1.3.6.1.4.1.311.* (Microsoft), or anything that can be owned by somebody else (known or unknown).

If Taiwan is unable to provide a clean mechanism for OID attribution, I'd suggest TWCA to switch to another RA, and maybe register for a 1.3.6.1.4.1 private OID arc, and then organize their stuff below it.

[Jean-Marc Desperrier]

Kathleen Wilson a écrit :

> We need 2 EV OIDs,

> [...]

> 2.16.158.3.1.6.5
> The reason is the historical political problem in Taiwan."
>
> Does anyone have concerns or questions about this change?

http://oid-info.com/get/2.16.158.3 says :
"Institute for Information Industry claims to have this OID but the
Registration Authority for the superior OID confirmed that this OID was
never assigned to III."

I don't know what Robin Lin thinks about that. As the Taiwan
Registration and Certification Authority Inc. did not attribute .3 to
anyone else, it doesn't lead to a direct conflict.

[Jean-Marc Desperrier]

Robin Lin a écrit :

>> >http://oid-info.com/get/2.16.886
>> >says that TWCA doesn't have the right to use this arc, and that everything should be transferred to 2.16.158 (which is assigned to Taiwan).
>> >
>> >So the question really is: can a 2.16.886.* OID be used by TWCA?
>

> As my understanding, Taiwan government change to use the OID from 158 to 886 for about 40 years ago after ROC is out from United Nation.
> The OID '886' is locally used in Taiwan... We also need to use it.
> For international commercial use, the 158 must be used because the first OID used in FEDI system, the 158 indicates Taiwan.

The oid-info page doesn't say that. .886 has initially been assigned to
Yemen, and it was a human error in, or slightly around, 1998 that led
Taiwan to use it.

However actually, since 1990 and the merge between Yemen and Democratic
Yemen, Yemen doesn't use that code anymore but instead .887.
So there's not much actual conflict with Yemen.

The following also provides some context :
http://www.alvestrand.no/objectid/taiwan.html

[Erwann Abalea]

Le jeudi 8 novembre 2012 20:40:05 UTC+1, Jean-Marc Desperrier a écrit :
> Kathleen Wilson a �crit :

The RA for 2.16.158 could have later assigned .3 to somebody else.
OID space shouldn't be considered as a "first come, first served" place.

[Robin Lin]

Erwann Abalea於 2012年11月9日星期五UTC+8上午8時07分57秒寫道：

There is no legal RA currently in Taiwan since Taiwan is not a member of ITU/ISO.
So I thought this is the political issue, Taiwan is not able to establish a country level RA because it cannot join ISO/ITU as a member.
We wish that we can use 2.16.158.3 if no harm to others.

Robin Lin

[Robin Lin]

Erwann Abalea於 2012年11月9日星期五UTC+8上午8時07分57秒寫道：

[Robin Lin]

Jean-Marc Desperrier於 2012年11月9日星期五UTC+8上午3時40分05秒寫道：

> Kathleen Wilson a �crit :
>

Actually, we use 2.16.158.3 for about 10+ years. There is no conflict with others. Especially, there is no official oid RA in Taiwan. Even that we wish to register our oid, we can not find any one can help us since Taiwan is not a member of ISO/ITU organizations.

[Robin Lin]

Jean-Marc Desperrier於 2012年11月9日星期五UTC+8上午3時40分05秒寫道：
> Kathleen Wilson a �crit :
>

[Erwann Abalea]

Le lundi 12 novembre 2012 06:50:39 UTC+1, Robin Lin a écrit :
> There is no legal RA currently in Taiwan since Taiwan is not a member of ITU/ISO.

There is one. The last known RA for 2.16.158 is named TWRA.

> So I thought this is the political issue, Taiwan is not able to establish a country level RA because it cannot join ISO/ITU as a member.
>
> We wish that we can use 2.16.158.3 if no harm to others.

This is not an acceptable solution. You cannot decide by yourself to use 2.16.158.3. What if another company also use 2.16.158.3? How is that dispute resolved? This is a decision that Mozilla cannot endorse.

As previously noted, SG17 OID project leader has been contacted (SG17 receives the 2.16.* RA agreements), proposed me another person to contact to get in touch with TWRA (the last known RA for 2.16.158), and I received his reply just this morning:

-----
TWCA, I remember that I told your company to apply a new OID at least 6 times.
Well, your company just ignored it and ask again repeatedly.
My last conversation was dated 2008/5/30, contact: rogerhong.
For the record, 2.16.158.3 arc did not assign to TWCA.

Please let me know if your company want to apply an OID.
Thank you.
-----

Even if 2.16.886 isn't to be assigned anymore, it can't be freely used either.
You cannot ask Mozilla (or any other browser) to allow you the use of 2.16.886 (Yemen), .810 (USSR), .80 (British Antartic Territory) or anything below 2.16 without the consent of 2.16 owners.
Further, you cannot ask for the use of 2.16.158.3 without the consent of 2.16.158 owner.
If you have some difficulty contacting them because of political problems, getting an OID under 1.3.6.1.4.1 is free and could have been done years ago.

[Erwann Abalea]

Le lundi 12 novembre 2012 09:13:29 UTC+1, Erwann Abalea a écrit :
> Le lundi 12 novembre 2012 06:50:39 UTC+1, Robin Lin a écrit :

[...]

> Further, you cannot ask for the use of 2.16.158.3 without the consent of 2.16.158 owner.
>
> If you have some difficulty contacting them because of political problems, getting an OID under 1.3.6.1.4.1 is free and could have been done years ago.

Mr Lin, you should contact service(at)twra.com.tw and oid(at)acast.net for 2.16.158 OID requests. If that fails, feel free to contact Raymond Lee raymond(at)acast.net.

Again, if all else fails, contact IANA to apply for a private enterprise number under 1.3.6.1.4.1.

[Jean-Marc Desperrier]

On 12/11/2012 06:58, Robin Lin wrote:
> Especially, there is no official oid RA in Taiwan. Even that we wish
> to register our oid, we can not find any one can help us since Taiwan
> is not a member of ISO/ITU organizations.

The administration of the 2.16 arc of the ITU/ISO is described here
http://oid-info.com/get/2.16 , it says :
"The assignment of registration responsibilities within a country is a
national decision."

It also refers to this document
http://www.oid-info.com/doc/country-OIDs.htm which says :
"It is strongly recommended today that any country wishing to establish
a Registration Authority (RA) for allocations within that country reach
agreement between the administration of an ITU Member State for the
country/state **(if any)** and the ISO Member Body for the country/state
**(if any)** "

None of those two entities exists for Taiwan, but this doesn't forbid
the OID to be attributed since it's a national decision, and both are
actually described as optional.

This document list the country RAs that the ITU recognizes and it does
officially recognize that one has been established for Taiwan :
http://www.oid-info.com/doc/country-OIDs.htm#agreements

The contact information is here : http://www.oid-info.com/get/2.16.158
Name: Taiwan Registration and Certification Authority Inc.

Address:
5F.-1, No.212, Sec. 3,
Bade Rd., Songshan Dist.,
Taipei City 105
Taiwan

Phone: +886 2 2577 8675

The name of the contact is indeed Raymond Lee, as Erwann already told you.
I suggest you contact him and you request him to write an official
letter to your superiors stating that his company has the authority to
assign identifiers under 2.16.158 and that TWCA is not actually allowed
to use 2.16.158.3.

I understand this will very probably raise some issues and problem for
retrocompatibility. But the situation needs to be clarified.

[Robin Lin]

Jean-Marc Desperrier於 2012年11月13日星期二UTC+8上午6時28分36秒寫道：

I tried to search the ITU member states using following link:
http://www.itu.int/GlobalDirectory/search.html
There is no any member can proof that "Taiwan Registration and Certification Authority Inc." is the country RA of Taiwan.
The question is go back to the source, Taiwan is not a member body of ISO and ITU. There is no one can resolve this problem. As Erwann said, no one can first use then get it first, but why the country code "2.16.158" could be?

To avoid this issue, I will try to apply PEN from IANA and use our private CP OID to enable the EV function in Mozilla.

[Robin Lin]

Jean-Marc Desperrier於 2012年11月13日星期二UTC+8上午6時28分36秒寫道：

[Robin Lin]

About TWCA EV OID, we have send request to apply PEN to IANA, it will take 30 days. This is current solution to resolve the OID question here.

About the action TWCA must take:
1. Fix hostname to remove underscore character.
--->FIXED; the new OCSP responder is "evsslocsp.twca.com.tw"
2. Fix URI in certificatePolicies extension to be RFC 3986 compliant.
--->FIXED; CPS URI indicator is point to our repository.
3. Fix issues with OCSP certificate: email address in subjectAlternativeName, entropy, ocspNoCheck extension.
--->FIXED; we remove the email, add ocspNoCheck extension and use 24 bits radom number in the serial number.
4. Support OCSP GET
--->FIXED, support both POST and GET

[Robin Lin]

[Jean-Marc Desperrier]

Robin Lin a écrit :

> Jean-Marc Desperrier於 2012年11月13日星期二UTC+8上午6時28分36秒寫道：
>> On 12/11/2012 06:58, Robin Lin wrote:
>> The administration of the 2.16 arc of the ITU/ISO is described here
>> http://oid-info.com/get/2.16 , it says :
>> "The assignment of registration responsibilities within a country is a
>> national decision."
>>

>> This document list the country RAs that the ITU recognizes and it does
>> officially recognize that one has been established for Taiwan :
>> http://www.oid-info.com/doc/country-OIDs.htm#agreements
>

> I tried to search the ITU member states using following link:
> http://www.itu.int/GlobalDirectory/search.html

We all agree Taiwan is not a member of ITU.

But the document I quoted does *not* require a country to be member to
have a recognized RA.

> There is no any member can proof that "Taiwan Registration and
> Certification Authority Inc." is the country RA of Taiwan.

The Project Leader of the ITU-T Study Group 7
(http://www.itu.int/en/ITU-T/about/groups/Pages/sg17.aspx in charge of
ITU security work coordination) *does* recognize this entity as the
country RA of Taiwan.

We could ask him on which document he relies to state that, and if there
can be an official document that indeed the ITU recognizes TRCA as the
entity currently in charge of the 2.16.258 arc.

[Robin Lin]

Hi,

We had applied one PEN from IANA and will use it as our enterprise OID tree root.
The PEN of TWCA is "1.3.6.1.4.1.40869"

The IANA page is:
http://www.iana.org/assignments/enterprise-numbers

We are update our CP and CPS to use the new OID right now, and will post the updated CP/CPS URL here for your review.

Robin Lin

[Robin Lin]

[Erwann Abalea]

Bonjour,

Le jeudi 29 novembre 2012 03:43:09 UTC+1, Robin Lin a écrit :
> We had applied one PEN from IANA and will use it as our enterprise OID tree root.
> The PEN of TWCA is "1.3.6.1.4.1.40869"

Thanks.

> The IANA page is:
>
> http://www.iana.org/assignments/enterprise-numbers
>
> We are update our CP and CPS to use the new OID right now, and will post the updated CP/CPS URL here for your review.

Could you also please update the inclusion bug (#745671) to clearly indicate the desired EV policy OID under this arc?

Cordialement.

[Robin Lin]

TWCA has been update EV OID, the CP/CPS are also available:
CP:
http://www.twca.com.tw/picture/file/12031626-Public%20Key%20Infrastructure%20Policy.pdf

CPS:
http://www.twca.com.tw/picture/file/12031629-EV%20SSL%20CA%20Certification%20Practice%20Statement.pdf

The new EV OID is:
1.3.6.1.4.1.40869.1.1.22.3

Also described as:
{ISO(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) TWCA(40869) certificates(1) policies(1) EV(22) class3(3) }

This will no conflict with others since this is our own OID extend from our PEN.

[Robin Lin]

[Kathleen Wilson]

> On 11/15/12 5:39 PM, Robin Lin wrote:
>> About the action TWCA must take:
>> 1. Fix hostname to remove underscore character.
>> --->FIXED; the new OCSP responder is "evsslocsp.twca.com.tw"
>> 2. Fix URI in certificatePolicies extension to be RFC 3986 compliant.
>> --->FIXED; CPS URI indicator is point to our repository.
>> 3. Fix issues with OCSP certificate: email address in subjectAlternativeName, entropy, ocspNoCheck extension.
>> --->FIXED; we remove the email, add ocspNoCheck extension and use 24 bits radom number in the serial number.
>> 4. Support OCSP GET
>> --->FIXED, support both POST and GET
>>

Thanks to all of you who have contributed to this discussion about
TWCA's request to turn on the Code Signing trust bit and enable EV for
the “TWCA Root Certification Authority” root certificate that was
included in NSS per bug #518503.

It is my opinion that all of the action items resulting from this
discussion have been completed,this discussion may be closed, and I
should recommend approval of this request in the bug.

As stated above, the EV Policy OID that will be used is:
1.3.6.1.4.1.40869.1.1.22.3

Thanks,
Kathleen

[Kathleen Wilson]

On 12/11/12 11:57 AM, Kathleen Wilson wrote:
>
> Thanks to all of you who have contributed to this discussion about
> TWCA's request to turn on the Code Signing trust bit and enable EV for
> the “TWCA Root Certification Authority” root certificate that was
> included in NSS per bug #518503.
>
> It is my opinion that all of the action items resulting from this
> discussion have been completed,this discussion may be closed, and I
> should recommend approval of this request in the bug.
>
> As stated above, the EV Policy OID that will be used is:
> 1.3.6.1.4.1.40869.1.1.22.3
>
> Thanks,
> Kathleen
>

Thank you to those of you who reviewed and contributed to this
discussion about the request from TWCA to turn on the Code Signing trust

bit and enable EV for the “TWCA Root Certification Authority” root

certificate.

All of the action items that were identified during this discussion have
been resolved.

I am closing this discussion, and I will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=745671

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen