Bodo Moeller wrote:
> > Do you prefer the patch against the pre-patched version or against the
> > patched version of the ca.pod file ?
>
> I'd prefer one for the patched version (but it shouldn't really matter
> if you use a context or unified diff).
Here it is. I think it should be "error" free, anyway if you have time check
it before submission (:-D).
> I don't think anyone has plans for that currently. If large-impact
> changes are needed, this should be discussed on openssl-dev.
Yes, I know. I have to check. Some work could be initially done by
introducing another switch (and conf keyword) to enable/disable the
usage of the index.txt backend during certificate issuing --> this
would enable using ca command with "unsupported" certificate profiles
(such as duplicate DNs).
Then, with patience, it should be a good thing starting a rewriting of
the backend db support ... and then, only then, we could start adding
new RFCs supported certificate profiles... This is a quite big work
to be done and I am not sure it can be done without backward
compatibility issues rising...
Another idea worth exploring could be the writing of a libca where ca
functions are held but I am not sure this is the scope of the openssl
project... anyway as this is strictly tied with openssl library itself
it could be useful having it together with the package.
I will forward this e-mail to the openssl-dev mailing list also to get
the feeling about all this stuff.
--
C'you,
Massimiliano Pala
--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.org Tel.: +39 (0)59 270 094
http://openca.sourceforge.net Mobile: +39 (0)347 7222 365
--- ca.pod Mon Oct 22 19:20:50 2001
+++ ca.pod.new Mon Oct 22 19:20:25 2001
@@ -34,6 +34,7 @@
[B<-spkac file>]
[B<-ss_cert file>]
[B<-preserveDN>]
+[B<-noemailDN>]
[B<-batch>]
[B<-msie_hack>]
[B<-extensions section>]
@@ -157,6 +158,16 @@
older IE enrollment control which would only accept certificates if their
DNs match the order of the request. This is not needed for Xenroll.
+=item B<-noemailDN>
+
+The DN of a certificate can contain the EMAIL field if present in the
+request DN, however it is good policy just having the e-mail set into
+the altName extension of the certificate. When this option is set the
+EMAIL field is removed from the certificate' subject and set only in
+the, eventually present, extensions. The B<email_in_dn> keyword can be
+used in the configuration file to enable this behaviour.
+
+=item B<-batch>
=item B<-batch>
this sets the batch mode. In this mode no questions will be asked
@@ -437,6 +448,7 @@
default_md = md5 # md to use
policy = policy_any # default policy
+ email_in_dn = no # Don't add the email into cert DN
nameopt = default_ca # Subject name display option
certopt = default_ca # Certificate display option
@@ -518,8 +530,11 @@
B<CA.pl> help a little but not very much.
Any fields in a request that are not present in a policy are silently
-deleted. This does not happen if the B<-preserveDN> option is used.
-The behaviour should be more friendly and configurable.
+deleted. This does not happen if the B<-preserveDN> option is used. To
+enforce the absence of the EMAIL field within the DN, as suggested by
+RFCs, regardless the contents of the request' subject the B<-noemailDN>
+option can be used. The behaviour should be more friendly and
+configurable.
Cancelling some commands by refusing to certify a certificate can
create an empty file.
S/MIME Cryptographic Signature
