Re: subjectAltName=email:move

2003-11-22 Thread Dr. Stephen Henson
On Fri, Nov 21, 2003, Joseph Bruni wrote:

 
 On a related note, how does this work for the other types of general 
 names (e.g. DNS, IP)? Looking through the v3_alt.c I don't see any code 
 that moves or copies DNS or IP values from the DN into alternative 
 names extensions. Do all these other general names types need to be 
 hard-coded in the config? (or at least hard-coded into the extensions 
 file?)
 

There isn't actually a DNS or IP equivalent in the DN, well I suppose for SSL
server certificates the CN is used for DNS but that's about it.

These can be included either in the config file for 'ca' or in the certificate
request as an extension and then copied with 'ca'.

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
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: subjectAltName=email:move

2003-11-21 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Thu, 20 Nov 2003 19:56:23 -0700, Joseph Bruni 
[EMAIL PROTECTED] said:

jbruni I've been trying to get the subjectAltName=email:move directive to 
jbruni work in the ca command with no luck, so I think this might be a bug.
jbruni 
jbruni It seems that the only way I can get this to work is to manually set 
jbruni the line in the CA section to something like:
jbruni 
jbruni subjectAltName=email:[EMAIL PROTECTED]
jbruni 
jbruni This isn't very flexible if I must edit this file for every cert. I 
jbruni want to sign.
jbruni 
jbruni If I try to use either the move or copy options, the
jbruni X509v3 Subject Alternative Name: extension ends up being
jbruni EMPTY.

Where do you expect the email address to come from?  The email:copy
and email:move are designed to copy or move an email address found in
the subject RDN with the attribute type emailAddress.  So basically,
if you have a subject DN that looks like this:

  C=SE, L= Stockholm, CN=Richard Levitte, [EMAIL PROTECTED]

... the following can be expected:

  1. with subjectAltName=email:copy:

 [EMAIL PROTECTED] in an email subjectAltName.
 Subject is unchanged.

  1. with subjectAltName=email:move:

 [EMAIL PROTECTED] in an email subjectAltName.
 Subject is now C=SE, L= Stockholm, CN=Richard Levitte


jbruni I have tried to get this to work two different ways: the first
jbruni with the subjectAltName in the DN, and the second in the
jbruni attributes section of the CSR.

Uhmm, subjectAltName has no business being inside any DN.  It's a
certificate extension, pure and simple.

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte   \ Tunnlandsvägen 3  \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: subjectAltName=email:move

2003-11-21 Thread Joseph Bruni
I had tried that as well with no success, which is what is leading me to believe this 
is a bug.

In the CSR, I have the emailAddress field set in the DN. In the CA section of the 
configuration file, I have subjectAltName=email:move in the section referenced from 
the x509_extensions option:

x509_extensions = email_extensions

[ email_extensions ]
subjectAltName = email:move

When the cert. is created, the X509v3 Subject Alternative Name field is set to the 
string EMPTY and the emailAddress that was formerly in the DN is no longer present. 
If I use the email:copy directive, the DN still has the emailAddress field (not 
removed), and the X509v3 Subject Alternative Name in the extensions part is still set 
to EMPTY.

For whatever reason, the email:move and email:copy directives are not populating the 
X509v3 Subject Alternative Name with any meaningful data.



On Friday, November 21, 2003, at 01:25AM, Richard Levitte - VMS Whacker [EMAIL 
PROTECTED] wrote:

In message [EMAIL PROTECTED] on Thu, 20 Nov 2003 19:56:23 -0700, Joseph Bruni 
[EMAIL PROTECTED] said:

jbruni I've been trying to get the subjectAltName=email:move directive to 
jbruni work in the ca command with no luck, so I think this might be a bug.
jbruni 
jbruni It seems that the only way I can get this to work is to manually set 
jbruni the line in the CA section to something like:
jbruni 
jbruni subjectAltName=email:[EMAIL PROTECTED]
jbruni 
jbruni This isn't very flexible if I must edit this file for every cert. I 
jbruni want to sign.
jbruni 
jbruni If I try to use either the move or copy options, the
jbruni X509v3 Subject Alternative Name: extension ends up being
jbruni EMPTY.

Where do you expect the email address to come from?  The email:copy
and email:move are designed to copy or move an email address found in
the subject RDN with the attribute type emailAddress.  So basically,
if you have a subject DN that looks like this:

  C=SE, L= Stockholm, CN=Richard Levitte, [EMAIL PROTECTED]

... the following can be expected:

  1. with subjectAltName=email:copy:

 [EMAIL PROTECTED] in an email subjectAltName.
 Subject is unchanged.

  1. with subjectAltName=email:move:

 [EMAIL PROTECTED] in an email subjectAltName.
 Subject is now C=SE, L= Stockholm, CN=Richard Levitte


jbruni I have tried to get this to work two different ways: the first
jbruni with the subjectAltName in the DN, and the second in the
jbruni attributes section of the CSR.

Uhmm, subjectAltName has no business being inside any DN.  It's a
certificate extension, pure and simple.

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte   \ Tunnlandsvägen 3  \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.


 

-- 
PGP Fingerprint:
886F 6A8A 68A1 5E90 EF3F  8EFA E2B8 3F99 7343 C1E3
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


subjectAltName=email:move

2003-11-21 Thread Joseph Bruni
I've been poking around in the v3_alt.c file to try to determine why the email address 
is not getting copied or moved into the extension. After sprinkling in a few debug 
statements, it looks like the copy_email() function is broken and never enters the 
while loop. Even though the DN has an 'emailAddress' field, this function is unable 
to locate it, and no value is getting copied into the v3 extensions.

This function is only called in response to an email:move or and email:copy directive. 
If this function is broken, it would explain why hard-coding in an email address works 
whereas the copy/move directives do not.

I will continue to analyze this function to determine why it's not working. I post 
this with the hope that someone more familiar with it can reach a solution faster than 
I can.



-- 
PGP Fingerprint:
886F 6A8A 68A1 5E90 EF3F  8EFA E2B8 3F99 7343 C1E3
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: subjectAltName=email:move

2003-11-21 Thread Dr. Stephen Henson
On Fri, Nov 21, 2003, Joseph Bruni wrote:

 I've been poking around in the v3_alt.c file to try to determine why the email 
 address is not getting copied or moved into the extension. After sprinkling in a few 
 debug statements, it looks like the copy_email() function is broken and never enters 
 the while loop. Even though the DN has an 'emailAddress' field, this function is 
 unable to locate it, and no value is getting copied into the v3 extensions.
 
 This function is only called in response to an email:move or and email:copy 
 directive. If this function is broken, it would explain why hard-coding in an email 
 address works whereas the copy/move directives do not.
 
 I will continue to analyze this function to determine why it's not working. I post 
 this with the hope that someone more familiar with it can reach a solution faster 
 than I can.
 
 

OK, someone's woke me up now. I'll look at it :-)

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
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: subjectAltName=email:move

2003-11-21 Thread Dr. Stephen Henson
On Sat, Nov 22, 2003, Dr. Stephen Henson wrote:

 On Fri, Nov 21, 2003, Joseph Bruni wrote:
 
  I've been poking around in the v3_alt.c file to try to determine why the email 
  address is not getting copied or moved into the extension. After sprinkling in a 
  few debug statements, it looks like the copy_email() function is broken and never 
  enters the while loop. Even though the DN has an 'emailAddress' field, this 
  function is unable to locate it, and no value is getting copied into the v3 
  extensions.
  
  This function is only called in response to an email:move or and email:copy 
  directive. If this function is broken, it would explain why hard-coding in an 
  email address works whereas the copy/move directives do not.
  
  I will continue to analyze this function to determine why it's not working. I post 
  this with the hope that someone more familiar with it can reach a solution faster 
  than I can.
  
  
 
 OK, someone's woke me up now. I'll look at it :-)
 

I've just tried this against OpenSSL 0.9.7c and it seems to work fine.

Could you send me your openssl.cnf and tell me the exact commands you are using
to get this behaviour?

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
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: subjectAltName=email:move

2003-11-21 Thread Dr. Stephen Henson
On Sat, Nov 22, 2003, Dr. Stephen Henson wrote:

 On Sat, Nov 22, 2003, Dr. Stephen Henson wrote:
 
  On Fri, Nov 21, 2003, Joseph Bruni wrote:
  
   I've been poking around in the v3_alt.c file to try to determine why the email 
   address is not getting copied or moved into the extension. After sprinkling in a 
   few debug statements, it looks like the copy_email() function is broken and 
   never enters the while loop. Even though the DN has an 'emailAddress' field, 
   this function is unable to locate it, and no value is getting copied into the v3 
   extensions.
   
   This function is only called in response to an email:move or and email:copy 
   directive. If this function is broken, it would explain why hard-coding in an 
   email address works whereas the copy/move directives do not.
   
   I will continue to analyze this function to determine why it's not working. I 
   post this with the hope that someone more familiar with it can reach a solution 
   faster than I can.
   
   
  
  OK, someone's woke me up now. I'll look at it :-)
  
 
 I've just tried this against OpenSSL 0.9.7c and it seems to work fine.
 
 Could you send me your openssl.cnf and tell me the exact commands you are using
 to get this behaviour?
 

Oh and which version of OpenSSL are you using?

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
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


Re: subjectAltName=email:move

2003-11-21 Thread Joseph Bruni
Do I ever feel like an idiot. I was building a minimalist configuration 
file for you and, lo, it started working -- on all versions of 0.9.7 
that I have been experimenting with (a,b,c).

After a little more experimentation to figure out why this suddenly 
started working, I uncovered my mistake:  I was missing the 
emailAddress field in the policy section for the CA command. Since I 
did not want the emailAddress in the DN, I removed this from the 
policy, which broke the email:move directive. It appears that the 
email:move takes place AFTER the policy is evaluated and the cert. DN 
is built. So that even though emailAddress appears in the CA policy, 
it will NOT appear in the DN if the subjectAltName=email:move is in 
force.

Sorry for the list noise, but this does seem a bit obscure. Perhaps 
even obtuse. :)

On a related note, how does this work for the other types of general 
names (e.g. DNS, IP)? Looking through the v3_alt.c I don't see any code 
that moves or copies DNS or IP values from the DN into alternative 
names extensions. Do all these other general names types need to be 
hard-coded in the config? (or at least hard-coded into the extensions 
file?)



On Nov 21, 2003, at 4:51 PM, Dr. Stephen Henson wrote:

On Sat, Nov 22, 2003, Dr. Stephen Henson wrote:

On Sat, Nov 22, 2003, Dr. Stephen Henson wrote:

On Fri, Nov 21, 2003, Joseph Bruni wrote:

I've been poking around in the v3_alt.c file to try to determine 
why the email address is not getting copied or moved into the 
extension. After sprinkling in a few debug statements, it looks 
like the copy_email() function is broken and never enters the 
while loop. Even though the DN has an 'emailAddress' field, this 
function is unable to locate it, and no value is getting copied 
into the v3 extensions.

This function is only called in response to an email:move or and 
email:copy directive. If this function is broken, it would explain 
why hard-coding in an email address works whereas the copy/move 
directives do not.

I will continue to analyze this function to determine why it's not 
working. I post this with the hope that someone more familiar with 
it can reach a solution faster than I can.


OK, someone's woke me up now. I'll look at it :-)

I've just tried this against OpenSSL 0.9.7c and it seems to work fine.

Could you send me your openssl.cnf and tell me the exact commands you 
are using
to get this behaviour?

Oh and which version of OpenSSL are you using?

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
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]


subjectAltName=email:move broken

2003-11-07 Thread Joseph Bruni
Hello all,

I've been trying to get the subjectAltName=email:move directive to 
work in the ca command with no luck. I think this is a bug.

It seems that the only way I can get this to work is to manually set 
the line in the CA section to something like:

subjectAltName=email:[EMAIL PROTECTED]

This isn't very flexible if I must edit this file for every cert. I 
want to sign.

If I try to use either the move or copy options, the X509v3 Subject 
Alternative Name: extension ends up being EMPTY.

I have tried to get this to work two different ways: the first with the 
subjectAltName in the DN, and the second in the attributes section of 
the CSR.

I've tried with the subjectAltName having the email: prefix and 
without in both the DN and in the attributes.

For the life of me, I cannot get the move to work. Has anyone ever 
gotten this to work aside from hard-coding the email address in the CA 
section?

Joseph Bruni


smime.p7s
Description: S/MIME cryptographic signature