[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slides from IETF in Memphis
-----BEGIN PGP SIGNED MESSAGE-----
At 12:19 AM 4/21/97 -0400, Carl Ellison wrote:
>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.
This is that reply.
>SPKI Status and Issues
>Carl Ellison
>cme@cybercash.com
>8 April 1997
There was an extended discussion of the syntax choice of
(certificate
(issuer (name <key> n))
(subject (...))
(tag (*))
)
versus
(certificate
(issuer <key>)
(subject (...))
(name n)
)
for defining SDSI names. The first form looks like creeping complication
but turns out to simplify the 5-tuple reduction process.
My copy of the title slide has many notes from that discussion which I can't
reproduce here (for lack of memory of the order of writing them).
>Open Issues -1-
>• what online tests should we define?
> – deliver CRL
maybe not
> – revalidate cert X
probably
This should be discussed here on the mailing list -- so I just sent mail
on it.
> – (more ??)
>• what predefined authorizations should we define? should these be in a
> separate RFC?
yes -- in a separate RFC
>• if subject is a bundle of hashes or keys, does the cert apply to all in
> the bundle?
for now, no -- but this is an open issue which needs to
be discussed someplace. W3C?
>Open Issues -2-
>• should we define a key validity certificate, so that a key itself can be
> revoked?
drop this
[it turns out that after the meeting, I convinced myself that a normal SPKI
certificate can achieve all that a key validity cert can achieve. The user
generates a permanent key and temporary keys. He gets permissions assigned
to the permanent key and delegates them to the temporary one. By having
permissions assigned to (subject (ref <key1> name)), where he owns <key1>
(the permanent key) and attaches the temporary key to name, he can even
receive permissions which don't include the permission to delegate.]
>• should we specify how users name crypto algorithms? URIs have been
> suggested.
Various possibilities were thrown out -- alg@domain.name, for example,
but someone suggested using SDSI names to name algorithms and that
appeals to me.
There are always IANA assignments.
>• should we restore references to Micali's [ECR]?
No
>• should we allow object, not just object-hash, inside a (signed ...)?
No
>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
This should be a separate document
>• should we have a different type from (ref ...) for the simple name option
> as an issuer?
Yes
[I propose using the syntax (issuer (name <key> n)) for this purpose.]
>• should we describe certificate server operation in this RFC or a separate
> one?
Separate one.
If we use DNS, how do we map SDSI names or SPKI keys into the
DNS namespace? This issue should be written up, possibly
in a separate document.
>Open Issues -4-
>• should we put examples of real authorizations in this RFC or a separate one?
Separate one
>• should we permit (propagage <group-name>)?
This is for mailing list discussion.
[I just sent a message about it.]
>• does (tag (program <hash-or-name>)) take care of PolicyMaker or the
> equivalent?
MAB said "no". I asked him afterwards and he will write this up, but
in summary, he's concerned that there is much to be done in vetting the code
which does 5-tuple evaluation, not just in certifying imported PolicyMaker
code. The syntax above is probably good enough for that limited purpose.
He wants to be able to prove that your trust model execution enviornment is
itself trustworthy.
----------------------
In addition, I had one blank overhead for additional issues:
1. pure binary vs. S-expression
This was raised by Tatu (maybe others) and we have been discussing this in
a smaller group, off the list. I believe I have a proposal which
incorporates both and does so without doing violence to either, but I want
to get that through Tatu's review before I present it to the list.
2. non-contiguous validity times
This is for discussion on the list. I'll send out mail now.
3. [Tatu] We should provide a working algorithm for 5-tuple reduction.
Agreed...as a separate draft.
4. [Tatu] The draft isn't explicit enough about white space.
Yes -- this is being fixed.
5. Work out hash of canonical S-expression and include in the draft.
Yes, the draft will contain hashes and signatures of various
objects, so that the draft reader can check them. I hope to publish
code for signing and verifying, not just hashing, referring to crypto
in the hole -- on the theory that since this is authentication code,
we don't have to sweat export rules. I'll check that with NSA contacts.
6. Fully explain the (ref k n) issuer issue.
Done at the meeting.
7. Give more elaboration of [] display hints.
I don't know now what was meant by this. Can the person who
raised it restate it on the list?
8. Give worked out example of 5-tuple reduction using
(issuer (name <key> n))(tag (*))
versus the -00 style
(issuer <key>)(tag (name n))
9. Explore non-membership certs, from SDSI 1.0
There were loud protests against this, as non-monotonic logic.
To me, non-membership in group x is the same as membership in some
real group named not-x, so it's a non-issue.
10. Are online tests allowed to have state? ...side effects?
[For example, an online test might be "does this account have more than $400
in it?" -- or "try to lock file Y and tell me if that succeeded."]
For now, the feeling was to just say no.
This is a characteristic of transaction processing systems and probably
not appropriate for the world of certificates. However, discussion is
always welcome.
11. Does anyone have an application requiring key revocation?
None did, in the meeting.
12. Should string lengths be ASCII rather than binary?
Our current thinking on canonical forms has binary string lengths
expressed as ASCII decimal numbers -- so that the rare individual who
needs to examine a canonical form object in an editor like vi or emacs
can skip over the given number of bytes to get to the end of the string.
-----------------
End of notes from Memphis. Sorry for the delay.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBM1r+NVQXJENzYr45AQEAYgQAsVf9zljQopbPDy5PQgSOpJ/g6lGscwDj
g5C10enKu3hrX+qkVSGG8Idpq3NTcDo/fjlQZkTGVdb7tHPZMIu2MZHG5t05VUGL
j9WUOjA2raUzSprQHxBouhts/+TdYeGSK+dY10irVnnofJ7iDGVACDI4gs5t/5ij
gTHKZoGlIxw=
=lvFo
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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:
References: