[openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
Test, please ignore ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
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* ::= {id-at
http://www.itu.int/ITU-T/formal-language/itu-t/x/x501/2008/UsefulDefinitions.html#UsefulDefinitions.id-at
9}
streetAddressATTRIBUTE
http://www.itu.int/ITU-T/formal-language/itu-t/x/x501/2008/InformationFramework.html#InformationFramework.ATTRIBUTE
::= {
WITH SYNTAXUnboundedDirectoryString
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.UnboundedDirectoryString
EQUALITY MATCHING RULEcaseIgnoreMatch
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.caseIgnoreMatch
SUBSTRINGS MATCHING RULEcaseIgnoreSubstringsMatch
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.caseIgnoreSubstringsMatch
IDid-at-streetAddress
http://www.itu.int/ITU-T/formal-language/itu-t/x/x520/2008/SelectedAttributeTypes.html#SelectedAttributeTypes.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.
btw your examples seem wrong to me, a space cannot escaped by \
as far as I understand rfc 1779
string ::= *(stringchar |pair )
| '' *(stringchar |special |pair ) ''
| #hex
special ::= , | = |CR | + | |
| # | ;
pair ::= \ (special | \ | '')
stringchar ::= any character exceptspecial or \ or ''
rfc 4514 has ' ', '', '#', '+', ',', ';', '', '=','', or '\'
The textual representations
CN= jAmes bonD
CN=James Bond
designate different encodings that match, i.e.
only one could be in a directory.
have fun
Peter Sylvester
Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
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 RD
KEYNECTIS
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
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. -- Erwann ABALEA erwann.aba...@keynectis.com Département RD KEYNECTIS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
