This is necessary in order to add proper support for CSRs in kx509,
where the KDC can examine all requested KUs/EKUs/SANs, check
authorization, and issue a certificate with all those extensions if
authorized.
This is the convention used by OpenSSL, of encoding all the KU, EKUs,
and SANs being requested as Extensions as they would appear in the
TBSCertificate, then putting those in as a single Attribute in the CSR's
Attributes list with attribute OID {id-pkcs-9, 14}.
- expose all hx509_request_*() functions
- finish support in hx509_request_parse*() for KU, EKU, and SAN CSR
attributes
- finish support in hx509_request_to_pkcs10() for encoding all
requested KU, EKU, and SAN extensions as a CSR extReq (extension request)
- add hx509_request_add_*() support for:
- id-pkinit-san and ms-upn-pkinit-san
- XMPP (Jabber) SAN
- registeredID (useless but trivial)
- add hxtool request-create options for all supported SANs
- add hxtool request-create options for KeyUsage
- add hxtool request-create options for ExtKeyUsage
- add hxtool request-print support for all these things
- fix bugs in existing id-pkinit-san handling
Possible future improvements
- add HX509_TRACE env var and support (it would be nice to be able to
observe why some certificate is rejected, or not matched in a query)
- add testing that CSR creating and printing round-trip for all KUs,
EKUs, and SANs
(probably in tests/kdc/check-pkinit.in)
- add testing that OpenSSL can print a CSR made by hxtool and
vice-versa
- hxtool ca: add KU sanity checking (via hx509_ca_sign() and/or friends)
(don't allow encrypt for signing-only algs)
(don't allow encrypt for RSA at all, or for RSA with small e exponents)
- hxtool request-print: warn about all unknown attributes and
extensions
- hxtool ca: MAYBE add support for adding requested extensions from the
--req=CSR
("Maybe" because CA operators should really verify and authorize all
requested attributes, and should acknowledge that they have, and the
simplest way to do this is to make them add all the corresponding
CLI arguments to the hxtool ca command, but too, that is
error-prone, thus it's not clear yet which approach is best.
Perhaps interactively prompt for yes/no for each attribute.)
- add additional SAN types:
- iPAddress (useless?)
- dNSSrv (useful!)
- directoryName (useless, but trivial)
- uniformResourceIdentifier (useful)
- it would be nice if the ASN.1 compiler could generate print
functions..., and/or even better, to-JSON functions
- it would be nice if we had a known-OID db, including the names of the
types they refer to in certificate extensions, otherName SANs and CSR
attributes, then we could generate a CSR and certificate printer for
all known options even when they are not supported by the rest of
Heimdal
- and we could also get friendly names for OIDs, and we could
resolve their arc names
- longer term, we could also stand to add some ASN.1 information
object system functionality, just enough to make
lib/hx509/asn1_print awesome by being able to automatically decode
all heim_any and OCTET STRING content (better than its current
--inner option)
Now we'll use mkostemp() and rename() into place to make
hx509_certs_store() atomic for FILE/DER-FILE/PEM-FILE stores.
This is not ideal, as it can leave temp files in place if a process
crashes in between the mkostemp() and the rename into place.
On Linux we'll eventually make use of O_TMPFILE and linkat(). The idea
will be to first create an anonymous, zero-link file in the directory
that will contain the file at the end, write the file, then linkat() the
file into place as a .new file, then rename() the .new into place. That
will limit the amount of junk that may be left behind to just one file.
(If the linkat() fails, then unlink() the .new and try again. If the
rename() fails that just means the caller raced with another and the
operation is complete.)
We should really make a lib/roken interface that does this.
This will help us generate a directory of OIDs from all the ASN.1
modules in lib/asn1, which will then help us create an hx509 API for
resolving OIDs to/from friendly names, which ultimately will help us
make hxtool more user-friendly.
This is necessary in order to have more control over, e.g., template
certificates for kx509. But also it's good to have this more generally.
Some batteries not included. Specifically: no attempt is made to validate that
given KeyUsage values are compatible with the subjectPublicKey's alrogithm and
parameters.
```
hxtool request-create --subject=... \
--generate-key=... \
--key-bits=... \
--key=STORE \
store
```
wants to generate a key, store it in the location specified by the --key
argument, then read it back, then generate the CSR, and store it in
`store`.
But it didn't work because for generating a key this really wants the
`--key` argument to be a file path into which a raw DER-encoded RSA key
will be written (only RSA is supported, ay!), but for reading the key
back it uses `hx509_certs_init()`, which wants `TYPE:name` keystore
specification. A deadly embrace.
Now that we have improved libhx509 functionality for reading/writing
private keys from/to PEM files we use this functionality and require a
store type in the `--key=STORE` argument.
This commit adds:
- hx509_cert_init_private_key() for creating an hx509_cert object that
has just a private key
- hx509_cert_have_private_key_only() for checking whether an hx509_cert
object has just a private key
This also generalizes the get_key() internal function in hxtool, which
is tasked with reding or generating a private key for use in signing
CSRs. Now hxtool request-create can read/write private keys to/from PEM
files, not just DER files.
This is needed to support key types other than just RSA for CSRs and
certificates.
Modern OpenSSL no longer has the 2038 year restriction. Update the
certs to last 500 years rather than 10 years.
Modern crypto requirements suggest a stronger key strength than 1024.
Update to use a minimum of 4096.
Fix executable bit on gen-req.sh
On 32-bit Windows Intel builds the __cdecl and __stdcall calling
conventions are different so labeling the functions that are
exported or assigned to function pointers matters.
Change-Id: I03b6f34baeb9ffb2e683fd979f12f27a5078a4da
libhx509 is not built according to the same export and calling conventions
on Windows as the other libraries. This change declares and applies
HX509_LIB_FUNCTION, HX509_LIB_NORETURN_FUNCTION, HX509_LIB_CALL and
HX509_LIB_VARIABLE to lib/hx509.
As a result of this change the calling convention for exported functions
will be __stdcall instead of __cdecl.
Change-Id: Ibc3f05e8088030ef7d13798f1d9c9b190bc57797
Using non-reentrant getpwuid() (or getpwnam(), or getspnam()) can be
dangerous. We had a report of a login application / PAM that calls
those, and Heimdal, by calling them too, clobbered the cached struct
passwd used by the login app / PAM.
OpenSSL 1.1 has the pkInitKDC OID built in, which breaks as it was redefined by
openssl.cnf in Heimdal. Try to determine if OpenSSL >= 1.1 and if so, use a
configuration file that omits this OID definition. The implementation is not
robust but as this is simply an example (not run by the test suites), it should
be adequete.
When comparing the first component of a multi-component
string that uses a field separator (e.g., '/' or ':'), be sure
to include the separator in the comparison to ensure that the
comparison does not succeed due to a prefix match.
Change-Id: Ieec3e73cb015a83bb652ec11cd7d83e57755c3d2
