<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>FYI:</p>
<p>1. ETSI EN 319 412-1 "Electronic Signatures and Infrastructures
(ESI); Certificate Profiles; Part 1: Overview and common data
structures".<br>
</p>
<p>2. ETSI EN 319 412-3 "Electronic Signatures and Infrastructures
(ESI); Certificate Profiles; Part 3: Certificate profile for
certificates issued to legal persons".<br>
</p>
Thanks,<br>
M.D.<br>
<br>
<div class="moz-cite-prefix">On 7/1/2016 11:34 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvaEPmTEdNyB_XML12tQdeig_=y=H7q52jv1OVFcPQo2nA@mail.gmail.com"
type="cite">
<div dir="ltr">This is extremely, extremely valuable Ben. I want
to personally thank you for the time and detail put into this.
<div><br>
</div>
<div>I'm not sure how to productively move the discussion
forward, but want to echo support for Peter's explanation, and
on the objectives of Li-Chun with naming, indicate that we
don't feel it would be appropriate or necessary to introduce
new OID arcs for EV attributes, and would in fact be
detrimental to the ecosystem. As such, unless new information
is shared to further understand the objective, we'd vote no on
any such ballot.</div>
<div><br>
</div>
<div>Similarly, I heartily agree with Peter's explanation - the
X.500 hierarchy of uniqueness is not a thing that the PKI
ecosystem reflects nor can enforce. As such, we do not see
there being a requirement for a global uniqueness of subject
names, because such global uniqueness requires centralized
registry coordination, and such a thing is not possible with
the WebPKI (recall, this is one of the many failures of X.500,
not strengths)</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jul 1, 2016 at 11:39 AM, Ben
Wilson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ben.wilson@digicert.com" target="_blank">ben.wilson@digicert.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">To
help this discussion along, here is a transcript of
yesterday’s Policy Review Working Group meeting:</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal">Peter: The EV OIDs for
jurisdiction were created by Microsoft. Microsoft
allocated those OIDs out of their namespace to the
EV program, correct? </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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? </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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? </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="m_-5792419369975293501__MailEndCompose"><span
style="font-size:11.0pt"> </span></a></p>
<span></span>
<div>
<div style="border:none;border-top:solid #e1e1e1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt">From:</span></b><span
style="font-size:11.0pt"> <a
moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a></a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Erwann Abalea<br>
<b>Sent:</b> Wednesday, June 29, 2016 10:02 AM<br>
<b>To:</b> </span><span
style="font-size:11.0pt;font-family:"MS
Gothic"">陳立群</span><span
style="font-size:11.0pt"> <<a
moz-do-not-send="true"
href="mailto:realsky@cht.com.tw"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:realsky@cht.com.tw">realsky@cht.com.tw</a></a>><br>
<b>Cc:</b> CABFPub <<a moz-do-not-send="true"
href="mailto:public@cabforum.org"
target="_blank">public@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabfpub] EV Gudelines
section 9.2.5 & X.520</span></p>
</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal">Bonjour, </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I haven’t seen an
authoritative definition of these 3 attributes,
but always considered them the way Peter
described them.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Maybe Microsoft should
propose a clear definition, using the syntax
from RFC5912, something like this:</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">id-MS-jurisdictionLocalityName
OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 311 60 2 1
1 }</p>
</div>
<div>
<p class="MsoNormal">id-MS-jurisdictionStateOrProvinceName
OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 311 60 2 1
2 }</p>
</div>
<div>
<p class="MsoNormal">id-MS-jurisdictionCountryName
OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 311 60 2 1
3 }</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">at-jurisdictionCountryName
ATTRIBUTE ::= {</p>
</div>
<div>
<p class="MsoNormal"> TYPE PrintableString
(SIZE (2))</p>
</div>
<div>
<p class="MsoNormal"> IDENTIFIED BY
id-MS-jurisdictionCountryName</p>
</div>
<div>
<p class="MsoNormal">}</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">at-jurisdictionStateOrProvinceName
ATTRIBUTE ::= {</p>
</div>
<div>
<p class="MsoNormal"> TYPE DirectoryString
{ub-state-name}</p>
</div>
<div>
<p class="MsoNormal"> IDENTIFIED BY
id-MS-jurisdictionStateOrProvinceName</p>
</div>
<div>
<p class="MsoNormal">}</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">at-jurisdictionLocalityName
ATTRIBUTE ::= {</p>
</div>
<div>
<p class="MsoNormal"> TYPE DirectoryString
{ub-locality-name}</p>
</div>
<div>
<p class="MsoNormal"> IDENTIFIED BY
id-MS-jurisdictionLocalityName</p>
</div>
<div>
<p class="MsoNormal">}</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">DirectoryString is also
redefined in RFC5912 to have a size constraint.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Cordialement,</p>
</div>
<div>
<p class="MsoNormal">Erwann Abalea</p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Le 29 juin 2016 à
17:08, <span style="font-family:"MS
Gothic"">陳立群</span> <<a
moz-do-not-send="true"
href="mailto:realsky@cht.com.tw"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:realsky@cht.com.tw">realsky@cht.com.tw</a></a>>
a écrit :</p>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> In X.520
as attached file or RFC 5280(<a
moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc5280"
target="_blank"><a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc5280">https://tools.ietf.org/html/rfc5280</a></a>)
, There are no
jurisdictionLocalityName (OID:
1.3.6.1.4.1.311.60.2.1.1), </span></p>
</div>
<div>
<p class="MsoNormal"><span>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. </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<p style="text-indent:12.0pt"><span>These
three OIDs are registered by
Microsoft. Please see <a
moz-do-not-send="true"
href="http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.1.html"
target="_blank"><a class="moz-txt-link-freetext" href="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</a></a>,
<a moz-do-not-send="true"
href="http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.2.html"
target="_blank">http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.2.html</a>
and <a moz-do-not-send="true"
href="http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.3.html"
target="_blank">http://www.alvestrand.no/objectid/1.3.6.1.4.1.311.60.2.1.3.html</a>
</span></p>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> Peter
referenced EV GL 9.2.5 such as </span></p>
</div>
<div>
<p class="MsoNormal"><span>Naming
attributes of type X520LocalityName</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>id-at-localityName
AttributeType ::= { id-at 7 }</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> that id
is 2.5.4. </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> 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. </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<p style="text-indent:42.0pt"><span>Li-Chun
CHEN</span></p>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<table border="0" cellpadding="0"
cellspacing="5">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt
.75pt">
<p style="text-indent:6.0pt"><span
style="font-family:"Times
New Roman",serif"> </span></p>
</td>
</tr>
</tbody>
</table>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>-----Original
Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">mailto:public-bounces@cabforum.org</a>]
On Behalf Of Peter Bowen<br>
Sent: Friday, June 17, 2016 4:52 AM<br>
To: CABFPub<br>
Subject: [cabfpub] EV Gudelines
section 9.2.5 & X.520</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>On today</span><span
style="font-family:"Courier
New"">’</span><span>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.</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>This section
says:</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>"Locality (if
required):</span></p>
</div>
<div>
<p class="MsoNormal"><span>subject:jurisdictionLocalityName
(OID: 1.3.6.1.4.1.311.60.2.1.1) </span></p>
</div>
<div>
<p class="MsoNormal"><span>ASN.1 -
X520LocalityName as specified in RFC
5280</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>State or
province (if required):</span></p>
</div>
<div>
<p class="MsoNormal"><span>subject:jurisdictionStateOrProvinceName
(OID: 1.3.6.1.4.1.311.60.2.1.2)</span></p>
</div>
<div>
<p class="MsoNormal"><span>ASN.1 -
X520StateOrProvinceName as specified
in RFC 5280 </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Country:</span></p>
</div>
<div>
<p class="MsoNormal"><span>subject:jurisdictionCountryName
(OID: 1.3.6.1.4.1.311.60.2.1.3) </span></p>
</div>
<div>
<p class="MsoNormal"><span>ASN.1 </span><span
style="font-family:"Courier
New"">–</span><span>
X520countryName as specified in RFC
5280"</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>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</span><span
style="font-family:"Courier
New"">”</span><span></span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Taken
together, this means:</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>jurisdictionCountryName
(OID: 1.3.6.1.4.1.311.60.2.1.3) must
be a PrintableString with two
characters which together are a </span><span
style="font-family:"Courier
New"">“</span><span>alpha 2</span><span
style="font-family:"Courier
New"">”</span><span> code
defined in ISO 3166 Part 1.</span></p>
</div>
<div>
<p class="MsoNormal"><span>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.</span></p>
</div>
<div>
<p class="MsoNormal"><span>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.</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>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.</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Does this
help clarify how these attributes
work?</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Thanks,</span></p>
</div>
<div>
<p class="MsoNormal"><span>Peter</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Naming
attributes of type X520LocalityName</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>id-at-localityName
AttributeType ::= { id-at 7 }</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Naming
attributes of type X520LocalityName:</span></p>
</div>
<div>
<p class="MsoNormal"><span>--
X520LocalityName ::= DirectoryName
(SIZE (1..ub-locality-name))</span></p>
</div>
<div>
<p class="MsoNormal"><span>--</span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Expanded
to avoid parameterized type:</span></p>
</div>
<div>
<p class="MsoNormal"><span>X520LocalityName
::= CHOICE {</span></p>
</div>
<div>
<p class="MsoNormal"><span>
teletexString TeletexString
(SIZE (1..ub-locality-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
printableString PrintableString
(SIZE (1..ub-locality-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
universalString UniversalString
(SIZE (1..ub-locality-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
utf8String UTF8String
(SIZE (1..ub-locality-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
bmpString BMPString
(SIZE (1..ub-locality-name)) }</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Naming
attributes of type
X520StateOrProvinceName</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>id-at-stateOrProvinceName
AttributeType ::= { id-at 8 }</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Naming
attributes of type
X520StateOrProvinceName:</span></p>
</div>
<div>
<p class="MsoNormal"><span>--
X520StateOrProvinceName ::=
DirectoryName (SIZE
(1..ub-state-name))</span></p>
</div>
<div>
<p class="MsoNormal"><span>--</span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Expanded
to avoid parameterized type:</span></p>
</div>
<div>
<p class="MsoNormal"><span>X520StateOrProvinceName
::= CHOICE {</span></p>
</div>
<div>
<p class="MsoNormal"><span>
teletexString TeletexString
(SIZE (1..ub-state-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
printableString PrintableString
(SIZE (1..ub-state-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
universalString UniversalString
(SIZE (1..ub-state-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
utf8String UTF8String
(SIZE (1..ub-state-name)),</span></p>
</div>
<div>
<p class="MsoNormal"><span>
bmpString BMPString
(SIZE (1..ub-state-name)) }</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Naming
attributes of type X520countryName
(digraph from IS 3166)</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>id-at-countryName
AttributeType ::= { id-at 6 }</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>X520countryName
::= PrintableString (SIZE (2))</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>-- Upper
Bounds</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>ub-locality-name
INTEGER ::= 128</span></p>
</div>
<div>
<p class="MsoNormal"><span>ub-state-name
INTEGER ::= 128</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>_______________________________________________</span></p>
</div>
<div>
<p class="MsoNormal"><span>Public
mailing list</span></p>
</div>
<div>
<p class="MsoNormal"><span><a
moz-do-not-send="true"
href="mailto:Public@cabforum.org"
target="_blank"><span
style="color:windowtext;text-decoration:none"><a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a></span></a></span></p>
</div>
<div>
<p class="MsoNormal"><span><a
moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
target="_blank"><span
style="color:windowtext;text-decoration:none"><a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></span></a></span></p>
</div>
</div>
<p class="MsoNormal"><span
style="font-family:"Times New
Roman",serif"> </span></p>
<div>
<div>
<p class="MsoNormal"><span
style="font-family:"MS
Gothic"">本信件可能包含中華電信股份有限公司機密資訊</span><span
style="font-family:"Times New
Roman",serif">,</span><span
style="font-family:"MS
Gothic"">非指定之收件者</span><span
style="font-family:"Times New
Roman",serif">,</span><span
style="font-family:"MS
Gothic"">請勿蒐集、處理或利用本信件</span><span
style="font-family:SimSun">內容</span><span
style="font-family:"Times New
Roman",serif">,</span><span
style="font-family:"MS
Gothic"">並請銷毀此信件</span><span
style="font-family:"Times New
Roman",serif">. </span><span
style="font-family:"MS
Gothic"">如為指定收件者</span><span
style="font-family:"Times New
Roman",serif">,</span><span
style="font-family:"MS
Gothic"">應確實保護郵件中本公司之營業機密及個人資料</span><span
style="font-family:"Times New
Roman",serif">,</span><span
style="font-family:"MS
Gothic"">不得任意傳佈或揭露</span><span
style="font-family:"Times New
Roman",serif">,</span><span
style="font-family:"MS
Gothic"">並應自行確認本郵件之附檔與超連結之安全性</span><span
style="font-family:"Times New
Roman",serif">,</span><span
style="font-family:"MS
Gothic"">以共同善盡資訊安全與個資保護責任</span><span
style="font-family:"Times New
Roman",serif">. </span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Times New
Roman",serif">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.</span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Times New
Roman",serif"> </span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Times New
Roman",serif"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-family:"Times New
Roman",serif"><T-REC-X.520-201210-I!!PDF-E.pdf>_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true"
href="mailto:Public@cabforum.org"
target="_blank">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
target="_blank">https://cabforum.org/mailman/listinfo/public</a></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span
style="font-family:"Times New
Roman",serif"> </span></p>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true" href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>