[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Referents and pointers.
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 8 May 1996 email@example.com wrote:
> I think that if you include such a powerful mechanism as pointer
> references you are likely to want to use it throughout. You have
> effectively created a secure referencing mechanism. We can then use
> that for delegation.
I'm not sure what you mean by "delegation." SDSI already has a delegation
mechanism independent of any secure referencing...
> If we make the keys into URIs then we can develop a syntax for a generalized
> secure inclusion mechanism consisting of a type, a reference link (ie
> URI) and an authenticator, either a hash of the absolute value of the
> object or a key for signature or MAC validation.
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. There's a balance to be struck between
making everything a reference and including some actual information in the
certificate. 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.
As for the typing info, I tend to agree that it should be included as much
as possible. In SDSI, the types are "presentation hints." When it comes
to pointers, the question is whether the hint is about the pointer or
about the object pointed to (the "pointee"? :) ).
So should it be
( Photo: [image/gif] ( Pointer: ... ) )
( Photo: [URI] ( Pointer: ... ) )
I think the ideal situation would allow the client program to decide
whether or not to retrieve a pointee. One can assume that client programs
can be written smartly enough to recognize a Pointer: construct and
present it as a URI to the user even though the presentation hint says
it's an image/gif. The client should only apply the image/gif hint to the
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----