NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 07-Nov-97
Chair(s):
Steve Bellovin <smb@research.att.com>
Perry Metzger <perry@piermont.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:spki@c2.net
To Subscribe: majordomo@c2.net
In Body: In Body: subscribe spki [email address]
Archive:
Description of Working Group:
Many Internet protocols and applications which use the Internet employ public key technology for security purposes and require a public key infrastructure to manage public keys.
The task of the working group will be to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use. For purposes of the working group, the resulting formats and protocols are to be known as the Simple Public Key Infrastructure, or SPKI.
The SPKI is intended to provide mechanisms to support security in a wide range of internet applications, including IPSEC protocols, encrypted electronic mail and WWW documents, payment protocols, and any other application which will require the use of public key certificates and the ability to access them. It is intended that the Simple Public Key Infrastructure will support a range of trust models.
Goals and Milestones:
Feb 97 |
|
Submit initial requirements document as an Internet-Draft. |
Mar 97 |
|
Submit initial specification as an Internet-Draft. |
Apr 97 |
|
Meet at Memphis IETF. |
May 97 |
|
Submit SPKI specifications to IESG for publication as an RFC. |
Internet-Drafts:
· Simple Public Key Certificate
· SPKI Requirements
· SPKI Certificate Theory
· SPKI Examples
No Request For Comments
Minutes of the Simple Public Key Infrastructure (spki) WG
Reported by stefek_zaba@hp.com
Co-chairs - Perry Metzger <perry@piermont.com>, Steve Bellovin <smb@research.att.com>
I. Carl Ellison presented progress on the spki drafts, with various items arising being debated, mostly to be taken to the list for final resolution
II. WG cochair's suggested Next Steps
III. Implementation report from Andrew Palka of DEC (Reading, UK) on using spki certs for Web access control
IV. Mention of binary format proposal by Tatu Ylonen
V. Shrinkwrap report from Angelos Keromytis
I. Progress on Drafts - Carl
[Slides will be available]
Carl kicks off, presenting SPKI-drafts progress. Notes that Requirements draft has expired: it's kicking around in an archive or two and on the Web, suggested to leave it dead. Current docs are split into three pieces: theory, structure, and examples. Intent is to make theory draft an Informational RFC, the Structure to be standards-track, meaning a small qty of info must move into struc from theory. Examples draft needs substantial fleshing out: implementors please step forward. [Carl didn't, to this minute-taker's perception, suggest a proposed status for the Examples draft - presumably to be an Informational RFC too?]
Implementation status: Carl's implementation lost in a disk crash :-)
Simplifications made as a result of previous semi-snide comments on the list and at the Munich IETF in August, as follows:
· Most *-forms removed;
· Tags assumed positional, can only "append" which always restricts authorizations (can't increase them)
· Separation of name and authorization cert forms: name certs can't change authorisations; doing this means
- easier to explain
- can omit name processing
Work still needed:
· More apps, with feedback on what's useful, what's not, what's missing
· Cert path discovery - currently prover's responsibility to supply all certs to verifier. May be possible to use analogies from network routing to allow certpath discovery.
· Need experience allocating/delegating authorization: current (X.509) practice emphasises CA's key-handling and identity-verification practices, but little emphasis on whether they're authorised to say what they do say about the subject. E.g., a site SSL cert for a webserver which puts up pages with the IBM logo - Preferred issuer might well be US trademark registration body, since they have authority appropriate to make such statements
· Spell out online messages - separate draft?
Outstanding questions:
· (sequence ...) useful at all? Can't be complete chain (loop) of certs, since ACL entry is firmly private to the *verifier* only. Comments on utility: Micheal Richardson likes bundling idea, not sure if current semantics help a lot. Perry tutorialises purpose of (sequence ...) as reducing computation load for verifier - Carl likes idea of making it be "just a bundling mechanism". Uri suggests slitting its throat with Occam's razor, i.e. get rid of it pending a proven need; and Tatu [alleged to be still in bed at this point] is alleged to also have expressed himself firmly AGAINST it. Suggested resolution:
- Consider it of doubtful utility but let implementation experience show otherwise, acknowledge a bias towards elimination of the nice-but-of-unproven-essentiality...
Pubkey syntax: currently (public-key (rsa-sha-pkcs1 (e ...) (n ...))). Proposal is to replace atom "rsa-sha-pkcs1" with S-expr. Eric Rescola asks why this single atom tries so hard to wrap up all of signature algorithm, hash algorithm, and packing into one atom - suggests firmly that (a) they should be separated, and (b) made an attrib of the *signature* (i.e., when key *used*) rather than of the *key*. Michael wonders if the explosion matters; Tatu and Eric point out that it's really *lame* to require different certs for using the same key just with different hashalgs. Tatu points out the *full* range of combinations is unlikely to be used; in practice there are just a few "sensible" combinations. Differing opinions on whether this (public-key...) construct is descrining a key only, or a key-and-its-cert, or a key-and-its-cert-and-its-expected-usage-when-forming-signatures.
Uri speaks for purity of concerns, i.e. for separating the usage of particular hashalgs and packings from the declaration of the key itself. "Resolution on the mailing list" seems like the likely path for untangling, although the mood as polled veers towards Eric and Uri's separation-of-concerns. Charlie Kaufman identifies the issue as trying to constrain which packing rule (alone) is being defined as to-be-used with the key (and admits to having introduced a security hole in work done in A Previous Life where not specifying the packing rules allowed a splicing attack). One proto-philosophical point raised: is there an intent to protect verifiers against deliberate stupidity, e.g., using 4-bit hashes or "yes those are bits so they must be a valid signature," or are we expecting verifiers to look after their own security concerns? [An exhausting discussion, which will doubtless continue on the list.]
Date format nit: no, we won't discuss that here! Carl will make an arbitrary decision and document it in the next rev of the draft.
Symmetric keys - to be allowed at all? Tatu had a very strong opinion, but chemicals available at the bar have caused amnesia :-) :-) Attempts to reconstruct this reasoning said that it's a complexity issue - making symmkeys mandatory-to-implement is implementation hassle; also having symmkeys in a cert means that the cert itself has to be kept secret. Maybe this a case where the not-yet defined extension mechanism might be used? Perry amplifies the "oddness" of a symmkey cert - exposure of the keys becomes more likely. Marcus notes two problems:
1. Someone might use it :-),
2. If you're going to use these, you're probably in an environment where lots of other protocol machinery is lying around, thus making out-of-band acquisition of necessary symmkey material quite feasible, instead of including symmkeys in the core spec. Possible resolutions are to mandate only hash-of-symmkey allowed; or to punt to the yet-to-be-defined extension mechanism. Straw poll is firmly against making it mandatory, and indeed against making it simply optional - make it a private extension: therefore we need to define an extension mechanism for this and other bits of magic! (But no volunteer arose to take this on.)
Display types: for all strings, or only special ones? Tatu suggests modifying the BNF in the doc, so as to use (say) "raw-byte-stream" and "may-be-display-typed-byte-stream". Michael (Richardson) worried about parsing complexity. Lots of don't-know/don't-care people, those who do have an opinion are split. Again - to be hashed out on the list! (Also an idea to get rid of display-types altogether :-) Agreement at least that certs assumed VOID if "you do something really stupid" like apply a display-type to a date, keyblob, or similar.
· Need to specify how to add algorithms:
- Limit algorithms to encourage interoperability? Allow user extensions to the algorithm set? IETF precedent is to specify a small number of MUSTs and a large variety of permitteds; general agreement on that idea.
Permit subset implementations for close apps (e.g., no (SDSI) names)? Strong consensus - no, unanimity, says *yes*.
Add (URI <uri>*) for optional URI sets
Extension mechs: draft (probably) should say verifier policy needs to be "if-I-don't-understand-this-extension I will declare this cert void". Extension mech will probably not be in this round of drafts.
II. Suggested Next Steps - Perry
Suggested immediate tasks: trimming of both text and features from drafts; implementations solicited, and (more to the point) usage IN REAL APPS is vigorously encouraged. Tatu will do an experimental SSH to use SPKIcerts.
III. Implementation Report - Andrew Palka
[Slides will be available]
On which theme - an implementation report from DEC's Andrew Palka: use of SPKI access controls for web sites. Intention is to do working SPKI demo and highlight any problem areas. Rqmts: easy to manage, not lots of certs, easy to extend cert-chains. Implementation: entirely in Java; based on Jigsaw server from W3C; uses "nearly" SPKI-certs; adds HTTP headers (with PEP). Scenario: hierarchical organisation; W3C website; and an XYZ website, which wants to specify access control policy to say "anyone who has (member) access to the W3C site can also access the XYZ site". User within the hierarchical org wants to access XYZ site; has lots of personal certs, but intermediate points don't necessarily make full chains available. Problems found: prover must retrieve all certs; use of "tags" (X.509 intermediate certs are tag-blind); privacy concerns - can certs from intermediate orgs be made available, esp. in bulk? Possible solutions: server (verifier) might be able to provide hints to client to help the client find the cert-chain; server may return certs to client, so that client gets all certs. BUT privacy concerns arise - revealing full set of authorized accessors may not be an unambiguously Good Thing.
Conclusions: "local names are Good"; "tags might have some use"; "cert-chain building is hard for any non-hierarchical structure which uses long chains". Code status: Andrew's code isn't publicly available at this point, might become so at some point... A link to Dynasoft's use of spki-like certs to produce ephemeral X.509 certs was pointed out by Marcus.
IV. Proposed Binary Format - Tatu
Tatu on binary formats: see Tatu's message to the list a few weeks ago suggesting a simple binary format (Message-Id: <199711231607.SAA11790@pilari.ssh.fi>). Short document (c. 5 pagen); not yet complete, more of a "thoughts for consideration". Tatu says he'll publish it as an I-D, having missed the cutoff time for this IETF (yes, that's an ACTION!)
Angelos K. also reports using spki-like certs, and the small-space utility of a binary format.
V. Verifier service ("shrinkwrap") - Angelo
[Slides will be available]
Angelo Keromytis reports on cert-result-server work: see draft-simpson-spki-shrinkwrap-00.txt. The problems which motivate this work include:
· Cert chains can be l-o-n-g
· Ipsec keying protocols use UDP, max dgram size small therefore (as little as 500 bytes^H^H^H^H^HoctetsTHE-ISO-THOUGHT-POLICE-MADE-ME-DO-IT) so carrying a l-o-n-g spki certchain in an isakmp message is pretty bogus
· Smartcards have limited storage, so cert-result-cert better to carry thereon than unreduced chain.
Enter shrinkwrap: allows verifier to reduce certchain - end-verifier may call a shrinkwrapper service to perform certchain reduction on its behalf, assuming the shrinkwrapper has better connectivity, faster computational resources, possibly trusted cache of previous on-line check results etc., etc. Shrinkwrapper protocol uses TCP to transport chain (allows more data than UDP would, acts as weak defense against denial of service); security of protocol depends on security of SPKI certs; prover is required to provide certs in correct order. Bytes on wire have typed records, monotonically increasing seqnumbers. Requestor initiates exchanges, provides certs one at a time; verifier (shrinkwrapper) eventually returns cert-result-cert (or refusal :-).
SPKI Draft Progress
SPKI - Shrinkwrap