Richard Levitte - VMS Whacker wrote:
>
> From: Ferdinando Ricchiuti <[EMAIL PROTECTED]>
>
> ferdinando.ricchiuti> There are 2 little problems in the ca command.
> ferdinando.ricchiuti>
> ferdinando.ricchiuti> 1)
> ferdinando.ricchiuti> RFC2459 states:
> ferdinando.ricchiuti>
> ferdinando.ricchiuti> Conforming implementations generating new
> ferdinando.ricchiuti> certificates with electronic mail addresses
> ferdinando.ricchiuti> MUST use the rfc822Name in the subject
> ferdinando.ricchiuti> alternative name field (see sec. 4.2.1.7) to
> ferdinando.ricchiuti> describe such identities. Simultaneous
> ferdinando.ricchiuti> inclusion of the EmailAddress attribute in
> ferdinando.ricchiuti> the subject distinguished name to support
> ferdinando.ricchiuti> legacy implementations is deprecated but
> ferdinando.ricchiuti> permitted.
> ferdinando.ricchiuti>
> ferdinando.ricchiuti> The ca command does not allow to specify the
> ferdinando.ricchiuti> Email ONLY in the subjectAltName.
>
> Well, it's not really a ca command problem. The problem really lies
> in the req command. The ca command will after all just sign (at least
> if used in the default kind of way). The certificate request is
> normally generated with the req command, and that's where the
> subjectAltName should be properly filled in.
>
Well actually 'ca' doesn't just sign the request, that description is
more accuarate when applied to the CA operations of 'x509'.
The 'ca' utility pulls the DN apart according to the info in the policy
section and checks it. It also only permits DN components which are
present in the policy to be included and in the same order. Its current
behaviour is to silently delete anything else: its always done that.
In future it may also modify the ASN1 string types in the request to
match PKIX guidelines.
If the -preserveDN option is set then it will copy the DN verbatim.
> As it is, one could think that the "emailAddress" lines in the
> req_distinguished_name section in openssl.cnf should simply be moved
> to the req_attributes section. Unfortunately, it's not that easy,
> because that would basically make emailAddress a standalone attribute
> instead of making it one of the values in subjectAltName.
>
> A real solution for this would be to have a third section that
> contains things to be prompted for, but that don't end up directly in
> the request, but would rather be internal values that would be used in
> lines like this:
>
> subjectAltName=email:copy
>
> That lines would require that emailAddress as is now in
> req_distinguished_name would be moved to that third, yet unnamed
> section.
>
> I think that in the long run, that would be a better soltuion than the
> hack to strip out things from the subject DN
>
The best solution is to include extensions in the certificate request
and have the 'ca' program add them. There are all sorts of things which
might appear in there other than subjectAltName, such as requesting
certain keyUsage bits (e.g. signing only) or extended key usage values.
Unfortunately the highly variable syntax for these extensions makes it
hard to just prompt for their values in a general way. One possible
solution would be to use a scipting language (e.g. perl) to build up a
config file based on the values and use that to generate the request.
In OpenSSL 0.9.7-dev the 'ca' utility can now copy extensions from a
request to the user certificate. I added this because its now possible
to customise the display of the certificate before it is signed so you
can actually see the extensions which would be added, to avoid someone
requesting a CA certificate without alerting the user.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
