Since TRANS is joined to X.509 at the hip, how about we just shovel all the metadata describing the configuration of the notary into the certificate that signs the notary log outputs periodically?
I am assuming here that the signing hierarchy for the log has an offline key that periodically signs the online key. The cert for the online key can specify the notary algorithm by OID (its ASN.1 after all) and any other parameters that might be useful. Probably want to allow for different accumulation strategies in case we ever decide a binary tree isn't the only choice. Might have some other options. Might want to be able to specify the CPS/CP equivalents for the notary, etc. On Tue, Apr 8, 2014 at 10:28 AM, Dmitry Belyavsky <[email protected]> wrote: > Hello Ben, > > > On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie <[email protected]> wrote: >> >> On 8 April 2014 15:18, Salz, Rich <[email protected]> wrote: >> >> > I do not understand why metadata is more secure then the data itself. >> > >> >> It is created by a different authority. >> > >> > ? Is this in the part of the RFC that is still TBD? >> >> The RFC describes how logs work and how clients work. It does not >> describe how clients decide what logs they are prepared to accept. I >> am not sure it should. >> >> But whoever does also decides whether the algorithms in use by the >> logs are acceptable and tells the client what those algorithms are >> (along with other things, like the log's key, base URL and MMD). >> > I think that the client should be able to find out the algorithm used by log > because it cant'be changed during the log lifetime. And if the RFC specifies > the URIs for certificate submit, it seems to me that it's reasonable to > specify the URI for finding out the algorithm. But I prefer to leave out of > band of the protocol only the data that can't be passed using it. > > Thank you! > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > -- Website: http://hallambaker.com/ _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
