+1-888-690-2424

What is PIV-I?

I have been involved with credentialing in the Federal Government for many years, coming on multiple decades to be honest, and it has been an interesting ride. Over the last few years there has been a substantial change, starting with the signing of HSPD-12 in 2004. What HSPD-12 did was to codify credential issuance within the Federal Government. HSPD-12 brought in not just a technical specification but also a process specification. The combination of these two elements was intended to address the differences between agencies issuance processes as well as allowing interoperability of credentials, at a logical and physical level, between agencies. As part of the extended process the Federal working groups within the Federal Identity, Credential and Access Management community also developed a set of requirements for organizations external to the Federal Government to create credentials that were based upon a well defined set of standards both from a technical perspective as well as from a issuance perspective. So what are the differences between a PIV card and a PIV-I card? I hate to give a bulleted list but I am not sure how else to do it so here goes: (Note the left side will always be PIV and the right PIV-I)

  • Identity Verification: While both PIV and PIV-I strongly authenticate individuals there is a slightly higher requirement for PIV. The PIV IV process requires that the end entity have a National Agency Check with Inquiries (NACI).
  • 10 vs 2: For PIV cards, ten fingerprints are collected, where possible, while for PIV-I only two are required to be collected
  • FASC-N vs UUID: These are identifiers for the end entity normally used as part of the access control decision for physical access. It is possible that the government will move towards the UUID but for now it is FASC-N. The structure does allow for quick differentiation between a PIV and PIV-I card at a PACS system.
  • Common Policy vs FBCA mapping: From a logical perspective the trust anchor for PIV is the Federal PKI Common Policy Root. For PIV-I the trust anchor is the issuers root but the issuers policy must be mapped to the Federal Bridge CA. This is demonstrated in the different OIDS used in the certificates in the cards. The intent here is to allow users under the Common Policy can trust users of PIV-I cards through the linkage at the FBCA.
  • Content Signing: Both PIV and PIV-I cards contain signed objects. These objects are signed using certificates that carry specific indicators that they be used only for content signing. The identifiers used are different for PIV and PIV-I and therefore it provides another way to differentiate the card.
  • Physical Layout: A PIV-I card MUST look different than a PIV card.

So as you can see there are differences but the intent is to make the PIV-I card usable within an organization and to also allow it to interoperate with other organizations, both physically and logically. The publication of the specifications, with a validation process, allows application vendors to build systems, logical and physical, to use the cards and also allows relying parties to be able to determine their policy on use of PIV-I cards.

So who should think about PIV-I and why? I will leave that to another day.

Entrust Product Management
Entrust Product Management
Product Manager

0 Comments

Add to the Conversation