On 06/04/2008 7:57 AM, 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).
It's SHOULD NOT in my working copy now. >> The certificate presented when connecting to x.example.com contains >> the following representations: > > >> The certificate presented when connecting to either x1.example.net or >> x2.example.net contains the following representations: > > I'm mildly concerned that this might be taken to mean it's only the > "server certificate" in terms of the TLS client/server split. These > certificates are also presented as the client certificate of a S2S > session. Maybe sticking with "presented by", or really spelling it out, > might help. OK. >> user. If included, a JID MUST be represented as an XMPP OID, i.e., >> as a UTF8String within an otherName entity inside the subjectAltName, >> using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under >> Section 15.2.1.3. > > The OID is just the ASN.1 object identifier, so this comes across as a > bit odd - you can't represent a JID as an OID, as such. Right, I was using "XMPP OID" as a shorthand term. Other suggestions are welcome. Or we can refer to these three representations by their real names as id-on-dnsSRV, dNSName, and id-on-xmppAddr if that is clearer. >> As an alternative to the "id-on-xmppAddr" notation, this Object >> Identifier MAY be represented in dotted display format (i.e., >> "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name notation >> specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5"). >> >> Thus for example the JID "[EMAIL PROTECTED]" as included in a >> certificate could be formatted in any of the following three ways: >> >> id-on-xmppAddr: >> 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. That's more of an implementation note than anything else, but it is my understanding that all three of those representations are equivalent and that this is not just an OpenSSL issue. Would it help to recommend one over the other? >> 15.2.2. Certificate Validation >> >> When an XMPP entity is presented with a server certificate or client >> certificate by a peer for the purpose of encryption or authentication >> as described under Section 6 and Section 7, the entity MUST validate >> the certificate in order to determine if the certificate shall be >> considered a TRUSTED CERTIFICATE, i.e., a certificate that is >> acceptable for encryption and authentication in accordance with the >> XMPP entity's local service policies or configured settings. The >> following rules apply. >> >> > Hmmm... Any certificate, or indeed no certificate at all, is acceptable > for encryption. I don't follow. > The discussion on what to do if the certificate is not suitable for > authentication is interesting, too - again, it's a case of confusing > whether a certificate provides authentication with whether it's a sign > of active tampering. > > I think this stems from "HTTPS", where TLS is the only form of server > authentication, so if the server certificate doesn't validate, then > without an explicit go-ahead from a human, you mustn't continue. For > XMPP, aside from the fact that we have a history of trusting the DNS, we > also typically have other mechanisms for authenticating the server, > since we have SASL. But dialback is not a SASL mechanism. We could use DIGEST-MD5 I suppose or any other password-based mechanism, but in practice that is not done since it would require a prior agreement between the peers. > Ideally, clients faced with a certificate which does not validate should > use a mechanism providing both channel binding and mutual > authentication, but mutual authentication is the key here. Again I'm not sure I follow, but I am not an X.509 geek. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
