OK. I now arranged to obtain an SCP 02 card , working over T0. At the time I ordered it, there was a perfectly valid technical need for T0 support; I wasn't *just* annoying USG.
One can imagine govt initiatives having such goals as : its time to dump T0, move to T1 as part of a national infrastructure. Then, power politics gets involved in moving standards committess, consensus, open source technology, in the direction of the power mover, the market leader, etc etc.
But, apart from such a power play, WHAT IS (technical aspects of ) the T0 vs T1 issue all about, re SCP 02 specifically?
What's driving the schism, that was not present in the SCP01's use of T0 for applet uploading, content management etc, days?
From: "Scott Guthery" <[EMAIL PROTECTED]> Reply-To: MUSCLE <[email protected]> To: "MUSCLE" <[email protected]> Subject: RE: [Muscle] GlobalPlatform R-MAC Date: Tue, 13 Dec 2005 12:40:44 -0500 Yes, indeed. Insecure messages through secured pipes (secure channels) vs. secured messages through insecure pipes (secure messages). You can't tell the difference looking at one message or even a sequence of messages if the latter are sent using chained commands. Why GP created this tempest in a T=0-Pot I'll never understand. That said, there are those that claim a difference in kind and can argue vociferously the advantages of one over the other. When GP tool GP to ISO they changed back to the 7816 vocabulary; i.e. secure messaging. Cheers, Scott -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Williams Sent: Tuesday, December 13, 2005 12:27 PM To: [email protected] Subject: RE: [Muscle] GlobalPlatform R-MAC >2) You might want to take a look at ISO/IEC 7816-13 which is >GlobalPlatform using secure messaging rather than secure channels. As >an international standard rather than a proprietary system it may turn >out to be more germane to managing FIPS 201 cards. Do I smell one of those those maxist, dialect[r]ical materalism moments, here? :-) Channels vs messaging. SSL vs SET. DARPA vs NSA. IETF vs ITU-T/OSI. Hmmm. > >Cheers, Scott > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Peter Williams >Sent: Tuesday, December 13, 2005 11:09 AM >To: [email protected] >Subject: RE: [Muscle] GlobalPlatform R-MAC > > > > > >From: Karsten Ohme <[EMAIL PROTECTED]> > >Reply-To: MUSCLE <[email protected]> > >To: MUSCLE <[email protected]> > >Subject: [Muscle] GlobalPlatform R-MAC > >Date: Tue, 13 Dec 2005 14:02:00 +0100 > > > >Hello, > > > >The secure channel protocol 02 of the GlobalPlatform specification > >allows to use a R-Mac (response MAC). In the specification is mentioned > >that the R-MAC is applied to all the subsequent command/response > >messages. Is this really true? Or is the R-MAC only applied to real > >command APDUs containing data and not to protocol APDUs like Get > >Response or on errors like Wrong Length (6C,61,...). > > > >Are there any cards which support R-MAC? > >Yes. > >FIPS 201 essentially requires an R-MAC capable SCP - for remote >management >of the GCs, as the content silos are instantiated - and rented off to >other >agencies/businesses. > >I have not personally encountered SCP 02 et al. over T0, in an off the >shelf >card. > >You might want to investigate SCP.n proposals. Our IBM colleagues may be > >able to faciliate controlled R&D access to GP.next drafts. > >In 7816 terms, secure messaging and logical channel support is >applicable to >all APDU transfers. A polling response is just a response. > >Its more fun to question whether the T0 procedure bytes and time request > >bytes (over USB relays in particular) are secured by the logical >channel, >and its binding to secure messaging. One assumes not. One assumes that >the >combination of T0 and the more advanced SCPs are really not >"future-compatible". > > > >Thanks, Karsten > >_______________________________________________ > >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 _______________________________________________ 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
