Ok. So lets get political! Given someone mentioned ISO, and the contribution of an NSA work product to an international forum.
So 20 years too late, ISO might specify an enumeration process for serial-interfaced microprocessors, on 9600 bps serial buses, using char-level link protocol. We've had ISA parallel enumeration, PCI parallel enumeration, USB and IEEE (secure) enumeration of 400mbps serial devices, and even SIP-based enumeration of smartcards over virtual desktop links. And now ISO will let us ping an applet, at 9600 bps, to learn what capabilities it has, and what stack profile it requires the host to adopt in its layer entities, for a pseudo 7 layer stack (with 2 subprotocols for vendor inconsistencies, per layer). ISO is clearly on the ball! Is NSA funding a Booz Allen or a CSC contractor in the ISO WGs? You can tell the agencies international policy goals by their choice of the defense contractor; it's a style issue. If you look at the individual's previous projects and area of technical excellence, you can tell why there were picked, and therefore what the US "unstated" policy objectives are, too. I don't know who wrote GSC-IS, that would well form the basis of an ISO normative standard effort. But having read the musclecard code, and only then read the NIST document, the similarities were striking: its as if the spec abstracted the plugins precisely, and gave everything names and acronyms, then factored in the learning from the CAC world, and finally tuned everything for a FIPS 140-2 ways of describing the management roles for the parties interacting with crypto modules. What was refreshing was that it described cryptocard KMI generically, independent of PKI concepts. US global policy comment aside, its an impressive technical document: it show real class. I think NIST should be very proud of its technical content, and the effectiveness of the presentation of the concepts. They are classical NIST skills. What GSC-IS reading did give me in a way that was not readily apparent in the code was (a) a clear _perspective_ on the designers goals for characterizing the two classes of card - javacard/.NET cards, and DF/EF cards, and (b) the role-based personalization/post-personalization management model - that leveraged NSA expertise in centralized key management for known-effective crypto-based network control systems. The main problem with GSC-IS is that it's a product of the 2001 period. Its only uses (and is conceptually limited to) C-MAC/C-ENC for SCP01, and the base concept limits GP secure messaging in the role of remote code distribution and simple secure personalization - not end-end messaging for application usage. This is particularly apparent in the discussion of CAC-related features, where the role-based management model shows off the designers assumptions about how hosts and management entities SHOULD cooperate, to maintain the online infrastructure. Failure to address end-end secure messaging, for both application and card management usages, is the big hangup, clearly. The 2001 infrastructure assumptions may not scale to the open community, which is not like DoD in its management culture. In a US technology dominated world - which assumes the PC is to be a trusted network relay (using TPM chipcontrol over personal crypto) and can participate in infrastructure-wide surveillance and key escrow etc - limiting the architecture to SCP01 assumptions is not such a big deal. But the new India and China markets able to deploy new capital infrastructure, folks are not going to use TPM, with its high IP cost basis, and the fear of foreign spying and control over their critical infrastructure, etc. More cheaply, most of the infrastructure benefits that GSC-IS address can come from end-end secure messaging: card to card. (And NSA knows how to technically architect this world, too! It clearly showed off its talents on write-to-reader (vs trusted network) architecture infrastructures in the 10 year DMS/Fortezza project.) I suspect, in conclusion, GSC-IS is a good work product to contribute to a normative standards effort, at the international level. I would expect that effort to have little or no impact on overcoming any _practical_ interoperability issues, however. Using policy to induce economic change - in which consumers demand interoperability, is classical US international policy. And that's what ISO normative standards are for, after all. As you taught us, Peter, normative 7816 did not make any two compliant cards/hosts talk to each other! But it did forment an industry and a multi-vendor market! Peter. > In the typical configuration of PC with microprocessor-controlled card > reader, none of these methods define either the card reader driver layer > in the PC or the card reader itself, but for the startup phase of the > card they do aim to closely define the PC software's internal interface > to the card reder driver and the card reader interface to the card. That > startup discipline is something that we have long needed in order to > have interoperability across multiple card types. > > (If Scott reads this, perhaps he can add something - or indeed correct > if I have got it wrong.) > > Peter T > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
