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

Re: IETF spki meeting minutes


At 05:32 PM 8/14/97 +0200, Steve Bellovin wrote:
>Timetable? Well, intention *did* exist to put forward a draft to become 
>part of standards process from this meeting.  Absence of Carl Ellison and 
>Tatu's doubts mean that this has slipped.

I really regret not having been there.

>Matt Blaze explains one important difference between SPKI and SDSI (in
>answer to a comment in the spirit of "this is so complex, isn't it just
>SDSI in drag") - SPKI is an authentication scheme, while SDSI was for

This isn't quite accurate.

The old 3 verbs, from time sharing days, were Identify, Authenticate and
Authorize.  In those days, you would identify yourself by user name,
authenticate by password and be authorized by ACLs.

In the PK world, some people have assumed that you would identify via a
globally unique name (which still bore some resemblance to a common name,
eg., by including it as a sub-field), authenticate by digital signature
and be authorized by ACLs.  This is a straight translation of time sharing
practice, but it's not appropriate.  In a system this big (the whole
globe), the name becomes unwieldy and meaningless.

What we're doing is recognizing that the public key itself is an
identification (a name, for computer purposes), authentication is by
digital signature and to keep ACL management from getting impossible,
we put *authorization* into the certificate (as well as allowing it
to be in an ACL).  This allows refinement of authorization by
organizational subunits without having to give those subunits access
to the master ACL (or worse a thousand points of ACL).

>Clarification requested for blind signature status - draft claims it'll 
>work but two people, including Marjku-Juhani who is doing an 
>implementation from the spec (see later) note that they do not in fact 

I still claim it works and haven't seen any counter-argument.  Let me
spell it out here:

   <signature>:: "(" "signature" <hash> <principal> <sig-val> ")" ;

The <hash> is a hash of what's being signed.  Assuming RSA and Chaum's
formulation, you take that hash, h, format it according to the
formatting rules (e.g., PKCS1), and multiply it by (r^e) -- then send
that byte string off to be raised to the d power by the blind signer.
When you get that byte string back, you divide by r and put that
value in your signature block as <sig-val>.

What prevents this from happening?  Is there any blind signature
proposal for any algorithm which the definition of <signature> above
doesn't accomodate?

>-- Discussion on current draft
>Floor opened for discussion on the draft. One voice says "it's long". 
>Other voices agree that "simple" isn't accurate any more. No-one was 
>willing to put their hand up to the opinion that it is now a "simple" pki .
>Doubt expressed (from Eric) that the "pulling things out" method for 
>simplification will work - suggests that admitting a mistake has been made 
>(perhaps rhyming with "Pudsey" :-) and maybe doing a grand reset would be 
>the right thing.

I have heard from others that it's too long and should be split into
pieces.  I will happily do so.  How about:

(1) wordiness moved over to requirements document
(2) BNF of objects (with examples)
(3) reduction rules (with sample code)
(4) extensions (e.g., K-of-N, if the group decides to remove it from the
	base spec)


We could certainly do a grand reset to the original proposal.  That was my 
1st of 4 options, on the top of p. 37.  That is:

<issuer>:: <principal> ;
<subject>:: <principal> ;
<delegation>:: <boolean> ;
<auth>:: <string> <count(= N)> <N strings> ;
<validity>:: <not-before>? <not-after>? <online>? ;

What we would lose is:

1.	SDSI names as issuers and subjects.  The current draft incorporates SDSI 
name evaluation (chain reduction) as a part of normal 5-tuple reduction.  
With SDSI names specified only as one kind of <auth> -- "NAME" -- any code 
that reduces SDSI name chains would live outside the 5-tuple machinery and 
would, in effect, duplicate it.

2.	*-forms (which can be cut back) -- but certain <auth> forms would need to 
specify the intersection rules.  This would have to live in some out-of-band 
statement.  The original spec was weak in that area and Ron's *-form 
suggestion made it clearer.  I probably went overboard in my elaboration of 
what can combine with what to produce what.  [It's the mathematician in me 
:).]  We might have too many *-forms.  What we need for sure is a way to 
specify numeric ranges (for banking, purchase orders, etc.) and a way to 
specify pathname completion (for access to file systems).

3.	K-of-N -- something really powerful, but something we could conceivably 
restrict to ACL entries (where the reduction rules are much simpler:  try to 
reduce N chains and see if K survive).

>Matt Blaze recounted a discussion of a year ago between him and Carl where 
>Carl suggested the full power of Policymaker was too general and 
>something simpler was needed - but the current accretion of features has 
>created something big again. Maybe an SPKI-lite is needed. Marjku also 
>points out that the full implementation is too big to verify, and that the 
>intersection algebra is going to be hard. Tatu notes that the S-expression 
>intersection combination is further complicated by star forms - algorithms 
>"aren't trivial", *probably* polynomial time. But Carl and RonR note that 
>you do not need to compute the intersection: you are always computing 
>whether a fully-ground TERM is a *member* of (multiple) predicate specs, 
>and you can cascade the tests...

This is probably my mistake in writing the current draft and the main reason 
I regret so strongly having missed the meeting.  I don't anticipate having a 
real 5-tuple reduction program implement all the *-form intersections I 
listed in the draft.  That's available, if one wants to do Left to Right 
reduction.  If you're doing right-to-left reduction, as we expect will be 
the case (except possibly for the more complex k-of-n cases), then you are 
always intersecting a *-free form with a *-form -- so almost none of those 
rules apply and those which don't apply don't need to be implemented.

>Floor requests the WG chair to say whether an X.509 or a SDSI cert is 
>harder to handle. "On advice of counsel", Bellovin replies "the 
>complexities are different". SPKI is simple to parse (but semantics are 
>another matter!) Also, X.509 does not carry the authorisation idea - SPKI 
>does. Problems with X.509 are not ASN.1, suggests 
>GUY-IN-BLACK-SITTING-NEXT-TO-MATT: rather that the structure is static and 
>only uninterpreted random octet-strings can be added.

To me the difference is that we're trying to do more of the security job 
than X.509 does.  We're doing the thing which matters, IMHO, namely the 
authorization.  Mere identification (name binding) is practically irrelevant 
in the modern world.  So, we do all the job you need in a structure which is 
simpler to parse and has no extraneous fields.  To me, that makes us 
substantially simpler.

>General consensus that "the path to simplicity has been lost" - WG chair 
>suggests taking this to the mailing list. 

I would like substantial feedback from the mailing list on this issue.

>-- More discussion on draft/current status
>Suggestions for simplification requested - maybe more hands to 
>assist Ron, Carl, and Tatu? 

In my experience, each additional set of hands has resulted in an additional 
set of nice features.  To get simplicity, we need to reduce the number of 
hands.  Specifically, I need to get a sense from the group and produce a 
spec to fit that sense.  I might defend simplicities which others claim are 
complexities, but that's the process.

>Marjku suggests "membership 
>operator" as one possible direction. 

I don't know what this means.

>Tatu speaks a bit more on motives for 
>introducing the binary-only representation[...]

I have a binary format which reduces to the canonical form, but uses 1-byte 
object names and fixed length binary byte string length fields.  Should I 
post that format?

>More on K-of-N: in "traditional" case of a certchain, full rights-granting 
>goes along the chain: [...]

This is a very powerful feature.  I would like to let the mailing list mull 
it over before rejecting it out of hand.  It does complicate the reduction 
process, however.  So, I would like to suggest three possibilities:

a.	toss k-of-n entirely
b.	use k-of-n only in ACLs
c.	keep k-of-n


>Observation from Ted Ts'O - can do the more complex example suggested
>by Eric by AND'ing the 2 primitives.  CA liability risks also
>reduced by secret-sharing, as are costs of protecting each individual
>secret keys.

I'd like more detail on this suggestion.  Can Ted post details?

>Tatu / others suggests complications in the spec (possible candidates for 
>elimination from the base spec) include:
> - the star-forms (or at least the set-algebra operations therein)

I should probably have just listed how to intersect a *-free form with each 
*-form, since that's what will happen in practice.

> - K-of-N

See above.

> - anything which goes beyond "does auth" and "is simpler than X.509"


> - SDSI names

I think these are essential, e.g., for e-mail.  We will end up supporting 
them, even if only via an <auth> field of the form "name (1) fred" [to use 
the 1996 syntax].  The question is whether we want to use them as well 
as define them -- and whether we want to provide the machinery for reducing 
a full SDSI name to its key, or let that be outside of SPKI's turf.

> - S-expressions :-)
>of which the Chair deftly bounced reopening the S-expression religious
>war and the "anything beyond" suggestions.

I was originally strongly opposed to S-expressions.  Then, as I fleshed out 
the detail of the original binary syntax I found myself creating begin/end 
statements of various flavors.  As soon as I made the second different 
begin/end pair, I realized that "()" takes care of this necessary grouping 
very cleanly.  The only problem S-expressions introduce is recursion, but we 
can limit that.

 - Carl

Version: PGP for Personal Privacy 5.0
Charset: noconv


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