[cabf_validation] [cabfcert_policy] Amend BR subsections 7.1.4.2.2 d/e
Peter Bowen
pzb at amzn.com
Wed Jun 29 11:56:10 MST 2016
(adding public@ as this has broad impact)
> On Jun 29, 2016, at 9:05 AM, 陳立群 <realsky at cht.com.tw> wrote:
>
> Dear Peter,
>
> In X.520 or within a CA, we have to let different entities to have different Distinguished Name and different key pairs. It is fundamental.
So I think this is where there is a fundamental disconnect. For end-entity certificates in the WebPKI, as implemented, there is no requirement that different entities have different Subject values. This is because the WebPKI has effectively co-opted the subject field to be used to contain certain data about the Subscriber. It is very possible that two subscribers have the same attributes. Now maybe this was a poor decision, but it is the current state.
It might be worth considering specifying a subject alternative name type (specifically an new type of other name) to store the required subscriber details instead of overloading the Subject — this would allow the Subject to used as you (and many others) want. The new name type could store the offline identity information about the subscriber, including the attributes required by EV. This might help not only your use case but also other eID and federated PKI use cases.
Thanks,
Peter
> 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.)
>
> For OV SSL certificates, we have explained that
> there are some other small countries 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.
>
> We know that you tends 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.png>
>
> Several CAs have issued certificates with countryName = TW where other subject attributes are incorrectly set. That’s because current CA not consider the real situation, so they try to fill some attributes to fill the state=Taiwan.
>
> In Taiwan’s Government, they have a site oid.nat.gov.tw, there are lots of DN for government entities, schools, Freelance Firm and Foundation there. For companies, moeaca.nat.gov.tw issues lots of certificates and private keys stored in IC card, Ministry of Economic Affairs have set up lots of DN in the LDAP.
>
> If a business entity ( store) in Taiwan, it needs locality in Subject DN, they should be C=TW then the stateOrProvinceName should be omitted:
>
> L=Kaohsiung City
> L=New Taipei City
> L=Taichung City
> L=Tainan City
> L=Taipei City
> L=Taoyuan City
>
> L=Chiayi City
> L=Hsinchu City
> L=Keelung City
>
> L=Changhua County
> L=Chiayi County,
> L=Hsinchu County
> L=Hualien County
> L=Kinmen County
> L=Lienchiang County
> L=Miaoli County
> L=Nantou County
> L=Penghu County
> L=Pingtung County
> L=Taitung County
> L=Yilan County
> L=Yunlin County
>
> But if it is a company, as previous email they only needs to be C=TW, O=xxx company in Taiwan.
>
> 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 removeed the "community" status, and the Taiwan provincial government degenerate reorganized as an agency of Executive Yuan. ) So in government entity’s or business entities’s DN such as certificates published in gca.nat.gov.tw or moeaca.nat.gov.tw,no s=Taiwan.
>
> Li-Chun CHEN
>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb at amzn.com]
> Sent: Saturday, June 25, 2016 3:49 AM
> To: 陳立群
> Cc: Tim Hollebeek; Dimitris Zacharopoulos; 王文正; policyreview at cabforum.org; validation at cabforum.org; Dean Coclin; Rob Stradling; Kirk Hall
> Subject: Re: [cabf_validation] [cabfcert_policy] Amend BR subsections 7.1.4.2.2 d/e
>
> Li-Chun,
>
> I think you are hitting on two different issues.
>
> #1: "The issue now we want to solve is that how to simply and uniquely to identify an applicant’s identity”
>
> OV and IV certificates do not _uniquely_ identify an applicant’s identity. As you have pointed out, there is the very real possibility that two distinct applicants will have the same subject in an OV or IV certificate. This issue is not limited to Taiwan, it is a worldwide issue. EV solves this by presuming that names are unique within a given namespace and defining the namespace within the subject. If you want you can use these fields in OV certificates, but there is no requirement to do so.
>
> I would not support a change to OV/IV to uniquely identify an applicant at the expense of specifying applicant address, but others might.
>
> #2: Several CAs have issued certificates with countryName = TW where other subject attributes are incorrectly set. As you point out this is a problem. It does not require BR changes, as this is already incorrect and not allowed. From my research, it looks like the following should be currently true for C=TW:
>
> If one of the following is in the localityName field, then the stateOrProvinceName should be omitted:
> Kaohsiung, New Taipei, Taichung, Tainan, Taipei, Taoyuan, Chiayi, Hsinchu, or Keelung
>
> Otherwise, one of the following should be located in the stateOrProvinceName and the city or township should be provided in the localityName attribute:
> Changhua, Chiayi, Hsinchu, Hualien, Kinmen, Lienchiang, Miaoli, Nantou, Penghu, Pingtung, Taitung, Yilan, or Yunlin
>
> Is this accurate?
>
> Thanks,
> Peter
>
>
>
> > On Jun 24, 2016, at 4:02 AM, 陳立群 <realsky at cht.com.tw> wrote:
> >
> > Dear Peter,
> >
> > 1. The problem we want to solve is not how to find the applicant's physical location. In SSL BR Section 3.2.2.1. as below, there are methods to verify, especially by A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition and there are a reliable database such as a Qualified Government Information Source for the vetting team.
> >
> > Section 3.2.2.1. Identity
> > If the Subject Identity Information is to include the name or address
> > of an organization, the CA SHALL verify the identity and address of
> > the organization and that the address is the Applicant’s address of
> > existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:
> > 1. A government agency in the jurisdiction of the Applicant’s legal
> > creation, existence, or recognition; 2. A third party database that is
> > periodically updated and considered a Reliable Data Source; 3. A site
> > visit by the CA or a third party who is acting as an agent for the CA; or 4. An Attestation Letter.
> > The CA MAY use the same documentation or communication described in 1
> > through 4 above to verify both the Applicant’s identity and address.
> > Alternatively, the CA MAY verify the address of the Applicant (but not
> > the identity of the Applicant) using a utility bill, bank statement,
> > credit card statement, government‐issued tax document, or other form of identification that the CA determines to be reliable.
> >
> > 2. The issue now we want to solve is that how to simply and uniquely to identify an applicant’s identity follow the country’s law and X.520. We found it is not suitable to enforce the CA to insert locality(L) or stateOrProvinceName(ST) into the subject DN in small country.
> >
> > 3. Please see X.520 as attached file,
> >
> > 6.3.1 Country Name
> > The Country Name attribute type specifies a country. When used as a
> > component of a directory name, it identifies the country in which the named object is physically located or with which it is associated in some other important way.
> >
> > 6.3.2 Locality Name
> > The Locality Name attribute type specifies a locality. When used as a
> > component of a directory name, it identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way.
> >
> > 6.3.3 State or Province Name
> > 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.
> >
> > For these red color sentences, they means that some of Country Name (2.5.4.6), State or Province Name (2.5.4.8), Locality Name (2.5.4.7) attributes such as Jurisdiction of Incorporation of Country, State or Province or Locality can be used to narrow down the naming space so that we can distinguish some entity from others within the naming space. Note that the meaning of "narrowing down naming space into some region of the county" is not always the same with the meaning of "being located at some region of the county".
> >
> > In Taiwan, according our Company Act, the company name must be unique for the whole country. Furthermore, our Company Law 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,
> >
> > 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.
> >
> > 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, 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 “ C=TW, L=Taipei City, O=ABC Store" and “ C=TW, L=Nantou County,
> > O=ABC Store" respectively.
> >
> >
> > We believe that there are also some other small countries 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.
> >
> > 4. When the Subject’s country does not have State/Province political subdivisions, the organization is chartered or operated at the national level, or other similar situations. Examples discussed in F2F Meeting 37 as the minutes included: U.S. Government entities, entities in Singapore, Taiwan, Greece, Vatican City, etc.
> >
> >
> > We found a wildcard SSL certificate signed by GlobalSign at
> > https://ebank.cotabank.com.tw/eBank/,
> >
> > The Subject DN is
> >
> > CN = *.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 for below example, Kaohsiung city is also a
> > special municipality like Taichung city. For a wildcard SSL
> > Certificate as in https://accessible.bok.com.tw/
> >
> > CN = *.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 Kaohsiung.
> >
> > Please also see the Taichung City Government English webpages in
> > http://eng.taichung.gov.tw/mp.aspx?mp=1 and Kaohsiung City Government
> > English webpages in http://www.kcg.gov.tw/EN/Index.aspx
> >
> > These two city governments called them “City” not province.
> >
> > We think below DN should be suitable:
> >
> > CN = *.bok.com.tw
> > O = BANK OF KAOHSIUNG CO., LTD.
> > OU = MIS Dept.
> > C = TW
> >
> >
> > CN = *.cotabank.com.tw
> > O = COTA Commercial Bank
> > OU = ITDs
> > C = TW
> >
> > They can be simple and clear identify *.bok.com.tw’ and COTA Commercial Bank’s organization DNs follow our country’s law and x.520.
> >
> > Another cas is as https://www.ecover.com.tw/ issued by Comodo,
> >
> > CN = 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
> >
> > But a proper DN should be
> >
> > CN = 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
> >
> > As Taipei City is a Municipality. Also for address, you can see other example such as 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
> > Last Updated: 2016-05-16
> >
> > No Taiwan Province.
> >
> >
> > 5. we would like to suggest CAB Forum to relief the rule of subject DN.
> > At least, the BR should allow the CA to not insert locality(L) or stateOrProvinceName(ST) into the subject DN if the organizationName is already unique at the country level.
> > The current BR rule of subject DN require countryName must be present if the organizationName is present.
> >
> > For peter’s replying about Dr. Wen-Cheng Wang’s example about A: You do not distinguish them by DN if there is no Postal Code or Jurisdiction of Incorporation information in the DN. I think peter’s thought does not solve the problem. As the streetAddress (OID: 2.5.4.9) or postalCode (OID: 2.5.4.17) are optional in BR. For example, the OV SSL certificate by Symantec in https://www.amazon.com/
> >
> > CN = www.amazon.com
> > O = Amazon.com, Inc.
> > L = Seattle
> > S = Washington
> > C = US
> >
> > 6. Certificate Policy Working Group has been discussed above issue, Ben has put them in
> > CABF Bugzilla – Bug#2 https://bugzilla.cabforum.org/show_bug.cgi?id=2
> > and discussed the issues in Policy Review Working Group Call.
> >
> >
> > In Bugzilla, 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.
> >
> > Ben suggested that
> >
> > We could amend subsections 7.1.4.2.2d/e to say:
> >
> > 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), 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..
> >
> > Dr. Wen-Cheng Wang of Chunghwa Telecom, suggested to amend subsections 7.1.4.2.2 d/e as below:
> >
> > 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.
> >
> > I suggest to discuss about Ben or Wen-Cheng’s suggestion and finally prepare a ballot.
> >
> > Sincerely Yours,
> >
> > Li-Chun CHEN
> >
> > -----Original Message-----
> > From: validation-bounces at cabforum.org
> > [mailto:validation-bounces at cabforum.org] On Behalf Of Peter Bowen
> > Sent: Saturday, June 04, 2016 11:03 AM
> > To: Tim Hollebeek; Dimitris Zacharopoulos; 王文正
> > Cc: policyreview at cabforum.org; validation at cabforum.org; Dean Coclin;
> > Rob Stradling; Kirk Hall
> > Subject: Re: [cabf_validation] [cabfcert_policy] Amend BR subsections
> > 7.1.4.2.2 d/e
> >
> > It seems like there is some confusion about the attributes that can go in a Subject Distinguished Name for a server authentication (“SSL”) certificate.
> >
> > Country Name (2.5.4.6), State or Province Name (2.5.4.8), Locality Name (2.5.4.7), and Postal Code (2.5.4.17) are used to include a physical location of the entity. State or Province Name, Locality Name, and Postal Code are best determined by checking with the Designated Operator listed by the Universal Postal Union (UPU) for the country in question. If the country in not a UPU member, then the CA will need to identify the equivalent operator to determine appropriate content for the two fields.
> >
> > On the other hand, Jurisdiction of Incorporation Country Name (1.3.6.1.4.1.311.60.2.1.3), Jurisdiction of Incorporation State or Province Name (1.3.6.1.4.1.311.60.2.1.2), and Jurisdiction of Incorporation Locality Name (1.3.6.1.4.1.311.60.2.1.1) are used to indicate where the entity is registered. If the entity is registered at the country level, then only Jurisdiction of Incorporation Country Name will be in the certificate. However if it is registered at a subdivision level, the the Jurisdiction of Incorporation State or Province Name and/or Jurisdiction of Incorporation Locality Name will be present.
> >
> > To address the question asked directly:
> >
> > Q: 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?
> >
> > A: You do not distinguish them by DN if there is no Postal Code or Jurisdiction of Incorporation information in the DN.
> >
> > As for how to handle Singapore, Monaco, and other city-states, one only needs to look to the UPU Postal addressing systems guide.
> >
> > Singapore:
> > http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/
> > sgpEn.pdf
> > Monaco: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/mcoEn.pdf
> > Vatican City: http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/vatEn.pdf
> >
> > All clearly show the name appearing both as the country and as a state/province/locality. Other small countries such as Malta, San Marino, and Bahrain clearly are listed as having multiple localities.
> >
> > For Taiwan, you seem to agree there is not an issue with finding an appropriate locality. "But I have to say that 高雄市 (or Kaohsiung) should be in the localityName field” makes it clear that there are localities.
> >
> > Based on this, I do not see any need to change the BRs.
> >
> > Thanks,
> > Peter
> >
> > > On Jun 3, 2016, at 4:18 PM, Tim Hollebeek <THollebeek at trustwave.com> wrote:
> > >
> > > These are generally less of a problem as they have a physical location (Department of Education, Washington, DC, US).
> > >
> > > Just because an entity is registered at the federal level doesn't mean it doesn't have a locality or state.
> > > From: policyreview-bounces at cabforum.org
> > > <policyreview-bounces at cabforum.org> on behalf of Dimitris
> > > Zacharopoulos <jimmy at it.auth.gr>
> > > Sent: Friday, June 3, 2016 1:46:52 PM
> > > To: Doug Beattie
> > > Cc: policyreview at cabforum.org; 王文正; validation at cabforum.org; Dean
> > > Coclin; Rob Stradling; Kirk Hall; Rick Andrews
> > > Subject: Re: [cabfcert_policy] [cabf_validation] Amend BR
> > > subsections
> > > 7.1.4.2.2 d/e
> > >
> > > I think all countries have some kind of central registry for some type of organizations (eg Universities, federal services). How should we handle these cases?
> > >
> > > DZ.
> > >
> > >
> > >
> > > On 3 Ιουν 2016, at 14:12, Doug Beattie <doug.beattie at globalsign.com> wrote:
> > >
> > >> To summarize, you’re saying you must have Country and Organization and that you must have stateOrProvinceName and/or localityName unless < you reason>, in which case both stateOrProvinceName and localityName can be omitted.
> > >>
> > >> Where <your reason> is: 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
> > >>
> > >> You have one small copy/past issue in your recommendation, but I understand what you meant.
> > >>
> > >> During the call yesterday we also discussed listing all of the countries where this is the case. You listed about 31 countries with no stateOrProvinceName, but it’s not clear which of these also have no localityName, just the 3 in red? 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.
> > >>
> > >> Doug
> > >>
> > >> From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of ???
> > >> Sent: Friday, June 3, 2016 6:56 AM
> > >> To: 'Rick Andrews' <Rick_Andrews at symantec.com>; 'Jeremy Rowley'
> > >> <jeremy.rowley at digicert.com>;validation at cabforum.org; Peter Bowen
> > >> <pzb at amzn.com>; 'Rob Stradling'
> > >> <rob.stradling at comodo.com>;policyreview at cabforum.org
> > >> Cc: Dean Coclin <Dean_Coclin at symantec.com>; 王文正
> > >> <wcwang at cht.com.tw>; Kirk Hall <Kirk.Hall at entrust.com>
> > >> Subject: [cabf_validation] Amend BR subsections 7.1.4.2.2 d/e
> > >>
> > >> Dear All,
> > >>
> > >> As yesterday’s validation working group phone call discussion about DN in small countries such as Singapore and Taiwan. I resend some discussions after Certificate Policy working group mailing list phone call, Bugzilla and discussion in 33rd F2F meeting (as attached file) as below.
> > >> After discussions, we will write a pre-ballot to fix the issue.
> > >>
> > >> We suggest to amend BR 7.1.4.2.2 d/e.
> > >>
> > >> Li-Chun CHEN 2016-02-05 01:29:17 MST After discussion in Chunghwa
> > >> Telecom, Dr. Wen-Cheng Wang suggests to amend subsections 7.1.4.2.2 d/e as below:
> > >>
> > >> 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.
> > >>
> > >> As for Peter, he e-mailed that I think there is a
> > >> misunderstanding. The address represented in the certificate by the plain localityName and stateOrProvinceName attributes is the Applicant’s address of existence or operation, not their jurisdiction of incorporation. The BRs note that a utility bill or bank statement can be used to verify the address.
> > >>
> > >> For example, https://crt.sh/?id=11206357&opt=cablint shows that the FQDN is www.fenton.com.tw. The contact information provided on the website (http://www.fenton.com.tw/index.php?route=information/contact) is 高雄市新興區民權一路251號24樓之2. Assuming you verify that this is the address of the applicant, then you could include 高雄市 (or Kaohsiung) in the localityName or stateOrProvinceName field.
> > >>
> > >> I don’t think there is any need to update the BRs for this case.
> > >>
> > >>
> > >> But I have to say that 高雄市 (or Kaohsiung) should be in the localityName field. There is no State or Province in Taiwan for高雄市(or Kaohsiung).
> > >>
> > >> And Dr. Wen-Cheng Wang has replied to Peter as below:
> > >>
> > >> We know that the current BR tends to interpret 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, 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?
> > >>
> > >> I 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.png>
> > >>
> > >>
> > >> Sincerely Yours,
> > >>
> > >> Li-Chun CHEN
> > >> Chunghwa Telecom Co. Ltd.
> > >>
> > >>
> > >>
> > >> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
> > >> 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.
> > >>
> > >>
> > >> _______________________________________________
> > >> Policyreview mailing list
> > >> Policyreview at cabforum.org
> > >> https://cabforum.org/mailman/listinfo/policyreview
> > >
> > >
> > > This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
> > > _______________________________________________
> > > Policyreview mailing list
> > > Policyreview at cabforum.org
> > > https://cabforum.org/mailman/listinfo/policyreview
> >
> > _______________________________________________
> > Validation mailing list
> > Validation at cabforum.org
> > https://cabforum.org/mailman/listinfo/validation
> >
> > 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
> > 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>
>
> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
> 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.
More information about the Validation
mailing list