[cabfpub] Suggestion to amend BR Section7.1.4.2.2d/e RE: EV Gudelines section 9.2.5 & X.520

Wed Jul 20 09:48:00 UTC 2016

    I reply as below, for readers easily to see what Erwann wrote were (https://cabforum.org/pipermail/public/2016-July/007996.html) , what I reply now are, I suggest to read attached pdf file, what I reply are in red or blue color.

Bonsoir,

About small countries that haven’t set up any state or province.

X.520 definition for the stateOrProvinceName attribute is (from 201210 edition):

The State or Province Name attribute type specifies a state or province. When used as a component of a directory name, it identifies a geographical subdivision in which the named object is physically located or with which it is associated in some other important way.

«Geographical subdivision » can mean anything. Maybe some would disagree, but I think that a CA can stretch it pretty easily while respecting the BRs.

If you want to follow the intent of the « province », since this latin-based word designates an administrative subdivision, it can even be a city or a village, and doesn’t necessarily mean a State in the US way. All the countries listed in Note 2 have cities.

=====> I think X.520 clearly specifies that 'The State or Province Name attribute type specifies a state or province.' (This is the first sentence of the stateOrProvinceName definition in X.520.) Should CAB Forum encourage the ambiguity that CAs may put the name of administrative subdivision at any level (such as a city, a county, a town, or a village) into stateOrProvinceName attribute? No, I don't think so.

About the uniqueness of an organizationName at a country level.

OV/IV certificates are not meant to unambiguously identify the subject named in the certificate. That role is left for EV certificates.

====> I am really surprised to see the interpretation that 'OV/IV certificates are not meant to unambiguously identify the subject named in the certificate' in the CAB Forum. Is this a common cognition of the CAB Forum? The fundamental function of a public-key certificate is to assert the binding between the subject identity and its public key, isn't it? The value of a CA in the internet community is to act as a Trusted Third Party (TTP) which is responsible to verify the identity of the subject and then guarantee the binding between the subject identity and its public key. I think that OV/IV certificates still need to unambiguously identify the subject named in the certificate. The difference between OV/IV certificates and EV certificates is that they provide different level of assurance regarding the identity information verified. I understand that there does not exist a global X.500 directory. However, A CA should still make its best to unambiguously identify the subject named in the OV/IV certificate. At least, the CA should guarantee that two different entities never share the same subject DN, otherwise how the relying parties can distinguish which organization/individual is actually behind the OV/IV certificate?

I have replied in previous email to Peter in  <https://cabforum.org/pipermail/public/2016-June/007897.html> https://cabforum.org/pipermail/public/2016-June/007897.html as below

For IV SSL certificate or citizen certificates, we can add unique serial number in Subject Distinguished Names to two different entities have the same names. (You said EV SSL certificates solve the problem, but don’t forget that EV SSL Certificates will not be issued to individuals, only be issued to Private Organization, Government Entities, Business entities and non-profit international organizations

Note that in  <https://cabforum.org/pipermail/public/2016-July/007912.html> https://cabforum.org/pipermail/public/2016-July/007912.html, I have replied to Peter in RFC 3739 there are Qualified Certificates Profiles.

I suggest you to read 

3.1.2. Subject

The serialNumber attribute type SHALL, when present, be used to differentiate between names where the subject field would otherwise be identical. This attribute has no defined semantics beyond ensuring uniqueness of subject names. It MAY contain a number or code assigned by the CA or an identifier assigned by a government or civil authority. It is the CA's responsibility to ensure that the serialNumber is sufficient to resolve any subject name collisions.

So for Taiwan’s GPKI, we can resolve any subject name collisions for government entities’ SSL certificates or citizen certificates more than 13 years.

For example, in an IV certificate, there can be more than one individuals named John Malkovich, living in the same country, same province, same city. Only one of them will obviously be able to have the <http://johnmalkoti.ch> johnmalkoti.ch domain, if it exists (it doesn’t).

Talking about OV certificates, even if it’s not possible to have 2 companies with the same name in the same jurisdiction, it’s possible to have 2 certificates having the same name representing 2 different entities. For example «C=UT, ST=MyVillage, O=XXXX», if XXXX is both a company and a brand (DBA).

Combine OV and IV, and «C=UT, ST=MyVillage, O=XXXX» can represent 3 different things, if XXXX is also the full name of an individual and the CA chooses to place this full name in the O field instead of GN/SN. (for a country named Utopia)

The rule for an OV/IV is something like « if you can provide evidence of the claimed identity, it’s good».

Again, if you want to disambiguate claimed identities, you’re free to add other attributes, or provide an EV certificate.

I don’t support the proposed BR changes, they only add complexity without any real benefit.

Looking at the example certificates:

*	certificate 1 is not problematic; if you want a less cluttered certificate, go for a DV; wether VA is really a country or not is left as an exercise (it’s a territory for me, but I’m not so difficult)

===>VA is really a country, they don’t set up a government entity whose legal name is called Vatican City State or Vatican City Province, but  <https://crt.sh/?q=98+ef+2b+4c+43+39+ae+04+3b+bd+55+08+59+b2+b7+b4+ee+76+cb+af> https://crt.sh/?q=98+ef+2b+4c+43+39+ae+04+3b+bd+55+08+59+b2+b7+b4+ee+76+cb+af

The Subject DN is
commonName=*.catholica.va
organizationName=Department of Telecommunications
localityName=Vatican City
stateOrProvinceName=Vatican City State
countryName =VA

The subject DN should be

commonName=*.catholica.va
organizationName=Department of Telecommunications
countryName =VA

It is enough to identify the domain name owner in Vatican.

*	certificate 2 is not wrong per se; Taichung City being a geographical subdivision of Taiwan, an administrative division, and a city, it’s not wrong to have Taichung in both the ST and L attributes — second example is « ST=Taiwan, L=Kaohsiung»; Taiwan being a province of the Taiwan country, and Kaohsiung being a city, it’s not wrong

===>Taichung City and Kaohsiung City are 6 special municipalities (Traditional  <https://en.wikipedia.org/wiki/Traditional_Chinese_characters> Chinese: 直轄市) or called  <https://en.wikipedia.org/wiki/Executive_Yuan> Yuan-controlled municipalities (院轄市),theYuan is referred to the Executive Yuan. Special municipalities have the rank of province. For example, following the merger of Taichung city and county on December 25, 2010, Greater Taichung became third-largest among Taiwan's six special municipalities with a population of 2,720,000 people. Its land area is three times the size of Singapore and twice that of Hong Kong.

Note that Taiwan Province is a non-public corporation, the province has been frozen to prevent Yeltsin (Борис Николаевич Ельцин )effect. (Taiwan Province , often referred to simply freeze province, downsizing or waste Province, in AD 1997 Upgrading the provisions of the Fourth Constitutional provisions of paragraph 3 of Article IX, in 1988,  the province was removed the "community" status, and the Taiwan provincial government degenerate reorganized as an agency of Executive Yuan. ). So the organization (Taiwan Province) has been a substantial reduction, function shrinking dramatically.

Or you can see Local Government Act of Taiwan, <http://www.moi.gov.tw/english/english_law/law_detail.aspx?sn=284> http://www.moi.gov.tw/english/english_law/law_detail.aspx?sn=284

Article 2.The terms used in this Act are defined as follows:

1.Local self-governing body: Bodies of standing that carries out local self-government in accordance with this Act. The Provincial Government is a branch of the Executive Yuan, while the province is not a local self-governing body.

2.Self-government matters: Matters that the local self-governing bodies may formulate legislation and carry out in accordance with the Constitution or provisions of this Act, or to matters that are to be handled by such bodies in accordance with law and where such bodies are responsible for policy formulation and implementation.

For government entity's DN and OID, our government set up a site at oid.nat.gov.tw, it is UTF 8 code in Traditional Chinese. It is no need to put S=Taiwan in DN for entities under Taichung City and Kaohsiung City.

*	I think certificate 3 is also fine; Taiwan Province is a province of the country Taiwan (just like Fujian Province is also such a province), and Taipei is a locality; wether the real name is Taipei or Taipei City is another remark

----No, the address of SOUTH CHINA INSURANCE CO., LTD is in Taipei city (The first special municipality in Taiwan). No need to put Taiwan Province.

The DN follows the Taiwan’s company act and current BR should be

CN = <http://www.ecover.com.tw> www.ecover.com.tw

OU = GlobalTrustSSLPro

OU = Provided by Global Digital Inc.

OU = MIS Dept

O = SOUTH CHINA INSURANCE CO., LTD.

STREET = 5F,No.560,Sec. 4,Chung Hsiao E Rd., Taipei City ,Taiwan

L = Taipei City

PostalCode = 110

C = TW

But it may misinterpretate SOUTH CHINA INSURANCE CO., LTD as registered in Taipei City. So we suggest to modify SSL BR and use below DN

CN = <http://www.ecover.com.tw> www.ecover.com.tw

OU = GlobalTrustSSLPro

OU = Provided by Global Digital Inc.

OU = MIS Dept

O = SOUTH CHINA INSURANCE CO., LTD.

STREET = 5F,No.560,Sec. 4,Chung Hsiao E Rd., Taipei City ,Taiwan

PostalCode = 110

C = TW

Because from Note1 of previous attached file, according Taiwan’s Company Act, the company name must be unique for the whole country. So we can omit the L = Taipei City. Also Taipei City appears in the Street field.

Our government has followed our country’s law to setup the government entities’ DIT, Distinguished Name, OID. For unambiguously identifying the difference of Chiayi City and Chiayi county, we suggest to use L=Chiayi City and L=Chiayi county. That is why we suggest to use L=Taipei City in previous email for the example certificate. 

You’re explaining your proposals by using «no need to put (some information) », or «registered in (somewhere)», but it’s not relevant here. The fact that a company is registered in a city shouldn’t prevent the CA from setting the postalCode or streetAddress attributes (it’s not wrong to set these attributes). And if you want to unambiguously identify the company « ABC Store» registered in Nantou County from the «ABC Store» registered in Taipei City, again, use an EV, that’s what they’re here for. This can raise some legitimate questions and necessary clarifications about the real content and hierarchy of jurisdiction*Name attributes, and it’s OK.

=====>I did not say if a store registered in a city, we should omit the postal code or address attribute. (But it is optional in current BR). Example 4 is just said in Taiwan, a store’s situation is different with a company. So there will be a “L”.

And forget about X.521, we’re not using it here, there’s no DIT, no object classes. We’re using X.509 certificates outside of the Big X.500 Directory, and not as an attribute of this Directory (it can be both).

===>In our cps, such as Public CA, we said

3.1.1 Types of Names

The PublicCA uses the X.500 Distinguished Name (DN) for the certificate subject name of issued certificates.

3.1.4 Rules for Interpreting Name Forms

The rules for interpreting name forms follow ITU-T X.520 name attribute definition.

As for the diagram taken from Annex B of ITU-T X.521, that is for discussion with Peter about two methods to interpret DN, then Peter's interpretation will let two different entities have the same Distinguished Name. And there is no similar diagram in X.520.

Cordialement,

Erwann Abalea

Li-Chun CHEN

                    Deputy Senior Engineer

                    CISSP, CISA, CISM, PMP,

                    Information & Communication Security Dept.

                    Data Communication Business Group

                    Chunghwa Telecom Co. Ltd.

                    realsky at cht.com.tw

From: Erwann Abalea [mailto:Erwann.Abalea at docusign.com] 
Sent: Saturday, July 16, 2016 4:04 AM
To: 陳立群
Cc: Ben Wilson; CABFPub
Subject: Re: [cabfpub] Suggestion to amend BR Section7.1.4.2.2d/e RE: EV Gudelines section 9.2.5 & X.520

Bonsoir,

About small countries that haven’t set up any state or province.

X.520 definition for the stateOrProvinceName attribute is (from 201210 edition):

The State or Province Name attribute type specifies a state or province. When used as a component of a directory name, it identifies a geographical subdivision in which the named object is physically located or with which it is associated in some other important way.

« Geographical subdivision » can mean anything. Maybe some would disagree, but I think that a CA can stretch it pretty easily while respecting the BRs.

If you want to follow the intent of the « province », since this latin-based word designates an administrative subdivision, it can even be a city or a village, and doesn’t necessarily mean a State in the US way. All the countries listed in Note 2 have cities.

About the uniqueness of an organizationName at a country level.

OV/IV certificates are not meant to unambiguously identify the subject named in the certificate. That role is left for EV certificates.

For example, in an IV certificate, there can be more than one individuals named John Malkovich, living in the same country, same province, same city. Only one of them will obviously be able to have the johnmalkoti.ch domain, if it exists (it doesn’t).

Talking about OV certificates, even if it’s not possible to have 2 companies with the same name in the same jurisdiction, it’s possible to have 2 certificates having the same name representing 2 different entities. For example « C=UT, ST=MyVillage, O=XXXX », if XXXX is both a company and a brand (DBA).

Combine OV and IV, and « C=UT, ST=MyVillage, O=XXXX » can represent 3 different things, if XXXX is also the full name of an individual and the CA chooses to place this full name in the O field instead of GN/SN. (for a country named Utopia)

The rule for an OV/IV is something like « if you can provide evidence of the claimed identity, it’s good ».

Again, if you want to disambiguate claimed identities, you’re free to add other attributes, or provide an EV certificate.

I don’t support the proposed BR changes, they only add complexity without any real benefit.

Looking at the example certificates:

*	certificate 1 is not problematic; if you want a less cluttered certificate, go for a DV; wether VA is really a country or not is left as an exercise (it’s a territory for me, but I’m not so difficult)
*	certificate 2 is not wrong per se; Taichung City being a geographical subdivision of Taiwan, an administrative division, and a city, it’s not wrong to have Taichung in both the ST and L attributes — second example is « ST=Taiwan, L=Kaohsiung »; Taiwan being a province of the Taiwan country, and Kaohsiung being a city, it’s not wrong
*	I think certificate 3 is also fine; Taiwan Province is a province of the country Taiwan (just like Fujian Province is also such a province), and Taipei is a locality; wether the real name is Taipei or Taipei City is another remark

You’re explaining your proposals by using « no need to put (some information) », or « registered in (somewhere) », but it’s not relevant here. The fact that a company is registered in a city shouldn’t prevent the CA from setting the postalCode or streetAddress attributes (it’s not wrong to set these attributes). And if you want to unambiguously identify the company « ABC Store » registered in Nantou County from the « ABC Store » registered in Taipei City, again, use an EV, that’s what they’re here for. This can raise some legitimate questions and necessary clarifications about the real content and hierarchy of jurisdiction*Name attributes, and it’s OK.

And forget about X.521, we’re not using it here, there’s no DIT, no object classes. We’re using X.509 certificates outside of the Big X.500 Directory, and not as an attribute of this Directory (it can be both).

Cordialement,

Erwann Abalea

Le 14 juil. 2016 à 11:51, 陳立群 <realsky at cht.com.tw> a écrit :

I did thank for Ben’ record of July 1’s Policy Review Working Group Call and Peter’s asking .

    Because there are two issues, I modify the subject to “Suggestion to amend BR Section7.1.4.2.2d/e”. 

    And left the second issue about EV Gudelines section 9.2.5 & X.520, RFC 5280 in RE: [cabfpub] EV Gudelines section 9.2.5 & X.520

To prevent presentation layout problem , I attached word and pdf version as attached file, and past as below for further discussion.   

   Amend of SSL BR section 7.1.4.2.2 d & e

Statement of intent:

In SSL BR section 7.1.4.2.2 d & e, either localityName or stateOrProvinceName is required for OV and IV SSL Certificates. As CABF Bugzilla – Bug#2  <https://bugzilla.cabforum.org/show_bug.cgi?id=2> https://bugzilla.cabforum.org/show_bug.cgi?id=2 , We amend section 7.1.4.2.2 d & e to solve below situations: 

(1). For small countries/jurisdictions, if they do not set up any state or province. Some CAs misplaced absence province or state name.  

(2). The organizationName is already unique at the country level. 

If the subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the subject:countryName field has a centralized registry for that kind of organizations so that the organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction. Those centralized registry databases are QGIS(Qualified Government Information Source, ) or QTIS(Qualified Government Tax Information Source) , and government law keep the organizations’ names are unique. [Note 1]

(3).In EU, "We found it is not suitable to enforce the CA to insert locality(L) or stateOrProvinceName(ST) into the subject DN in small country" remains still open as it is the same in other EU countries too. Please see  <https://portal.etsi.org/TBSiteMap/ESI/ESIActivities.aspx> https://portal.etsi.org//TBSiteMap/ESI/ESIActivities.aspx

a. ETSI EN 319 412-1 "Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures".

b. ETSI EN 319 412-3 "Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons".

C.319 412-4 v1.1.1: Certificate profile for web site certificates issued to organisations

The minimal set of Subject info for legal person in Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons

4.2.1 Subject

The subject field shall include at least the following attributes as specified in Recommendation ITU-T X.520 [1]:

• countryName;

• organizationName;

• organizationIdentifier; and

• commonName.

(4) There will be the possibilities of Distinguished Name collisions for different entities following current BR.

Table:   Proposed versions: 

SSL BR V1.3.4 

Proposed versions

7.1.4.2.2 Subject Distinguished Name Fields

d. Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present.

e. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if subject:organizationName and subject:localityName fields are present.

1.      Dr. Ben Wilson of DigiCert’s version

7.1.4.2.2 Subject Distinguished Name Fields

d.Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the country name provided under subsection g. is Taiwan (TW), Singapore (SG)[Note 2], etc..

e.Certificate Field:subject:stateOrProvinceName (OID: 2.5.4.8) 

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if: (a) subject:organizationName and subject:localityName fields are present, or (b) if the country name provided under subsection g. is Taiwan (TW), Singapore (SG), etc..

2.      Dr. Wen-Cheng Wang of Chunghwa Telecom’s Version

7.1.4.2.2 Subject Distinguished Name Fields

d. Certificate Field: subject:localityName (OID: 2.5.4.7) 

Required if the subject:organizationName field is present and the subject:stateOrProvinceName field is absent.

Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the subject:countryName field has a centralized registry for that kind of organizations so that the organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.

Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.

e.  Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8) 

Required if the subject:organizationName field is present and subject:localityName field is absent.

Optional if: (a) the subject:organizationName and subject:stateOrProvinceName fields are present, or (b) if the subject:organizationName and subject:countryName fields are present and the country/jurisdiction specified by the subject:countryName field has a centralized registry for that kind of organizations so that the organization name specified by the subject:organizationName field is "unique" in the entire country/jurisdiction.

Normally, situation (b) may exist in small countries/jurisdictions such as Singapore (SG), Taiwan (TW), etc.

Some problems if we don’t amend SSL BR and soultions:

1.      For a Symantec OV SSL Certificate that I found in  <https://mv.vatican.va/3_EN/pages/MV_Home.html> https://mv.vatican.va/3_EN/pages/MV_Home.html (with error message by browser for the FQDN in URL is not matched the Subject Alternative Name, *.catholica.va and catholica.va, in this SSL certificate)or you can see it in

 <https://crt.sh/?q=98+ef+2b+4c+43+39+ae+04+3b+bd+55+08+59+b2+b7+b4+ee+76+cb+af> https://crt.sh/?q=98+ef+2b+4c+43+39+ae+04+3b+bd+55+08+59+b2+b7+b4+ee+76+cb+af

Its Subject DN is 
commonName=*.catholica.va
organizationName=Department of Telecommunications
localityName=Vatican City
stateOrProvinceName=Vatican City State
countryName =VA

The subject DN should be 

commonName=*.catholica.va
organizationName=Department of Telecommunications
countryName =VA

It is enough to identify the domain name owner in Vatican.

Note that from  <http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/vatEn.pdf> http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/vatEn.pdf given by Peter Brown of Amazon

The Vatican uses an address format identical to that of Italy, except the province abbreviation, which is not used in the Vatican.

2.      A wildcard SSL certificate signed by GlobalSign at  <https://ebank.cotabank.com.tw/eBank/> https://ebank.cotabank.com.tw/eBank/, 

Its Subject DN is 

CN = *. <http://cotabank.com.tw/> cotabank.com.tw

O = COTA Commercial Bank

OU = ITDs

L = Taichung

S = Taichung

C = TW

But there is No Taichung Province or Taichung State in Taiwan, only Taichung city in Taiwan. 

I also mail to Doug of GlobalSign for below example, 

Kaohsiung city is also a special municipality as Taichung city. For a wildcard SSL Certificate for a bank as in  <https://accessible.bok.com.tw/> https://accessible.bok.com.tw/

Its Subject DN is 

CN = *. <http://bok.com.tw/> bok.com.tw

O = BANK OF KAOHSIUNG CO., LTD.

OU = MIS Dept.

L = Kaohsiung

S = Taiwan

C = TW

The rule by GlobalSign vetting team is not the same as in cotabank in Taichung city for BANK OF KAOHSIUNG CO., LTD. in Kaohsiung city.

Please also see the Taichung City Government English webpages in 

 <http://eng.taichung.gov.tw/mp.aspx?mp=1> http://eng.taichung.gov.tw/mp.aspx?mp=1 and Kaohsiung City Government English webpages in

 <http://www.kcg.gov.tw/EN/Index.aspx> http://www.kcg.gov.tw/EN/Index.aspx

These two city governments called them “City” not province. They are special municipalities, it is no need to put S=Taiwan. 

We think below DN should be suitable:

CN = *. <http://cotabank.com.tw/> cotabank.com.tw

O = COTA Commercial Bank

OU = ITDs

C = TW

CN = *. <http://bok.com.tw/> bok.com.tw

O = BANK OF KAOHSIUNG CO., LTD.

OU = MIS Dept.

C = TW

They can be simple and clear identify *. <http://bok.com.tw/> bok.com.tw’ and COTA Commercial Bank’s organization DNs follow our country’s law and x.520. 

3.      Another case is as  <https://www.ecover.com.tw/> https://www.ecover.com.tw/ issued by Comodo, 

CN =  <http://www.ecover.com.tw/> www.ecover.com.tw

OU = GlobalTrustSSLPro

OU = Provided by Global Digital Inc.

OU = MIS Dept

O = SOUTH CHINA INSURANCE CO., LTD.

STREET = 5F,No.560,Sec. 4,Chung Hsiao E Rd.,Taipei,Taiwan

L = Taipei

S = Taiwan

PostalCode = 110

C = TW

As Taipei City is a Municipality, we should not put S=Taiwan. Also for its address, you can see other example such as  <http://www.tcc.gov.tw/en/cp.aspx?n=BBF5C83DDCCEE939> http://www.tcc.gov.tw/en/cp.aspx?n=BBF5C83DDCCEE939 of Taipei City Council:

Copyright ©2013 Taipei City Council 
No.507, Sec. 4, Ren-ai Rd., Xinyi Dist., Taipei City 110, Taiwan (R.O.C.)
 <tel:(02)2729-7708> TEL:(02)2729-7708
Last Updated: 2016-05-16

No need to put Taiwan Province.

The DN follows the Taiwan’s company act and current BR should be

CN =  <http://www.ecover.com.tw/> www.ecover.com.tw

OU = GlobalTrustSSLPro

OU = Provided by Global Digital Inc.

OU = MIS Dept

O = SOUTH CHINA INSURANCE CO., LTD.

STREET = 5F,No.560,Sec. 4,Chung Hsiao E Rd., Taipei City ,Taiwan

L = Taipei City

PostalCode = 110

C = TW

But it may misinterpretate SOUTH CHINA INSURANCE CO., LTD as registered in Taipei City. So we suggest to modify SSL BR and use below DN

CN =  <http://www.ecover.com.tw/> www.ecover.com.tw

OU = GlobalTrustSSLPro

OU = Provided by Global Digital Inc.

OU = MIS Dept

O = SOUTH CHINA INSURANCE CO., LTD.

STREET = 5F,No.560,Sec. 4,Chung Hsiao E Rd., Taipei City ,Taiwan

PostalCode = 110

C = TW

Because from Note1, according Taiwan’s Company Act, the company name must be unique for the whole country. So we can omit the L = Taipei City. Also Taipei City appears in the Street field.

4.      On the other hand, in Taiwan, we have small businesses (such as stores, or as Business Entities as in EVGL) which is established and registered according to our Business Registration Act( <http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080004> http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080004, See Article 28). In Taiwan, small businesses is registered in municipal level. The Business Registration Law requires that the name of the small business must be unique with the municipality (that will be a city or a county) where it is registered.

For example, there might be a small business named "ABC Store" registered in Taipei City, while there might be another "ABC Store" registered in NantouCounty. 

Therefore, the suitable subject DN for these two small businesses will be “

CN=ABC Store’s FQDN 

O=ABC Store

L=Taipei City 

C=TW

and

CN=ABC Store’s FQDN

O=ABC Store

L=Nantou County

C=TW

respectively.

5. In X.520 or within a CA, A CA has to let different entities to have different Distinguished Name, different serial numbers and different key pairs. It is fundamental. For IV SSL certificate or citizen certificates, we can add unique serial number in Subject Distinguished Names to two different entities have the same names. (Peter Brown of Amazon in the discussion said EV SSL certificates solve the problem, but don’t forget that EV SSL Certificates will not be issued to individuals, only be issued to Private Organization, Government Entities, Business entities and non-profit international organizations.) 

For OV SSL certificates, we have explained that there are some other small countries or jurisdictions where stateOrProvinceName is not available and where companies is registered in the country level. 

In such situations, we do not think it is suitable to enforce the CA to insert locality(L) or stateOrProvinceName(ST) into the subject DN. 

Peter tended to interpret the current BR that the localityName and stateOrProvinceName attributes as identifying the subject’s address of existence or operation. However, to enforce this kind of interpretation and require the Subject DN must at least contain either the localityName and stateOrProvinceName attributes may cause problem in some situations as Dr. Wen-Cheng Wang’s email before, especially in some small country where organizations are allowed to be registered at country-level. 

For example, in Taiwan, a corporation can be registered at country-level but can also be register at city/county-level. If there is a country-level corporation named “Farmer’s Association” of which physical address is located in Taipei City, with current Subject DN rule of BR, its Subject DN will be “C=TW, L=Taipei City, O=Farmer’s Association”. However, if there is also a city/county-level “Farmer’s Association” in Taipei City, its Subject DN will also be “C=TW, L=Taipei City, O=Farmer’s Association”. How do you distinguish them by DN?

We do not understand why we need to enforce require the Subject DN must at least contain either the localityName and stateOrProvinceName attributes if the registered organizational name of a country-level corporation/organization is already guaranteed to be unique under the country name?

The following diagram is taken from Annex B of ITU-T X.521 (Suggested name form and Directory information tree structures). Please note path 1 -> 3, it suggests that there is no need to include a Locality attribute in the directory name of a country-level organization.

<image001.jpg>

Several CAs have issued certificates with countryName = TW where other subject attributes are incorrectly set. That’s because those CA don’t not consider the real situation, so they try to fill some attributes to fill the state=Taiwan or even state=Taichung.

Other Q & A

1.      In Bugzilla(CABF Bugzilla – Bug#2  <https://bugzilla.cabforum.org/show_bug.cgi?id=2> https://bugzilla.cabforum.org/show_bug.cgi?id=2) , Dimitris Zacharopoulos suggested that 

There are some countries that have a centralized registry for commercial companies which means that company names are "unique" in the entire country. 

The BR could address this issue in Section 7.1.4.2.2d/e and provide an exception for these cases. However, the CA's qualified auditors should verify that there is a single company naming registry in the entire country which forces uniqueness of company names. The Root programs could request a letter from the CA's auditors to verify this situation that would enable the exception.

Ans: I think the CA's qualified auditors will be glad to verify that there is a single company naming registry in the entire country which forces uniqueness of company names and offer the letter under request of Browser Root Certificate Program. Also I have showed the URL of Taiwan’s company act. Taiwan’s National Development Council asked Government PKI’s qualified auditors to join the F2F Meeting 39 in Redmond. Li-Chun CHEN has helped David of KPMG, Taiwan to join.

Below is website of Company Registration Database:

 <http://gcis.nat.gov.tw/mainNew/classNAction.do?method=list&pkGcisClassN=4,website> http://gcis.nat.gov.tw/mainNew/classNAction.do?method=list&pkGcisClassN=4,website of Importer registration system:https:// <http://fbfh.trade.gov.tw/rich/text/indexfbOL.asp> fbfh.trade.gov.tw/rich/text/indexfbOL.asp

2.      In CA/B Forum meeting of July 7th, Kirk asked if a general rule can be written rather than writing up a list of specific countries. Ben said that had not been discussed. 

Ans: What about discussion like the minimal set of Subject info for legal person in Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons? Or choose the edition from Ben or Wen-Cheng.

3.      In certificate Policy working Group, Ben offer discussion records between Peter Brown and Li-Chun CHEN as 

  <https://www.mail-archive.com/public@cabforum.org/msg01333.html> https://www.mail-archive.com/public@cabforum.org/msg01333.html

     Note that in RFC 3739 there are Qualified Certificates Profiles, In section 2.4.  Uniqueness of names:

   Distinguished name is originally defined in X.501 [X.501] as a
   representation of a directory name, defined as a construct that
   identifies a particular object from among a set of all objects.  The
   distinguished name MUST be unique for each subject entity certified
   by the one CA as defined by the issuer name field, for the whole life
   time of the CA.

For Taiwan’s Government PKI, there is a certificate and CRL profile as
 <http://grca.nat.gov.tw/download/GPKI_Cert_and_CRL_Profiles_v2.0.pdf> http://grca.nat.gov.tw/download/GPKI_Cert_and_CRL_Profiles_v2.0.pdf, we have this document around 14 years. Only that it is written in Tradition Chinese, not English. So we don’t think there are some issues that Peter said, like “For end-entity certificates in the WebPKI, as implemented, there is no requirement that different entities have different Subject values.”

4.     Doug Beattie said in Validation Working Group : I still think it would be a good idea to enumerate the entire list of Country codes where both stateOrProvinceName and localityName can be omitted so there is no confusion and compliance can be monitored.

5.      

Ans: I list all the Country Codes as in Note 2. But we have to consider it seems that some are not ISO 3166-1 code, some is ISO 3166-2 code. The original source is from   <https://www.drupal.org/node/636464> https://www.drupal.org/node/636464, and I check by web sites such as Wikipedia, those government sites,   <https://en.wikipedia.org/wiki/ISO_3166> https://en.wikipedia.org/wiki/ISO_3166and  <http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html> http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html. We hope more volunteers provide comments and advices.

[Note 1]: In Taiwan, according our Company Act, the company name must be unique for the whole country. Furthermore, Taiwan’s Company Act requires the company to register its business location which will be some city or county. 

In  <http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001> http://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001, 

Company Act article 18 , 

No company may use a corporate name which is identical with that of another company. Where the corporate names of two companies contain any marks or identifying words respectively that may distinguish the different categories of business of the two companies, such corporate names shall not be considered identical with each other.

A company may conduct any business that is not prohibited or restricted by the laws and regulations, except for those requiring special approvals which shall be explicitly described in the Articles of Incorporation of the company.

Any category of business to be conducted by a company shall, when making the registration thereof, be identified with the Category Code applicable to the said business category as assigned in the Table of Categories of Businesses by the central competent authority. For a company which has already been registered, and the category of business conducted by it is registered with descriptive words, then, such descriptive words shall be replaced with the applicable Category Code as assigned in the foregoing Table, while applying for alteration of the entries of existing company registration record.

A company shall not use a name which tends to mislead the public to associate it with the name of a government agency or a public welfare organization, or has an implication of offending against public order or good customs.

Before proceeding to the company incorporation registration procedure, a company shall first apply for approval and reservation, for a specific period of time, of its corporate name and the scope of its business. Rules for examination and approval of such application shall be prescribed by the central competent authority.

In Taiwan, since the company name must be unique for the whole country, the subject DN for a company, such as Chunghwa Telecom, should look like 

"C=TW, O=Chunghwa Telecom Co., Ltd

This subject DN already uniquely identifies the company. 

There is no necessary to add RDNs such as locality(L), or stateOrProvinceName(ST), Address (optional in BR) into the subject DN. 

If we specify the subject DN as "C=TW, L=Taipei City, O=Chunghwa Telecom Co., Ltd.", that will mean it is a company registered in Taipei City. This will not conform to our Company Law because companies in Taiwan is registered in the country level not in the municipal level.

[Note 2]:

Table:   Example of small countries/jurisdictions

 <https://en.wiktionary.org/wiki/ISO> ISO 3166  <https://en.wiktionary.org/wiki/country_code> country code

 <https://en.wiktionary.org/wiki/Bouvet_Island> Bouvet Island

BV

British Virgin Islands

VG

Christmas Island 

CX

Falkland Islands

FK

Faroe Islands

FO

French Guiana

GF

Gibraltar

 <https://en.wikipedia.org/wiki/ISO_3166-2:GI> GI

Guadeloupe

GP

Guam

GU

Guernsey

GG

Isle of Man 

IM

Jersey

JE

Lebanon

LB

Macedonia

MK

Martinique

MQ

Mayotte

YT

Montenegro

ME

Netherlands Antilles

AN

Niue

NU

Norfolk Island

NF

Palestinian Territory 

PS

Pitcairn

PN

Reunion

RE

Serbia

RS

Singapore 

SG

Slovenia 

SVN

South Georgia and the South Sandwich Islands

GS

Svalbard and Jan Mayen 

SJ

Taiwan

TW

Vatican

VA

Western Sahara 

EH

Sincerely Yours,

                    Li-Chun CHEN

                    Deputy Senior Engineer

                    CISSP, CISA, CISM, PMP,

                    Information & Communication Security Dept.

                    Data Communication Business Group

                    Chunghwa Telecom Co. Ltd.

                     <mailto:realsky at cht.com.tw> realsky at cht.com.tw

                    +886-2-2344-4820#4025

From: Ben Wilson [ <mailto:ben.wilson at digicert.com> mailto:ben.wilson at digicert.com] 
Sent: Saturday, July 02, 2016 2:40 AM
To: Erwann Abalea; 陳立群
Cc: CABFPub
Subject: RE: [cabfpub] EV Gudelines section 9.2.5 & X.520

To help this discussion along, here is a transcript of yesterday’s Policy Review Working Group meeting:

Li-Chun:  I would like to address the Subject Name issue and a new issue, which is the proprietary OID of Microsoft for jurisdiction of incorporation.  We feel we need to prepare a proposal to modify the EV Guidelines and allow CAs to modify their CPSs and internal programs to accommodate a non-proprietary OID.  And then on the first issue,  maybe we can find more examples, such as in Europe, of small countries with the subject name issue.  I don’t know why browsers reject the ballot.   I think that most of the CAs agree with the effort.  

Peter:  The EV OIDs for jurisdiction were created by Microsoft.  Microsoft allocated those OIDs out of their namespace  to the  EV program, correct?  

Li-Chun:  But in the EV Guidelines we said we are referencing with X.520.  They are just excluding the  BRs, such as country OID, state or province OID, and locality OID.  The BRs are accurate.  Our position is that those OIDs are not just  for physical address.  It’s also about jurisdiction, and X.520 is for the way we support the Distinguished Name.  We cannot sort different entities with the same Distinguished Name.  If you sync the register with the protocol and for the hierarchical structure.  Also, for example in RFC 3739 there are Qualified Certificates Profiles.  So there will be the serial number for individuals or for natural person and they can use it with an IV certificate, and also we use the serial number in the Subject Distinguished Name for our citizen certificate in Taiwan.  We just need to offer to better, one is for relief the registration for subject’s state or province and the locality for small countries, as we discussed previously.  

Another is the proprietary Microsoft OID.   The BRs state that for the state, province and locality OID.  And we will offer this in the mailing list in the future  in two weeks.  

Peter:  You’ve  raised several  good topics.  First, regarding what you’ve raised as the proprietary Microsoft OIDs, as I understand it, the definition of  a Subject Distinguished Name is a sequence of attributes  of  any type.  X.520 lists some attribute types, but it is  not an exclusive set.   Any organization can allocate new attribute types.  As part of the  development of the  EV specification, several new attribute types were defined.  This is similar to what countries do when they develop new attribute types for their certificates, which we’ve seen with things like electronic IDs in Europe, etc.  I am not familiar with the Taiwanese electronic ID standard, but it may use OIDs from its arc as well.  The question in the  EV Guidelines that I think is confusing, which I’d like to  see if we could clarify, are those OIDs from Microsoft where the content definition in them, that is the ASN.1 structure was defined as a reference to the data type that includes the phrase X.520, which is from RFC 5280.  It is not a reference to  X.520 itself.  Instead RFC 5280 uses the term X.520 itself.  So I can see how it is confusing.   Erwan posted a revision to the mailing list a version that did not use that  term.  Did Erwan’s email  make more sense?  Should we propose a ballot that  uses that  terminology instead?

Li-Chun:  We have seen that email, but  we think it is a proprietary OID.  We suggest that we use the OIDs in the Baseline Requirements and in X.520, country, state and locality.  

Peter:  I believe that all of the browsers have coded those other OIDs at this point.  So it would not be an EV certificate and the  browsers would not accept it as such without those OIDs that are underneath the  Microsoft OID arc.

Li-Chun:  We think the  browsers only put those OIDs printable chain in to appear when we click  on the  EV certificate’s detailed information.  So, those efforts will  be in CAs’ program to  change proprietary OID  to an X.520 OID.  I think they will not involve browsers.  I think we can discuss this topic further on the mailing list.

Peter:  Just to make sure I understand what you’re saying, your objection is to the inclusion of OIDs that are not covered in the X.520 document in the CA/B Forum standards?

Li-Chun:  Yes, and I will discuss this  with my colleagues,  and I think in the EV Guidelines we say they are from X.520, so we don’t want an X.520 and RFC 5280 … There are Microsoft registered proprietary OIDs.  So I think  several years ago they discussed this about the EV Guidelines and they follow the TOC for Microsoft’s suggestions for OIDs and nobody cared about this,  and now we find in an international environment we suggest that  we not use a proprietary OID.  

Peter: OK.  Now I believe on the other topic of Distinguished Names, Subject Contents, you sent the diagram from the X.500 series several times … I believe it is from X.521?   Your concern is that, as defined by the X.500 series, distinguished names should be part of a hierarchical tree.  So the challenge is that the CA/B Forum guidelines do not follow that because it is not possible to make a reasonable hierarchical tree with the distinguished names that are specified in the  guidelines.  For example, the  EV Guidelines require two entries that both require country names,  which therefore does not follow X.520. Is that correct?  

Li-Chun:  We want to  start discussing this problem in more countries like Taiwan or Singapore and so we don’t have the  state or province and we have a centralized database of government to let different companies will not have the  same company’s name.  We have an English version.  I have  referenced our Taiwan Companies Act, and there are those rules, and the Distinguished Name for the company certificate, we use either the state or province.  So we suggest that  we release the restrictions that  we have to put the  state or province for small countries.  Like Ben’s suggestion, we can list those country codes that don’t require the state or province.  For those companies, their distinguished name can just be, for example, C=TW, O=Chunghwa Telecom, and we need not put in L=Taipei City. 

Peter:  Li-Chun, are you using a standard in Taiwan, or is there something that  your CA complies with, where  you use the Distinguished Name that is present in your certificates in another context?  

Li-Chun:  We have a commercial CA and a government CA, and for those CAs with the Distinguished Name  we can distinguish in the whole country the jurisdiction.  We don’t need to put in a locality because of the X.520 hierarchy structure.  And we can distinguish the  company and we can guarantee that  they will  not have  the  same name.  So we will not put in the  locality.  I reference that in the email.

Peter:  So, what if all of the web browsers said, “we don’t care about X.520 and the hierarchy.  That is, we’re using X.509-formatted certificates, but the intent is not to  follow the  strict, direct hierarchy that is called out in some of the  other standards”?  Does that  conflict with other things that  you are required to  follow?

Li-Chun:  If for some reason you say you didn’t want to  follow X.520, but in the EV Guidelines you say you follow X.520, I see in RFC 5280, and Baseline Requirements, and the EV Guidelines all say we follow the  X.520 standard.   I don’t know why other CA/Browser Forum members would not want to follow.  Where we identify the subject’s identity,  we first have to check with the  government so that  we will  know it.  You  have to  consider the small country’s situation.  In America you  have  so many states, and you  can use those to  distinguish the English name, but in our  country, we rely on the  X.520 data.  I think  it is fundamental for each CA to distinguish their own subscribers’ identities.    We have to keep them distinguished if they have a different public key, a different subject distinguished name, and a different serial number.  We have to vet them to  prevent a collision problem.      

From:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org [ <mailto:public-bounces at cabforum.org> mailto:public-bounces at cabforum.org] On Behalf Of Erwann Abalea
Sent: Wednesday, June 29, 2016 10:02 AM
To: 陳立群 < <mailto:realsky at cht.com.tw> realsky at cht.com.tw>
Cc: CABFPub < <mailto:public at cabforum.org> public at cabforum.org>
Subject: Re: [cabfpub] EV Gudelines section 9.2.5 & X.520

Bonjour, 

I haven’t seen an authoritative definition of these 3 attributes, but always considered them the way Peter described them.

Maybe Microsoft should propose a clear definition, using the syntax from RFC5912, something like this:

id-MS-jurisdictionLocalityName OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 311 60 2 1 1 }

id-MS-jurisdictionStateOrProvinceName OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 311 60 2 1 2 }

id-MS-jurisdictionCountryName OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 311 60 2 1 3 }

at-jurisdictionCountryName ATTRIBUTE ::= {

  TYPE PrintableString (SIZE (2))

  IDENTIFIED BY id-MS-jurisdictionCountryName

}

at-jurisdictionStateOrProvinceName ATTRIBUTE ::= {

  TYPE DirectoryString {ub-state-name}

  IDENTIFIED BY id-MS-jurisdictionStateOrProvinceName

}

at-jurisdictionLocalityName ATTRIBUTE ::= {

  TYPE DirectoryString {ub-locality-name}

  IDENTIFIED BY id-MS-jurisdictionLocalityName

}

DirectoryString is also redefined in RFC5912 to have a size constraint.

Cordialement,

Erwann Abalea

Le 29 juin 2016 à 17:08, 陳立群 < <mailto:realsky at cht.com.tw> realsky at cht.com.tw> a écrit :

    In X.520 as attached file or RFC 5280( <https://tools.ietf.org/html/rfc5280> https://tools.ietf.org/html/rfc5280) , There are no jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), 

jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3).  You can use search function to search attached PDF file.  

These three OIDs are registered by Microsoft. Please see  <http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.1.html> http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.1.html,  <http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.2.html> http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.2.html and  <http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.3.html> http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.3.html

   Peter referenced EV GL 9.2.5 such as 

Naming attributes of type X520LocalityName

id-at-localityName      AttributeType ::= { id-at 7 }

     that id is 2.5.4.  

    But Country Name (2.5.4.6), State or Province Name (2.5.4.8) and  Locality Name (2.5.4.7) are appeared in X.520. 

Li-Chun CHEN

-----Original Message-----
From:  <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org [ <mailto:public-bounces at cabforum.org> mailto:public-bounces at cabforum.org] On Behalf Of Peter Bowen
Sent: Friday, June 17, 2016 4:52 AM
To: CABFPub
Subject: [cabfpub] EV Gudelines section 9.2.5 & X.520

On today’s validation working group call, there was a question about how X.520 related to the attributes defined in section 9.2.5 of the EV Guidelines.

This section says:

"Locality (if required):

subject:jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1) 

ASN.1 - X520LocalityName as specified in RFC 5280

State or province (if required):

subject:jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2)

ASN.1 - X520StateOrProvinceName as specified in RFC 5280 

Country:

subject:jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3) 

ASN.1 – X520countryName as specified in RFC 5280"

The ASN.1 definitions all reference RFC 5280 and are defined in Appendix A.  They are copied at the end of this email.  RFC 5280 also says " The DirectoryString type is defined as a choice of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString.  CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString”

Taken together, this means:

jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3) must be a PrintableString with two characters which together are a “alpha 2” code defined in ISO 3166 Part 1.

jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), if included, should be either a PrintableString or UTF8String and must contain at least 1 and not more than 128 characters.

jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), if included, shoud be either a PrintableString or UTF8String and must contain at least 1 and not more than 128 characters.

The appropriate values for these attributes, and when one needs to include the the latter two, is defined in section 9.2.5 as well.

Does this help clarify how these attributes work?

Thanks,

Peter

-- Naming attributes of type X520LocalityName

id-at-localityName      AttributeType ::= { id-at 7 }

-- Naming attributes of type X520LocalityName:

--   X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name))

--

-- Expanded to avoid parameterized type:

X520LocalityName ::= CHOICE {

      teletexString     TeletexString   (SIZE (1..ub-locality-name)),

      printableString   PrintableString (SIZE (1..ub-locality-name)),

      universalString   UniversalString (SIZE (1..ub-locality-name)),

      utf8String        UTF8String      (SIZE (1..ub-locality-name)),

      bmpString         BMPString       (SIZE (1..ub-locality-name)) }

-- Naming attributes of type X520StateOrProvinceName

id-at-stateOrProvinceName AttributeType ::= { id-at 8 }

-- Naming attributes of type X520StateOrProvinceName:

--   X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name))

--

-- Expanded to avoid parameterized type:

X520StateOrProvinceName ::= CHOICE {

      teletexString     TeletexString   (SIZE (1..ub-state-name)),

      printableString   PrintableString (SIZE (1..ub-state-name)),

      universalString   UniversalString (SIZE (1..ub-state-name)),

      utf8String        UTF8String      (SIZE (1..ub-state-name)),

      bmpString         BMPString       (SIZE (1..ub-state-name)) }

-- Naming attributes of type X520countryName (digraph from IS 3166)

id-at-countryName       AttributeType ::= { id-at 6 }

X520countryName ::=     PrintableString (SIZE (2))

-- Upper Bounds

ub-locality-name INTEGER ::= 128

ub-state-name INTEGER ::= 128

_______________________________________________

Public mailing list

 <mailto:Public at cabforum.org> Public at cabforum.org

 <https://cabforum.org/mailman/listinfo/public> https://cabforum.org/mailman/listinfo/public

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 

Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

<T-REC-X.520-201210-I!!PDF-E.pdf>_______________________________________________
Public mailing list
 <mailto:Public at cabforum.org> Public at cabforum.org
 <https://cabforum.org/mailman/listinfo/public> https://cabforum.org/mailman/listinfo/public

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 

Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

<Suggestion-to-BR-Section7.1.4.2.2de.docx><Suggestion-to-BR-Section7.1.4.2.2de.pdf>_______________________________________________
Public mailing list
 <mailto:Public at cabforum.org> Public at cabforum.org
 <https://cabforum.org/mailman/listinfo/public> https://cabforum.org/mailman/listinfo/public

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160720/5fb7bef2/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: replying to Erwann-2016July.pdf
Type: application/pdf
Size: 236672 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160720/5fb7bef2/attachment-0003.pdf>