Re: Subject Key Attestation Evidence "light" - Invention Disclosure

"Timothy J. Miller" <> Mon, 22 September 2008 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADB283A69FB for <>; Mon, 22 Sep 2008 06:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T5jgPAcLR3Aa for <>; Mon, 22 Sep 2008 06:56:59 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f04:392::2]) by (Postfix) with ESMTP id 4CAB73A69DC for <>; Mon, 22 Sep 2008 06:56:59 -0700 (PDT)
Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id m8MDj17A016021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 06:45:01 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id m8MDj1uB016020; Mon, 22 Sep 2008 06:45:01 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with ESMTP id m8MDixX7016007 for <>; Mon, 22 Sep 2008 06:45:00 -0700 (MST) (envelope-from
Received: from (localhost.localdomain []) by (8.13.1/8.13.1) with ESMTP id m8MDixKm009547 for <>; Mon, 22 Sep 2008 09:44:59 -0400
Received: from imchub1.MITRE.ORG ( []) by (8.13.1/8.13.1) with ESMTP id m8MDixnF009541; Mon, 22 Sep 2008 09:44:59 -0400
Received: from [] ( by imchub1.MITRE.ORG ( with Microsoft SMTP Server (TLS) id; Mon, 22 Sep 2008 09:44:59 -0400
Message-ID: <>
Date: Mon, 22 Sep 2008 08:44:56 -0500
From: "Timothy J. Miller" <>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Anders Rundgren <>
Subject: Re: Subject Key Attestation Evidence "light" - Invention Disclosure
References: <00e101c91a2b$e2481320$82c5a8c0@arport2v> <> (added by <024501c91a6b$fd73d720$82c5a8c0@arport2v> <> <02bf01c91a76$91ac48a0$82c5a8c0@arport2v> <> <00f901c91cb5$397d2190$82c5a8c0@arport2v>
In-Reply-To: <00f901c91cb5$397d2190$82c5a8c0@arport2v>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms060201060303030401070606"
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

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 

> 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