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

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

Return-Path: <owner-ietf-smime@mail.imc.org>
X-Original-To: ietfarch-smime-archive@core3.amsl.com
Delivered-To: ietfarch-smime-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB283A69FB for <ietfarch-smime-archive@core3.amsl.com>; Mon, 22 Sep 2008 06:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5jgPAcLR3Aa for <ietfarch-smime-archive@core3.amsl.com>; Mon, 22 Sep 2008 06:56:59 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4CAB73A69DC for <smime-archive@ietf.org>; Mon, 22 Sep 2008 06:56:59 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (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 owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8MDj1uB016020; Mon, 22 Sep 2008 06:45:01 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8MDixX7016007 for <ietf-smime@imc.org>; Mon, 22 Sep 2008 06:45:00 -0700 (MST) (envelope-from tmiller@mitre.org)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m8MDixKm009547 for <ietf-smime@imc.org>; Mon, 22 Sep 2008 09:44:59 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m8MDixnF009541; Mon, 22 Sep 2008 09:44:59 -0400
Received: from [129.83.200.24] (129.83.200.24) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 22 Sep 2008 09:44:59 -0400
Message-ID: <48D7A158.9080807@mitre.org>
Date: Mon, 22 Sep 2008 08:44:56 -0500
From: "Timothy J. Miller" <tmiller@mitre.org>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: ietf-smime@imc.org
Subject: Re: Subject Key Attestation Evidence "light" - Invention Disclosure
References: <00e101c91a2b$e2481320$82c5a8c0@arport2v> <48B6B19801185BEB@pne-smtpin1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) <024501c91a6b$fd73d720$82c5a8c0@arport2v> <48D3D002.7030108@mitre.org> <02bf01c91a76$91ac48a0$82c5a8c0@arport2v> <48D79438.40304@mitre.org> <00f901c91cb5$397d2190$82c5a8c0@arport2v>
In-Reply-To: <00f901c91cb5$397d2190$82c5a8c0@arport2v>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms060201060303030401070606"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=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 
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