[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
cme@cybercash.com
8 April 1997

Agenda
• Matt Blaze -- PolicyMaker
• Status presentation
– changes since December
– changes since current draft
– closed issues
– open issues
• Discussion

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 
  solid
• [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 
  definitions)

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 
  needed
• 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 
  explicitly
• all cert-like objects are certs, except for ACL which allows multiple 
  subjects
• 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 
  revoked?
• should we specify how users name crypto algorithms?  URIs have been 
  suggested.
• 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 
  SPKI/SDSI 2.0
• 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 
  one?

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 
  equivalent?

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        |
+------------------------------------------------------------------+


Follow-Ups: