*Internet2 PKI Labs Conference Call*
September 25, 2000

*Attendees*

Ken Klingenstein (co-convener) - Colorado/Internet2
Neal McBurnett (co-convener) - Avaya

Larry Levine - Dartmouth
David Nicol - Dartmouth
Sean Smith - Dartmouth
Punch Taylor - Dartmouth
Bob Brentrup - Dartmouth

Eric Bok - Wisconsin
Keith Hazelton - Wisconsin
Larry Landweber - Wisconsin
Eric Norman - Wisconsin
Mike Rosen - Wisconsin

Carl Ellison - Intel
Bob Morgan - Washington
Bob Moskowitz - ICSA
Cliff Neuman - USC/ISI
Vishwa Prasad - AT&T
Jeff Schiller - MIT/CREN

Bill Doster - Michigan
Michael Gettes - Georgetown
Olga Kornievskaia - Michigan

Ben Chinowsky (scribe) - Internet2
...and a few others...

*Discussion*

Ken opened the meeting; the central aim of the PKI Labs is to bring Internet2's unique assets to bear on the problems of "public sector PKI", without duplicating existing efforts. Non-duplication is the focus of today's discussion, which will be concerned with an "environmental scan and priority setting". Ken asked for a short presentation from each Lab.

Sean introduced the Dartmouth PKI Lab, a partnership between the Department of Computer Science, Computing Services, and the new Dartmouth Institute for Security Technology Studies. Dartmouth is a "fairly wired campus" with lots of Macs; email is the principal means of student-student communication. The Dartmouth participants are interested in both PKI and PKI-using apps; http://www.cs.dartmouth.edu/~sws/research/pkilab/ lists several possible projects, including authorization and bridging, secure coprocessing, SSL servers and the browsers that use them, and PKIs for machines as well as people. More material will be added soon.

Keith introduced the Wisconsin PKI Lab. The principal participants are the Department of Computer Science and the DoIT; Health Sciences is also involved via the Wisconsin Integrated Advanced Management System. Wisconsin is also a very wired campus, and in particular is one of the most "ISP-like" campuses, with more modems than any other they know of. The Wisconsin PKI Lab Web site (http://www.cs.wisc.edu/pkilab/) lists three primary areas of work: integration with the Grid via Condor (a 10-year-old Wisconsin-based project which is close to Globus), a language for authorization and policy management, and "overcoming the inconvenience barrier" to PKI.

Ken broke down the roll call: present are Labs participants from Wisconsin and Dartmouth, Advisory Board "visionaries", real-world deployment people, and representatives of some Internet2 members who submitted good though rejected proposals. Ben will maintain the Internet2 PKI Labs web pages (http://middleware.internet2.edu/pkilabs/) and produce minutes of the quarterly conference calls; Ken and Neal are responsible for Internet2 PKI Labs support more generally.

Bob Moskowitz discussed work in the PKI Forum (http://www.pkiforum.org). The PKI Forum has business and technical groups; the technical group is further along. The business group deals with "marketing education", policies, apps, and best practices. The technical group has several white papers in the works on topics including interoperability and PKI, CA-CA interoperability, cross-certification, and LDAP. The interoperability work is led by Moskowitz and will be publicly available to the community. In response to a question from Carl Ellison, Moskowitz confirmed that he sees PKCS#11 and PKCS#15 as inimical to interoperability.

The group discussed work underway in IETF-PKIX (http://www.ietf.org/html.charters/pkix-charter.html, http://www.imc.org/ietf-pkix/) and IETF-SACRED (http://www.imc.org/ietf-sacred/). A "qualified certs document" from PKIX is now in the IESG process. Controversy is being generated by a digitally-signed-timestamps document that takes a trusted-third-party approach; Jeff noted that "you either trust a third party or you don't." Patent issues continue to slow this work. The Microsoft CMC code has been published; people have been waiting for this in order to have a reference standard to interoperate with. With respect to SACRED, Jeff noted that there are two schools of thought in the IETF. Jeff's school sees IKE as "way too hairy" and thinks that extensions to IKE won't cut it. The opposing school wants to "screw around with IKE to pass passwords around", thus enshrining hacks in the standard. See RFC 2797.

Ken provided an ultra-condensed outline of the Internet2/EDUCAUSE/CREN HEPKI work. HEPKI's technical activities group (TAG) is looking at open-source, mobility, and certs standardization issues; its policy activities group (PAG) is doing an extensive certificate-policies comparison, with a particular focus on interoperability with the Federal Government. Bob Moskowitz noted that the Feds have made it clear that they can provide certs only for Government entities, and not for everyone who needs to work with the Government -- so they know they'll need to interoperate. For example, they're deploying ACES for online validation checks (http://www.gsa.gov/aces/), and certificates for students in the student loan program, but these certs would make no sense in other contexts. The Feds continue to work on S/MIME, though staffing is a problem in this area.

Next was a survey of other "communities of interest" known to be doing work on PKI. Carl, who chairs the PKI working group of the Trusted Computing Platform Alliance (TCPA, http://www.trustedpc.org), discussed Intel's work with the TCPA. The idea here is to make it possible to record what's loaded on to a computer. Hashes are used; the keying material will go on chips, which raises problems related to keying chips at the manufacturer. The key must never be released; the current design releases it only to a privacy CA or an "anonymizer". Steve Farrell and Carl have improved this scheme by removing the privacy CA, and they are working on a solution to the problems that arise from having only one key for a family of chips. Ken noted the importance of the medical community of interest, especially in the light of HIPAA. A big ANX (automotive, http://www.anx.com) meeting is coming soon. Carl noted that the financial community has done interesting work in authorization, where the real work is.

Bill Doster discussed Michigan's KX.509 work. They use the Kerberos infrastructure to get junk keys, then throw them away at logout. Junk certs are particularly useful for web authentication; see http://www.citi.umich.edu/projects/kerb_pki/.

Finally there was a discussion of matters arising. Ken asked the group to think about what Internet2 might be able to offer; one possibility is to install monitoring code at the approximately 182 Internet2 universities.

Carl discussed several outstanding problems (his extensive notes are appended below). 1) There would be great value in finding a way to do cert path discovery, especially if you have pools of certs held in different locations. Path discovery is known to be possible, but implementing the formal proof is not practical; industry won't even bother looking at it. Carl noted that the real path-discovery problems arise when many directories are hidden behind firewalls or other acccess control mechanisms. 2) The name-management problem has replaced the key-management problem -- "Diffie-Hellman lied." Bob Morgan noted that much interesting work on name management has been done in CS departments. 3) Another unsolved problem is using shared knowledge for authentication in an Internet that shares this information (e.g. SSNs and credit bureaus). 4) Yet another problem is that where the cert issuer is a third-party payment company rather than the organization legally responsible for the site, there is no information in a cert that lets you determine if the source of a page is an approved service provider or a "man in the middle". If you follow the links, you don't know if you're going to who you want to talk to, and people almost always start with an unsecure URL (no "https://") anyway. 5) Finally, what would it take to make non-repudiation possible? WebELF was suggested as a way to start building non-repudiation into both sides. Carl called attention to "the Radar O'Reilly problem" -- you don't know what the OS is handing the person to be signed. Moskowitz noted the central importance of the "personal security environment" in this connection.

Eric Norman noted that there has been some interesting work related to the need to be able to identify a document regardless of its medium, for example for academic or medical citations. See http://www.doi.org and http://www.cnri.reston.va.us.

*Action Items*

1. Neal and Ben will update the PKI Labs web pages, including adding URLs discussed in this call; Neal will notify the PKI Labs list when this has been accomplished.
2. The email list will be streamlined and separate discussion and announcement lists will be created.
3. Carl will send Neal his writings and a URL about Intel's open-sourcing of CDSA middleware. (Done, see notes below.)
4. All will send names of potential advisory board recruits to Neal and Ken.
5. Neal and Ken will discuss the PKI Labs call schedule and send a proposal to the group; another areas-of-work call will be held in about six weeks, tentatively at 3pm Eastern on November 7.
6. Ken will contact Lisa about working with the PKI Forum, in particular on reviewing PKI Forum documents and avoiding duplication of effort.
7. All will send suggested additional areas of work to Neal, building on this call's identification of areas of work that are not getting proper attention.
8. Jeff will send the group Tim Polk's presentation from PKIX.
9. Eric Norman will try to find source documentation on the problem of using crypto for identifying scholarly works regardless of medium. (Done, see URLs above.)
10. Ken will send Sean a note about the implications for middleware of AT&T's renewed focus on the importance of cash.

==================================================

*Notes by Carl Ellison*

For those who want certificate processing middleware, Intel's open source release of CDSA is available at http://developer.intel.com/ial/security/. It offers both X.509 and SPKI certificate creation and validation, as well as PKIX hooks.

I would recommend looking at that code, even if some other source of working code is chosen, for the way we designed authorization computations. In particular, the authorization logic of SPKI was separated out into a module of its own (AC), using an internal form for the semantic content of a certificate (the datatype TUPLE). The translation from SPKI ACL and certificate entries into TUPLEs is straightforward, but so is the translation from X.509 or PGP (although that translation code is not included in the current CDSA release). The AC module design allows one to extract authorization and naming information from X.509 and mix it with authorization information from SPKI ACLs or certificates -- to yield an authorization result. It's interesting to note here that the SDSI name reduction rules, as implemented by that AC module, are the same as the original X.509 name reduction rules (assuming each intermediate CA has its own name, unique among the names issued by its superior CA).

I believe the AC design represents one current approach to authorization computation, and a place from which research might take off.

Papers about the AC design and function can be found at http://developer.intel.com/ial/security/specifications.htm#spki.

==================================================

There were a number of research problems I mentioned as being still open.

==================================================

Leading my list is the tough problem of secure-computation for certificate path discovery. That is, in University environments, open directories of all students and faculty are considered acceptable. In industry, such directories would not be provided, since employee lists are considered confidential. When you do only the most simple certificate path construction (e.g., involving only published cross-certificates and published corporate root certificates over 1-level hierarchies), it is probably not difficult to discover certificate paths. However, when certification gets more involved, including the delegation of specific authorizations from within an organization, doing this path discovery becomes much more difficult. In general, you might have a certificate path constructed from multiple certificates in each of 2 or more repositories, none of which is open to interrogation from the outside. We know we can solve this by a formal secure computation (a.k.a. secure circuit evaluation), releasing minimal knowledge to anyone outside, but that is impractical in terms of performance. A high performance but still secure implementation of this would be a good discovery and probably worth a PhD thesis. This will hit the X.509 community the most strongly with attribute certificates, but it should still present itself with just ID certificates in some measure.

In SPKI, SDSI (and probably KeyNote), where we already have this problem, we avoid this problem in practice by having the person or agency that delegates some authorization hand off to the person receiving the delegation not just the end certificate granting that entitlement, but also the rest of the chain providing that power. This bundle of certificates is then used to gain desired access or back up further delegations.

X.509 doesn't employ that habit, by current practices, although habits could be changed. Currently, directory accesses are considered the norm for finding certificates and so the path discovery problem is open there -- and not just a juicy theoretical problem.

==================================================

On a more practical level, there is the problem with SSL that I illustrate with the example of buying a replacement stylus from http://www.palm.com for my Palm III. When I first get to an SSL secured page, I check the certificate behind the page and find it was issued to a company called Modus Media, International. The assumption is that Palm has outsourced its shopping pages to Modus Media, but there is nothing in either the browser or the design of SSL or its PKI to allow me to discover whether that is true or Modus Media is a Man In The Middle. Solving this problem (e.g., securely showing the user whether or not the keyholder serving up the page being viewed is allowed to use a particular logo or trademarked word found on that page) would require modifications to the browser. Some might be tempted to solve this by directories of business relationship information. However, such directories could be seen as a privacy violation (instant economic intelligence), so the solution should probably avoid use of directories.

==================================================

There is a problem with S/MIME for handling sensitive documents. We are running into this all the time. Monday morning, after our conference call, I was talking with one of our group managers who pleaded with me to get the industry to solve what we locally call The John Wilson Problem. (This is because we currently have 9 John Wilsons, in various spellings, including one in my group.) In the most recent incident (I learned after our phone call), a new person had joined with the same name as one of our lawyers and very sensitive legal e-mail had been sent to the new person instead of the lawyer. This is not just our problem. It's a problem shared by all people using Outlook/Exchange, as far as I've been able to tell, and it's a direct side-effect of the use of a large directory of names for routing e-mail. I've heard matching horror stories from Microsoft and from folks in the Pentagon. This becomes an immediate S/MIME problem, for those using Outlook S/MIME. However, it's indicative of a more general problem.

[BTW, the problem is much less severe for people using Eudora, because Eudora offers no directory. Under Eudora (or PINE, or ...), one typically makes a local alias mapping to the unique DNS email name and tests the mapping with an innocent first message.]

The general problem is that S/MIME authorization is hybrid, between a human (who provides the mapping from Authorization to Name) and computer (which provides a certificate from Name to Key). Because the human holds the authorization ACL entry (in my terminology), it is obligated to do the Name to Name comparison. This comparison is between a name in the human's memory and some constructed, unique name in the certificate (or Exchange database). The match will not be exact, of course, since a person never uses constructed Distinguished Names in his or her memory. In many cases, the name enters the human's memory through spoken language, so there is a sounds-like match involved as well as a lexical match.

When this is just a case of normal e-mail mis-routing, the result is embarrassment. When it involves sensitive data (as it would be expected to in S/MIME), it's a security flaw.

What does S/MIME do to help this situation? Nothing. It hurts, in fact. It hurts, because the error is infrequent enough that people might learn to give S/MIME signed messages more respect than they're worth -- opening those people up to an impersonation attack. By the rules of S/MIME, the attacker sends the certificate the user uses to validate the attack message. It also hurts because S/MIME doesn't solve the biggest information-leakage problem but those who put it in place might expect it to. (I estimate between 9000 and 14000 misdirected e-mails per workday, in our company, thanks to Outlook Exchange and the use of its company-wide directory. We're a small company, compared to something like the DoD, and name confusion increases with size of community as does the amount of e-mail traffic, so the effect is greater than linear.)

PGP avoids some of this, because by design and habit in PGP, an incoming signed message or outgoing encrypted message is processed against certificates already in the user's personal keyring. If the user is careful to permit only properly validated certificates into that ring, then he might keep the number of such certificates below the threshold for name confusion. That is, common name comparisons work just fine, provided the set of names is small. However, PGP still has the problem that keys are bound to global names (e-mail names). At least in theory, we should be able to do much better if we use SDSI names (local ones) and had a mailer that employed only SDSI names and certificates for e-mail security. Doing that would be an interesting project. Finding a much better solution, if there is one, would be even more interesting.

The general statement of the global problem is that names work for humans only when the set of names is small. The Internet is not a small community. Therefore, mechanisms that rely on humans to use names to identify people and things are inherently flawed and some mechanism that does not use names must be found. This is a user-interface design issue, at the least, and probably calls for multi-disciplinary research including the social sciences alongside CS.

==================================================

There is a problem with the frequent reference to non-repudiation in PKI circles. How do you achieve non-repudiation in fact (not just legally, at the risk of victimizing the keyholder)? How do you prevent a consumer's PC, with his keying material either in a file on the PC or plugged in via some PKCS#11 device, from being used by invading software? What about the family PC in the nice new built-in computer desk in the family room, when a neighborhood teenage hacker comes over to play with the family's kids? How do you protect a PC from such a potential misuse of the private key?

One approach we have considered is the use of a hand-held appliance for signing things. However, it would need a viewer so that the thing being signed could be displayed to the user. That viewer might have to be Microsoft Word or Outlook -- unfortunately, the doors through which recent attack software has entered the PC.

Is there any solution to this problem? It seems to be getting worse with time, not better. When Diffie and Hellman wrote, computers were big expensive things, kept in locked rooms, with only carefully vetted (and usually expensive) software loaded by the professional sysadmin staff. I don't see any market forces that would drive it to get better and many that will drive it to get worse.

If we assume that non-repudiation can never be achieved in general, what can PKI do to help e-commerce? This is an open research problem.

==================================================

There is a minor research problem with X.509 cross-certification and bridge CAs. These activities merge previously independent CA hierarchies, each with its own namespace. Those namespaces might have name conflicts. How are those resolved? In SPKI/SDSI we resolved them by recognizing up front, as a part of the design, that all namespaces are local -- and we would construct global names by including the public key of the namespace creator:

(name <key> <spelling>)

X.509, on the other hand, started out with the intention of having a single root for the namespace (X.500) and never really addressed the problem of non-local use of local namespaces. This may come back to bite people when they cross-certify. This might be something covered already by the PKI Forum, along with interoperability among vendors, or by the PKIX WG and so might not be a proper topic for research.

This issue is also discussed somewhat in http://world.std.com/~cme/html/web.html.

==================================================