[openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote:
> That being said, though, your recommendation should probably specify
> (after discussing it) exactly what keys, certs and so on should be
> supported. Otherwise, everyone will have a slightly different idea of
> what's reasonable and you will end up in the same space as today... 

Oh $DEITY yes, that's the whole point. And I don't think I've left much
ambiguity there. As ever, suggestions for improvement would be most
welcome...

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.1

4.1.  File name

   Many applications support the use of certificates and private keys
   stored in files on the file system.  Such applications MUST support
   the use of files in any of the formats mandated in Section 5, in both
   PEM and DER containers.

   Applications MUST NOT require the user to provide any additional
   hints regarding the contents of the file, such as whether the
   contents are in PEM or DER format.  This MUST be determined by the
   application itself, automatically.

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#formats

5.  File formats

   ...

   Applications MUST accept all of the formats below without requiring
   any additional information from the user or the configuration.  Where
   an application has an existing "key format" or similar option which
   has historically been required to disambiguate between formats
   (either the formats below or between PEM and DER), application SHOULD
   NOT document this use of that legacy option as current practice, and
   SHOULD default to working it out automatically.  Application authors
   who cannot achieve this SHOULD consider taking up goat farming, and
   never touching a cryptographic application again in their life.

5.1.  PKCS#1 and other native ASN.1 encodings

   Applications MUST support unencrypted private keys:

   o  RSA keys in PKCS#1 form as defined by [RFC2437]
   o  DSA keys in the ASN.1 form defined by OpenSSL and documented in
      Appendix B (if DSA keys are supported at all)
   o  ECDSA keys in the form defined by [RFC5915]
   o  EdDSA keys in the form defined by [I-D.ietf-curdle-pkix]

5.2.  PKCS#8

   Applications MUST support keys stored in PKCS#8 form as defined in
   [RFC5208] for all key types.  Applications MUST support unencypted
   PKCS#8 objects, as well as those which are encrypted in various forms
   as discussed in Section 6.1.

   Applications MAY support the updated version of PKCS#8 is defined in
   [RFC5958]. ...

5.3.  PKCS#12

   Applications MUST support the use of certificates and keys from
   PKCS#12 objects ([RFC7292]), encrypted with any of the the methods
   mandated in Section 6.1.  Applications MUST support the use of at
   least SHA1 and SHA256 HMAC, and SHOULD support other HMAC algorithms
   which become common.

6.  Private keys

6.1.  Encryption

   Applications MUST support the encrypted PEM files in the form based
   on [RFC1423] which is commonly used by historical versions of
   OpenSSL, with at least the DES-EDE3-CBC, AES-128-CBC and AES-256-CBC
   modes.

   For PKCS#12 [RFC7292] and PKCS#8 [RFC5208] formats, applications MUST
   support reading objects stored with the following encryption methods:

   o  PBES1 pbeWithMD5AndDES-CBC [RFC2898]
   o  PBES1 pbeWithSHA1And3-KeyTripleDES-CBC [RFC7292]
   o  PBES2 AES-128-CBC (OID: 2.16.840.1.101.3.4.1.2) [RFC2898]
   o  PBES2 AES-256-CBC (OID: 2.16.840.1.101.3.4.1.42) [RFC2898]

   The weak methods included in the above list are unfortunately still
   commonplace, and thus clients need to keep supporting them as noted
   in Section 11.  However, applications MAY emit a warning to the user
   when weak (or no) encryption is used, and MAY require an additional
   configuration directive to enable the use of weakly-encrypted and
   unencrypted keys.

   The presence of these algorithms in the list is not in any way to be
   taken as approval for tools to continue creating objects in such
   forms.  Except for a brief discussion in Section 6.3. the creation of
   private keys is outside the scope of this document.

   ...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161124/21c76a68/attachment.bin>