From: Peter Williams (home_pwmsn.com)
Date: Sat Apr 09 2005 - 23:09:40 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

GSC-IS is an architecture - for cardedge templates. Think of it as a factory
for class factories, much like

        CSingleDocTemplate* pDocTemplate;
        pDocTemplate = new CSingleDocTemplate(
                IDR_MAINFRAME,
                RUNTIME_CLASS(CDoc),
                RUNTIME_CLASS(CMainFrame), // main SDI frame window
                RUNTIME_CLASS(CDView));
        AddDocTemplate(pDocTemplate);

in the MFC class library.

Fitting to the runtime schema for legal factory objects, a cardedge template
instance specifies a protocol/wire-format class, and an abstract interface
class. In the case of the musclecard template instance, there are two
instantiations of each: one for javacards, and one for Oberthur cards. Each
cases shows off one particular stereotype in the architecture: dynamic cards
with custom PDUs, and static ISO-style cards with DF/EF file-based messaging
and ISO 7816-4 PDUs.

CAC is a different class factory, and different set of class
implementations. The CAC world and muscle world are quite different,
particularly in the role-based security model assumed for deployment and
operational management of the functional groups of cardedge features. For
example, the muscle world has monolithic distribution model (one applet) and
classical manufacturing time personalization time, whereas in CAC world
management is more distributed (multiple applets, and a custom card manager
for card capability configuration/discovery and applet re-loading)

I have to admit categorizing PIV is hard, in the GSC-IS meta model. Its
probably a cross between another template instance, and a profiled
meta-model. Its probably relates to musclecard and CAC in the same ways as a
MDI template relates to a SDI template, in the DocTemplate meta space of
MFC's AFX architectural framework.

Hope the grounding of the abstraction in MFC (something millions of
programmers are familiar with) helps.

I don't think of muscle's javacard and oberthur as vendor-specific service
plugins to the musclecard template instance - the phrase in your note that
got me thinking. They are each class factories, providing class-level
implementations of the standardized interface set, conforming to template
standards specified in GSC-IS.

I remember reviewing a formal description of this world about a year ago, in
a proof/reasoning language. Its more useful to use dynamic programming
modeling through, I've been finding - though it may turn out harder to find
an evaluator willing accept this style of security target disclosures and
evidence, showing the correctness and completeness of your PIV token to the
spec.

> -----Original Message-----
> From: muscle-bounceslists.musclecard.com [mailto:muscle-
> bounceslists.musclecard.com] On Behalf Of gnulokimac.com
> Sent: Saturday, April 09, 2005 7:00 PM
> To: musclelists.musclecard.com
> Subject: [Muscle] NIST Services
>
> I've seen the Common Access Card (CAC) service module but is there one for
> the NIST ones, aka a Government Smart Card Interoperability Specification
> (GSC-IS) or the new Personnel Identity Verification (PIV) service?
>
> Reading the documentation it seems like it should be relatively easy, but
> time intensive, to write service modules. But all I've seen so far are
> vendor specific libraries.
>
> Eric
> _______________________________________________
> Muscle mailing list
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]