[cabfpub] Ballot 208 - dnQualifiers

Moudrick M. Dadashov md at ssc.lt
Sun Oct 22 19:02:51 UTC 2017

Just for the record, see Section 4.2.1 how ETSI resolved the 
disambiguation of identical subject issue:



On 10/22/2017 9:05 PM, Peter Bowen via Public wrote:
> The dnQualifier is designed to add “disambiguating information” to 
> Distinguished Names.  This ballot uses it for that purpose.  Notably I 
> expect CAs to use it to disambiguate certificates where there is no 
> distinguished name or where the CA has information that two 
> certificates with identical subjects were issued to different entities.
> The issue that both Li-Chun and Geoff raise appears to be whether we 
> should use a different attribute type instead of dnQualifier.  The 
> most obvious suggestion would be to define a new attribute type, under 
> an Object Identifier arc that is managed by the Forum or a member. 
>  However this results in real-world compatibility issues.  There are 
> numerous products which error if a certificate DN contains attributes 
> not on a whitelist.
> Two examples I found with a few minutes of looking online:
> Cisco VCS: "If you experience unknown ssh failures such as ssh tunnels 
> failing to establish, please verify there are no unknown OIDs in the 
> certificate. This can be done by checking that there are no undecoded 
> numerical entries in the CN of the Issuer & Subject fields” (from 
> https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-8/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-8.pdf)
> IBM Sterling B2B Integrator: “Cannot find a class that corresponds to 
> Oid; please see oid.map for details” (from 
> http://www-01.ibm.com/support/docview.wss?uid=swg21649708)
> A bit of searching on “oid.map”, I did find the source, which is a 
> PKIX library from Certicom.  The part of oid.map that seems relevant 
> is below.  I note dnQualifier is not there, so maybe we should choose 
> one of the attributes below:
>   "CommonName, CN",
>   "Surname, SN",
>   "SerialNumber",
>   "Country, C",
>   "Locality, L",
>   "StateOrProvince, ST, SP",
>   "StreetAddress, STREET",
>   "Organization, O",
>   "OrganizationUnit, OU",
>   "Title",
>   "PostalCode",
>   "PhoneNumber",
>   "EmailAddress, E", 1.2.840.113549.1.9.1
>   "rfc822Mailbox", 0.9.2342.19200300.100.1.3
>   # Controls (from RFC-2511)
>   "Registration Token",
>   "Authenticator",
>   "Publication Information",
>   "Archive Options",
>   "OldCert ID",
>   "Protocol Encryption Key",
>   # Registration Info (from RFC-2511)
>   "UTF8 Pairs",
>   "Cert Request",
>   # X.500 directory stuff (from RFC-1274)
>   "userId", 0.9.2342.19200300.100.1.1
>   # These are Trustpoint defined and are used between the policies and 
> the Admin in the
>   # additional-info sent up
>   "Request-Time",
>   "Integrity-Verified",
>   "EE-Password",
>   "EE-Certificate",
>   # Domain Component
>   "Domain Component", 0.9.2342.19200300.100.1.25
>   "IncorporationLocality",
>   "OtherCountry",
>   "OtherState",
>   "BusinessCategory",
>> On Oct 22, 2017, at 7:41 AM, 陳立群 via Public <public at cabforum.org 
>> <mailto:public at cabforum.org>> wrote:
>> I would like to second Geoff's opinion about the dnQualifier 
>> attribute. In the ITU-T X.520 standard, the definition of the 
>> dnQualifier attribute is as the following:
>> The DN Qualifier attribute type specifies disambiguating information 
>> to add to the relative distinguished name of an entry. It is intended 
>> to be used for entries held in multiple DSAs which would otherwise 
>> have the same name, and that its value be the same in a given DSA for 
>> all entries to which this information has been added.
>> From what I understand, the dnQualifier attribute is intended to 
>> distinguish two different entities which would otherwise have the 
>> same DN if they are named by different DSAs (or naming authorities). 
>> Therefore, the attribute value of the dnQualifier is usually used to 
>> indicate the name of the DSA which is in charge of naming the entity.
>> If we use the dnQualifier attribute in the manner proposed this 
>> ballot, that will be a distortion on its original definition in the 
>> X.520 standard.
>> Li-Chun Chen
>>         Chunghwa Telecom
>> *From:*Public [mailto:public-bounces at cabforum.org]*On Behalf Of*Geoff 
>> Keating via Public
>> *Sent:*Saturday, October 21, 2017 3:15 AM
>> *To:*Ryan Sleevi
>> *Cc:*CA/Browser Forum Public Discussion List
>> *Subject:*[外部郵件] Re: [cabfpub] Ballot 208 - dnQualifiers
>> On Oct 20, 2017, at 11:30 AM, Ryan Sleevi <sleevi at google.com 
>> <mailto:sleevi at google.com>> wrote:
>> On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating via Public 
>> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>>> - How this matches with the X.520 definition of dnQualifier, in 
>>> particular the second sentence:
>>> The DN Qualifier attribute type specifies disambiguating 
>>> information to add to the relative distinguished name of an entry. 
>>> It is intended to be used for entries held in multiple DSAs 
>>> which would otherwise have the same name, and that its value be the 
>>> same in a given DSA for all entries to which this information has 
>>> been added.
>> This matches 1:1. Is there a concern that it doesn't match, or that 
>> more rules are necessary?
>> What I quoted above is X.520.  It doesn't seem to me to be describing 
>> the same thing as the ballot.  In particular, normally you would 
>> consider a CA’s issuing infrastructure to be one single DSA, which 
>> produces a contradiction between the ballot text "The CA MAY set the 
>> dnQualifer value to the base64 encoding of the SHA1 hash of 
>> the subjectAlternativeName” and X.520’s text “its value be the same 
>> in a given DSA”.
>>> - How this is actually intended to be used in the web PKI?
>> As raised on our most recent call, one notable thing is that this 
>> allows CAs to issue single certificates for domain names greater than 
>> 64 characters, at a DV level, while interoperably working with the 
>> Web PKI. This flows as follows:
>> - The X.509/RFC 5280 definition for commonName is limited to 64 
>> characters.
>> - If you have a certificate with a domain name greater than 64 
>> characters, you cannot place it in the common name of the subject.
>> - The common name of the subject may only contain domain names and IP 
>> addresses.
>> - All other specified fields of the Subject must be validated to OV 
>> level.
>> As a consequence, the only way with DV today to represent these 
>> certificates is with an empty sequence for the subject name and a 
>> critical subjectAltName, pursuant with RFC5280. You can see this 
>> athttps://no-subject.badssl.com <https://no-subject.badssl.com/>
>> If you tried to load that on Apple iOS, it would load.
>> If you tried to load that on Apple macOS earlier than 10.10, it would 
>> load.
>> If you tried to load that on Apple macOS since 10.10, it will fail, 
>> as empty subjects are no longer supported.
>> It works for me in 10.11—so does that mean this ballot is no longer 
>> needed?
>> This provides a way for a CA to ensure that a DV certificate with a 
>> domain name of more than 64 characters can be issued, by using the 
>> dnQualifier field (which is CA-controlled, as noted in the relevant 
>> X.520 text you cited) to serve as a disambiguator between 
>> certificates the CA has issued.
>> Does that help capture it?
>> I see the problem but I’m very hesitant to standardise something in 
>> CABforum which contradicts X.520.
>> Have we really explored other alternatives?  For example, truncate 
>> the commonName to 60 characters and append an ellipsis in Unicode 
>> (“…”) so that it can’t be confused with a domain name.
>>>>> On Oct 12, 2017, at 11:04 AM, Ben Wilson via Public 
>>>>> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>>>>> *Ballot 208 - dnQualifiers*
>>>>> This ballot allows CAs to use dnQualifiers in certificates to 
>>>>> partition groups of certificates into different sets and to allow 
>>>>> non-identity information to be included in DV certificates.
>>>>> The following motion has been proposed by Peter Bowen of Amazon 
>>>>> and endorsed by Ben Wilson of DigiCert and Ryan Sleevi of Google.
>>>>> -- MOTION BEGINS --
>>>>> In the Baseline Requirements, REPLACE the definition of "Subject 
>>>>> Identity Information" with:
>>>>> "Information that identifies the Certificate Subject. Subject 
>>>>> Identity Information does not include [strikeout]a domain name 
>>>>> listed in the subjectAltName extension or the Subject commonName 
>>>>> field[/strikeout] [insert]_dnQualifier attributes in Distinguished 
>>>>> Names, commonName attributes in Distinguished Names, dNSName 
>>>>> Subject Alternative Names, iPAddress Subject Alternative Names, or 
>>>>> SRVName Subject Alternative Names_[/insert]."
>>>>> In Section Subject Distinguished Name Fields, re-letter 
>>>>> "j" (Other Subject Attributes) as letter "k" and INSERT a new 
>>>>> subsection j. that reads:
>>>>> j. Certificate Field: subject:dnQualifier
>>>>>   * Optional. Contents: This field is intended to be used when
>>>>>     several certificates with the same subject can be partitioned
>>>>>     into sets of related certificates. Each related certificate
>>>>>     set MAY have the same dnQualifier. The CA may include a
>>>>>     dnQualifier attribute with a zero length value to explicitly
>>>>>     indicate that the CA makes no assertion about relationship
>>>>>     with other certificates with the same subject. The CA MAY set
>>>>>     the dnQualifer value to the base64 encoding of the SHA1 hash
>>>>>     of the subjectAlternativeName extnValue if it wishes to
>>>>>     indicate grouping of certificates by alternative name set.
>>>>> -- MOTION ENDS --
>>>>> The procedure for approval of this Final Maintenance Guideline 
>>>>> ballot is as follows (exact start and end times may be adjusted to 
>>>>> comply with applicable Bylaws and IPR Agreement):
>>>>> BALLOT 208 Status: Final Maintenance Guideline Start time (22:00 
>>>>> UTC) End time (22:00 UTC)
>>>>> Discussion begins October 12, 2017 22:00 UTC and ends October 19, 
>>>>> 2017 22:00 UTC (7 days)
>>>>> Vote for approval begins October 19, 2017 22:00 UTC and ends 
>>>>> October 26, 2017 22:00 UTC (7 days)
>>>>> If vote approves ballot: Review Period (Chair to send Review 
>>>>> Notice) (30 days). If Exclusion Notice(s) filed, ballot approval 
>>>>> is rescinded and PAG to be created. If no Exclusion Notices filed, 
>>>>> ballot becomes effective at end of Review Period. Upon filing of 
>>>>> Review Notice by Chair 30 days after filing of Review Notice by Chair
>>>>> From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final 
>>>>> Maintenance Guideline, such ballot will include a redline or 
>>>>> comparison showing the set of changes from the Final Guideline 
>>>>> section(s) intended to become a Final Maintenance Guideline, and 
>>>>> need not include a copy of the full set of guidelines. Such 
>>>>> redline or comparison shall be made against the Final Guideline 
>>>>> section(s) as they exist at the time a ballot is proposed, and 
>>>>> need not take into consideration other ballots that may be 
>>>>> proposed subsequently, except as provided in Bylaw Section 2.3(j).
>>>>> Votes must be cast by posting an on-list reply to this thread on 
>>>>> the Public list. A vote in favor of the motion must indicate a 
>>>>> clear 'yes' in the response. A vote against must indicate a clear 
>>>>> 'no' in the response. A vote to abstain must indicate a clear 
>>>>> 'abstain' in the response. Unclear responses will not be counted. 
>>>>> The latest vote received from any representative of a voting 
>>>>> member before the close of the voting period will be counted. 
>>>>> Voting members are listed here:https://cabforum.org/members/
>>>>> In order for the motion to be adopted, two thirds or more of the 
>>>>> votes cast by members in the CA category and greater than 50% of 
>>>>> the votes cast by members in the browser category must be in 
>>>>> favor. Quorum is shown on CA/Browser Forum wiki. Under Bylaw 
>>>>> 2.2(g), at least the required quorum number must participate in 
>>>>> the ballot for the ballot to be valid, either by voting in favor, 
>>>>> voting against, or abstaining.
>>>>> <pre-ballot-208-dnQualifier.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
>> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 
>> 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
>> 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.
>> _______________________________________________
>> 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/20171022/b49bee36/attachment-0003.html>

More information about the Public mailing list