Dave,
I appreciate your comments, and of course you are correct. I was trying to
suggest to make some progress in these various areas that would capitalize on
the historical interests and expertise of the various participants, more than
the specifc, IETF-endorsed charter.
1. The 3 mailing lists have quite-different scope(s). pem-dev is about
messaging security. It has nothing to do with commerce, per se.
This is certainly true, although I recall a more than a few megabytes of
discussion on various aspects of supporting commerce via digitally signed
e-mail, and there is still a pretty good chance that secure e-mail (perhaps
MOSS with a new body type for electronic payments) might emerge as the protocol
of choice for certain applications.
My point was that today there is an overwhelming, obvious need for a group that
will focus on the nuts and bolts of creating a certification authority
infrastructure that would be capable of support electronic commerce, secure
messaging, and other aspects of public-key cryptographic-enabled applications.
I don't mean to suggest that all uses of public key cryptography require the
use of a CA infrastructure, but some obviously will, and we need to support
such uses.
Four or five years ago, when the PEM WG started in earnest, we had a conceptual
trust model that was strongly influenced by work that had been done in the SDNS
architecture and other military/governmental applications, where there was a
strong hierarchical authority component. However, formidable obstcles in
establishing a CA infrastructure capable of supporting PEM and numerous other
applications have arisen. Many of these issues involve serious organizational,
legal, and financial obstacles -- in particular the delicate balancing of the
liability risk and business rewards between the originator/signer of a message,
the recipient/relying party, and the CA. If the risks are disproportionate to
the rewards for any of those three parties, the system will simply not be
deployed.
In looking at these issues, particularly issues of risk/liability of the three
parties, we have seen that it will be necessary to place tighter constraints on
the certification path, name subordination, policy coordination,
cross-certification, etc. In addition, substantive issues have arisen as to how
to include policy disclaimers, caveats, and limitations within the certificate
itself, in order to provide adequate legal notice of such terms to the relying
parties. Extensions along these lines have been proposed to the X.509 version
3, in particular by the X9F committee, but these extensions have not yet been
vetted by the wider technical community and may not be sufficinent. In
particular, it may be necessary to mark such attributes as Critical, so that
implementations which do not understand how to process the information would
reject the certificate. Likewise, there may be situations where it is desirable
to include information provided by the subscriber but which has not or can not
be verified by the CA.
Without denigrating the efforts within X9F and the ISO community, I believe
that there is a role for the IETF to play in examining the technical
infrastructure for certification authorities to support a broad range of
applications. The scope of the examination should not be limited to any single
application, such as secure message, or electronic commerce, or electronic
benefits transfer, but should attempt to address all of these areas in general.
Regardless of the specific charter or focus of the PEM WG, if any is still
operative, the pem-dev list itself has attracted a very substantial readership,
including many with a broad grasp of the issues involved in establishing a
national public-key infrastructure.
I was therefore suggesting that we capitalize on the expertise of the existing
pem-dev membership, and use that list to focus on the public key
infrastructure, and in particular the contents and format of the X.509
certificate and the functioning of the certification authorities.
e-payments is a general discussion about electronic payments.
ietf-payments is specifically (and exclusively) intended for discussion of
IETF-based payments-related standards (or, more generally, technical)
efforts. The latter two, therefore, are distinguished by presence/absence
of focused work.
My suggestion was that there are (at least) two areas of interest in addition
to the CA-infrastructure that would appear to be quite useful for the IETF to
focus on. The first was the protocol to be used to come to agreement (I
hesitate to say negoitate) on the price of the goods/services being acquired
and the descripton of them. The second would be to examine the iKP protocol as
at least a protocol of potential interest to a substantial portion of the
community.
I do NOT want to get into an argument about the applicability, much less the
universality, of the credit card model vs. other electronic payment models,
including micropayments. But it would appear to useful to review the iKP model
at the mechanism level for any problems (as Wembo Mau has apparently done,
although I have not yet had a chance to read his analysis). In addition,
(almost) regardless of the details of the cryptographic message flow, there is
a legitimate issue as to how those messages should be carried at a dataflow
level of abstraction. Are all of these transactions taking place
contemporaneously, or conceivably are they taking place over an extended period
of time? Are the various components of the iKP protocol being sent as
individual, standalone IP packets, as part of a TCP/IP or other session
protocol, or via e-mail?
Whether the transaction are being sent to an acquiring bank per se, or perhaps
to some othermore general form of clearing house function, it would appear
that these would be useful questions to address.
2. The Mastercard/Visa announcements at the IETF BOF were consdidered by
the BOF attendees. My own reading of the consensus was the the IETF should
proceed in the matter it sees fit, neither ignoring nor waiting for the M/V
work. Unless and until it is released, we simply cannot evaluate its
impact on any possibly-related IETF efforts.
I like that phraseology - "neither ignoring nor waiting for the M/V work."
Ideally, I would hope that the IETF could work cooperatively with MasterCard
and Visa, respecting their schedules and application requirements and
suggesting various potential implementation alternatives.
I'm hoping that others will participate in the discussion about the
ietf-payments working group charter. With that, we can figure out what
SPECIFIC problems we are going to try to solve and in what order. In
particular, I hope that folks offer comments on the draft charter I sent,
either suggesting specific wording changes or offering their own draft
charters. General discussion can be helpful but carries the danger of
breeding more general discussion and less specific work.
Yup, I agree. My impression is that after almost two decades of cajoling,
moving, prodding, and pleading with various interest groups to consider the use
of public key cryptography, suddenly the horse is bolting out of the barn and
we are in the position of trying to catch up. It's a nice problem to have, for
a change.
Bob
--------------------------------
"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>
Staff Scientist, Wireless and Secure Systems Laboratory
GTE Laboratories, 40 Sylvan Road, Waltham, MA 02254
Waltham office: Voice: 1-617-466-2820, FAX: 1-617-466-2603
Telecommuting: Voice: 1-508-264-0485, FAX: 1-508-264-4165