[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Referents and pointers.
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 9 May 1996 firstname.lastname@example.org wrote:
> >I'm not sure what you mean by "delegation." SDSI already has a delegation
> >mechanism independent of any secure referencing...
> SDSI has *a* delegation mechanism, if secure linkages were incorporated
> into the
> format there would be a second mechanism which would subsume the first.
> Therefore these mechanisms would need to be combined.
Maybe it's the warm weather we're having, but this just isn't sinking in
for me. The current SDSI delegation mechanism allows me to create a cert
that says "these principals can sign these kinds of things on my behalf."
In a SDSI with secure pointers, I'd still have that delegation cert,
except some (or all) of its parts can be pointers to objects. But the
meaning of the cert stays the same and the delegation mechanism stays the
same. Can you give an example of this second mechanism you're talking
> >I don't see the need to URI-ify everything, especially keys. While it's
> >tempting to make every element of a certificate a secure pointer to some
> >data, I think that'd be overkill.
> You seem to be confusing the idea of a URL, a pointer to data with a URI
> which might be a reference or simply a name.
There's no doubt that the subtleties of the UR[LIN] acronyms confuse me to
no end! :) When I say "URI" I mean something that can be plugged into
most web browsers to retrieve a file.
As for other types of names, SDSI's Local-Name: attribute lets you assign
any arbitrary string to any arbitrary object. Is this the kind of name
you're talking about?
You seem to have made a conceptual jump somewhere and lost me. Perhaps if
you restate what functionality you're looking for I'll have more
understanding of where you're coming from...
> > I don't think any one group can define what should or should
> >not be a reference. Rather, the option should be available and each
> >application can find its own mix.
> That is precisely the point I was trying to make. Do not require a
> to incorporate material by reference but arrange the syntax so that any value
> can be made into a reference.
I believe the Pointer: construct I proposed already fulfills that
requirement. There's no certificate involved -- given the (hash,
location) pair, retrieve the object and compare its hash to the given hash.
If they match, all is well.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----