e30a09e604
As with SPKI parsers, the intent is make EVP_PKEY capture the key's constraints in full fidelity, so we'd have to add new types or store the information in the underlying key object if people introduce variant key types with weird constraints on them. Note that because PKCS#8 has a space for arbitrary attributes, this parser must admit a hole. I'm assuming for now that we don't need an API that enforces no attributes and just ignore trailing data in the structure for simplicity. BUG=499653 Change-Id: I6fc641355e87136c7220f5d7693566d1144a68e8 Reviewed-on: https://boringssl-review.googlesource.com/6866 Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
CMakeLists.txt | ||
internal.h | ||
p5_pbe.c | ||
p5_pbev2.c | ||
p8_pkey.c | ||
pkcs8_test.cc | ||
pkcs8.c | ||
pkcs12_test.cc |