<div dir="ltr">I support this idea, for the same reasons Peter mentioned. We'd like to be able to issue certificates for hostnames >64 characters, which means that the hostname can't be included in the Subject CN. Since that would leave the Subject empty, which causes interoperability problems, we need some attribute that is legal to include in Subject when doing Domain Validation. DN Qualifier seems reasonably well-suited to the purpose.<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 19, 2017 at 4:28 PM, Peter Bowen via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Certificate Field: subject:qnQualifier (OID: 2.5.4.46) )<br></blockquote><div> </div><div>I think this was a small typo and Peter meant to write dnQualifier here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Optional.<br>
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 ough to 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 wish to 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.<br></blockquote><div><br></div><div>Any reason for SHA1 here over SHA2? I realize the security properties here are not important, but using an older hash always triggers a bit of a code smell.</div></div></div></div>