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

Minutes from SPKI meeting at IETF38

-----BEGIN PGP SIGNED MESSAGE-----

Here are my minutes of the SPKI meeting last week.  Carl Ellison
has reviewed them and didn't see any howling errors :-)

But note that some of the discussion was hard to hear and/or
unclear, so some of the notes here are best interpreted as
a reminder of a topic and need for further clarification rather
than as a definitive answer or example.

Cheers,

Neal McBurnett <nealmcb@bell-labs.com>  503-331-5795  Portland/Denver
http://bcn.boulder.co.us/~neal/      (with PGP key)


    Simple Public Key Infrastructure (SPKI) minutes,
    IETF38 in Memphis, Tue 1997 Apr 8
    by Neal McBurnett <nealmcb@bell-labs.com>


This was the first meeting of the new SPKI working group.

Mailing List Information:

       General Discussion:spki@c2.net
       To Subscribe: majordomo@c2.net
             In Body: In Body: subscribe spki [email address]

Perry Metzger noted that since the posting of
    draft-ietf-spki-cert-structure-01.txt
a few weeks ago there has been lots of activity on the list.
(I'll say!)

Other references and the 'draft-in-progress' can be found at
	http://www.clark.net/pub/cme/html/spki.html


Matt Blaze announced that PolicyMaker has finally been approved for release.
By the end of the week it should be available, in source code form,
at <ftp://ftp.research.att.com/dist/mab/policymaker.readme>

He suggested that the continuing focus in SPKI/SDSI on naming and "ACLs"
is misguided, and suggests that programmable credentials as embodied in
a system like PolicyMaker is the way to go.  He will write up something
for the list.


Next Carl Ellison, one of the authors of the draft, updated the
issues which have been closed since the 01 draft went up.

For those concerned about the complexity of SDSI naming, he noted
that SPKI can be used fine without SDSI names.


Review of recently closed issues:

"Auth" renamed to "tag" and redefined for easier 5-tuple reduction
 via set intersection rules.

No counter-signatures by subject.

Assume support for blind signatures in most or all algorithms.

Eliminate final ":" in object names.

Boolean delegation with (propagate to-key) for groups.

Tag option for multiple auths: (* set ...)

Object type names have non-global scope.


Next Carl went thru open issues:

Much discussion of online tests.  Matt pointed out that they
had better have no side effects, or else proofs of correctness
are much harder.  Alternative to online test:
require a cert that the test has been passed (recently?).

We decided not to define any tag (auth) types in the cert draft, but
instead leave that for future documents.

"If subject is a bundle, does cert apply to all hashes in the bundle?"
    No.

Use URIs to name new crypto algorithms?
    (I didn't note any answer to this one).

Any desire to replace ECR text from Micali that was present in previous
draft?
    No: alleged patent protection, left out.

Allow object, not just object-hash inside a (signed ...)
    No.

Provide SDSI 1.0 => SPKI/SDSI2.0 conversion hints?
    Not in the base cert document.

Include how to do Certificate server operation in this draft?
    No.

Permit propagate <groupname>?
does (tag (program <hash-or-name>)) take care of PolicyMaker or equivalent?
Matt says "no", but Carl wanted to talk with him offline about that.


Finally, issues raised in open discussion:

1 Pure binary format vs S-expressions: too much complexity, ambiguity in
S-expressions
    Resolution: Tatu will take it to the list.

2 Non-contiguous validity times?  "weekdays, not sat/sun"
    No.  Handle via tags.

3 Desire for worked-out algorithm for cert chain reduction in the draft.
    Will be added.

4 Whitespace connonicalization not explicit enought.
    Examples will help.

5 Put worked out hash of example cert.
    Will be added.

6 Fully explain (ref k n) issuer
(Rough notes - beware of typos.... ndm)

    Goal in SDSI: (ref ki ns) = ks

    Original:
    (issuer ki)
    (subj ks)
    (tag (name ns))

    New set-based auths:
    (issuer (ref ki ns))
    (subj ks)
    (tag (*))

    (issuer ki)
    (subj kg)
    (tag (*))       or (tag (ftp (*)))


7 More elaboration of [] hints
    Will be done via the list.

8 Worked out examples of (issuer (ref k n)) vs older style
    Will be added.

9 Explore idea of explicit statement of "non-membership"
    Avoid - would involve non-monotonic reasoning, much harder to prove
    correctness.

10 Are on-line tests allowed to have side-effects or state.
    (e.g. "is account positive after deducting transaction amount",
    or file locking)
    No
    Issue of making them atomic?

11 Are there any apps requiring key revocation?

12 Use ASCII lengths, not binary?

13 How to do secret sharing for certificates.
    "Easier than for keys"(?)

Request for an explanation of how SDSI ACL's work in SPKI.

Define key validity cert?  Avoid having to track down CRL?
    Defer until an example is provided.
    Could be field in (public-key)  or Drop for now.

Note on trusting clocks and clock skews
Best if the system only requires that you trust your own clock
We can't trust other clocks without secure timestamping service.

Use IANA names for crypto and hashes (stamped by group of subject experts).
TLS and IPSEC want the same thing.

Use a different name than (ref ...)
    Yes.

SDSI groups? (propagate <group name>)
    Leave open for list.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBM1gHD3Oxjn5XNuDtAQGN2AMAlrve6hwH4ocENlwz+B44axHBa1zZKDV+
Wh0VVq6DpQFUNT2y+wMlLP9ucCCB3S0ZtC/ljfbY7C1J0AfhpcjK8+PuC0iV2Hxr
rsm6+WuG3+YBLaGuGIrvPEtRa8TRUL++
=mg71
-----END PGP SIGNATURE-----
Follow-Ups: