Subject: [Trans] AD Review of draft-ietf-trans-rfc6962-bis-30

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Dec 2018 12:13:32 -0800

his seems to be getting a lot closer. I have a few small issues
remaining.
IMPORTANT
S 4.2.
>      To ensure that logged certificates and precertificates are
>      attributable to a known trust anchor, and to set clear expectations
>      for what monitors would find in a log, and to avoid being overloaded
>      by invalid submissions, the log MUST NOT accept any submission until
>      it has verified that the submitted certificate or precertificate
>      chains to an accepted trust anchor.

I think the rules still have to be clarified a bit here. E.g., does it
have to be within validity windows? How much of the RFC5280 rules do I
need to follow?

S 8.1.3.
>
>      In addition to normal validation of the server certificate and its
>      chain, CT-using TLS clients MUST validate each received SCT for which
>      they have the corresponding log's parameters.  To validate an SCT, a
>      TLS client computes the signature input by constructing a "TransItem"
>      of type "x509_entry_v2" or "precert_entry_v2", depending on the SCT's

How do I proceed if I have an invalid SCT but by policy I would accept
the certificate if the SCT had been omitted.

COMMENTS
S 6.5.
>      o  The TLS server sends a modified Certificate message (as described
>         in section 4.1 of [RFC7924]).
>
>      If the "hash_value" of any "CachedObject" of type "ct_compliant" sent
>      by a TLS client is not 1 byte long with the value 0, the CT-using TLS
>      server MUST abort the handshake.

Note: this isn't really a hash, so we should probably acknowledge
that.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Dec 2018 18:52:37 -0500 (EST)

On Mon, 24 Dec 2018, Eric Rescorla wrote:

Speaking as individual,

> have to be within validity windows?

The goal was to log as much as possible. The text states:

    Logs MAY accept certificates and precertificates that have expired,
    are not yet valid, have been revoked, or are otherwise not fully
    valid according to RFC 5280 verification rules in order to
    accommodate quirks of CA certificate-issuing software.

So I am not sure what else needs to be clarified on validity window?

> How much of the RFC5280 rules do I need to follow?

I believe the WG wanted to accept _everything_ signed by the CA the log
accepts certs from, irrespective of their invalidity or broken content.

If there is enough structure to check the signature and it validates, it
should be logged. Possibly for the above quoted reasons, if the validity
times cannot be read from the data, it is probably safe to not add it to
the log to prevent spamming the log. Especially since browsers that
cannot read the validity would also never accept the certificate. But
a log may temporarilly halt submissions from a new CA as well:

    (A log may decide, for example, to
    temporarily reject valid submissions to protect itself against
    denial-of-service attacks).

So perhaps this corner can be left to local policy of the log operator.
The general case, log as much as you can even if it violates 5280
rules, should really be implemented, as we do want to see all those
mis-issuances in the logs. That's what these distributed audit logs are
for.

I don't see what other clarifications or new text is needed.

> the certificate if the SCT had been omitted.

The section quoted tells you what to do with invalid SCT's, namely fail the validation.

I suspec your real question is if that is the right thing to do when
SCT's were not mandatory as policy for the CT-using clients? To me it
seems prudent to fail the validation in that case. So the text seems
correct and complete.

Are there any implementers concerned that they would not detect this
because they wouldn't look at the SCT if the policy doesn't require
it? And so would prevent them from honoring the MUST in this section?

> Note: this isn't really a hash, so we should probably acknowledge

Sure, I think one of the author's can clarify that.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Dec 2018 17:13:10 -0800

On Mon, Dec 24, 2018 at 3:52 PM Paul Wouters <[email-masked]> wrote:

> The goal was to log as much as possible.

Logging as much as possible would involve logging every certificate, valid
or not. In fact, this text explicitly tells you *not* to do that, even if
you practically could do so.

>     accommodate quirks of CA certificate-issuing software.

Ah, I thought I remembered this text but didn't see it. What about chains
in which a properly-issued EE cert signs another EE cert?

> So perhaps this corner can be left to local policy of the log operator.

Unfortunately, no. This is a 2119 MUST and therefore the boundaries of the
mandate need to be precisely delineated.

> The section quoted tells you what to do with invalid SCT's, namely fail

This text does not tell you to fail validation of the certificate; it tells
you you MUST validate all the SCTs and then doesn't tell you how to behave
if one does not validate.

> SCT's were not mandatory as policy for the CT-using clients?

No, that's not my question. Consider the case where my policy is that there
must be 2 valid SCTs and the server supplies 3 but only 2 validate. I'm
required to validate all of them, but I could conform with this text by
validating all three, logging the failure, and moving on.

> To me it

Well, you and I seem to disagree about the meaning of this text, so
apparently
not.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Dec 2018 12:10:07 -0500 (EST)

On Mon, 24 Dec 2018, Eric Rescorla wrote:

> Logging as much as possible would involve logging every certificate, valid or not. In fact, this text explicitly tells you *not* to do that, even if you practically could do so.

Where does it "explicitely tell you" to "log every certificate"? All
of this is predicated on logging the behaviour of one or more CAs. So
that's clearly a limiting factor on what to accept.

The log is meant to log _everything_ signed by the CAs for which it logs.
Any data that is so bogus that you cannot determine if the CAs your log
for have signed it, can obviously be rejected.

The only exception to not logging data that has been signed by the CA,
is during a denial of service attacks on the log. So all the reasons
to refuse have to do with the _amount_ of logging, not the _content_
of what is logged.

It does not say "validated an SCT or certificate" based on acceptable
content. It says "until it has verified [...] chains to an accepted
trust anchor".

> Ah, I thought I remembered this text but didn't see it. What about chains in which a properly-issued EE cert signs another EE cert?

The logs will only log data signed by certain CAs. If the CA signed the
EE cert, it goes in. If that EE cert signed another EE cert, it was not
signed by the CAs being audited and does not go in. Just like
self-signed EE-certs don't go in.

> Unfortunately, no. This is a 2119 MUST and therefore the boundaries of the mandate need to be precisely delineated.

The MUST is not violated by _temporarilly_ halting logging as the text describes.

> This text does not tell you to fail validation of the certificate; it tells you you MUST validate all the SCTs and then doesn't tell you how to behave if one does not validate.

I believe the actions of what to do on validation failure are a local
policy. It could be a total rejection, a popup etc. While 6962bis gives
guidance for CT-using TLS clients, it is not a client specification
document. See also: https://trac.ietf.org/trac/trans/ticket/15

> No, that's not my question. Consider the case where my policy is that there must be 2 valid SCTs and the server supplies 3 but only 2 validate. I'm required to validate all of them, but I could conform with
> this text by validating all three, logging the failure, and moving on.

That behaviour is up to the client implementation and/or local policy.

> Well, you and I seem to disagree about the meaning of this text, so apparently not.

Anyone can make any statement for any arbitrary line of text, so tis argument is a non sequitur.

Speaking as an individual, I still do not see any text requiring changes.

Speaking as co-chair, we did try to get a client behaviour document
started, but at first waited for the bis document to be in better shape,
and later on there was not enough interest at the time. For example,
there is this expired draft:

https://tools.ietf.org/html/draft-dseomn-trans-browsers-01

Although that one also does not answer your question:

    However, A TLS client that is a browser MAY discriminate against a
    certificate presented for a web site if the certificate is not
    accompanied by an SCT, e.g., providing an indication of this via the
    user interface. The details of such discrimination are outside the
    scope of this specification.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Dec 2018 09:30:11 -0800

On Wed, Dec 26, 2018 at 9:10 AM Paul Wouters <[email-masked]> wrote:

> > Logging as much as possible would involve logging every certificate,
> valid or not. In fact, this text explicitly tells you *not* to do that,
> even if you practically could do so.
>
> Where does it "explicitely tell you" to "log every certificate"?

You're misreading my text above. This text tells you *not* to log every
certificate supplied to you.

> > Ah, I thought I remembered this text but didn't see it. What about
> chains in which a properly-issued EE cert signs another EE cert?
>
> The logs will only log data signed by certain CAs.

Where do you think it says that? What I see is text about chaining to a
trust anchor, not about certificates signed directly by specific CAs. And
in this case, there would be a chain of signatures to a trust anchor.

> > Unfortunately, no. This is a 2119 MUST and therefore the boundaries of
> the mandate need to be precisely delineated.
>

The relevant MUST is the requirement to *reject* certificates in the
following paragraph.

   Logs MAY accept certificates and precertificates that have expired,
   are not yet valid, have been revoked, or are otherwise not fully
   valid according to RFC 5280 verification rules in order to
   accommodate quirks of CA certificate-issuing software.  However, logs
   MUST reject submissions without a valid signature chain to an
   accepted trust anchor.  Logs MUST also reject precertificates that do
   not conform to the requirements in Section 3.2.

And what must clearly be delineated is the boundaries of that MUST.

> > This text does not tell you to fail validation of the certificate; it
> tells you you MUST validate all the SCTs and then doesn't tell you how to
> behave if one does not validate.
>

But there is a MUST here for clients, and so again, the boundaries of that
MUST need to be clear.

> > No, that's not my question. Consider the case where my policy is that
> there must be 2 valid SCTs and the server supplies 3 but only 2 validate.
> I'm required to validate all of them, but I could conform with

Great. Then the text should say that.

I'm not asking for a complete client specification. What I am asking is
that every normative requirement in this specification be unambiguous, and
I do not believe that this one is.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Dec 2018 14:31:33 -0500 (EST)

On Wed, 26 Dec 2018, Eric Rescorla wrote:

> Where do you think it says that? What I see is text about chaining to a trust anchor, not about certificates signed directly by specific CAs. And in this case, there would be a chain of signatures to a trust
> anchor.

Ahh I understand our differences now. I was thinking in terms of CA
signed, and not in the proper terms of "anchors to a trust anchor".

As for path length, the draft states:

 	Logs SHOULD limit the length of chain they will accept.  The maximum
 	chain length is one of the log's parameters (see Section 4.1).

As you poined out, additional text is needed to cover denial of service
possibilities by EE-certs and intermediate CA's signing CA/EE certs
at (and beyond) the root anchor's path length or log max chain.

> The relevant MUST is the requirement to *reject* certificates in the following paragraph.
> 

Right, so likely a sentence should be added like:

 	Intermediate CAs used for validation to an accepted trust anchor
 	MUST pass all RFC 5280 verification rules, such as the Basic
 	Constraint path length and CA flags. Certificates failing these
 	constraints could be valid to be accepted to the log themselves
 	(eg as a valid intermediate CA or EE-cert), but signatures
 	created by these certificates MUST NOT be accepted as a trusted
 	chain to the log's trust anchors and therefor MUST NOT be
 	logged. This prevents bogus certificates from spamming the log.

Although possibly, instead of MUST NOT we could say "MAY temporarilly reject" like the other DoS case.

>       >       > >      In addition to normal validation of the server certificate and its
>       >       > >      chain, CT-using TLS clients MUST validate each received SCT for which
>       >       > >      they have the corresponding log's parameters.  To validate an SCT, a
>       >       > >      TLS client computes the signature input by constructing a "TransItem"
>       >       > >      of type "x509_entry_v2" or "precert_entry_v2", depending on the SCT's
>       >       >
>       >       > How do I proceed if I have an invalid SCT but by policy I would accept
>       >       > the certificate if the SCT had been omitted.
>       >
> But there is a MUST here for clients, and so again, the boundaries of that MUST need to be clear.

The MUST tells you to validate, not to tell you exactly what to do when
validation fails. So it tells you that you cannot skip validating the
3rd SCT even if you only needed two according to your client policy. So
I still do not understand why you think this case is a problem.

> I'm not asking for a complete client specification. What I am asking is that every normative requirement in this specification be unambiguous, and I do not believe that this one is.

I think it does, but I guess it won't harm to make it more explicit.  I'll leave that up to the authors.

Paul

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Dec 2018 16:33:31 +0000

> On Mon, 24 Dec 2018, Eric Rescorla wrote:
<snip>
> Sure, I think one of the author's can clarify that.

Proposed text:
https://github.com/google/certificate-transparency-rfcs/pull/303

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Dec 2018 16:43:18 +0000

On 26/12/2018 19:31, Paul Wouters wrote:
>>       >           Logs MAY accept certificates and precertificates 
>> that have expired,
>>       >           are not yet valid, have been revoked, or are 
>> otherwise not fully
>>       >           valid according to RFC 5280 verification rules in 
>> order to
>>       >           accommodate quirks of CA certificate-issuing software.
>>       >
>>       >
>>       > Ah, I thought I remembered this text but didn't see it. What 
>> about chains in which a properly-issued EE cert signs another EE cert?
>>
>> Where do you think it says that? What I see is text about chaining to 
>> a trust anchor, not about certificates signed directly by specific 
>> CAs. And in this case, there would be a chain of signatures to a trust
>> anchor.
> 
>>       >           (A log may decide, for example, to
>>       >           temporarily reject valid submissions to protect 
>> itself against
>>       >           denial-of-service attacks).
>>       >
>>       >       So perhaps this corner can be left to local policy of 
>> the log operator.
>>       >
>>       >
>>       > Unfortunately, no. This is a 2119 MUST and therefore the 
>> boundaries of the mandate need to be precisely delineated.
>>
<snip>

Proposed text:
https://github.com/google/certificate-transparency-rfcs/pull/305

This PR takes an axe to the "Accepting Submissions" section, splitting 
it into two subsections in order to (I think) more clearly specify (1) 
what are the minimum rules for acceptable submissions and (2) what's 
left to the log's discretion.

I've added text to the minimum rules subsection regarding checking the 
Basic Constraints and Key Usage extensions.

I'd like to hear your thoughts about the general approach of this PR as 
well as its detail.  Thanks!

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Dec 2018 16:59:51 +0000

On 27/12/2018 16:43, Rob Stradling wrote:
<snip>
> well as its detail.  Thanks!

Groups of logs sharded by (pre)certificate notAfter date are explicitly 
permitted by the Chromium CT Log Policy [1], and this is becoming the 
norm for new CT logs intended for use by the WebPKI.  Whilst working on 
PR 305 just now, I noticed that 6962-bis doesn't say anything about this 
topic.

As a follow-on to PR 305, I think we should:
   - Add optional "rangeBegin" and "rangeEnd" parameters to section 4.1 
("Log Parameters").
   - Describe the use of these optional parameters in the new 
"Discretionary Acceptance Criteria" subsection proposed by PR 305.

Any comments?

[1] 
https://github.com/chromium/ct-policy/blob/master/log_policy.md#permissible-logging-rejection-criteria

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 27 Dec 2018 12:03:17 -0500

> well as its detail.  Thanks!

Just to highlight and ensure it's intentional:
1) This would prohibit X.509v1 and X.509v2 (by virtue of requiring at least
one extension)
2) This would prohibit RFC 3820 Proxy Certificates

I totally accept that this is a wobbly gray area - some arguing only
properly DER-encoded, fully-profile-conforming certificates should be
accepted (which makes writing MUSTs easier and, by proxy, is assumed to
clean up the ecosystem), others wanting to capture the world-as-it-is, not
the world-as-it-should-be. Is CT a means of achieving the PKIX Protocol
Police, or is it the camera that merely records all, without passing
judgement or opinion?

That said, I'm not sure the motivations for why these requirements are
there are supported by the text. That is, expectations about what a monitor
will find in the log aren't necessarily set (because the trust anchors may
change over the lifetime of the log), and likewise, the attribution issue
is problematic because, again, the trust anchors accepted by the log may
chance over time. The primary reason for any of this largely is about
preventing Log DoS (whether from spam or content/profile, collectively,
"invalid submissions"). Basic constraints and usage are really just
variants of DoS prevention, right?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Dec 2018 09:47:48 -0800

On Thu, Dec 27, 2018 at 9:09 AM Ryan Sleevi <[email-masked]> wrote:

> 1) This would prohibit X.509v1 and X.509v2 (by virtue of requiring at
> least one extension)

What's fraught about this from my perspective is that the current text
requires that the server *reject* certificates which don't conform to
certain rules, apparently in the name of DoS protection. As a result:

- From a formal perspective, the set of certificates which must be rejected
needs to be unambiguous
- From a technical perspective, we should ensure that it's not trivial to
create DoS attacks with certificates that are not required to be rejected
(otherwise, the requirement is pointless)

-Ekr

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Dec 2018 17:58:45 +0000

On 27/12/2018 17:03, Ryan Sleevi wrote:
> On Thu, Dec 27, 2018 at 11:43 AM Rob Stradling wrote:
> 
> 
>     Proposed text:

It doesn't prohibit v1/v2 certificates that are accepted trust anchors, 
since that text in the PR only applies to "the zero or more intermediate 
CA certificates in the chain".

Intermediate CA certificates that conform to RFC5280 cannot be v1 or v2. 
  However, I suppose X.509v1 and X.509v2 certs currently (in 
draft-ietf-trans-rfc6962-bis-30) fall under "Logs MAY accept 
certificates and precertificates that...are otherwise not fully valid 
according to RFC 5280 verification rules".  Hmmm...

Shall I change that part of the PR to read as follows?
"* Each of the zero or more intermediate CA certificates in the chain 
MUST have one or more of the following features:
    * The Version field has the value v1(0) or v2(1).
    * The Basic Constraints extension with the cA boolean asserted.
    * The Key Usage extension with the keyCertSign bit asserted."

Is there even such a thing as a v1 or v2 intermediate CA certificate in 
any technical standard or any known implementation?

> 2) This would prohibit RFC 3820 Proxy Certificates

Sorry, I've never read this one.  Advice welcome.

> clean up the ecosystem), others wanting to capture the world-as-it-is, 
> not the world-as-it-should-be. Is CT a means of achieving the PKIX 
> Protocol Police, or is it the camera that merely records all, without 
> passing judgement or opinion?

It's the camera.  I think this WG reached consensus on that long ago. 
Right?

> there are supported by the text. That is, expectations about what a 
> monitor will find in the log aren't necessarily set

"and to set clear expectations for what monitors would find in the log" 
originated in this PR from Eran back in March:
https://github.com/google/certificate-transparency-rfcs/pull/293/files

Perhaps we should delete this clause?

> (because the trust 
> anchors may change over the lifetime of the log), and likewise, the 
> attribution issue is problematic because, again, the trust anchors 
> accepted by the log may chance over time.

How about I change "...attributable to an accepted trust anchor..." to 
"attributable to a once or currently accepted trust anchor..." ?

> The primary reason for any of 
> this largely is about preventing Log DoS (whether from spam or 
> content/profile, collectively, "invalid submissions").

I agree.

> Basic constraints 
> and usage are really just variants of DoS prevention, right?

Yes.

Email: [email-masked]
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Dec 2018 15:21:41 -0500 (EST)

> It's the camera.  I think this WG reached consensus on that long ago.

With chair hat on: yes.

Paul

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Dec 2018 16:43:18 +0000

<snip>

Proposed text:

---

From: Rob Stradling <[email-masked]>
Date: Fri, 28 Dec 2018 10:33:06 +0000

<snip>
>>       >       > >      In addition to normal validation of the server 
>> certificate and its
>>       >       > >      chain, CT-using TLS clients MUST validate each 
>> received SCT for which
>>       >       > >      they have the corresponding log's parameters.  
>> To validate an SCT, a
>>       >       > >      TLS client computes the signature input by 
>> constructing a "TransItem"
>>       >       > >      of type "x509_entry_v2" or "precert_entry_v2", 
>> depending on the SCT's
>>       >       >
>>       >       > How do I proceed if I have an invalid SCT but by 
>> policy I would accept
>>       >       > the certificate if the SCT had been omitted.
>>       >
>>       >       The section quoted tells you what to do with invalid 
>> SCT's, namely fail the validation.
>>       >
>>       > This text does not tell you to fail validation of the 
>> certificate; it tells you you MUST validate all the SCTs and then 
>> doesn't tell you how to behave if one does not validate.
>>
>>       >       I suspec your real question is if that is the right 
>> thing to do when
>>       >       SCT's were not mandatory as policy for the CT-using 
>> clients?
>>       >
>>       > No, that's not my question. Consider the case where my policy 
>> is that there must be 2 valid SCTs and the server supplies 3 but only 
>> 2 validate. I'm required to validate all of them, but I could
>>       conform with
>>       > this text by validating all three, logging the failure, and 
>> moving on.
>>
>> I'm not asking for a complete client specification. What I am asking 
>> is that every normative requirement in this specification be 
>> unambiguous, and I do not believe that this one is.
> 

This is already covered by section 8.1.6 "Evaluating compliance", but...OK.

Proposed text:
https://github.com/google/certificate-transparency-rfcs/pull/306