Add two ways to exclude private keys when dealing with an hx509
certificate store. One as a load option (load no private keys, never
add private keys), one as a store option (store no private keys).
This is useful for CA code so it can have a single store with the
issuer's credentials _and_ the chain for it, and copy those to a store
with the issued certificate and _not_ accidentally include the issuer's
private key.
It would be much safer still to flip the default for this flag, but that
could break out-of-tree libhx509 dependents.
krb5_kdc_process_request() must return 0 when it produces a reply, and only
return non-zero when it could not construct any kind of reply (e.g., ENOMEM, or
-1 if no handler claimed responsibility for the request).
We take all of the kdc_log() and _kdc_r_log() calls in AS and TGS
and move their log levels down to debugging on the assumption that
our new log line subsumes the "informational" requirements. We
collect some additional information in the kv-pair "pe-text" which
is like e-text except it is not returned to the client.
We refactor the code a bit to extend kdc_request_t which until now
was only used for the AS. We make the structure extensible and
start using it for the TGS as well. We leave digest and kx509
alone for the time being.
We also define the concept of kv-pairs in our audit trail which
allows us to define a rigorous but extensible format:
type error from-addr client server key1=val1 key2=val2 ...
Our logging framework used to strnvisx(3) each and every line
iff it is written to a FILE. This is often unhelpful because
the line usually contains a number of elements that have already
been quoted and it makes the logs much more difficult to read in
this case. An example if krb5_unparse_name() which will already
quote most characters that one cares about.
We change the behaviour to simply drop unprintable characters
rather than encoding them. We thus rely on the rest of the
code to properly encode data elements written into the logs.
This commit adds a few functions for marking KU, EKUs, and SANs as
authorized, and for getting a count of unsupported certificate
extensions requested, and a count of authorized KU/EKUs/SANs.
The intent is to make it easier to build CSR authorization and CA code
that is robust in the face of future support for certificate extensions
and SAN types not currently supported. An application could parse a
CSR, iterate all KU/EKUs/SANs, check a subject's authorization to them,
mark them authorized where authorized, then check if there are any
remaining unauthorized extensions or unsupported extensions requested.
Ultimately, if a CSR's KU/EKUs/SANs are all authorized, then they can
all be copied to a TBS, and a certificate can be issued.
In 0cc708ba36, we removed the definition of id-ms-client-authentication
without a corresponding removal from lib/asn1/libasn1-exports.def.
Maybe we should generate lib*-exports.def?
