[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: