Add support for some broken PKCS#8 formats.

[openssl.git] / doc / apps / pkcs8.pod

diff --git a/doc/apps/pkcs8.pod b/doc/apps/pkcs8.pod
index 171b58b4b8404f57e3d7e6b46d068287596bb5c3..359eb6f8984db031de14c5e979c74a561fbb545c 100644 (file)
--- a/doc/apps/pkcs8.pod
+++ b/doc/apps/pkcs8.pod
@@ -19,6 +19,8 @@ B<openssl> B<pkcs8>
 [B<-noiter>]
 [B<-nocrypt>]
 [B<-nooct>]
+[B<-embed>]
+[B<-nsdb>]
 [B<-v2 alg>]
 [B<-v1 alg>]
 
@@ -93,11 +95,24 @@ code signing software used unencrypted private keys.
 
 =item B<-nooct>
 
-This option generates private keys in a broken format that some software
+This option generates RSA private keys in a broken format that some software
 uses. Specifically the private key should be enclosed in a OCTET STRING
 but some software just includes the structure itself without the
 surrounding OCTET STRING.
 
+=item B<-embed>
+
+This option generates DSA keys in a broken format. The DSA parameters are
+embedded inside the PrivateKey structure. In this form the OCTET STRING
+contains an ASN1 SEQUENCE consisting of two structures: a SEQUENCE containing
+the parameters and an ASN1 INTEGER containing the private key.
+
+=item B<-nsdb>
+
+This option generates DSA keys in a broken format compatible with Netscape
+private key databases. The PrivateKey contains a SEQUENCE consisting of
+the public and private keys respectively.
+
 =item B<-v2 alg>
 
 This option enables the use of PKCS#5 v2.0 algorithms. Normally PKCS#8
@@ -202,11 +217,16 @@ Convert a private key from any PKCS#8 format to traditional format:
 
 =head1 STANDARDS
 
-Test vectors from this implementation were posted to the pkcs-tng mailing
-list using triple DES, DES and RC2 with high iteration counts, several
-people confirmed that they could decrypt the private keys produced and
-Therefore it can be assumed that the PKCS#5 v2.0 implementation is
-reasonably accurate at least as far as these algorithms are concerned.
+Test vectors from this PKCS#5 v2.0 implementation were posted to the
+pkcs-tng mailing list using triple DES, DES and RC2 with high iteration
+counts, several people confirmed that they could decrypt the private
+keys produced and Therefore it can be assumed that the PKCS#5 v2.0
+implementation is reasonably accurate at least as far as these
+algorithms are concerned.
+
+The format of PKCS#8 DSA (and other) private keys is not well documented:
+it is hidden away in PKCS#11 v2.01, section 11.9. OpenSSL's DSA private
+key format complies with this standard.
 
 =head1 BUGS
 
@@ -219,6 +239,7 @@ the old format at present.
 
 =head1 SEE ALSO
 
-dsa(1), rsa(1), genrsa(1), gendsa(1)
+L<dsa(1)|dsa(1)>, L<rsa(1)|rsa(1)>, L<genrsa(1)|genrsa(1)>,
+L<gendsa(1)|gendsa(1)> 
 
 =cut