[cabfpub] Ballot 208 - dnQualifiers
Moudrick M. Dadashov
md at ssc.lt
Mon Oct 23 16:25:42 UTC 2017
One more reference, see section 5.1.4 in:
http://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.01.01_60/en_31941201v010101p.pdf
Thanks,
M.D.
On 10/23/2017 6:02 PM, 陳立群 via Public wrote:
>
> What about using serialNumber (2.5.4.5)?
>
> Li-Chun Chen
>
> *From:*Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Monday, October 23, 2017 9:54 PM
> *To:* 陳立群
> *Cc:* Geoff Keating; CA/Browser Forum Public Discussion List
> *Subject:* [外部郵件] Re: [cabfpub] Ballot 208 - dnQualifiers
>
> Given that the naming authority is the DNS, and two entities with the
> same 64 character prefix domain would be equivalent, it does not seem
> at all incorrect or imprecise to include this information in the
> dnQualifier.
>
> Hopefully we can find a solution other than "Don't have long domains
> because the commonName" - a field deprecated nearly two decades ago.
>
> On Sun, Oct 22, 2017 at 10:41 AM, 陳立群<realsky at cht.com.tw
> <mailto:realsky at cht.com.tw>> 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
> <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 at
> 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.
>
>
> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
> 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
>
> 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
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171023/98d8379f/attachment-0003.html>
More information about the Public
mailing list