Miklos Vajna
2018-01-04 21:50:59 UTC
Hi,
When I was working on ECDSA support for the NSS backend, I noticed that
the mscrypto backend can't have the same support, as Microsoft is not
adding that feature to its CryptoAPI, which seems to be deprecated today
[1].
As far as I see the replacement is the CNG API [2], which has relatively
good documentation, so doing similar things with CNG (compared to
CryptoAPI) sounds doable.
Adding CNG support as part of the existing mscrypto backend sounds quite
problematic, though -- since most of that backend is CryptoAPI calls,
while the point would be eliminating those.
So perhaps the best way forward would be a new backend (let's name it
"mscng" e.g.), even if that would mean a little duplication (e.g.
CryptAcquireCertificatePrivateKey() is needed in both contexts,
depending on arguments it either returns a CNG NCRYPT_KEY_HANDLE or a
CryptoAPI HCRYPTPROV). That way also the new backend would be "clean"
from wincrypt.h (and similarly mscrypto would be not polluted by
ncrypt.h and so on).
Does this sounds like a good direction to go? My hope would be that even
with my limited free time I could implement an initial mscng backend
that has one working use-case (e.g. ecdsa/sha256 dsig verification,
something not supported by mscrypto), get that reviewed, and once that
looks good, we can iterate from there. And once (long-term) it's on par
with the mscrypto backend feature-wise, it can be discussed what to do
with the mscrypto backend. But that's a lot of work of course.
I'm asking if adding CNG support in the form of a new mscng backend is
OK as I would like to avoid writing the boilerplate code for a new
backend if that is seen as the wrong approach anyway. :-)
Thanks,
Miklos
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380252(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx
When I was working on ECDSA support for the NSS backend, I noticed that
the mscrypto backend can't have the same support, as Microsoft is not
adding that feature to its CryptoAPI, which seems to be deprecated today
[1].
As far as I see the replacement is the CNG API [2], which has relatively
good documentation, so doing similar things with CNG (compared to
CryptoAPI) sounds doable.
Adding CNG support as part of the existing mscrypto backend sounds quite
problematic, though -- since most of that backend is CryptoAPI calls,
while the point would be eliminating those.
So perhaps the best way forward would be a new backend (let's name it
"mscng" e.g.), even if that would mean a little duplication (e.g.
CryptAcquireCertificatePrivateKey() is needed in both contexts,
depending on arguments it either returns a CNG NCRYPT_KEY_HANDLE or a
CryptoAPI HCRYPTPROV). That way also the new backend would be "clean"
from wincrypt.h (and similarly mscrypto would be not polluted by
ncrypt.h and so on).
Does this sounds like a good direction to go? My hope would be that even
with my limited free time I could implement an initial mscng backend
that has one working use-case (e.g. ecdsa/sha256 dsig verification,
something not supported by mscrypto), get that reviewed, and once that
looks good, we can iterate from there. And once (long-term) it's on par
with the mscrypto backend feature-wise, it can be discussed what to do
with the mscrypto backend. But that's a lot of work of course.
I'm asking if adding CNG support in the form of a new mscng backend is
OK as I would like to avoid writing the boilerplate code for a new
backend if that is seen as the wrong approach anyway. :-)
Thanks,
Miklos
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380252(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx