diff options
author | Dr. Stephen Henson <steve@openssl.org> | 2000-02-05 21:07:56 +0000 |
---|---|---|
committer | Dr. Stephen Henson <steve@openssl.org> | 2000-02-05 21:07:56 +0000 |
commit | 66430207a4de2160082d84bb69feedde9cf7ac83 (patch) | |
tree | bc63386f4719a4e96c79f9c4d86834a9f8f4e110 /doc/apps/pkcs8.pod | |
parent | eb5a6a55c51a7409da9433afc15efa9d5ec2f93a (diff) | |
download | openssl-66430207a4de2160082d84bb69feedde9cf7ac83.tar.gz |
Add support for some broken PKCS#8 formats.
Diffstat (limited to 'doc/apps/pkcs8.pod')
-rw-r--r-- | doc/apps/pkcs8.pod | 32 |
1 files changed, 26 insertions, 6 deletions
diff --git a/doc/apps/pkcs8.pod b/doc/apps/pkcs8.pod index a7d2932100..359eb6f898 100644 --- 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 |