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
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
