Subject: Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 1 Apr 2014 13:25:32 +0400

Hello Ben,

On Mon, Mar 31, 2014 at 2:51 PM, Ben Laurie <[email-masked]> wrote:

> On 31 March 2014 09:21, Dmitry Belyavsky <[email-masked]> 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

---

From: Ben Laurie <[email-masked]>
Date: Tue, 1 Apr 2014 10:35:16 +0100

> out the concrete setting f the log server.

That seems like a bad idea, because then log servers could, for
example, vary their promised MMD.

> specified somewhere in the section describing TLS client behaviour.

Perhaps you could file a ticket on the issue tracker?

-- 
Certificate Transparency is hiring! Let me know if you're interested.