Hello, Peter:
1) GSC-ISv2.1 has been entered into the ISO/SC17 standards process. It is in
TG9 of WG4, chaired by Teresa Schwarzhoff, one of the authors of GSC-ISv2.1 and
an employee of NIST. The emerging standard is called ISO/IEC 24727. There are
5 parts in various stages of drafting. Part 1=Architectur, Part 2= Generic
Card Edge, Part 3=Application Programming Interface, Part 4=End-to-End
Security, and Part5=Testing. All parts are firmly founded on the ISO/IEC
7816-4,-8,-9 and -15 "toolkit".
ISO/IEC 24727 is an interworking framework for interoperabilty a la the
Internet. I.e. it is a way for card systems to interwork just as the Internet
protocols are a way for networks to interwork. Internet. Get it?
There is a meeting of WG4 adn WG4/TF9 next week in Munich. See you there?
2) I don't know if NSA is funding any contractors to work on standards but NIST
certainly is.
3) You might also like to check-out NIST Special Publication 800-73
http://csrc.nist.gov/publications/nistpubs/index.html
This is a specification for a card application purpose-built for Personal
Identity Verification (PIV). The specification defines both a card edge
interface and an application programming interface. The design rule was
maximal KISS (Keep It Simple, Stupid) to maximise the probability of
interoperability defined as "independent implementations interchangeable"
Plans for entering SP 800-73 into one or more standards processes are still up
in the air.
Don't hesitate to ask follow-on questions (anybody).
Hope all is well.
Cheers, Scott
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Peter Williams
Sent: Sun 4/10/2005 12:23 PM
To: 'MUSCLE'
Cc:
Subject: RE: [Muscle] NIST Services
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
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
