Subject: Re: [Trans] path validation

From: Stephen Kent <[email-masked]>
Date: Wed, 01 Oct 2014 10:29:31 -0400

David,

> On Monday, September 29, 2014, Rick Andrews <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Santosh,
>
>     Since it's not an absolute requirement at this point (either from
>     CABF or from individual browsers' policies) I suggest that log
>     servers cannot enforce the use of technical constraints in
>     intermediate CAs.
>
>
> We're talking about (non-normatively-specified) monitor servers here, 
> right?
I am suggesting that the checks be mandatory, and that logs perform them, so
that syntactically mis-issued certs don't get SCTs. If getting an SCT 
based on a
pre-cert is supposed to "encourage" CAs to play the CT game, then this 
helps them
get off on the right foot.
> Log servers need to continue to accept based solely on signature 
> validity; otherwise they'll miss misissuance. (So *log* servers will 
> necessarily be agnostic about this.)
I disagree. Once Ben said that he meant mis-issuance to be interpreted 
in a much broader context,
and cited EV cert requirements as an example, I pursued documenting what 
that would mean. If
the WG wants to say that mis-issuance is more than issuing a cert to the 
wrong Subject, then
we need to say just what it is, not hand wave.

Also, log servers, per se, do not detect mis-issuance, unless we have 
them perform the checks
I suggested. What I think you meant to say is that if log servers reject 
syntactically mis-issued
certs, then these certs will not be subject to analysis by Monitors. 
That's true, but there seems
to be an inconsistent argument in play. If one argues that TLS client 
will, eventually, reject c
erts that do not contain (or are not accompanied by) SCTs, then having 
logs reject syntactically
mis-issued certs is a good thing.

If we agree that the CABF guidelines for Web PKI CAs are the best 
reference we have for this
(which seems reasonable for the Web PKI context), then why not enforce 
them? Having logs do
the checks has the advantage that CAs get immediate feedback when they 
don't get it right at
this basic level.

Monitors, I think, should focus on detecting semantic mis-issuance for 
the Subjects that they serve.
Not every Subject may arrange to have a Monitor protect its name and key 
binding, and not every
Subject will perform monitoring for itself. So, if logs perform the 
basis, syntactic checks,
we get that level of coverage for a lot of Subjects, without having to 
require them to perform
or arrange for Monitor functions.  Again, this is analogous to the 
argument that has been made
for pre-certs, i.e., forcing a CA to embed an SCT into a cert avoids 
relying on Subjects to
upgrade their web software to pass a post-issuance SCT during the TLS 
handshake. if that is a
valid argument for why we're using the rather complex pre-cert 
mechanism, it seems that my
argument for log checking of cert syntax is equally valid.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 01 Oct 2014 10:30:32 -0400

Stephen,

I'm puzzled by your "advice."

The IETF cites documents of other SDOs when relevant and when they
do not conflict with the scope of IETF WGs.

The CABF has created a profile of 5280, and 3647, for the Web PKI
context, precisely the context that CT is addressing.

Ben asserted that mis-issuance entails more than the simple
notion that a cert was issued to the "wrong" subject. He specifically
cited key size and EV cert criteria. These are criteria defined by the
CABF guidelines.

How can we proceed on CT if we don't have a solid definition of the
problem it purports to address? Certainly detecting mis-issuance
has to be well-defined.

Steve
> We've received a reminder from our friendly area director not
> to introduce any normative dependencies on CAB Forum documents
> or processes, as well as a query about how much x.509 processing
> should be specified, as well.
>
> Melinda
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 01 Oct 2014 10:34:21 -0400

Matt,
> Logs shouldn't be enforcing *anything*. A log isn't a judge, it's a 
> record. The only constraints on what should be rejected from being 
> accepted by a log should be those things which prevent abuse 
> sufficient to render a log unusable. 
That's a very simple, strong assertion, but it isn't accompanied by a 
rationale.

I agree that the current description of a log focuses on recording cert
info, but it already includes an element of "judgement" since it has
a list of the root CAs that must anchor the cert chains that it will accept.

If we stick with the detection of mis-issuance rationale that the document
asserts as the goal for CT, and if we define mis-issuance as broadly as Ben
suggested in response to my first cut at a defintiion, with his specific 
references
to EV certs and key sizes, then we have to check certs against those 
criteria at some
place in the system.

The current design appears to call for Monitors to do this, and one 
could stick
with that approach. The description of Monitors says that " They 
alsowatch for
certificates of interest." I interpret this to mean that a Monitor has a 
list
of certs, or of Subject names and keys, that it is "protecting." If a 
Subject
does not run its own Monitor, and it it doesn't arrange for some other 
entity
to act as a Monitor to protect the Subject's certs, then no checking for
syntactic mis-issuance will take place. That observation motivates 
exploring the
notion of having logs perform the function. By so doing we have an 
opportunity to
perform detection of syntactic mis-issuance for every logged cert, a 
service to
the broad Web PKI community.

It seems as though some are arguing that if a log rejects certs that 
fail to meet
the syntactic criteria this is a bad thing, because it will deter 
logging of certs.

I thought the CT design makes a counter argument, i.e., that CAs are 
motivated
to log certs because, over time, TLS clients will reject connections to 
servers
when there is no evidence of an SCT. if this argument is true, then 
having logs
check for syntactic mis-issuance is a good thing. If the argument is not 
true,
it should not be part of the "why CT will work" description.

Steve

---

From: David Leon Gil <[email-masked]>
Date: Wed, 1 Oct 2014 10:47:42 -0400

On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent <[email-masked]> wrote:
> I disagree. Once Ben said that he meant mis-issuance to be interpreted in a
> much broader context,

You are missing the point of certificate transparency.

We have no idea all the forms that misissuance -- particularly
malicious misissuance -- might take. If it were trivial to detect
"misissuance", browsers would validate certs for "misissuance" and the
problem would be solved.

The point of having a log that includes everything signed with a CA's
key is that analysis of issued certificates can be conducted post-hoc.

Proposals to limit the scope of what logs can log kneecap CT. They
should not be considered.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 01 Oct 2014 10:54:03 -0400

>should not be considered.

Maybe the term mis-issuance should just be discarded.  There seems to be
agreement that logs should accept anything signed by one of the CAs
covered by a log.  Monitors can always detect whatever they want relative
to the certificate collection maintained by a log (be it “mis-issuance” or
something else).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Oct 2014 16:05:00 +0100

Hiya,

> problem it purports to address? Certainly detecting mis-issuance

I think this is the crux of the matter.

Mis-issuance is not a feature but a bug. Attempting to
describe all possible bugs of any sort is futile. If you
argue that a CT RFC has to describe all possible bugs, then
that amounts to arguing to not do CT. But the IETF has
reached consensus to do CT so it seems that others do not
agree with you that "detecting mis-issuance has to be
well-defined" at least if that is meant to call for a
complete enumeration of all the ways in which mis-issuance
might occur. (And I don't get what else you might have
meant, but please correct me if I'm misreading what
you've written.)

Having some examples of mis-issuance described is quite
reasonable. Asking that all forms of mis-issuance be
documented is not reasonable.

Now as to CABF, while its very reasonable to think about
their requirements, I don't think it'd be a good plan
to hard-code a dependency on a version of those into a CT
RFC. Their baseline reqs doc has changed 3 times this year
already for example and 5 times in 2013 and I suspect will
continue to evolve significantly.

But if you see a stable useful and quotable definition of
mis-issuance in one of their documents, then sending a
pointer to that text would be good. I don't know if there
is such a piece of text though.

Cheers,
S.

PS: I'm not sure CABF would describe themselves as an SDO
either, but that's a mere matter of terminology.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 01 Oct 2014 16:10:13 +0100

On 01/10/14 15:34, Stephen Kent wrote:
<snip>
> motivated to log certs because, over time, TLS clients will reject
> connections to servers when there is no evidence of an SCT.

Over time, yes, we hope that this will happen.  But we obviously can't 
guarantee that, in N months/years from now, 100% of TLS clients will 
support CT.

> if this argument is true, then having logs check for syntactic
> mis-issuance is a good thing.

I disagree.  There is a gap between what is syntactically properly 
issued (according to CABF guidelines, etc) and what a typical TLS client 
actually accepts.  If logs checked for syntactic mis-issuance, a rogue 
CA could exploit this gap by maliciously mis-issuing certs containing 
"syntax errors".  CT would not reveal the attack (because the logs would 
refuse to issue SCTs), but TLS clients that don't reject connections 
when no SCT is provided would be vulnerable.

We want to provide as much "herd immunity" as possible to TLS clients 
that don't support CT.  This means that we need all certs to be publicly 
logged, to maximize the chances that any (maliciously) mis-issued cert 
will be discovered quickly.

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Oct 2014 12:13:47 -0400

David,

> On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent<[email-masked]>  wrote:
I may, since the definition of the goals seem to change over time.
> "misissuance", browsers would validate certs for "misissuance" and the
History suggests otherwise. We have seen many examples of browsers not
performing cert path validation correctly, e.g., not paying attention to
the basicConstrants extension (with serious security consequences), etc.
So browsers are not a reliable way to deal with many cert-related 
security concerns.

More to the point, CT is a set of external mechanisms designed to detect
mis-issuance that might not be visible to an individual TLS client. So your
argument that if it were trivial to detect, browsers would do it, is way
off the mark.
> key is that analysis of issued certificates can be conducted post-hoc.
Well, to be accurate, CRLs are not logged, as per the current proposal,
so it's not "everything signed with a CA's key." But, irrespective of
that detail, I am not suggesting that we alter the post-hoc analysis;
I was suggesting that there might be benefits to checking at the time
of issuance, principally in the case of pre-certs.
> should not be considered.
What CT does should or should not be ought to be justified based on an
analysis of attacks and what CT does to address them, not on blanket 
statements
that mis-issuance cannot be defined.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Oct 2014 12:13:56 -0400

Rob,
> guarantee that, in N months/years from now, 100% of TLS clients will 
I agree, which is why I suggested that text to the contrary be modified 
in 6962-bis.
> issued (according to CABF guidelines, etc) and what a typical TLS 
> client actually accepts. 
is that a good thing?
> If logs checked for syntactic mis-issuance, a rogue CA could exploit 
> this gap by maliciously mis-issuing certs containing "syntax errors".  
> CT would not reveal the attack (because the logs would refuse to issue 
> SCTs), but TLS clients that don't reject connections when no SCT is 
> provided would be vulnerable.
See my attack analysis, which notes this as part of the larger set of 
what CT can and cannot
detect.
> that don't support CT.  This means that we need all certs to be 
> publicly logged, to maximize the chances that any (maliciously) 
> mis-issued cert will be discovered quickly.
That's a clear statement about wanting to protect clients who don't 
implement CT, i.e.,
don't mandate the presence of an SCT.  That's a reasonable argument, 
better that a mere
assertion that "logging is good." It belongs in 6962-bis. See my revised 
proposal on syntax
checking, which addresses this.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Oct 2014 12:25:41 -0400

Stephen,
> that amounts to arguing to not do CT.
I didn't say that, don't put words in my mouth.
> But the IETF has
> reached consensus to do CT
I think that's s an overstatement. This WG was formed without a BoF.
So the usual IETF consensus process was not followed. You persuaded your
fellow IESG members to approve the WG and to use the Experimental RFC as
the starting point for a standard track RFC. I doubt that many of them
paid close attention to the Experimental RFC. In any case, the charter
does not use the term "rubber stamp" so I think we're free to revisit
the design, which is under-specified, lacks a security analysis, etc.
> so it seems that others do not
Again, don't mis-characterize what I have said. One need not
enumerate _all_ the ways that a cert can be mis-issued. One can,
however, should be able to characterize classes of behavior that
constitute mis-issuance, unless one is _trying_ to be ambiguous. Within
the classes of mis-issuance it ought to be possible to enumerate a fair
number of MUSTs, to note when no external examination of certs can detect
mis-issuance, and to note when mis-issuance can be detected based on 
specified,
per-Subject (and/or per-Issuer) data. These all seem like reasonable 
characterizations
that ought to be pursued. I have been doing so in the text I've provided.
> documented is not reasonable.
ibid.
> continue to evolve significantly.
We can accommodate changes in specs; we do it in other contexts.
I looked at the 3 2014 versions of the baseline spec, using the
diff's the CABF provides on its website. None of the changes in 2014
affected any of the requirements included in my proposed Appendix.

Looking at the 2013 changes, the only one I noted that had real impact 
on the
syntax checks I proposed was version 1.1.6 (July 2013). In that version
the discussion of EKU and nameConstraints was added. That change relates
to just one set of syntactic checks. In 1.1.4, they added DSA 
modulus/divisor
constraints. This is precisely what Ben cited as a cert mis-issuance 
criteria,
so, presumably, we would want to update our specs accordingly.

Given that, over the past 2 years, there have been only two changes that
have any impact on the syntax checks I enumerated, and that they impact
only two of the detailed chekcs, I think this argument is a red herring.
> is such a piece of text though.
First, they would never define mis-issuance, any more than 5280
would define a defective cert, per se, so the suggestion is silly,
Stephen. The guidelines define requirements for the format of certs (DV 
and EV)
and procedures for cert issuance by CAs. So, one develops a definition 
for syntactic
mis-issuance, based on their guidelines, by noting violations of the 
format MUSTs.
Semantic mis-issuance is similarly defined.

Steve

p.s. Yes, I agree that CABF is not an SDO, but neither was the source of 
PKCS
doc when the IETF elected to use them as the basis for CMS.

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Oct 2014 13:36:35 -0400

> either, but that's a mere matter of terminology.

I think it is fairly easy to define mis-issuance, but I think it is nearly impossible to detect mis-issuance by an independent third party.

To my way of thinking, mis-issuance is a certificate that is issued in violation to some aspect of the certificate policy identified in the certificate itself.  I can think of very many policy violations that are not visible in the certificate itself.

Russ

---

From: David Leon Gil <[email-masked]>
Date: Thu, 2 Oct 2014 17:02:09 -0400

> I may, since the definition of the goals seem to change over time.

That, in a nutshell, is exactly the point of certificate transparency.

CT should provide a log service in a way that is neutral with respect
to whatever requirements CABF or browser vendors may in future impose.

This is good for good CAs: It means that they will have the
flexibility to provide new services / cert types as soon as clients
will accept them. They won't have to, in addition, go through this
WG.[*]

[*] Requiring CAs/browser vendors to get this WG's blessing seems to
be the motivation of many of the proposals.

> of issuance, principally in the case of pre-certs.

These proposals amount to this:

Let's spare a CA who lets their private key be used to sign something
it shouldn't have signed any reputational damage by requiring logs to
not report it. This is exactly the wrong incentive. CAs -- both root
and intermediate -- need to have security controls that ensure that
they don't sign malicious things.

> statements that mis-issuance cannot be defined.

[and other Stephen]: > That's . . . better that a mere assertion that
"logging is good."

The IETF has previously standardized logging protocols. See, inter
alia, RFC 5424. Is consensus lacking for the idea that logging is
good?

---

From: Stephen Kent <[email-masked]>
Date: Fri, 03 Oct 2014 15:29:13 -0400

David,
> On Thu, Oct 2, 2014 at 12:13 PM, Stephen Kent<[email-masked]>  wrote:
An inability to clearly characterize goals is a bug, not a feature :-) when
developing a standard. I cannot recall any major security area WGs that
have ignored this issue in the past few years.
> will accept them. They won't have to, in addition, go through this
My revised proposal from yesterday allows a CA to assert that
the cert being submitted does not purport to conform to the CABF DV/EV
guidelines, so it seems to address this concern.
> be the motivation of many of the proposals.
Can you be more specific?
> they don't sign malicious things.
I agree with the sentiment that CAs should be held responsible.
I have no idea why you believe that I suggested otherwise. Please
cite any messages I have generated that support the first sentence above.
> alia, RFC 5424. Is consensus lacking for the idea that logging is
5424 didn't invent syslog. It provided a common format for communicating 
syslog
entries and a standard means for transport. It did not require any 
system to make
use of the protocol, to export syslog entries to arbitrary third 
parties, etc.
Thus, syslog is not a reasonable analogy to CT.

Steve