Re: [Fed-Talk] SmartCard Login
Re: [Fed-Talk] SmartCard Login
- Subject: Re: [Fed-Talk] SmartCard Login
- From: "Timothy J. Miller" <email@hidden>
- Date: Tue, 28 Feb 2006 08:23:24 -0600
Paul Nelson wrote:
There is no
documented way to determine which smartcard certificate should be used to
attempt the as_req.
I forgot to respond to this before. In fact, this part is easy.
There are three certs on a CAC; one for email signing, one for identity
authentication (little used), and one for email encryption.
Insofar as the PKINIT standard is concerned, any cert with the right key
usage (digital sig) can work. There are two of these on the CAC: the
email signing and the identity certificates.
However, Windows levies additional certificate profile requirements. In
particular, it will (currently) only accept certificates that also
contain the smartcard logon (SCL) enhanced key usage OID
(1.3.6.1.4.1.311.20.2.2) *and* contain the user's AD
universalPrincipalName in the subjectAlternativeName extension.
(Technically, it's an ASN.1 encoded blob stuffed into an otherName type
field in the SAN extension.) There's only one cert on the CAC that
meets both of these requirements: the email signing certificate.
So for now, look for the SCL OID and use that cert. If you need the
user's account (the UPN), it can be extracted from the same cert.
The DoD PKI made a conscious choice to avoid "customizing" certificates
to meet application requirements whenever possible; and when impossible
to avoid, the custom extensions all go into the email signing certificate.
Toward that end, Vista makes some significant changes regarding SCL, at
the DoD PKI's behest. In Vista Server environments there will be *no*
certificate profile requirements specific to SCL (aside from basic key
usage constraints, of course). This will allow us to map *both* the
email signing and the ID certs to an account, and either will work just
fine. So the cert selection logic will get even simpler; you can even
let the user choose.
The JITC CACs you get will have all this in their certs.
A word about UPNs:
In AD, your UPN is your account name plus your home domain FQDN (frex.,
email@hidden). This is *not necessarily* your email address, so
*don't* use the rfc822Name that's also in the certificate when you need
the UPN.
But we do UPNs a little differently in the DoD. Because of some complex
infrastructure issues, we create user UPNs using the user's electronic
data interchange personal identification (EDIPI) number, with the domain
FQDN portion set to @mil. EDIPIs are 10-digit numbers that (supposedly)
replaced SSNs for ID purposes. (JITC CACs use fake EDIPI numbers, but
the data is present in the email signing certs.)
Yes, this creates cross-forest issues in AD, but we don't do
cross-forest stuff right now, so we avoid those issues. Vista's changes
to SCL certificate requirements completely solve this issue for us: the
certificate will no longer be the source for UPN data. GINA will prompt
the user for an account name as well as their CAC PIN. This opens up
the ability to map one certificate to more than one account, which is an
extremely important capability for us to have.
-- Tim
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden