[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

slides from IETF in Memphis

Here are the slides as they were prepared for the IETF meeting in Memphis.
In a reply to this message, I will give the notes I handwrote on those 
slides (and blank ones) during the presentation.

SPKI Status and Issues
Carl Ellison
8 April 1997

 Matt Blaze -- PolicyMaker
 Status presentation
 changes since December
 changes since current draft
 closed issues
 open issues

Changes from -00.txt
 include SDSI as a subset (not all of SDSI -- SDSI pared down for 2.0)
 pure SPKI operation (without SDSI names) is still possible, for those 
  wanting max simplicity
 switch to S-expression encoding from pure binary
 almost complete

Changes from -01.txt
 single choices for object types, in a new BNF
 RLR's (tag) definition -- simplifies 5-tuple reduction and makes it more 
 [soon] a public key definition
 [soon] a hook for program tags (e.g., PolicyMaker)

Closed Issues -1-
 don't force counter-signature by Subject
 assume we support all blind signatures
 eliminate final ":" in object names
 separate iems of a public key (hash alg, input formatting, pub key alg and 
  values, output format)
 boolean delegation, with (propagate to-key) as a possibility

Closed Issues -2-
 object names are case sensitive -- all object names we define are lowercase
 (* set ...) tag options allow for multiple authorizations in a cert 
  without seriously complicating the reduction

Closed Issues -3-
 hashes inside a file which is the subject of a cert are not necessarily 
  delegated the authorization of the cert.  This is a general issue the web 
  community may face with signed web pages and we should wait for them to deal 
  with it.
 private key validity dates aren't needed in the cert

Closed Issues -4-
 defining public keys without a hash is a possibility in the public key 
  structure which people probably should not use.
 SDSI member and SDSI name are now the same
  issuer is restricted to key, key-hash or simple SDSI name (to permit SDSI 
  name or group definitions to have the same syntax/semantics as SPKI group 

Closed Issues -5-
 we will use [xxx] yyy for display info
 we will use one spelling for object names, not short and long options
 object type names have non-global scope
 subject is allowed to be the hash of a non-key; no second object type is 
 the draft should make it clear that we deal only with signatures and 
  signing keys

Closed Issues -6-
 we use (ref ...) for all name forms.
 we've added (keyholder k) to indicate the person who is the keyholder 
 all cert-like objects are certs, except for ACL which allows multiple 
 let (propagate to-key) take care of stopping delegation at the leaves of a 
  SDSI group

Open Issues -1-
 what online tests should we define?
 deliver CRL
 revalidate cert X
 (more ??)
 what predefined authorizations should we define?  should these be in a 
  separate RFC?
 if subject is a bundle of hashes or keys, does the cert apply to all in 
  the bundle?

Open Issues -2-
 should we define a key validity certificate, so that a key itself can be 
 should we specify how users name crypto algorithms?  URIs have been 
 should we restore references to Micali's [ECR]?
 should we allow object, not just object-hash, inside a (signed ...)?

Open Issues -3-
 We need to add a section showing SDSI 1.0 users how to do the same things in 
 should we have a different type from (ref ...) for the simple name option 
  as an issuer?
 should we describe certificate server operation in this RFC or a separate 

Open Issues -4-
 should we put examples of real authorizations in this RFC or a separate one?
 should we permit (propagage <group-name>)?
 does (tag (program <hash-or-name>)) take care of PolicyMaker or the 

SPKI Working Group
 mailing list spki@c2.net, majordomo@c2.net to subscribe
 drafts on the ietf draft site (draft-ietf-spki-*.txt)
 http://www.clark.net/pub/cme/html/spki.html has the latest (unsubmitted) 
  draft and other documents

|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |