-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New API Proposal: PKCS#12 Support #114
Comments
I'm generally a bit reluctant to get too far down into supporting PKCS#12. It's a very complex and general format, that also has a lot of legacy baggage. For example, PBES1 is typically used to protect the contents, a scheme that uses either DES or RC2 as the bulk cipher. Neither of those are good choices in 2023, and we don't have Swift API for them. PBES2 is conceptually more broadly useful, but still requires a bunch of new primitives in swift-crypto that represent poor cryptographic choices. In general, I think I'd prefer to allow other tools to produce PKCS#12 files. There are a wide range of API surfaces for achieving this outcome on a number of platforms, and it would probably be better to delegate to those APIs. |
Fair point about it being an interesting format. As for the crypto behind it, it is already implemented at OpenSSL/BoringSSL, so I believe we should somehow be able to map those implementations to Swift. If you do feel that PBES1/PBES2 is insufficient, there's also the option to not provide any password (seems more insufficient); the last one would mean that someone can just encrypt the file using the contemporary cryptographic primitives.
This should never be an argument to not implement something. Anything can be made! 💪🏼
We do have an
In the meantime, can you point me at such tools, preferably in Swift/Objective-C/iOS/macOS? |
Sure, that's very do-able. The question is much more about whether we should do it. The trade-off that CryptoKit (and by extension Crypto) have tried to make has been about being opinionated. Where possible, we don't want to allow sharp edges that make it too attractive or easy to use primitives that are no longer up to the task. You're right that the DES, RC2, and 3DES are in a very different boat. Bringing these algorithms, which are all superseded by stronger and better alternatives, into something like Swift Crypto is really quite substantially risky. A good suggestion for how to manage this would be to consider implementing the PKCS#12 support in a separate package. This package could depend on swift-certificates (for certs), swift-asn1 (for the PKCS#12 DER), and then bring its own implementations of the encryption primitives. That allows users who require PKCS#12 to obtain it, without pushing the weaker crypto primitives into the core Swift cryptography libraries.
The easiest shortcut tool is swift-nio-ssl: adding support to that library to be able to produce PKCS#12 files is a good first step. The OpenSSL command line tool is also capable of achieving this. So can Keychain Access on macOS. |
New API Proposal: PKCS#12 Support
Motivation:
Thinking of X.509, certificates and keys and ways to transport these at once, one must have ran into the PKCS#12 standard. It's an archive file format used for storing all kinds of cryptography objects. It's often used to, but not limited to:
Importance:
A quick search reveals that there are some existing server side/native implementations that already have some form of PKCS#12 occurrence already (swift-nio-ssl, Uniform Type Idnetifiers, ...) and I feel like this certificate library is a good fit to have some form of PKCS#12 support too, which may be limited to combining a private key and a related certificate into a container, or combining the certificate chain into a container.
The text was updated successfully, but these errors were encountered: