Re: [openssl.org #81] Bug Report 0.9.7b1: make install broken on NeXTSTEP/OpenStep
On 02-06-05 15:43:45 CEST, Rich Salz wrote:
Richard Levitte via RT wrote:
Can I assume that sed exists and works properly? dirname can be
coded like this:
echo $$i | sed -e 's|[^/]*$||' -e 's|/$||'
dirname foo returns . which the above doesn't catch.
I can only think of the following short shell script
#! /bin/sh
for I
do
case $I in
*/* ) echo $I | sed -e 's@\(.*\)/.*@\1@' ;;
*) echo .
esac
done
i remember on my SVR3 machine dirname(1) was a shell script:
-r-xr-xr-x 1 sys bin93 Oct 11 1985 /bin/dirname*
expr \
${1-.}'/' : '\(/\)[^/]*/$' \
\| ${1-.}'/' : '\(.*[^/]\)//*[^/][^/]*//*$' \
\| .
the solaris 1 dirname is:
#! /bin/sh
#
# @(#)dirname.sh 1.5 89/03/22 SMI; from S5R2 1.2
#
PATH=/bin:/usr/bin
expr \
${1-.}'/' : '\(/\)[^/]*//*$' \
\| ${1-.}'/' : '\(.*[^/]\)//*[^/][^/]*//*$' \
\| .
i.e. the same with attribution.
unlike sed expr usually is a sh built-in.
rj
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
strangeness in `x509 -noout -text` output
`x509 -noout -text` prints inconsistent output.
... openssl x509 -noout -text -in old.pem | grep Issuer:
Issuer: [EMAIL PROTECTED], CN=CA UCO, O=Universidad de Cordoba, C=ES
... openssl x509 -noout -text -in new.pem | grep Issuer:
Issuer: C=ES, O=Universidad de Cordoba, CN=AC [EMAIL PROTECTED]
see the / that magically appears, instead of a , ?
if found the place that does this magic and commented it out:
... openssl x509 -noout -text -in old.pem | grep Issuer:
Issuer: [EMAIL PROTECTED], CN=CA UCO, O=Universidad de Cordoba, C=ES
... openssl x509 -noout -text -in new.pem | grep Issuer:
Issuer: C=ES, O=Universidad de Cordoba, CN=AC UCO, [EMAIL PROTECTED]
it does it because the type emailAddress starts lower case!
rj
--- orig/openssl-SNAP-20020423/crypto/asn1/t_x509.c Wed Feb 13 20:00:30 2002
+++ openssl-SNAP-20020423/crypto/asn1/t_x509.c Fri Apr 26 11:50:13 2002
@@ -460,12 +461,12 @@
for (;;)
{
#ifndef CHARSET_EBCDIC
- if (((*s == '/')
+ if (((*s == '/') /*
((s[1] = 'A') (s[1] = 'Z') (
(s[2] == '=') ||
((s[2] = 'A') (s[2] = 'Z')
(s[3] == '='))
-))) ||
+))*/) ||
(*s == '\0'))
#else
if (((*s == '/')
DN handling
the DN handling in openssl seems to be a little uneven. getting special characters in seems to be no problem when using the interactive interface (at least when 'special' restricts itself to the ASCII characters with special syntactic function). but as soon as it comes to looking at the result, the output shows interesting variety and ambiguity: ... openssl req [...] -noout -text | grep Subject Subject: C=DE, L=Berlin, O=Acme, Inc., CN=#1 test: a+b=c/d ... openssl req [...] -noout -subject subject=/C=DE/L=Berlin/O=Acme, Inc./CN=#1 test: a+b=c/d in neither form are the delimiters escaped when they occur in the attribute values, like the comma in the O or the slash in the CN. the index.txt file uses the latter form. i don't know whether this non-escaping causes any problems. does it? what i find problematic is that the input suffers from similar problems: ... openssl req -new -key [...] -subj 'C=DE, L=Berlin, O=Acme, Inc, CN=#2 test: a+b=c\\/d' Subject Attribute Inc has no known NID, skipped Subject Attribute d has no known NID, skipped special characters cannot be escaped. apart from that, the encoding is ...strange. ... openssl req [...] -utf8 -subj '[...], CN=bäh' leads to a commonName object with the T61String b\344h which according to RFC 1345 is bĦh. the encoding is wrong, but it is documented in the BUGS section. (\344 is ä in ISO 8859-1.) trying to get a non-ISO-8859-1 character (the EUR sign for example) in fails: ... openssl req [...] -utf8 -subj '[...], CN=€' problems making Certificate Request 28715:error:0D07A07C:asn1 encoding routines:ASN1_mbstring_copy:illegal characters:a_mbstr.c:162: doing it via the interactive prompts leads to: ... openssl req -new [...] -utf8 [...] Organizational Unit Name (eg, section) []:€ problems making Certificate Request 29035:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:329:group=req_distinguished_name name=organizationalUnitName_min 29035:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:329:group=req_distinguished_name name=organizationalUnitName_max 29035:error:0D07A07C:asn1 encoding routines:ASN1_mbstring_copy:illegal characters:a_mbstr.c:162: the SPKAC format is problematic too, it doesn't work with non-ASCII DN's either. what are the openssl team's intentions for DN handling? keep it X.500 style which doesn't seem to define any string representation or go the RFC 2253 way? is there anybody working on this or would you like somebody to send patches? since 0.9.7 is frozen, i guess this will make it into 0.9.8 the earliest? rj __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Wrong DNs
On 02-04-16 16:49:25 CEST, Richard Levitte - VMS Whacker wrote: BTW, thinking about it, I'm not sure why this discussion acme up at all. Certificates are often stored as attributes of a record (eh, terminology isn't a strength of mine, so if record isn't the proper term, please pardon me), at least in the directories that I've viewed, and the LDAP DN isn't necesserely the same (obviously, it's at least inversed :-)). no, it is not. :-) it's the different presentations of a DN that are inverses. So I wonder, what exactly is the problem here? Do the OpenCA folks the exact problem is that the openca-developers were confused. and most people here didn't know much better either? :-) but howard chu's comments made me look for a proof that both the X.500 presentation and the LDAP presentation--despite their opposite order-- describe the same DER presentation, and i think i found it in RFC 2253 2.1. now we (openca developers) can write code to handle this mess. rj __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Wrong DNs
On 02-04-16 11:02:58 CEST, Howard Chu wrote:
the order of everything. Certificates are specified in X.509 and are
properly
a part of the X.500 family, and the X.500 DN syntax is clearly specified.
the syntax is clearly specified, but the only thing that i could find
about the RDN order is implicit from an example DN in X.501 that starts
with { C=US, .
where does it explicitly say that DNs should start with the most
significant part at the left end and continue to the least significant?
Any software that claims to support X.509 certificates must operate using
X.500 syntax. The LDAP DN specification is backwards, and a cert with
backwards DNs could only be considered to be broken, and certainly will
not be interoperable with the vast majority of already deployed PKI.
is the order part of X.500 syntax (isn't it semantics?) or is it just
a general convention?
and why is LDAP reversed?
because LDAP is an internet standard and the internet's DNS domain names
are ordered that way?
in peter gutmann's X.509 style guide i see both sort orders mentioned...
so, how does one best handle this mess?
expect X.509 DNs to be big endian and reverse them to be little endian
for use with LDAP?
i'm assuming here that in both cases the display order is the same as
the ASN.1 SEQUENCE order.
is that assumption correct?
(in other words: do the ASN.1 representations (DER) for X.509 and LDAP
DNs differ or just their human readable presentation?)
rj
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Wrong DNs
On 02-04-16 10:51:31 CEST, Howard Chu wrote: At its core, LDAP is simply a different front-end for the X.500 information model. A DN is a name that uniquely identifies an object in the X.500 name space. Practically speaking, a DN is a DN. In pure X.500, DNs are specified to be big-endian, most-significant component listed first. An X.500 directory path follows the same convention as a Unix filesystem path in this regard. In LDAP, the convention is to display the DNs in the opposite order, but the semantic meaning of the DN is unchanged. The X.500 representation /c=us/o=foo/ou=people/cn=joe specifies the exact same object as the LDAP DN cn=joe,ou=people,o=foo,c=us in other words, you mean that the X.500 presentation c=us,cn=John Doe and the LDAP presentation cn=John Doe,c=us have the exact same DER byte stream encoding? can you or anyone else prove this? :-) To answer your question is there a definition of how to transform X.500 DNs to LDAP representation? the answer is yes, it's RFC 2253. you mean (RFC 2253, 2.1) [...] the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence (according to 2.2), starting with the last element of the sequence and moving backwards toward the first. with backwards being the key word? seems to make sense, i wasn't aware of that before. thanks. rj __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[joop@fokus.gmd.de: SPKAC file and non-ASCII DNs]
i sent this to -users a few days ago, but perhaps the people who know the answer only hang around on -dev...? rj ---BeginMessage--- when i create a client certificate using a mozilla browser, a CGI script generates an SPKAC file for use with `openssl ca -spkac infile`. the DN then becomes of ASN.1 type T61STRING which is encoded illegally, which the openssl documentation admits: quote src=http://www.openssl.org/docs/apps/req.html; BUGS OpenSSL's handling of T61Strings (aka TeletexStrings) is broken: it effectively treats them as ISO-8859-1 (Latin 1), Netscape and MSIE have similar behaviour. This can cause problems if you need characters that aren't available in PrintableStrings and you don't want to or can't use BMPStrings. As a consequence of the T61String handling the only correct way to represent accented characters in OpenSSL is to use a BMPString: unfortunately Netscape currently chokes on these. If you have to use accented characters with Netscape and MSIE then you currently need to use the invalid T61String form. /quote what does an SPKAC file have to look like so that the DN turns up encoded as ASN.1 BMPString? the req command has a -utf8 option, but it doesn't read SPKAC files, so i can't use it to turn the SPKAC file into PKCS#10. the spkac command hasn't got any -utf8 option. is there any other way to generate a correctly encoded non-ASCII DN for a mozilla client? rj __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ---End Message---
Re: -utf8 option
On 02-03-26 12:09:59 CET, Robert Joop wrote:
On 02-03-25 18:03:56 CET, Stephen Sprunk wrote:
Here's the more interesting question: why do we have a switch for
UTF-8 encoding, instead of determining it from the user's locale?
what is the canonical way to detect this?
following up to myself...
one can find a number of recipes here:
http://www.cl.cam.ac.uk/~mgk25/unicode.html#activate
the -utf8 should be left there anyway as an additional option,
because some systems don't have proper locale software?
while this is quite elegant:
#include locale.h
#include langinfo.h
main()
{
setlocale (LC_CTYPE, );
printf (cs=%s\n, nl_langinfo (CODESET));
}
it doesn't work on freeBSD (it lacks nl_langinfo()).
rj
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: -utf8 option
On 02-03-26 15:01:37 CET, George Rogers wrote: Have you guys forgotten that the client and server are on different ends of the wire? Which end of the wire is going to use the certificate? Which end of the wire is creating the certificate? The switch has to be there to allow creation of certificates, etc for use other than on the local system. this is command line usage, no client-server relationship. it's about printing the certificate contents to the parent process' stdout, or getting the certificate contents from the parent process' stdin, resp. (openssl x509, spkac, req, etc...) rj __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
-utf8 option
the explanation of the -utf8 option doesn't make sense, does it? quote src=http://www.openssl.org/docs/apps/req.html; -utf8 this option causes field values to be interpreted as UTF8 strings, by default they are interpreted as ASCII. This means that the field values, whether prompted from a terminal or obtained from a configuration file, must be valid UTF8 strings. quote ASCII is a proper subset of UTF-8, rendering the -utf8 totally superfluous? i guess what is meant is ISO 8859-1 instead of ASCII? (ISO 8859-1 and UTF-8 are conflicting encodings, whereas ASCII and UTF-8 are not.) rj __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl ca sets wrong authorityKeyIdentifier
On 02-03-19 23:05:52 CET, Dr S N Henson wrote: I can't see how that can happen. The ca command only passes the issuing CA certificate to the extension routines. It does not have access to any other CA certificate. It fills in the authority key identifier by extracting the issuer name of that issuing authority and its serial number. but it seems that it indeed does happen. Is the issuer name of the CA correct? If there's nothing obviously wrong can you send me an example of a user certificate exhibiting this behaviour and all the CA certificates too? the user cert has the user CA's DN in the issuer DN (CN=User CA) and the root CA's DN in the authority key identifier DirName (CN=Test-CA (G4)), see the attached example. but the user cert's authority key identifier keyid is the user CA cert's subject key identifier and the user cert's authority key identifier serial is the user CA cert's serial. ((i ask myself) what's that X509v3 Authority Key Identifier exactly anyway...?) rj example.tar Description: Unix tar archive
Re: 0.9.5a won't compile under solaris 1.1.1
On 00-07-11 23:25:44 MET DST, Richard Levitte - VMS Whacker wrote: From: Robert Joop [EMAIL PROTECTED] Please try the latest snapshot and see if that helps. No guarantees, though... rj OpenSSL version: 0.9.5a rj Last change: Make sure _lrotl and _lrotr are only used with MSVC rj OS (uname): SunOS rainbow 4.1.4 9 sun4m rj OS (config): sun4m-sun-sunos4 rj Target (default): sunos-gcc rj Target: sunos-gcc rj Compiler: gcc version 2.8.1 rj rj Failure! [...] rj gcc -o openssl -DMONOLITH -I../include -O3 -mv8 -Dssize_t=int openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o -L. -L.. -L../.. -L../../.. -L.. -lssl -L.. -lcrypto rj collect2: ld returned 2 exit status rj ld: Undefined symbol rj_memmove rj_strtoul rj_strerror well, despite the CHANGES file not mentioning the fix, the 000711 snapshot doesn't exhibit the problem (and compiles and links fine). thanks! well, i hope the huge list of new features doesn't destablize the program as to make it unfit for my CA purposes... but `make test` left a good impression. :-) rj __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
