Byron Johnson wrote:
This is partly correct. DoD does not allow you to export private keys, they are stored and locked onto the CAC card. You can not authenticate someone, unless your server or meta-directory is granted access to do so. Currently I know of nothing but AKO that is allowed to do such. If you are inside AKO you can authenticate. Otherwise you are merely authorizing or validating the user credentials. The credentials for authorizing has nothing to do with the PKI private/public key pair. Instead one is only presenting the CN of the card and verifying via CRL's or OCSP responders that the card is not revoked.
Cert validation (CRLs or OCSP) is used during authentication, not authorization. SSL authentication, such as to AKO or the AF Portal, involves an exchange of certificates, trustpoint chaining, cert validation, *and* an exchange of private key proofs (otherwise anyone in possession of your certificate can authenticate as you).
Once authenticated, apps are pretty much free to make authZ decisions as they see fit. Most use the subject alternative names in the certs (such as the AD UPN to map the user's cert to a local authZ store, but I also know of applications that use the public key itself.
Technically speaking, the card is immaterial to this process. While DoD PKI certs loaded on CACs include an OID indicating that the keys were issued on a hardware token, I personally know of no applications that process this OID; we've encouraged it but most COTS products aren't that flexible. So a software key pair with the right certificate profile can also be used. However, the DoD is pretty strict about profiles usage in software certs.
-- Tim
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
