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
smime.p7s
Description: S/MIME Cryptographic Signature