No "discovery application". No ATR. No mapping. No "interface discovery ids"
(huh?). No renaming. No context tagging. No logical channels. No applets. No
file system. No driver hacks. No "end-end process interaction" (whatever that
is). No stream navigation (yeah, I really need a bunch of that). No mobile
semantics.
Perhaps you should try reading the PIV specification, Peter.
Just 11 names.
"I'll have a Big Mac." "OK, here's your Big Mac."
Just names, Peter. Check out the PKCS#15 header file. What you'll find is
names.
One of the defining principles of European software design is that renaming is
progress. Consider for example that quintessential European programming
language, TTCN-3. About all one can do in this programming language is rename
things. It's a tour de force to actually get something -- anything -- to
happen. But then Europeans believe that all the world needs is a couple more
layers of well-paid, job-for-life bureaucrats and we'll all live happily ever
after.
We all know how that story comes out ... 'cept, of course, the pampered
denizens of the Sorbonne.
Cheers, Scott
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Peter Williams
Sent: Wed 3/22/2006 5:34 PM
To: [email protected]
Cc:
Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
Ah,
So we select a discovery application, once we recognise a std ATR,
rather
than a MF/EF/DF ISO file system. Then we GET/PUT the object-file-store
hosting application data, and object data - rather than READ/WRITE
records
in ISO files. ok....
We for PIV, we do a funky GET/PUT for TLV objects, renamed by ISO 8824
tagging, that sort of map onto interface discovery ids, and a PKCS#15
stream
(which has only context tagging), but which all uses ISO file system
acls,
acl management, and logical channels to control host->applet security.
This
contrasts with simply reading a PKCS#15 stream from an ISO file system
over
SCP02015 (remember the ISO files were admittedly not designed for
streams),
or interact with an applet supporting PKCS#15 stream navigation.
So, assuming that the PIV design concept is to put the semantics of
PUT/GET
now into the host/TPM driver, rather than in an ICC-side applet for
navigating the PKCS#15 stream, we make a giant step backwards in favor
of
yet more driver hacks, per card (discovery applet). Control over end-end
process interaction does however pass to the TPM however... which is
probably the (unstated) point of USG's design concept - to ensure the
national id card works with the TPM-based secure storage control, to
control
a core's functional set arming, motherboard bus enumeration discovery
beneath the Intel ACPI, etc
And who was it who said that the European design concepts were
complicated,
and unweildy?
----
having said all that, been looking at some PIV hardware prototypes.
25mAh rechareable battery-backed always on card via USB-enabled 7816-1
module, with chip on flex micro manufacturing, with buttons,
flexi-display
for OTP, emulated swipe strip, and Mifare contactless capaility via
internal
antenna conenctivity into the back of the die. Nice USB-SIE enabled
AVR-based 144k ROm, 144k eeprom for NSA's javacard silos, with 6k RAM.
Default Applets should come with RSA's KIP, for configuring the OTP
device
over the wire ,for different C/R schemes, and to resync the
temp-sensitive
clock.
All in all, software + hardware, its all very complicated... leading
edge...
and at risk, becuase of those facts alone.
>From: "Douglas E. Engert" <[EMAIL PROTECTED]>
>Reply-To: MUSCLE <[email protected]>
>To: MUSCLE <[email protected]>
>CC: Peter Tomlinson <[EMAIL PROTECTED]>
>Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
>Date: Wed, 22 Mar 2006 15:51:14 -0600
>
>
>
>Scott Guthery wrote:
>
>>Just as a note in passing, the ISO/IEC 7816-4 GET DATA and PUT DATA
>>commands for reading and writing TLV data objects do NOT require a
file
>>system. The PIV card application is an example of this approach.
>
>And the PIV responds to a select of "A0 00 00 xx xx 00 00 10 00"
>where NIST published on 10/6/2005 that xx xx is 03 08
>See NIST 800-73-1
>
>OpenSC has some code to use the PIV cards, usable with PKCS#11
>applications.
>
>
>
>>
>>Cheers, Scott
>>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Willden
>>Sent: Tuesday, March 21, 2006 5:16 PM
>>To: [email protected]
>>Cc: Peter Tomlinson
>>Subject: Re: [Muscle] Re: Muscle Digest, Vol 25, Issue 21
>>
>>On Tuesday 21 March 2006 14:38, Peter Tomlinson wrote:
>>
>>>There is provision in ISO/IEC 7816 for a card to identify itself in
>>>several ways, but the majority of card suppliers either do not encode
>>>the necessary information or encode it inadequately - or it gets
>>
>>changed
>>
>>>to something else during personalisation. Typically the ATR may be
the
>>>starting point, or there may be extended information in an ATR File -
>>>and there may also be a DIR file giving a directory of card
>>>applications. (EMV of course has its own method of application
>>
>>selection.)
>>
>>>GlobalPlatform also has provision for ID information, using data
>>
>>objects
>>
>>>stored at the MF level.
>>
>>
>>Both of which require a 7816 file system (or enough of one, anyway).
As
>>more and more Javacards are deployed, fewer cards have a file system
:-/
>>
>>
>>>We are still in the mindset that thinks bytes are extremely
expensive,
>>>and we need to get out of that and do the job properly.
>>
>>
>>What's funny about that is I've seen one system that fires literally
>>dozens of APDUs at a card in an attempt to determine what is on it...
it
>>would
>>take far fewer bytes to query a file structure.
>>
>> Shawn.
>>_______________________________________________
>>Muscle mailing list
>>[email protected]
>>http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>>
>>_______________________________________________
>>Muscle mailing list
>>[email protected]
>>http://lists.drizzle.com/mailman/listinfo/muscle
>>
>>
>
>--
>
> Douglas E. Engert <[EMAIL PROTECTED]>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444
>_______________________________________________
>Muscle mailing list
>[email protected]
>http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
