[cabfpub] EV Gudelines section 9.2.5 & X.520
Moudrick M. Dadashov
md at ssc.lt
Fri Jul 1 23:34:10 UTC 2016
FYI:
1. ETSI EN 319 412-1 "Electronic Signatures and Infrastructures (ESI);
Certificate Profiles; Part 1: Overview and common data structures".
2. ETSI EN 319 412-3 "Electronic Signatures and Infrastructures (ESI);
Certificate Profiles; Part 3: Certificate profile for certificates
issued to legal persons".
Thanks,
M.D.
On 7/1/2016 11:34 PM, Ryan Sleevi wrote:
> 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
> <mailto: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>
> [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:* 陳立群<realsky at cht.com.tw <mailto:realsky at cht.com.tw>>
> *Cc:* CABFPub <public at cabforum.org <mailto: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
> <mailto: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>
> [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
>
> Public at cabforum.org <mailto: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 <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto: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/20160702/53982647/attachment-0003.html>
More information about the Public
mailing list