Re: [Fed-Talk] Two different PIV certificates on CAC?
Re: [Fed-Talk] Two different PIV certificates on CAC?
- Subject: Re: [Fed-Talk] Two different PIV certificates on CAC?
- From: "Miller, Timothy J." <email@hidden>
- Date: Tue, 11 Sep 2018 12:49:19 +0000
- Thread-topic: [Fed-Talk] Two different PIV certificates on CAC?
Remember there are two card edges (i.e., data models)--CAC and PIV--and each
exposes a slightly different view of the key containers on the card. This is
an artifact of the fact that the CAC predates the PIV specification by a fair
number of years.
There are actually 5 keypairs on a CAC; PIV-Auth, DoD-ID, DoD-Sign,
DoD-Encrypt, and Card-Auth.
The PIV card edge exposes PIV-Auth, DoD-Sign, DoD-Encrypt, and Card-Auth.
The CAC card edge exposes DoD-ID, DoD-Sign, and DoD-Encrypt. Depending on the
service issuer, the CAC card edge may also expose PIV-Auth. IIRC only the AF
links the PIV-Auth key to the CAC data model at card issuance. Anyone can link
PIV-Auth to the CAC card edge at the User Maintenance Portal/Post-Issuance
Portal (UMP-PIP).
These keys have overlapping purposes, as shown by their respective certs'
keyUsage and extendedKeyUsage extensions. The main overlap is between PIV-Auth
and DoD-Sign. Under the CAC card data model, DoD-Sign is used for signing
documents (incl. email) and login authentication to systems. Under the PIV
card data model, these purposes are separated; PIV-Auth is for login
authentication and DoD-Sign for signing documents.
Under the CAC data model, DoD-ID is used for proving user identity without
reference to other names (e.g., email identifiers). This ended up not being
all that useful in practice, so under the PIV model the ID key goes away and
that role is absorbed by the DoD-Sign key. There are still some personnel
systems that require the ID cert, however.
CACKey implements the CAC data model; the cert you're seeing is actually the
DoD-ID cert. Apple's framework implements the PIV data model; the cert you're
seeing there is the PIV-Auth cert. Therein lies the difference. :)
(FWIW, the Card-Auth key is to prove the validity of the card and issuer and is
only used in physical access control scenarios without user PIN entry. As a
result some middleware will simply ignore it--users should never be interacting
with it anyway.)
(And yes, I'll try to get some time to compile and test the module again. :)
-- T
On 9/10/18, 10:14 PM, "Fed-talk on behalf of Ken Hornstein"
<fed-talk-bounces+tmiller=email@hidden on behalf of
email@hidden> wrote:
This isn't technically a question about the Mac/OSX, but I know there are
a lot of smart people on here and I figured it wouldn't hurt to ask.
I've been developing a PKCS#11 interface to the Security framework (see
previous email on this topic, it's been coming along well), and I've
been using CACKey as a reference as to what a "working" PKCS#11 module
should do (since it's open source and seems to work with everything I
tried it with).
The big difference between my keychain-pkcs11 module and CACKey is
CACKey communicates directly with a smartcard, whereas keychain-pkcs11
uses the Security framework and lets the High Sierra supplied drivers
do the hard work of communicating with the card. Both CACKey and
the Security framework return 3 certificates from the CAC; 1 PIV
certificate, 1 email certificate, and 1 decryption certificate. Fine,
everyone knows this. But after some weird results I realized that there
are in fact _2_ PIV certificates on the CAC; CACKey returns one, and the
Security framework returns the other.
Now, specifically ... CACKey shows for my PIV certificate a certificate
signed by DOD ID CA-41, with a serial number of 1875831. The Apple
Security framework shows a PIV certificate also signed by DOD ID CA-41,
but with a serial number of 1875854 (the email certificate and the
decryption certificate are the same between PKCS#11 implementations).
These certificates have a lot of similarities; they have the same validity
dates, and the same subject name and issuer. They have different public
and associated private keys (that's how I first noticed). They also have
different key usage; the CACKey certificate shows key usage of Digital
Signature and Non Repudiation, whereas the Security key just has a key
usage of Digital Signature. There is also an additional policy OID
on the Security key, 2.16.840.1.101.3.2.1.3.13, which seems to be the
Federal PKI "common-auth" policy, and the extended key usage for the
Security key also contains "Microsoft Smartcardlogin". I checked with
some co-workers, and their CACs also have these two PIV certificates.
So, I guess my question is ... what's up with that? How come two
different PIV certificates are on the CAC? Anyone know what the deal
is? Obviously they both "work" since they're properly signed, but this
was new information for me.
--Ken
_______________________________________________
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
_______________________________________________
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