Hodie III Id. Sep. MMXI, Peter Sylvester scripsit:
> On 09/11/2011 12:12 AM, Erwann ABALEA wrote:
>
> Hodie IV Id. Sep. MMXI, Maarten Billemont via RT scripsit:
>
> According to rfc1779, the key STREET in the subject name should be
> capitalized.
>
> obj_dat.h specifies it as a lower-cased "street".
>
> This is incorrect and breaks when OpenSSL is used to parse in
> rfc1779-compliant distinguished names generated by external parties.
>
> The solution is to upper-case it to "STREET", just like "C", "CN", etc.
>
> The "street" attribute type (OID 2.5.3.9) is not defined by RFC1779.
> This RFC doesn't state that those tokens are case sensitive (you could
> even use "cn" instead of "CN").
> This RFC is defective at least in one aspect: the following names are
> not considered equal:
> CN=James Bond, O=MI6, C=UK
> CN=James \ Bond, O=MI6, C=UK
> CN=\ \ jAmeS bonD, O=MI6, C=UK
> these examples are equal, following X.520 rules.
>
>
> Hm,
>
> OID 2.5.3.9 is id-at-streetAddress OBJECT IDENTIFIER ::= {[1]id-at 9}
>
> streetAddress [2]ATTRIBUTE ::= {
> WITH SYNTAX [3]UnboundedDirectoryString
> EQUALITY MATCHING RULE [4]caseIgnoreMatch
> SUBSTRINGS MATCHING RULE [5]caseIgnoreSubstringsMatch
> ID [6]id-at-streetAddress
> }
>
> In 1779
>
> CN CommonName
> L LocalityName
> ST StateOrProvinceName
> O OrganizationName
> OU OrganizationalUnitName
> C CountryName
> STREET StreetAddress
>
> rfc 4514 has
>
> CN commonName (2.5.4.3)
> L localityName (2.5.4.7)
> ST stateOrProvinceName (2.5.4.8)
> O organizationName (2.5.4.10)
> OU organizationalUnitName (2.5.4.11)
> C countryName (2.5.4.6)
> STREET streetAddress (2.5.4.9)
> DC domainComponent (0.9.2342.19200300.100.1.25)
> UID userId (0.9.2342.19200300.100.1.1)
>
> in objects.txt
>
> X509 3 : CN : commonName
> X509 6 : C : countryName
> X509 7 : L : localityName
> X509 8 : ST : stateOrProvinceName
> X509 9 : street : streetAddress
> X509 10 : O : organizationName
> X509 11 : OU : organizationalUnitName
>
> IMO should be STREET
> (but existing req etc config files should become broken)
>
> the rfc doesn't treat equality or matching.
> the rfc describes a textual representation of an encoded name.
> not any kind of canonical or distinguished form.
If the OP is concerned by a mismatch between "street" and "STREET"
then I guess his question concerns matching strings.
The OP also complains that OpenSSL has a problem parsing
RFC1779-compliant DNs. In fact, OpenSSL doesn't parse RFC1779 names.
It has its own format.
> btw your examples seem wrong to me, a space cannot escaped by \
> as far as I understand rfc 1779
I could have used quotes, yes, but escaping is valid (yet ugly).
-----
The quoting mechanism is used for the following cases:
o Strings containing ",", "+", "=" or """ , <CR>, "<",
">", "#", or ";".
o Strings with leading or trailing spaces
o Strings containing consecutive spaces
-----
Quoting is defined as prefixing the character with a "\", or enclosing
the whole string in a """ pair, or both (is the string also contains
""" characters).
> rfc 4514 has ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
And RFC4519 names the attribute 'street', and all others in lowercase.
> The textual representations
>
> CN=" jAmes bonD"
> CN="James Bond"
>
> designate different encodings that match, i.e.
> only one could be in a directory.
Yes, as cn="James Bond", i.e. the case of the directory attribute name
is not important.
Test it an LDAPv3-compliant LDAP server, and you'll be able to use
both forms (lower and upper case) for the directory attributes. You
may even be able to use the OID form. Same with the "certificateMatch"
filter, if your LDAP server supports it.
--
Erwann ABALEA <erwann.aba...@keynectis.com>
Département R&D
KEYNECTIS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
