Re: subject design for certificates
Dr. Stephen Henson wrote: On Mon, Nov 24, 2003, Michael Bell wrote: some people ask me how to create the following subject for certificates: cn=abc + serialNumber=123,o=company,c=de It is no problem to insert this subject to the -subj option of openssl ca but the sourcecode looks like OpenSSL ca uses abc + serialNumber=123 as value. Is this correct and if yes is there a way to issue certificates with mutlivalued attributes in RDNs? Yes but you need OpenSSL 0.9.8-dev for this. It doesn't (yet) work with -subj but if you use the config file for 'req' and make the first character of a DN component '+' it should create a multivalued RDN correctly. -subj in ca.c is important for me. So I start reading the code. I dug in req.c and it looks for me like mval signals as the last argument to X509_NAME_add_entry_by_NID that this is not a new RDN only an addition to the last RDN. Does this be correct? If yes then I start fixing -subj for ca.c or better I'm fixing do_subject which is used by req.c too. Best regards Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
On Tue, Nov 25, 2003, Michael Bell wrote: -subj in ca.c is important for me. So I start reading the code. I dug in req.c and it looks for me like mval signals as the last argument to X509_NAME_add_entry_by_NID that this is not a new RDN only an addition to the last RDN. Does this be correct? Yes that's correct. If yes then I start fixing -subj for ca.c or better I'm fixing do_subject which is used by req.c too. There's possibly a problem in that it would change the meaning of the '+' character which might break existing use of -subj or even permit some malicious use. So I'd suggest that any new behaviour should only be enabled with a command line swicth. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
Dr. Stephen Henson wrote: There's possibly a problem in that it would change the meaning of the '+' character which might break existing use of -subj or even permit some malicious use. So I'd suggest that any new behaviour should only be enabled with a command line swicth. Ok, taken. I created a patch and will put it into the request tracker. It uses a new option -multivalue-rdn to activate the new code. another problem is the output like you mentioned. -nameopt oneline works but -nameopt rfc2253 fails. rfc2253 escapes a blank but perhaps I send the blank to OpenSSL by myself - so no real problem. This is not wrong but it is senseless. oneline --- C = DE, O = Humboldt-Universitaet zu Berlin, OU = Internet, serialNumber = 123456 + CN = ABC XYZ , serialNumber = 30 rfc2253 --- serialNumber=30,CN=ABC XYZ \ +serialNumber=123456,OU=Internet,O=Humboldt-Universitaet zu Berlin,C=DE Thanks for your help Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #779] multivalued RDNs for -subj
Hi, I added support for multivalued RDNs to -subj in ca.c. I added this support to req.c too. Nevertheless it was tested with openssl ca. The new code can be activated with the switch -multivalue-rdn. If the switch is too long then please reduce it to something like -multirdn. The diffs were build with diff -u and openssl-SNAP-20031124. Best regards Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: subject design for certificates
On Tue, Nov 25, 2003, Michael Bell wrote: another problem is the output like you mentioned. -nameopt oneline works but -nameopt rfc2253 fails. rfc2253 escapes a blank but perhaps I send the blank to OpenSSL by myself - so no real problem. This is not wrong but it is senseless. Senseless it may be but it is a requirement of RFC2253. In 2.4 is clearly states that if a space occurs at the end of a string then it must be escaped. Who am I to argue? :-) Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Equivalent API for X509_NAME_oneline
Is there an equivalent API to do exactly the opposite of what X509_NAME_oneline() does? if i have a issuer name in the form of a string, is there an API which will give me a pointer to/update the X509_NAME object? satish
Re: Equivalent API for X509_NAME_oneline
On Tue, Nov 25, 2003, Bommareddy, Satish (Satish) wrote: Is there an equivalent API to do exactly the opposite of what X509_NAME_oneline() does? if i have a issuer name in the form of a string, is there an API which will give me a pointer to/update the X509_NAME object? Not the exact opposite no. X509_NAME_oneline() (which is deprecated BTW) loses some information when it prints out an X509_NAME structure, specifically the string types of the components. The nearest is X509_NAME_add_entry_by_txt() which will add a single compoent given the name and value text representations. So you'd have to split up a string into its components and call that on each in turn. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #695] [PATCH] DSO: dlfcn support for MacOS X
hmm ... RT has a weird bug that added an empty comment whilst changing ticket status. Please ignore it. [EMAIL PROTECTED] - Wed Sep 24 07:48:10 2003]: Anyway, here's a patch for MacOS X, the patch for dso_dlfcn.c could be implemented in other ways also. There would be no need for ifdef's if dlfcn_bind_var and dlfcn_bind_func would just probe for underscored symbol names at first, and then without it, if the first probe fails. I'd rather see the later method used, if possible. I don't like the idea of generic dlfcn handlers magically checking for translated versions of symbols before looking for the as-is names they were passed. In particular, this gets grimy if a loaded library defines symbols that differ only by how many leading underscores they have! IMHO: there are two acceptable solutions - (i) the one you've sketeched out, which is to test with a prefixed underscore *if* the configuration indicates we are building for a platform that does this (in which case the secondary test without the underscore is presumably useless - and worth using an #else clause to eliminate it perhaps??), or (ii) implement a distinct DSO_METHOD that piggy-backs DSO_METHOD_dlfcn() by performing the underscore prefixing before handing control over. For now, I think the -DDLFCN_NEED_UNDERSCORE approach is fine, and (ii) would be total overkill anyway. Could you please regenerate your diff against a recent 0.9.7-stable snapshot (from ftp://ftp.openssl.org/snapshot/) and test that this still has the desired effect on MacOS-X? The diff in this ticket didn't apply cleanly to my 0.9.7-checkout, and I have no MacOS-X box to confirm with if I meddle with the patch manually. Also, please take a look at the snapshot for the development head too - we will have to commit an equivalent there so the MacOS-X support doesn't go missing in the next major release. The underscore change to dso_dlfcn.c will port trivially enough, but the Configure and Makefile.org changes won't - the development head uses a different scheme for building shared libraries. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #695] [PATCH] DSO: dlfcn support for MacOS X
sigh I (stupidly) wrote: [snip] are building for a platform that does this (in which case the secondary test without the underscore is presumably useless - and worth using an #else clause to eliminate it perhaps??), or (ii) implement a distinct [snip] Of course you already *have* implemented this as #if_foo#elsefoo#endif rather than #if_foo#endiffoo - forgive the oversight/hallucinations, it will teach me to look at too many things at once. Hopefully the rest of my feedback is still valid though ...? :-) -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
