- Giving asn1_compile the name of an ASN.1 module w/o the ".asn1" stem
will cause the compiler to add the ".asn1" stem, and it will cause
the compiler to look for a ".opt" file as well.
- The default C module name substring derivation from the .asn1 file
name is improved.
- There is now a --gen-name=NAME option for specifying the C module
name substring. This is useful for specifying that in a .opt file.
- More options now have helpful usage messages.
This will allow simplification of lib/asn1/Makefile.am's invocations of
asn1_compile.
We may well end up requiring the automatic .opt file finding feature
when we eventualy add support for parsing multiple modules in a single
invocation for better support of IMPORTs.
Many external ASN.1 modules that we have imported over time define types
like this:
Foo ::= SEQUENCE { bar Bar }
Bar ::= SEQUENCE { aMember INTEGER }
and before this change one had to re-order the definitions so that the
one for `Bar` came first. No more.
We can now have out of order definitions in ASN.1 modules and the
compiler will topologically sort output C type declarations so that one
no longer has to manually sort types in ASN.1 modules when importing
them.
Besides that, it is now possible to create circular data types using
OPTIONAL since we generate such fields as pointers (which can then be
pointers to incomplete struct declarations):
Circular ::= SEQUENCE {
name UTF8String,
next Circular OPTIONAL
}
Circular types aren't necessarily useful, but they have been used in the
past. E.g., the rpc.mountd protocol uses a circular type as a linked
list -- it should just have used an array, of course, as that's
semantically equivalent but more space efficient in its encoding, but
the point is that such types exist out there.
C enum labels have to be globally unique. ASN.1 module ENUMERATED and
INTEGER types with named values are not globally unique. This means
that ASN.1 integer type value names and enumerations can cause conflicts
when compiled to C.
This new option allows the user to specify a prefix to apply to such
names. Then this:
Foo ::= ENUMERATED { v1 (0) }
can generate:
typedef enum Foo {
prefix_v1 = 0,
} Foo;
instead of
typedef enum Foo {
v1 = 0,
} Foo;
which is very likely to conflict.
TBD: Add option to use the type name as the prefix?
TRUE/FALSE may not be defined, so emitting those symbols when generating
code for `... BOOLEAN DEFAULT TRUE -- or FALSE` causes the generated
code to fail to compile. We could move the definitions of TRUE/FALSE to
krb5-types.h, or maybe we could have an asn1_compile option to force
inclusion of more than one header file so we can have headers defining
such constants. But the simplest fix is to just emit 1/0 instead of
TRUE/FALSE.
This explains why some BOOLEAN DEFAULT usages in PKIX are made OPTIONAL
in Heimdal.
In preparation for adding support for TPM attestations as an authentication
method in bx509d for a host trust bootstrap mechanism based on TPMs and their
endorsement keys and endorsement key certificates.
The plan is to add support to libhx509 and hxtool for PermanentIdentifier
(RFC4043) and HardwareModuleName (RFC4108) SANs, and then to add a query
parameter to bx509d for passing an attestation and a proof-of-possession
(either CMS or CSR), and add an authorizer plugin call for authorizing a device
manufacturer and serial number to hostname. Support for TPMs w/o endorsement
key certificates should also be possible based on a digest of the endorsement
key as the "serial number".
On Windows i386 the asn1 tests would crash due to stack corruption
as a result of functions being executed with the wrong calling
conventions.
Change-Id: Ic4f8b3a05dad36e3db6397fbd9270b98f0a5dfc5
The code generators were shifting "1LU" by (<< 32) and (<< 63) which
are undefined operations for a 32-bit integer. To ensure the integer
is 64-bit use "1ULL".
Change-Id: I062cae5638139a9fe51563f64b1964f87e2f49e3
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?
This commit adds support for proof of posession to the kx509 protocol by
using PKCS#10 CSRs.
This allows conveyance of extReq CSR attributes requesting desired
Certificate Extensions.
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)
This commit adds support for kx509 in libkrb5, and revamps the KDC's
kx509 service (fixing bugs, adding features).
Of note is that kx509 is attempted optimistically by the client, with
the certificate and private key stored in the ccache, and optionally in
an external PEM or DER file.
NOTE: We do not optimistically use kx509 in krb5_cc_store_cred() if the
ccache is a MEMORY ccache so we don't generate a key when
accepting a GSS context with a delegated credential.
kx509 protocol issues to be fixed in an upcoming commit:
- no proof of possession (this is mostly not too bad, but we'll want to
fix it by using CSRs)
- no algorithm agility (only plain RSA is supported)
- very limited (no way to request any options in regards to the
requested cert)
- error codes are not very useful
Things we're adding in this commit:
- libkrb5 kx509 client
- automatic kx509 usage hooked in via krb5_cc_store_cred() of start TGT
- per-realm templates on the KDC side
- per-realm issuer certificates
- send error messages on the KDC side
(this is essential to avoid client-side timeouts on error)
- authenticate as many error messages
- add a protocol probe feature so we can avoid generating a
keypair if the service is not enabled
(once we add support for ECC algorithms we won't need this
anymore; the issue is that RSA keygen is slow)
- support for different types of client principals, not just username:
- host-based service and domain-based service, each with its own
template set per-{realm, service} or per-service
(the idea is to support issuance of server certificates too, not
just client/user certs)
- more complete support for SAN types
- tests (including that PKINIT->kx509->PKINIT works, which makes it
possible to have "delegation" of PKIX credentials by just delegating
Kerberos credentials)
- document the protocol in lib/krb5/kx509.c
Future work:
- add option for longer-ticket-lifetime service certs
- add support for ECDSA, and some day for ed25519 and ed448
- reuse private key when running kinit
(this will require rethinking how we trigger optimistic kx509
usage)
- HDB lookup for:
- optional revocation check (not strictly necessary)
- adding to certificates those SANs listed in HDB
- hostname aliases (dNSName SANs)
- rfc822Name (email)
- XMPP SANs
- id-pkinit-san (a user could have aliases too)
- support username wild-card A RRs, ala OSKT/krb5_admin
i.e., if a host/f.q.d.n principal asks for a certificate for
some service at some-label.f.q.d.n, then issue it
(this is not needed at OSKT sites because OSKT already
supports keying such service principals, which means kx509
will issue certificates for them, however, it would be nice
to be able to have this independent of OSKT)
(a better way to do this would be to integrate more of OSKT
into Heimdal proper)
- a kx509 command, or heimtools kx509 subcommand for explicitly
attempting use of the kx509 protocol (as opposed to implicit, as is
done in kinit via krb5_cc_store_cred() magic right now)
Issues:
- optimistically trying kx509 on start realm TGT store -> timeout issues!
- newer KDCs will return errors because of this commit; older ones
will not, which causes timouts
- need a separate timeout setting for kx509 for optimistic case
- need a [realm] config item and DNS SRV RR lookup for whether a
realm is expected to support kx509 service
Prior to this commit the Heimdal ASN.1 compiler supported DEFAULTing
SEQUENCE fields on the encoder side, but not the decoder side, where
ASN1_MISSING_FIELD would inevitably result when fields were defaulted.
This patch adds the missing decode-side support for DEFAULT.
This commit adds functions for finding OIDs by symbolic name, meaning by
their symbolic names given in the ASN.1 modules that define them.
TBD:
- Resolve OIDs to names.
- Support a file in /etc for additional OID resolution.
- Add support for resolving OID arc names.
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.
the code generated by asn1_compile.exe includes a large number
of unreferenced local variables. The resulting warnings drown
out other potentially more serious warnings.
This change suppresses the C4101 warnings in the generated
source files.
Change-Id: I17642ff427f457c885b1eb0e62436f3bc9057ee1
