Hi Peter and Charles, This is my proposal for the form filling https://github.com/cisba/ots-media-type/blob/main/form.md
In the internet draft I need at least to have already made request for the media type, . So I would like to submit the form to IANA next Friday at the latest. Please let me have your views, if interested, by email or with a pull request. KR, Emanuele BTW: what is the meaning of the last 8 bytes "bf 89 e2 e8 84 e8 92 94" before the major version numeber? On Thu, 13 Aug 2020 at 08:10, Peter Todd <p...@petertodd.org> wrote: > On Tue, Jul 07, 2020 at 08:36:05PM +0200, Emanuele Cisbani wrote: > > Hi, > > > > For the media type I agree on using the vendor tree with something like > > > > application/vnd.opentimestamps.ots > > > > where: > > > > vnd is the prefix for vendor tree > > opentimestamps is the vendor id > > ots is the ots format > > > > > > As required by https://tools.ietf.org/html/rfc6838#section-3.2 > > Note that the calendar REST interface has the clients use > application/vnd.opentimestamps.v1 in the "Accept" header. But that's *not* > the > same format as the file: that's the raw proof itself. A OTS file is > essentially > that, prepended with a header describing how to hash the file, and the > expected > hash digest. > > > N.B.: proofs and promises are different content but same media type, > > so it is not exact naming "proof" the format used for both, IMHO > > Strictly speaking a .ots file containing only pending attestations is > still a > proof. Just not a very useful one. :) > > Anway, application/vnd.opentimestamps.ots is fine. > > > If an URLs in the file points to a malicious server, the security has to > be > > granted > > by the client application that MUST discard non compliant responses. > > Thinking about it I think the security considerations section properly > isn't > going to be trivial. > > Re: URL's, the OTS client has a glob-matched whitelist of calendars, and > won't > contact any that don't match the whitelist. Currently it's: > > https://*.calendar.opentimestamps.org > https://*.calendar.eternitywall.com > https://*.calendar.catallaxy.com > > It's perfectly ok to have a OTS proof containing non-whitelisted calendars. > They'll just get ignored unless the user opts into using them. This is also > important for interoperability when additional attestations > types/calendars get > added. Though looks like the java-opentimestamps library doesn't have a > whitelist... :/ > > Remember that a URL is not a cryptographic identity, so it's probably > safest to > assume an attacker can MITM the connection. Calendars aren't supposed to be > trusted anyway, so that philosophy should be fine. > > For interoperability considerations, the current spec > (python-opentimestamps) > doesn't behave ideally, as it doesn't have any mechanism to handle unknown > opcodes in a forwards compatible manner. Instead, any unknown upcode is > just > rejected. We could instead just treat the output of an unknown opcode as > unknown, and ignore that part of the timestamp tree. > > > About the magic number I already made also a patch one year ago: > > https://twitter.com/emanuelecisbani/status/1126698067665625090?s=20 > > with this data: > > > > 0 string \x00\x4f\x70\x65\x6e\x54\x69\x6d\x65\x73\x74\x61\x6d\x70\x73\x00 > > OpenTimestamps > > >16 string > \x00\x50\x72\x6f\x6f\x66\x00\xbf\x89\xe2\xe8\x84\xe8\x92\x94\x01 > > Proof > > Note that the last byte of that header is the major version number, 1 in > this > case. Client parsing logic should be to reject any unknown major version, > which > currently means only version 1 would be accepted. There is no minor version > number. > > > I think it will be useful to share a draft of the answers to the form > > because there are many fields to fill, and many possible errors. > > Good idea. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org >
