Andrew Bromage, <bromage(_at_)cs(_dot_)mu(_dot_)oz(_dot_)au>, writes:
I may be missing something here, but why don't we just mandate that
the attribute is a MIME document (possibly compressed, possibly
multipart), then leave the interpretation of that document up to the
client?
It's true that MIME is a widely used standard which can represent many
different kinds of data. And it is used for more than its original
designed purpose of multimedia email these days. But it's not clear
that it is appropriate for this use.
We are looking at a relatively limited application and may not need the
full power of MIME, with multiparts, etc. MIME has considerable overhead,
which may not matter for a multi-K picture or voiceprint, but could be
costly for smaller attributes. It's not really in keeping with the PGP
philosophy of compactness.
The specific things we might want to put in attributes will not
necessarily have MIME types defined for them. We might use some special
encoding of fingerprints or other biometric data. This would require
defining new MIME types before we could add them to our standard.
Somebody is going to want to stick in a voiceprint, someone is going
to want to put in their v-card (don't blame me; some people like them),
someone is going to want to put in a link to their web page etc etc.
Much easier to borrow an existing well-supported standard, IMO.
If we need to I could see defining an attribute type later which is a
MIME object. But initially I would prefer to keep it simple.
Possible security risk: It should be made clear to the person doing the
checking that information stored via a hyperlink is not necessarily
signed.
Good point, although I think MIME has provisions to include the hash of
externally referenced documents so that they do end up being signed.
Hal