On 06/04/2008 9:36 AM, Shumon Huque wrote: > On Wed, Jun 04, 2008 at 02:57:16PM +0100, Dave Cridland wrote: >> On Tue Jun 3 17:58:19 2008, Peter Saint-Andre wrote: >>> 15.2.1.1.4. Common Name >>> >>> A server's domain identifier MUST NOT be represented as a Common >>> Name; instead, the Common Name field MUST be reserved for >>> representation of a human-friendly name. >>> >>> >> I have a feeling this breaks sdrawkcab compatibility for some older >> applications, and arguably a domain identifier is a reasonably human >> friendly name, so I think SHOULD NOT/SHOULD is probably more >> appropriate. (Also, RFC 2119 would suggest that as a MUST NOT/MUST >> implies that ignoring it will prevent interoperability, it's the >> wrong choice anyway). > > I also agree with this. Much as we'd all like to denigrate the use > of Common Name for hostnames and hostname like things, I think it's > too much of a practical barrier at the current time to deployed > infrastructure to say MUST NOT. > >>> subjectAltName=otherName:id-on-xmppAddr;UTF8:[EMAIL PROTECTED] >>> dotted display format: subjectAltName=otherName: >>> 1.3.6.1.5.5.7.8.5;UTF8:[EMAIL PROTECTED] >>> URN notation: subjectAltName=otherName:urn:oid: >>> 1.3.6.1.5.5.7.8.5;UTF8:[EMAIL PROTECTED] >>> >>> >> This bit is all weird - it's discussing some string representation >> that I suspect is specific to OpenSSL, but I'm really not sure. >> Either way, an OID in an X.509 certificate is represented as an OID - >> it's a native type in BER, DER, or whatever it is that X.509 >> certificates use, so this discussion is a bit like discussing how to >> represent an element in XML. > > Yup, I agree. The same OpenSSL configuration file style syntax > also appears in Section 15.2.1.1.5: > > subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.im.example.com > subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.im.example.com > subjectAltName=dNSName:im.example.com > subjectAltName=otherName:id-on-xmppAddr;UTF8:im.example.com > CN=Example Products, Inc. > > It might be better to describe how the SAN fields should be populated, > without referring to an application specific syntax, eg. > > otherName type of SRVName (id-on-dnsSRV) contains an IA5String > (ASCII) string of: "_xmpp-client.im.example.com" > otherName type of XmppAddr (id-on-xmppAddr) contains a UTF8 > string of: "im.example.com" > dNSName contains an ASCII string of "im.example.com"
Yes I'll do that. I almost did the first time. :) > (PS. I don't think the Peter's syntax for SRVName works in current > versions of OpenSSL. I think you'd need to spell out the whole > OID and it's content type with: > > > subjectAltName=otherName:1.3.6.1.5.5.7.8.7;IA5STRING:_xmpp-client.im.example.com > ) Yeah, the lines got too long so I arbitrarily truncated them to fit the RFC text file format in a fit of pique because I wanted to submit the damn I-D. :) But using your suggested text will solve that problem anyway... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
