Hi all,
I am ri-posting this message as I have received no replies to it.
If no one is interested in the proposals then simply ignore this
message.
---ooooOOOOoooo------
[ openssl ca command improve ]
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 (empty DNs, etc... )...
This is a quite big work to be done.
I am not sure but I think it can be done without backward compatibility
issues rising...
[ libca development ]
Another idea worth exploring could be the writing of a libca where ca
functions are held as most of them are getting quite big and important
and having in one large ca.c should be avoided.
I am not sure this is the scope of the openssl project but as this lib
will be strictly tied with openssl library itself it could be useful
having it together with the package.
--
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
