Anders Rundgren wrote:
Yes, it will be fairly interesting to see how the US government intends to deal with secure mobile device applications which (at least for practical purposes) are incompatible with FIPS 201.
Tokens are mandated. Applications run on platforms. Platforms support tokens. Match it all up and it's all good. :)
Now, that's not considering cost. SME-PEDs aren't cheap. :)
This is how it has been so far; KeyGen2 is about to change this by offering remote secure issuance including dynamically setting PIN policies in an issuer-specific way. Even issuer PUKs will be possible to set. The enforcement may be in the secure container but it may be in the middleware as well depending on how much the market is prepared to spend on secure containers. This is also subject to Moore's law that makes the future look very good.
Dynamically configurable applets would be interesting, but I don't know if it's new. However, you'd still need the secure channel to reconfigure the applets on the card, which implies a token manager somewhere.
Thank you for clarifying this! It is pretty obvious that such a scheme only works for one issuer who own (have bought) the tokens. The KeyGen2 protocol is intended for usage by multiple issuers who share a secure container with the user.
PIV generally means that the issuer own the token. The issuer can be a shared provider (e.g., GSA) or the issuing organization itself (e.g., DoD), but it has to be someone. This way there's someone to audit, and audit is a key part of PIV.
Anything else isn't PIV, at least not as it currently stands.Now, what you're really asking for is a multi-domain token--i.e., a token with multiple partitions that are prevented from interacting (e.g., when using in domain A I can't touch data in domain B). This is sorely needed (think tokens for multiple classification levels) but doesn't currently exist.
Maybe this conversation should move over to ietf-pkix. -- Tim
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature