Long note, only for folks interested in programmatic design issues for interoperability, re muscle work. Don't read if your muscle interests are about code, and/or installation practices, etc. There is no code, here!
---------------- I invested two hours reading the goal/motives/introduction sections of the US government's latest reporting level contribution to the smartcard and id-card efforts in the US government employment and contracting world (which is also a contribution to a set of international norm setting processes, also, evidently). The main objective of the analytical reading was to see how the world is evolving around our movement, and thus how the open source design world can take account of these ongoings, if at all. http://csrc.nist.gov/publications/nistpubs/800-73/SP800-73-Final.pdf. The acknowledgements to the SP note Scott's role in authoring the cited document, and note the special contribution of Booz Allen Hamilton for technical and editorial contributions. I will attempt to discover who paid for BAH's work product, from public records; for all we know, it could be BAH itself, making an admirable, public contribution. AS we should all note, this is an SP, not a FIPS: it's a report --- on "good stuff", related to standards work, - but not a standards effort in itself. (a) some of the early goals language will be clearly unacceptable to ISO. ISO normative standards don't "govern", where NIST standards and their SP support document under the modern FISMA do now "govern" US folk. As always in the US-speak used in its executive branch FIPS and related documents, normal words have very technical and legal meanings. FISMA changed NIST's authorities to now include the right "to govern" public security, recall. At the same time, the intro to this _report_ only cites OMB A-130, as the legal basis for the process of its issuing. How the SP contents relates to the authority in FIPS 201 is not clear; the language usage suggests the document production programs are related (as you'd expect, its one real team after all) but somewhat confused in their authorities. (b) "FIPS 201 also specifies that the identity credentials must be stored on a smart card." While this may seem to mean what the world thinks the term "smart card" means, we NOW know the authors (of the SP) intend the term to means anything acting like a smart card - including soft smartcard "PGP key ring". If I understand Scott, its intended that your (enhanced) PGP keyring in software could be a "smart card", subject to the governing usage controls of PIV, assuming that said key ring satisfied the PIV interface requirements. I.E. politically, PIV as expressed in the SP is _intended_ to embrace and to govern all forms of cryptomodule, assuming it can emulate a 7816-4 supporting device that is PIV compliant. (c) What is interesting is that the interfacing requirements also include ICC (i.e. chip level) interfacing requirements. That is, only certain chips of certain functional parameters and assurance levels can be PIV compliant, in the wider sense of the PIV II initiative. If the PIV is on a soft crypto module, on the PC, presumably, the Pentium has to play the assurance role of the "ICC", and be "PIV conforming". More likely, the TPM controlchip is intended to play this role, as Scott hinted. This means the TPM is being envisioned as going far beyond its current role in trusted computing - securing OS integrity, and enforcing US crypto export rules for application of keying material, into being a(nother) repository for personal id. Presumably the right to boot a PC, or a VM within the PC or over RDP, and the right to use crypto (locally or remotely in the hosted VM), will be functions that are will only be armed when the PIV fragment of the motherboard's TPM has verified the PIV-borne credentials. That! Or: all PIV capable smartcard will be themselves TPMs, in 7816-1 module form. These forms of TPMS are now appearing from in major chip making companies. Scott indicated that PIV devices are supposed independent of the "media", by design intent, and can be TPM hosted or not TPM hosted. The SP should be read in that light. (d) All the US agency specific stuff needs to get removed, before the document can be referred to, in an ISO setting. The wider world doesn't care a jot about OMB (a White House authority), and its stick and carrot role in rule-ing over and then auditing other US executive agencies and depts' use of their White House budget allocations. Now that we know about these disclosures, however, the issue of OMB authority and influence is relevant, in adjudging the PIV initiative, in the wider ISO sense. It is relevant to note that, today, we can view OMB these days as the legal enforcement arm of a more politically involved NIST, and its security programs under the public law. One has to be aware of these relationship though, internationally, amongst the US stakeholders who are influencing the PIV document content. These are issue relevant to analyzing the US contribution to ISO. (e) Looking a bit forward in the document to the ICC related sections, we see mandates on Crypto algorithm support. This will need to go, in the ISO format. ISO doesn't mandate crypto requirement support, ever. We reference the ISO registries of crypto mechanisms, schemes, etc. National govts choose their crypto. Period. Thus its for the a multi-lateral operational profile of PIV, not PIV in ISO form, to agree on the common set of algorithms and their parms, so we can wander with our ePassports anywhere, effectively. More widely, US power and its control over crypto algorithm access and distribution have to be addressed in the politics of the ISO WG and plenary processes, as do North American patents on ECC algorithm varieties. Etc. We cannot have ISO used as means of projecting Intellectual Properties policies that suit the US economy, or its particular export control objectives, or its own national security goals re crypto strength, key lengths etc. All these factors are PIV related, and are part of the wider ISO process. At the same time, working compatibility with the features of the world's largest economy has obvious user benefits... ------- That's enough broad review on the program itself, I think, given publication of the SP - which we should thank the US govt for releasing so the US public can see a little of what's likely to be going on, in ISO, on their behalf. Its always fun to watch government in action on crypto-related matters - even if we have to do it by proxy via the analyzing the public SPs and FIPSs. Peter. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
