Subject: [Trans] Certificate verification

From: Linus Nordberg <[email-masked]>
Date: Fri, 17 Oct 2014 14:51:14 +0200

Hi list,

6962bis-4 says that logs may log and publish invalid certificates as
long as the chain ends in a known cert. It then lists three examples of
what can be accepted, all related to time.

   Logs MUST verify that the submitted end-entity certificate or
   Precertificate has a valid signature chain leading back to a trusted
   root CA certificate, using the chain of intermediate CA certificates
   provided by the submitter.  Logs MAY accept certificates that have
   expired, are not yet valid, have been revoked, or are otherwise not
   fully valid according to X.509 verification rules in order to
   accommodate quirks of CA certificate-issuing software.  However, logs
   MUST refuse to publish certificates without a valid chain to a known
   root CA.  If a certificate is accepted and an SCT issued, the
   accepting log MUST store the entire chain used for verification,
   including the certificate or Precertificate itself and including the
   root certificate used to verify the chain (even if it was omitted
   from the submission), and MUST present this chain for auditing upon
   request.  This chain is required to prevent a CA from avoiding blame
   by logging a partial or empty chain.  (Note: This effectively
   excludes self-signed and DANE-based certificates until some mechanism
   to limit the submission of spurious certificates is found.  The
   authors welcome suggestions.)

Since the purpose of the log is to put light on bad certificates, would
it make sense to instead have text 1) specifying a minimum of checks to
be done (i.e. the chain) and 2) encouraging logging and publishing of
all other certificates?

On a minor note, I think that "trusted" in the very first sentence
should be changed to "known. Should I use the issue tracker?

---

From: Matt Palmer <[email-masked]>
Date: Sat, 18 Oct 2014 10:44:00 +1100

> what can be accepted, all related to time.

[...]

> be done (i.e. the chain) and 2) encouraging logging and publishing of

IMO, yes.  My opinion is that a log which rejects certificates for reasons
other than those required to maintain the operation of the log (ie spamming)
is worthless -- you're *not* getting a complete view of what a CA intended
to issue, you're getting some sort of filtered, sanitised view of it.

> should be changed to "known. Should I use the issue tracker?

I've been advised that for small, non-controversial changes, submitting a
pull request direct to the github repo is fine.

- Matt

---

From: Linus Nordberg <[email-masked]>
Date: Sat, 18 Oct 2014 14:22:22 +0200

Matt Palmer <[email-masked]> wrote
Sat, 18 Oct 2014 10:44:00 +1100:

| > Since the purpose of the log is to put light on bad certificates, would
| > it make sense to instead have text 1) specifying a minimum of checks to
| > be done (i.e. the chain) and 2) encouraging logging and publishing of
| > all other certificates?
| 
| IMO, yes.  My opinion is that a log which rejects certificates for reasons
| other than those required to maintain the operation of the log (ie spamming)
| is worthless -- you're *not* getting a complete view of what a CA intended
| to issue, you're getting some sort of filtered, sanitised view of it.

Thanks, this is my view as well. Happy to try to provide text unless
other people on the list have a good case against this.

| > On a minor note, I think that "trusted" in the very first sentence
| > should be changed to "known. Should I use the issue tracker?
| 
| I've been advised that for small, non-controversial changes, submitting a
| pull request direct to the github repo is fine.

Thanks, did that.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 20 Oct 2014 12:09:48 +0000

On Fri Oct 17 2014 at 1:51:01 PM Linus Nordberg <[email-masked]> wrote:

> be done (i.e. the chain)

Since checking is for spam limitation, and different logs may have
different views on what is spam, I am not convinced this is a good idea -
for example, any chain check would appear to automatically rule out logging
self-signed certs, and it seems to me that should be left open to log
operators to think about (e.g. Microsoft would appear to have sufficient
information to do spam limitation through use measurement:
http://blogs.technet.com/b/pki/archive/2014/02/22/a-novel-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx
)

> and 2) encouraging logging and publishing of
> all other certificates?
>

That seems like a good plan :-)

> should be changed to "known. Should I use the issue tracker?

Yes, please.

>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 20 Oct 2014 14:32:24 +0200

Ben Laurie <[email-masked]> wrote
Mon, 20 Oct 2014 12:09:48 +0000:

| On Fri Oct 17 2014 at 1:51:01 PM Linus Nordberg <[email-masked]> wrote:
| 
| > Hi list,
| >
| > 6962bis-4 says that logs may log and publish invalid certificates as
| > long as the chain ends in a known cert. It then lists three examples of
| > what can be accepted, all related to time.
| >
| >    Logs MUST verify that the submitted end-entity certificate or
| >    Precertificate has a valid signature chain leading back to a trusted
| >    root CA certificate, using the chain of intermediate CA certificates
| >    provided by the submitter.  Logs MAY accept certificates that have
| >    expired, are not yet valid, have been revoked, or are otherwise not
| >    fully valid according to X.509 verification rules in order to
| >    accommodate quirks of CA certificate-issuing software.  However, logs
| >    MUST refuse to publish certificates without a valid chain to a known
| >    root CA.  If a certificate is accepted and an SCT issued, the
| >    accepting log MUST store the entire chain used for verification,
| >    including the certificate or Precertificate itself and including the
| >    root certificate used to verify the chain (even if it was omitted
| >    from the submission), and MUST present this chain for auditing upon
| >    request.  This chain is required to prevent a CA from avoiding blame
| >    by logging a partial or empty chain.  (Note: This effectively
| >    excludes self-signed and DANE-based certificates until some mechanism
| >    to limit the submission of spurious certificates is found.  The
| >    authors welcome suggestions.)
| >
| > Since the purpose of the log is to put light on bad certificates, would
| > it make sense to instead have text 1) specifying a minimum of checks to
| > be done (i.e. the chain)
| 
| 
| Since checking is for spam limitation, and different logs may have
| different views on what is spam, I am not convinced this is a good idea -
| for example, any chain check would appear to automatically rule out logging
| self-signed certs, and it seems to me that should be left open to log

(Depends on how you define "trusted/known root CA certificate", but OK
that might be a stretch.)

But the current text _does_ require a chain check, doesn't it?

   Logs MUST verify that the submitted end-entity certificate or
   Precertificate has a valid signature chain leading back to a trusted
   root CA certificate, using the chain of intermediate CA certificates
   provided by the submitter.

and

                                                           However, logs
   root CA.

My intention was to make the specification less restrictive by changing 

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

to something indicating that anything more than a chain check is either
forbidden or discouraged.

| operators to think about (e.g. Microsoft would appear to have sufficient
| information to do spam limitation through use measurement:
| http://blogs.technet.com/b/pki/archive/2014/02/22/a-novel-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx)
| 
| 
| > and 2) encouraging logging and publishing of
| > all other certificates?
| >
| 
| That seems like a good plan :-)
| 
| 
| >
| >
| > On a minor note, I think that "trusted" in the very first sentence
| > should be changed to "known. Should I use the issue tracker?
| >
| 
| Yes, please.

Is this the right place?
https://github.com/google/certificate-transparency-rfcs/pull/7

---

From: Ben Laurie <[email-masked]>
Date: Mon, 20 Oct 2014 12:43:39 +0000

> But the current text _does_ require a chain check, doesn't it?

Yes. This may be a bug. :-)

However, you should probably look at the archives, there's been
considerable debate around checking!

> | http://blogs.technet.com/b/pki/archive/2014/02/22/a-
> novel-method-in-ie11-for-dealing-with-fraudulent-digital-certificates.aspx
> )
> |
> |

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Oct 2014 13:44:57 -0400 (EDT)

On Mon, 20 Oct 2014, Linus Nordberg wrote:

as individual without chair hat...

>   accommodate quirks of CA certificate-issuing software.

That seems to bring up the topic a bit too broadly I think? How about:

 	Logs MUST protect themselves against spam. They MAY require a
 	fully validated X.509 certification chain to one of their configured
 	trusted root CA's.

That leaves out the discussion for other checks, that may or may not go
into a separate section or document.

Paul

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 20 Oct 2014 23:33:51 +0200

Paul Wouters <[email-masked]> wrote
Mon, 20 Oct 2014 13:44:57 -0400 (EDT):

| On Mon, 20 Oct 2014, Linus Nordberg wrote:
| 
| as individual without chair hat...
| 
| >   Logs MUST verify that the submitted end-entity certificate or
| 
| > My intention was to make the specification less restrictive by changing
| >
| >                               Logs MAY accept certificates that have
| >   expired, are not yet valid, have been revoked, or are otherwise not
| >   fully valid according to X.509 verification rules in order to
| >   accommodate quirks of CA certificate-issuing software.
| 
| That seems to bring up the topic a bit too broadly I think? How about:

The text above is the current text in 6962bis-4.

| 	Logs MUST protect themselves against spam. They MAY require a
| 	fully validated X.509 certification chain to one of their configured
| 	trusted root CA's.

This may be OK for the spam issue but certainly not for attribution.

My current standpoint is that I think logs MUST perform signature chain
validation up to any root in a set of known root certs, chosen by the
log operator, and MUST NOT reject a certificate for any other reasons.

This effectively rules out self-signed certs, which I dislike, but
that is not a change from current text.

Maybe I'm just rehashing some of the points in the "path validation"
thread (started 2014-09-29). A summary of points in that thread by
someone who understands that discussion might help here. Afraid I was
lost pretty early.

---

From: Matt Palmer <[email-masked]>
Date: Tue, 21 Oct 2014 08:51:23 +1100

> 	fully validated X.509 certification chain to one of their configured

I prefer a more broad wording:

    Logs MAY reject certificate submissions which would compromise the
    integrity or availability of the log.  An example of a valid reason to
    reject a submission would be an attempt to "spam" the log with large
    numbers of certificates, consuming all its storage space and/or
    processing capacity.  Logs MUST NOT reject certificates for any other
    reason.

I'm willing to compromise a little on that last sentence, but I've seen some
comments recently that suggest that some people think CT logs are a
validation checker, not an activity log, so it'd be nice to clarify that in
the spec.

- Matt

-- 
[An ad for Microsoft] uses the musical theme of the "Confutatis Maledictis"
from Mozart's Requiem. "Where do you want to go today?" is on the screen,
while the chorus sings "Confutatis maledictis, flammis acribus addictis,".
Translation: "The damned and accursed are convicted to the flames of hell."

---

From: Matt Palmer <[email-masked]>
Date: Tue, 21 Oct 2014 09:27:58 +1100

> This may be OK for the spam issue but certainly not for attribution.

Is attribution critical for the core functionality of CT?  (I know this goes
back to the "purpose of CT" thread that Stephen's done a lot of work
defining, and I've got to get around to participating in that thread)  While
I agree that the remediation mechanisms available increase if you know which
root CA to hassle to get a cert revoked, knowledge that a cert was issued
still has *some* value, even if there's no clear indication of who issued it
(in a fanciful future of infinite storage, where self-signed certs were
accepted in logs).

- Matt

-- 
Java. The elegant simplicity of C++. The blazing speed of Smalltalk.
		-- From http://c2.com/cgi/wiki?SmalltalkMinusMinus

---

From: Ben Laurie <[email-masked]>
Date: Tue, 21 Oct 2014 09:39:15 +0000

> (in a fanciful future of infinite storage, where self-signed certs were

Exactly - for example, accepting self-signed certificates would not change
Chrome's behaviour when it sees one, whether it comes with an appropriate
SCT or not.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2014 11:46:18 -0400

Matt,

Fair question. If attribution is not possible, because we choose to not 
require
chaining to a root accepted by the log (as currently called for) then 
the attack
analysis will be updated to reflect this loss of security functionality 
in those
cases.

Note that my proposal to allow (not require) logs to perform syntactic 
checks,
and to note the result of such checks, is compatible with logs that 
choose to not
perform even basic path validation. It would be another class of (non) 
checks that
can be registered in the proposed IANA registry and reported by a log. 
Also, if
basic path validation is not performed, a log should advertise that, 
just as it
should advertise the set of root CAs that it does check. This allows 
Monitors and
clients to know what the log says it is doing, so that others do not 
have to guess
or learn by some unspecified, OOB means.

I suggest another registry entry for logging self-signed certs will make 
sense
too, if 6962-bis stops excluding them.

Steve