Re: [therightkey] review of draft-laurie-pki-sunlight-03

[Ben Laurie <[e-mail]>]

On 17 December 2012 01:54, Stephen Farrell <[e-mail]> wrote:

> needs fixing, but no thought:
> -----------------------------
>
> - abstract: the RFC editor doesn't want references in
> abstracts, just use the RFC number and then put the [] into
> the body of the text 1st time you refer to each RFC. That
> might mean you need to repeat stuff from the abstract.
> (Apparent reason for RFC editor pref is that sometimes people
> just see the abstract and couldn't follow the reference, feel
> free to argue with the RFC editor on this about some other
> document:-)

Done.

> - Where're the OIDs in 3.1 and 3.2 registered? They should be
> in the some registry I guess.
>
> - 3.1, shameless self-promotion - draft-farrell-decade-ni has
> a way to hash public keys:-) Yes, filling in the TODO is
> needed.

Am I allowed to refer to I-Ds?

>
> - STH needs to be expanded on 1st use

Done.

>
> - section 5, 2nd para: gossip TBD needs to be done
>
> - ref [1] results in a 404

Fixed.

> random comments:
> ----------------
>
> - abstract: "public end-entity" might not be the best term,
> maybe the word "web server" is needed since that's the real
> (inital) concern?

I added seb servers as an example.

> - abstract: "accompanied by" seems wrong, "for which an
> accompanying" would seem better since that log-sig might be
> found in or out of band.

No, it is always in band.

> - abstract: s/will be valid indefinitely/are good or bad
> forever and have no "expiry"/ ?

I just said "do not expire".

> - intro, para1:  s/solve the problem/mitigate the problem/
> better not to over-claim

Good point.

> - intro, para1: what is an "untrusted log"?

This is explained in the last paragraph.

> - intro, para1: s/added/are added/

Fixed.

> - intro, para1: s/public TLS/public TLS server/ or are you
> adderssing client certs too? I don't care assuming it works
> but you ought be clear.

The protocol would require tweaking for client certs, so I have said server.

> - intro, para 2: ought "required" be 2119 terminology here?
> Its ok if it is repeated later, but if its not repeated later
> then it ought IMO be a 2119 term here.

It is repeated later. It seems mean to put normative requirements into an intro!

> - intro, para 2: I'd avoid the word "prove" since mistakes can
> be made (e.g. a clock might be off)

I am slightly at a loss for a better word here!

> - intro, last para: I think you need to be clear about
> trusting the log. Clients do need to trust it to be available
> at least, and if they process a signature then they need to
> trust it to sign properly and for whatever signature-validity
> controls.

I have tried to clarify this.

> - 2.1: "MTH({d(0)}) = SHA-256(0 || d(0))." The first input to
> the hash is ASCII '0' (0x30) or a 1-octet number 0 (0x00) or
> something else? You need to be clear on all those. Be good to
> say why you chose a 0 for the first but a 1 for others.

Done.

> - 2.1: would it be worth adding "if n is a power of 2 then
> k=n/2" ? Someone might miss "smaller than" when coding, though
> I'm not sure their code could work at all in that case, or
> could it?

It would be an infinite loop :-)

> - 2.1.4: the NIST reference should be a proper reference

Done.

> - 3, 2nd para: saying clients MUST reject without defining
> client is odd and esp when doing more than audit with CT is
> optional. The servers MUST there is also odd. I think you want
> to say "conforming to this spec" in both cases at minimum.

Surely that's implicit in all normative language? Even standards track
documents don't impose anything on me if I don't conform to them. I
have, however, made it clear that I mean TLS clients and servers.

> - 3, last para, is the MUST there correct use of 2119
> language? Formally its not an interop thing but it is a
> security thing. While I have no issue with that, some other
> ADs do (mistakenly IMO, but nonetheless it has to be dealt
> with;-). Reading and closely following the definitions in 2119
> might help with that. If, OTOH you want to argue that that's
> silly then I'm with you on that.

I would argue that:

a) It is an interop thing because you cannot audit a log that fails to
conform to that requirement, and

b) RFC 2119 says "In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)".
Failure to include the cert in the log causes harm.

>
> - 3.1, 1st para: a list of roots does not "attribute each
> logged cert to its issuer"

I'm not sure what you think is wrong with this, but assuming you mean
the terrible grammar, I've changed it to " In order to enable
attribution of each logged certificate to its issuer..."

> - 3.1, not all roots need to make self-signed certs for their
> root public keys, even though all probably do. Might be better
> for the language to recognise that.

Done.

> - 3.1, 1st para, s/shall/SHALL/ and maybe s/should/might
> usefully/ in the same sentence.

Done.

> - 3.1, what's the use-case for a log accepting a cert that has
> expired? (just curious)

People use expired certificates, either by accident or design, and
users can (currently) choose to accept them - therefore we should
allow audit of expired certificates.

> - 3.1, the log doesn't "publish" certs does it?

Yes?

> - 3.1, why are log entries called "certificate entries"?

I can't find where we say that.

> - 3.1, why "0..." for X509ChainEntry and "1.." for
> PrecertChainEntry? You probably ought say and that might need
> to change if you change the "same CA issued both EE cert and
> precert-signing-cert" rule.

I can't parse this!

> - 3.2, it might be a pain to have the string
> SignedCertificateTimestampList mean two things i.e.  both a
> type and the name of an OCTET STRING field.

But they're actually the same thing, just in two different contexts.

> - 3.2, p13, 1st para, again you say *the* CA.

Changed to "a".

> - 3.4, 64 bits for tree size? seems a lot but ok. Is there any
> way to use a large size there as a DoS by someone on anyone?

32 bits seemed risky given a few million certs per year at current rates.

> I've not thought about it, but has anyone?

Issuing very large number of certs would DoS logs and monitors. We
imagine that logs would have a discussion with CAs that started to do
this.