[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