Hello Ben,
On Mon, Mar 31, 2014 at 2:51 PM, Ben Laurie <[email protected]> wrote: > On 31 March 2014 09:21, Dmitry Belyavsky <[email protected]> wrote: > > Dear Ben, > > > > Sorry for my late response. > > > > 18.03.2014 18:20, Ben Laurie wrote: > >> As I mentioned elsewhere, in our view you change algorithm by starting > >> a new log. > > > > Ok. What about a way to find out the algorithm in use? > > That is metadata that clients must discover outside the protocol > (along with things like MMD, log URL, etc). > I think that whether we have to discover the log URL outside the protocol, it will be better to specify URL like https://<log server>/ct/meta/ to find out the concrete setting f the log server. > > >> It seems to me there shouldn't be any difficulty accommodating GOST > >> like this - I guess we'd have to add the rule that non-GOST > >> certificates MUST NOT use GOST logs. Not sure whether we should > >> require the opposite, though (i.e. GOST certificates MUST NOT use > >> EC/SHA logs)? > > > > What is expected to be a right behaviour in case when a certificate has > SCT > > from some different log servers, if some of the SCT signatures can't be > > verified? If they are to be just ignored, I'm not sure we need such a > > limitation. > > Fair point. > So it seems to me that this (or any other reasonable) behaviour should be specified somewhere in the section describing TLS client behaviour. Thank you! -- SY, Dmitry Belyavsky
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
