[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF spki meeting minutes
In <firstname.lastname@example.org>, Carl wrote:
> At 05:32 PM 8/14/97 +0200, Steve Bellovin wrote:
(actually errors and misreportings are, at least at the draft stage of
the minutes, my fault rather than smb's. In particular I apologize if
the somewhat light-hearted tone of the draft minutes gives anyone the
impression that Carl's draft was in any way the object of derision -
> >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.
[Note minute-taker's incomplete binding of an individual's identity above;
final form of minutes would be more useful as either "It was remarked that"
or with a community-recognisable name replacing "GUY-IN-BLACK-.*"]
> 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.
Personally I find the above is a compelling statement of requirements;
nor, having been little more than an intermittent lurker on the list to
date, do I yet have a strong sense as to whether the remedy for the
> >General consensus that "the path to simplicity has been lost"
is to prune bits of perceived complexity, to have their apparent complexity
more clearly explained and accepted as necessarily powerful primitives,
or the radical reset suggested by some present at the WG meeting.
> >Marjku suggests "membership
> >operator" as one possible direction.
> I don't know what this means.
I *think* what Markku was getting at was an operator specifically to
intersect a *-free form with a *-form, rather than requring the generality
of *-form intersection which you (Carl) described earlier:
> 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.
However if I've got hold of the wrong end of the stick, I invite Markku
and Carl to beat me bloody with it :-)
> > - anything which goes beyond "does auth" and "is simpler than X.509"
This was a comment in the "not *simple* any more, let's reset" category.
As an (almost) throwaway remark during the session wrap-up I probably
shouldn't have put it into the minutes, as the thinking behind it was
more clearly expressed by the more detailed suggestions in this wrap-up
Hope these few clarifications make the minutes clearer; I have a vague,
unfounded presumption that smb will put out a final, non-draft form of
the minutes when it seems like all those who want to clarify the minutes
draft have had a chance to do so.
In-real-life: Stefek Malkowski Zaba
Organisation: Hewlett-Packard Laboratories, Bristol
Address: Filton Road, Stoke Gifford, Bristol, England, BS12 6QZ
Telephone: +44 117 922 8071 / HP Telnet 312 8071
US Voicemail: 415 857 6442
Fax: +44 117 922 9285
PGP fingerprint: 26 5B 8B 56 00 6A B4 45 F9 D1 3E A0 D6 C5 8A 04
All and any statements, assertions, and opinions above void
where prohibited by reality.