Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 12:05:31 -0000

#73: Section 3 text re log cert validation is ambiguous

Comment (by [email-masked]):

 On the issue of specifying deviations, I am not sure how that could
 realistically be done. For example, our logs will permit whatever
 deviations OpenSSL permits. I don't think anyone knows precisely what
 those are, and I'm prepared to bet they vary between versions.

 Even leaving that aside, experience suggests we have to permit deviations
 in order to admit incorrect certificates that are accepted by browsers. I
 don't think we can anticipate what all of those are.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  critical     |   Milestone:
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/73#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 12:47:48 -0000

Changes (by [email-masked]):

 * milestone:   => review

Comment:

 X.509 issue fixed at https://github.com/google/certificate-transparency-
 rfcs/commit/716e7f5df4b465283f26d48bdf46e21c61d9c3d4

 Priority:  critical     |   Milestone:  review

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/73#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: Karen Seo <[email-masked]>
Date: Mon, 6 Jul 2015 09:36:52 -0400

Ben,

I get 404 error when I click on the link below.

Karen

---

From: Rob Stradling <[email-masked]>
Date: Mon, 06 Jul 2015 15:29:51 +0100

Hi Karen.  Were you trying to access 
https://github.com/google/certificate-transparency- by any chance? 
That's only half the URL.  The full URL gets wrapped onto two lines 
somewhere between TRAC and your inbox.

On 06/07/15 14:36, Karen Seo wrote:
>>   X.509 issue fixed at
>> https://github.com/google/certificate-transparency-
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 11:06:31 -0400

If there is no standard for the validation checks logs perform, because 
of a
desire to accept malformed certs from (sloppy) CAs, then a CA cannot 
know whether
its submission will be rejected by a log. The alternative is to specify 
a way for
each log to specify what checks it performs, and to publish that the 
same way other
log info is advertised.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 06 Jul 2015 16:15:15 +0100

On 06/07/15 16:06, Stephen Kent wrote:
> of a desire to accept malformed certs from (sloppy) CAs, then a CA cannot
> know whether its submission will be rejected by a log.

Huh?  Why can't the (potentially sloppy) CA call add-chain (or 
add-pre-chain) and see what happens?

Either the log will return an SCT (in which case it accepted the 
submission), or it won't (in which case it rejected the submission).

> The alternative is to specify a way for
> same way other log info is advertised.
>
> Steve
>
>

---

From: Ben Laurie <[email-masked]>
Date: Mon, 6 Jul 2015 16:42:34 +0100

On 6 July 2015 at 16:06, Stephen Kent <[email-masked]> wrote:
> If there is no standard for the validation checks logs perform, because of a
> desire to accept malformed certs from (sloppy) CAs, then a CA cannot know
> whether
> its submission will be rejected by a log.

If a CA wants to be sure in advance (why?) that a log will accept its
certs, then it should conform with the relevant standards.

> each log to specify what checks it performs, and to publish that the same
> way other
> log info is advertised.
>
> Steve
>
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 12:00:10 -0400

Rob,

Having a cert rejected does not tell the submitter (CA or otherwise) 
why, and
thus the submitted doesn't know how to resolve the problem.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 13:42:02 -0400

Ben,

> On 6 July 2015 at 16:06, Stephen Kent<[email-masked]>  wrote:
If we don't cite the "relevant standards" how does a submitter know
what they are? Also, I thought your argument here was that there is no
agreed upon set of standards to which all CAs adhere, so ...

Steve

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 19:26:40 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  critical     |   Milestone:  review
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:  fixed
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/73#comment:4>
trans <http://tools.ietf.org/trans/>

---

From: Rob Stradling <[email-masked]>
Date: Mon, 06 Jul 2015 20:30:18 +0100

On 06/07/15 17:00, Stephen Kent wrote:
> why, and thus the submitted doesn't know how to resolve the problem.

Are the folks that work for (sloppy) CAs really incapable of reading 
RFC5280 for themselves, incapable of examining their rejected certs to 
discover the problem(s) for themselves, and incapable of finding a 
suitable mailing list on which to ask questions if they get stuck?

I really don't see why we should over-complicate CT logs just to assist 
sloppy/lazy/incompetent CAs that are already expected (by the various 
web browser root cert inclusion programs) to be familiar with RFC5280.

It's likely that CT logs will not implement their own RFC5280 
certificate processing code.  The certificate-transparency.org code, for 
example, uses OpenSSL.  If OpenSSL rejects a blob of data that is 
allegedly a cert, the error stack doesn't always explain precisely why 
the blob of data was rejected.  Sometimes you just have to resort to 
reviewing an ASN.1 dump or firing up a hex editor.  So I think the 
implication of what you're requesting might be that CT logs cannot use 
third-party RFC5280 certificate processing libraries at all!

Do any other IETF protocols that validate certs return a precise 
explanation for rejection if rejection occurs?  I don't see a fully 
enumerated list of reasons for rejecting a "cert" in the TLS 1.2 spec, 
for example.  So why should 6962-bis be required to do this?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 15:50:13 -0400

Rob,

> suitable mailing list on which to ask questions if they get stuck?
I think may have misunderstood my point. I did not request that a log 
return an error indicating
why a cert failed the logs checks. I asked that there be a deterministic 
way for a submitter
to know whether a cert will pass. That can be accomplished in (at least) 
two ways:
establish a standard set of checks that all logs perform, or establish a 
way to each log to
state what set of checks it performs.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 06 Jul 2015 21:03:55 +0100

On 06/07/15 20:50, Stephen Kent wrote:
> return an error indicating why a cert failed the logs checks. I asked
> that there be a deterministic way for a submitter to know whether a
> cert will pass.

Ah, I see.

> That can be accomplished in (at least) two ways:
> establish a standard set of checks that all logs perform

The I-D already says:
   "Logs MUST accept certificates that are fully valid according to RFC
    5280 [RFC5280] verification rules and are submitted with such a
    chain."

So the "deterministic way for a submitter to know whether a cert will 
pass" is for the submitter to ensure that the cert is fully compliant 
with RFC5280 verification rules and is supplied with a chain up to a 
root cert that the log accepts.

We don't want to encourage submitter CAs to needlessly violate RFC5280, 
so I see no good reason why we should turn the following behaviour into 
something deterministic:

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

> , or establish a way to each log to state what set of checks it performs.
>
> Steve
>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Jul 2015 15:23:32 -0400

Rob,

> ...
Glad to see we're on the same page now.
> root cert that the log accepts.
I agree. BUT, the argument is being made that some (many?) CAs issue 
certs that do not
comply with 5280, and that CT logs cannot reject such certs because such 
sloppiness
is too widespread. That appears to be the rationale for the text you 
cite below.
So, we are saying is that logs MAY reject certs that do not comply with 
5280, for
any set of unspecified reasons, but there is no way for a submitter to 
know which
logs do what checks, given the vast leeway accorded by the text below. 
That results in
the non-determinism, which I see as bad.

(Note that my proposal to create a set of IANA-registered profiles for types
of certs, each describing syntax and other checks,  might be applicable 
here.
A log could enumerate the profiles against which it will perform 
validation checks
and a submitter can indicate under which profile the cert was issued. 
Just a thought.)
> We don't want to encourage submitter CAs to needlessly violate RFC5280, 
I agree!
> so I see no good reason why we should turn the following behaviour 
> into something deterministic:
>
Your argument seems to be that by introducing ambiguity and uncertainty 
into the
log validation process we will encourage CAs to adhere to 5280. That 
strikes me as a
questionable design strategy.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Fri, 10 Jul 2015 12:01:29 +0100

On 07/07/15 20:23, Stephen Kent wrote:
> certs that do not comply with 5280, and that CT logs cannot reject such
> certs because such sloppiness is too widespread.

Yes.  Such sloppiness is too widespread for WebPKI browsers to enforce 
strict 5280 compliance.  Since CT is concerned with protecting the 
WebPKI ecosystem, it must follow suit.  Otherwise, it would be trivial 
for a bad CA to issue a cert that won't be logged by CT but will be 
accepted by browsers that don't require CT.

> That appears to be the rationale for the text you cite below.
> 5280, for any set of unspecified reasons, but there is no way for a
> submitter to know which logs do what checks, given the vast leeway
> accorded by the text below. That results in the non-determinism, which
> I see as bad.

I'll admit it's not ideal, but I think that we would get lost in a maze 
of ratholes if we tried to do it any differently.

> (Note that my proposal to create a set of IANA-registered profiles for
> types of certs, each describing syntax and other checks,  might be
> applicable here.

The "profile" for Google's logs would be something like this:

"We accept whatever OpenSSL accepts.  Good luck!"

> validation checks and a submitter can indicate under which profile the
> cert was issued. Just a thought.)

Do any other IETF protocols that validate certs do this?

For example, when a TLS server sends its cert chain to a TLS client, can 
the TLS server know, deterministically, that the TLS client will either 
accept or reject the cert chain?

Clearly the answer is no.  So why should CT be expected to achieve a 
higher standard of determinism than TLS?

> into the log validation process we will encourage CAs to adhere to 5280.
> That strikes me as a questionable design strategy.

Actually, I don't expect the level of CA adherence to 5280 to increase 
or decrease due to this strategy.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 10:38:01 -0400

Rob,

> accepted by browsers that don't require CT.
agreed.
> I'll admit it's not ideal, but I think that we would get lost in a 
> maze of ratholes if we tried to do it any differently.
>
and is Google's log acceptance criteria the only one that counts?
> Do any other IETF protocols that validate certs do this?
Some IETF protocols call for certs to be validated as per 5280, even if, 
in practice,
implementations often fail to do so. As a standards body we try to 
establish desirable
behavior for implementations, knowing that we may not always succeed.
> For example, when a TLS server sends its cert chain to a TLS client, 
> can the TLS server know, deterministically, that the TLS client will 
> either accept or reject the cert chain?
in principle, only the lack of an agreed upon trust anchor should cause 
a compliant
client to reject a cert from a server (ignoring local policy controls). 
Servers rely
on the ubiquity of trust anchor stores to reduce the likelihood that 
validation will
fail on that basis.  So, for all practical purposes, a server can have 
high confidence
that its cert will be accepted by browsers, if the cert is issued by a 
CA that is
widely represented in the (almost uniform) trust store.
> higher standard of determinism than TLS?
two observations:
     first, I disagree that the TLS example above is a probative as you 
suggest.
     second, we have years of experience with what's wrong with TLS in terms
of cert processing, and hopefully we can do better with this effort, 
when we create
new ways to introduce non-determinism.
> or decrease due to this strategy.
I don't either, yet that seems to be a part of the argument you made.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Tue, 14 Jul 2015 22:05:21 +0100

On 14/07/15 15:38, Stephen Kent wrote:
<snip>
> and is Google's log acceptance criteria the only one that counts?

No.

<snip>
> a compliant client to reject a cert from a server (ignoring local policy
> controls).

Ditto for CT.  i.e. in principle, only the lack of an agreed upon trust 
anchor should cause a compliant log to reject a cert from a submitter.

> Servers rely on the ubiquity of trust anchor stores to reduce the
> likelihood that validation will fail on that basis.  So, for all
> practical purposes, a server can have high confidence that its cert will
> be accepted by browsers, if the cert is issued by a CA that is

I disagree.  Only if the CA issues 5280-compliant certs can they have 
that high confidence.

For example, recently one CA was found to be incorrectly encoding 
basicConstraints.CA=FALSE by explicitly including the FALSE value even 
though FALSE is the DEFAULT (and DEFAULT values must not be explicitly 
included).  This was discovered when a popular browser maker tightened 
up their DER decoding code and the certs stopped being accepted.

>      first, I disagree that the TLS example above is a probative as you

TLS clients and CT logs both need to verify certificate chains that they 
receive, and it's very likely that they'll use existing certificate 
chain processing libraries rather than roll their own code.

So there will be OpenSSL-based TLS clients that encounter 
5280-non-compliant cert chains, and there will be OpenSSL-based CT logs 
that encounter 5280-non-compliant cert chains.  In both cases, OpenSSL 
does the certificate chain verification.

>      second, we have years of experience with what's wrong with TLS in
> terms of cert processing, and hopefully we can do better with this
> effort, when we create new ways to introduce non-determinism.

I agree that it would be nice to do better, but I just don't see how 
anyone could ever complete the task of enumerating all of the ways in 
which 5280 can be violated (including all of the ways that haven't even 
been thought of yet) such that there can be a list of profiles detailing 
which sets of violations are tolerated and which aren't.  It would be a 
constantly moving target, entirely unsuited to being an IANA registry.

I can recall a couple of bugs in Comodo's ASN.1 code over the years that 
have led to some certs being issued with "minor" ASN.1 encoding errors. 
  In both cases, the affected certs seemed to "work" fine everywhere 
until a new version of OpenSSL was released that no longer tolerated 
those particular encoding errors.  So what did I do?  Did I blame 
OpenSSL for breaking my certs?  No.  Did I blame IETF for not 
enumerating all possible encoding errors?  No, that didn't even occur to 
me!  I blamed myself ('cos I wrote the code that had the bugs), and I 
fixed the bugs.

If, in the future, any CT logs start to reject Comodo certs and this 
leads to the discovery of another bug in my ASN.1 code, I will blame 
myself and fix the bug.  I don't want CT to be vastly overcomplicated 
just so that CA bug authors such as myself aren't required to put in 
some effort (reading 5280, reviewing the OpenSSL source code, asking 
questions on mailing lists, etc, etc) to diagnose and fix our mistakes.

Assuming I've still not convinced you, then let's agree to disagree. 
You think achieving determinism is practical, and I really don't.

> I don't either, yet that seems to be a part of the argument you made.

It really isn't.