[cabfpub] EV Gudelines section 9.2.5 & X.520
Ryan Sleevi
sleevi at google.com
Fri Jul 1 20:34:47 UTC 2016
This is extremely, extremely valuable Ben. I want to personally thank you
for the time and detail put into this.
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.
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)
On Fri, Jul 1, 2016 at 11:39 AM, Ben Wilson <ben.wilson at digicert.com> wrote:
> 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:* 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:* 陳立群 <realsky at cht.com.tw>
> *Cc:* CABFPub <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, 陳立群 <realsky at cht.com.tw> a écrit :
>
>
>
>
>
> In X.520 as attached file or RFC 5280(
> 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.2.html and
> 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: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org
> <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
>
> Public at cabforum.org
>
> 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
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160701/c800e671/attachment-0003.html>
More information about the Public
mailing list