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

[Stephen Farrell <[e-mail]>]

Hiya,

I think this is getting very near the point where we can last
call it, but isn't quite there yet. My review below.

Cheers,
S.

maybe needs thought, defo needs answering:
------------------------------------------

(1) RFC 5878 has a bunch of IPR declarations [1] attached and
is not afaik widely implemented (is it at all?). Is re-use of
that really a good plan for something ultimately intended to
be used for all web servers if that IPR were problematic?
Note: in the IETF we don't judge the terms nor applicability
of IPR but we do pay attention to what IETF participants say
they think about that. In this case, there's no WG, so I'm
asking. (Full disclosure: one of the declarations is a 3rd
party one I made. [2]) My take is that this might be
problematic, but what do others think?

  [1]
https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=5878
  [2] https://datatracker.ietf.org/ipr/808/

(2) abstract: "domain owners or their agents" makes it sound
like I might have to pay to monitor; be good to re-assure that
no such constraint is planned. (Such re-assurance doesn't need
to be in the abstract, arguably not even in the draft, but
also arguably ought be somewhere.) While its none of the
IETF's business who charges for what in general, in this case,
where there has been ongoing negative comment on the impact of
PKI business models on Internet security, I do think it'd be
good for the authors of proposals to be clear how they think
they're affecting such charging issues.  Personally, I guess
that since EFF and some academics have been able to afford to
populate large databases of TLS server certs, this shouldn't
become a huge barrier, but it could in principle impose new
subscription costs or constraints on TLS servers or even
clients and that might not be a good plan.

(3) Sometimes you say "the log" and other times "logs" I think
the term log needs to be used consistently otherwise we may
end up being unclear about cardinalities of things later.
Suggest adding a specific definition for this term, or invent
a term for all logs everywhere.

(4) You say you expect "most" public CAs to take part. I think
that's a bad thing to say for an experimental RFC and could
cause you problems at IETF LC (say if some CA says "this is BS
because we're not taking part"). The experiment in any case
doesn't need most CAs, just some useful number and you seem to
have that.

(5) 2.1, better to say sha-256 is hard-coded for now and that
that's ok for an experiment - you may well get comment on that
since a standards-track RFC would need alg. agility probably.
Do *all* logs have to use sha-256 or is it just that all logs
have to use one hash alg? Be good to be clear on that too.

(6) The precertificate thing needs some more detail at least,
e.g. what's "poision" about? (I assume its to prevent such a
"pre-cert" be verified anywhere, but then you could also mess
with the dates.) Also, saying the precert-signing-cert has to
be signed by "the CA cert" private key isn't quite enough. If
you mean the same CA cert that's above the TLS server cert
then that might not be possible (e.g. with pathLen) albeit
that's unlikely, but there could be other reasons why that CA
can't issue a CA cert (which the precert-signing-cert is,
right?)

(7) 3.1, p10, 2nd para: "...chain...to a trusted root..." does
that mean that trusted root has to be the CA that issued the
topmost cert in the submission to the log, or is any trusted
root accepted by the log ok? ("using" the chain might not be
considered normative.)

(8) 3.1, says the log can accept "not fully valid" things but
also says that a "valid chain" is required. That needs
clarification I think, since some would consider that a valid
chain cannot contain e.g. an expired end-entity cert.

(9) 3.1, " However, the log MUST refuse to publish
certificates without a valid chain to a known root CA." seems
to preclude any solution for self-signed certs or DNSSEC/DANE.
Is that a good plan? Maybe if you make it a positive "must
accept" then that'd avoid that problem? (If a good solution
for SSCs or DANE spam is figured out later.)

(10) 3.1, identifying a log solely on the basis of its key_id
without any roll-over seems dumb. What if the log wants to
roll its signature key? This would have to be fixed in a
standards-track RFC but really could be done now and would be
better for having being done.

(11) various places: I'm not sure you need extensions in all
the places you have 'em - if this does become an experimental
RFC followed by a standards-track RFC, then that can be
handled then.

(12) 4.x - would it make sense to use .well-known/ct/ URLs or
not?

(13) 4.x - how does CT impact on the TLS server cert used for
these HTTPS connections?

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:-)

- 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.

- STH needs to be expanded on 1st use

- section 5, 2nd para: gossip TBD needs to be done

- ref [1] results in a 404

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?

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

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

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

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

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

- 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.

- 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.

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

- 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.

- 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.

- 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?

- 2.1.4: the NIST reference should be a proper reference

- 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.

- 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.

- 3.1, 1st para: a list of roots does not "attribute each
logged cert 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.

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

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

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

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

- 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.

- 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.

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

- 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?
I've not thought about it, but has anyone?