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

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Dec 2012 01:54:01 +0000

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?

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Dec 2012 12:17:50 +0000

> needs fixing, but no thought:

Done.

> a way to hash public keys:-) Yes, filling in the TODO is

Am I allowed to refer to I-Ds?

> - STH needs to be expanded on 1st use

Done.

> - ref [1] results in a 404

Fixed.

> random comments:

I added seb servers as an example.

> accompanying" would seem better since that log-sig might be

No, it is always in band.

> forever and have no "expiry"/ ?

I just said "do not expire".

> - intro, para1:  s/solve the problem/mitigate the problem/

Good point.

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

This is explained in the last paragraph.

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

Fixed.

> adderssing client certs too? I don't care assuming it works

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

> then it ought IMO be a 2119 term here.

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

> be made (e.g. a clock might be off)

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

> trust it to sign properly and for whatever signature-validity

I have tried to clarify this.

> say why you chose a 0 for the first but a 1 for others.

Done.

> I'm not sure their code could work at all in that case, or

It would be an infinite loop :-)

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

Done.

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

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

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

> for the language to recognise that.

Done.

> usefully/ in the same sentence.

Done.

> - 3.1, what's the use-case for a log accepting a cert that has

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.

> precert-signing-cert" rule.

I can't parse this!

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2012 12:47:33 +0000

Just the bits where there's something to say:

> Am I allowed to refer to I-Ds?

You could. However, my I-D is gonna be stuck for a while
since it has a normative dependency on http/1.1 drafts so
unfortunately you're probably better to just copy the bit
of text you need from there, if you want to use it. If
you do that you could copy what you need and add an
informative reference and it could all be fixed up later
without slowing down your RFC.

Or you could refer to DANE [rfc6698] assuming you hash
the SPKI which both my draft and DANE do.

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

s/prove/provide strong evidence /  maybe

>> precert-signing-cert" rule.

Can't say I blame you, wonder who typed that silly comment;-)

It was this bit that triggered the comment:

    struct {
           ASN.1Cert leaf_certificate;
           ASN.1Cert certificate_chain<0..2^24-1>;
       } X509ChainEntry;

       struct {
           ASN.1Cert tbs_certificate;
           ASN.1Cert precertificate_chain<1..2^24-1>;
       } PrecertChainEntry;

The certificate_chain can be empty but the
precertificate_chain cannot. That's right given the
current spec, but maybe non-obvious.

The 2nd part of the comment was that if you do need
to change the precertificate_chain idea (if the
issuing CA cannot create a precert issuer under itself
e.g. because of a pathLenConstraint) then the
PrecertChainEntry syntax might also have to change.
I dunno if that'd be a real problem now, or only
later, or is just theoretical but I'd say there
will be CAs that can issue TLS server certs but
that cannot issue a sub-ca cert for precertificates.

Cheers,
S.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 19 Dec 2012 13:02:32 +0000

On 19/12/12 12:47, Stephen Farrell wrote:
<snip>
> that cannot issue a sub-ca cert for precertificates.

Ben, you said to me privately a couple of months ago that you would be 
happy to support the option of having each pre-cert signed directly by 
the same root/intermediate CA that will sign the final cert.

Are you still happy to support this option?

IMHO, having to include a Precertificate Signing Certificate in the 
precert chain represents unnecessary hassle.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Dec 2012 13:41:44 +0000

> the SPKI which both my draft and DANE do.

For a single sentence it seems simpler to just say it again!

> s/prove/provide strong evidence /  maybe

OK.

> that cannot issue a sub-ca cert for precertificates.

Well, in response to Rob's comment I'm going to have to change this anyway :-)

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Dec 2012 13:43:13 +0000

On 19 December 2012 13:02, Rob Stradling <[email-masked]> wrote:
> Ben, you said to me privately a couple of months ago that you would be happy
> to support the option of having each pre-cert signed directly by the same
> root/intermediate CA that will sign the final cert.
>

Absolutely. All we care about is a strong link to the issuer - we
don't care how that's achieved! The current convoluted method was, I
think, in response to some CAs' concern that they didn't want to issue
a usable cert as an intermediate step.

>
> IMHO, having to include a Precertificate Signing Certificate in the precert
> chain represents unnecessary hassle.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 19 Dec 2012 13:56:22 +0000

On 19/12/12 13:43, Ben Laurie wrote:
<snip>
> Absolutely.

Great. :-)

> All we care about is a strong link to the issuer - we

Are there any alternative ways to make the precerts unusable, even if 
issued directly by the same root/intermediate CA that will sign the 
final cert?

How about requiring each precert to have a Critical extension with an 
OID that no existing software will recognize and which CT-compliant 
software will be required to reject ?

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Dec 2012 13:58:47 +0000

On 19 December 2012 13:56, Rob Stradling <[email-masked]> wrote:
>>> happy

We are more than happy to support _any_ option that meets the
requirements of CT and is convenient for CAs.

> Are there any alternative ways to make the precerts unusable, even if issued
> directly by the same root/intermediate CA that will sign the final cert?\

Yes - there's already belt & braces going on there - the precert
includes a critical extension that is otherwise unused, and so should
prevent processing of it by any X509v3 client. The intermediate was
just an extra precaution.

> How about requiring each precert to have a Critical extension with an OID
> that no existing software will recognize and which CT-compliant software
> will be required to reject ?

You have read the I-D, right? :-)

---

From: Rob Stradling <[email-masked]>
Date: Wed, 19 Dec 2012 14:07:22 +0000

On 19/12/12 13:58, Ben Laurie wrote:
<snip>
> You have read the I-D, right? :-)

TBH, I haven't yet read -03 properly.  :$

The critical poison extension wasn't in -02.  I had been expecting you 
to remove the Precertificate Signing Certificate concept and add the 
critical poison extension concept at the same time.  ;-)