[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:
http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf
Thanks,
M.D.
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 1.3.6.1.4.1.311.60.2.1.1; 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", 2.5.4.3
> "Surname, SN", 2.5.4.4
> "SerialNumber", 2.5.4.5
> "Country, C", 2.5.4.6
> "Locality, L", 2.5.4.7
> "StateOrProvince, ST, SP", 2.5.4.8
> "StreetAddress, STREET", 2.5.4.9
> "Organization, O", 2.5.4.10
> "OrganizationUnit, OU", 2.5.4.11
> "Title", 2.5.4.12
> "PostalCode", 2.5.4.17
> "PhoneNumber", 2.5.4.20
> "EmailAddress, E", 1.2.840.113549.1.9.1
> "rfc822Mailbox", 0.9.2342.19200300.100.1.3
>
> # Controls (from RFC-2511)
> "Registration Token", 1.3.6.1.5.5.7.5.1.1
> "Authenticator", 1.3.6.1.5.5.7.5.1.2
> "Publication Information", 1.3.6.1.5.5.7.5.1.3
> "Archive Options", 1.3.6.1.5.5.7.5.1.4
> "OldCert ID", 1.3.6.1.5.5.7.5.1.5
> "Protocol Encryption Key", 1.3.6.1.5.5.7.5.1.6
>
> # Registration Info (from RFC-2511)
> "UTF8 Pairs", 1.3.6.1.5.5.7.5.2.1
> "Cert Request", 1.3.6.1.5.5.7.5.2.2
>
> # 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", 1.3.6.1.4.1.3156.11.1
> "Integrity-Verified", 1.3.6.1.4.1.3156.11.2
> "EE-Password", 1.3.6.1.4.1.3156.12.1
> "EE-Certificate", 1.3.6.1.4.1.3156.12.2
>
> # Domain Component
> "Domain Component", 0.9.2342.19200300.100.1.25
> "IncorporationLocality", 1.3.6.1.4.1.311.60.2.1.1
> "OtherCountry", 1.3.6.1.4.1.311.60.2.1.3
> "OtherState", 1.3.6.1.4.1.311.60.2.1.2
> "BusinessCategory", 2.5.4.15
>
>
>> 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 7.1.4.2.2 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