Subject: Re: [Trans] defining "mis-issuance"

From: Stephen Kent <[email-masked]>
Date: Wed, 01 Oct 2014 11:05:42 -0400

Rick,
> ...
>
> It's doable, but it still leaves the CA in a bind. What if the CA 
> wants to start issuing certs according to new CABF docs, but finds 
> that none of the existing log servers support that version? This is 
> probably a moot point, isn't it, because Melinda has reminded us not 
> to introduce any normative dependencies on CAB Forum documents or 
> processes.
>
I'm ignoring that "advice" for now, as it was not accompanied by any 
description of
a procedural basis for ignoring the CABF guidelines in this context :-).

More to the point in the IETF if we want to avoid a normative reference 
to another SDO's doc,
we can do what I have already done, i.e., create our own version 
(usually a subset) of the doc
and make it part of an RFC (or make it a standalone RFC). We started 
doing this long ago when
we created CMS as a standards track RFC that updated PKCS docs. So, we 
can literally avoid
a normative dependency on CAF guidelines, merely cite them as the 
source/motivation for
our CT mis-issuance definitions.

Still, your point is a good one.  We could push the syntax checking back 
to Monitors,
but then we loose the ability to provide immediate feedback to CAs that 
are issuing
syntactically malformed certs. I'll have to think more about this issue.
>
> ....
>
>
> If the Subject provides a list of all o the keys associated with the 
> Subject, perhaps in the form
> of certs issued to the Subject (and currently valid) this would enable 
> a Monitor to detect this form of mis-issuance, agreed?
>
> Agreed, but it puts a burden on the Subject. Before issuing any new 
> legitimate certificate, the Subject would need to notify the Monitor 
> of the new Subject name and/or public key. We've got some customers 
> who issue thousands of certificates across their organization. IMO, 
> the model might work better if the Monitor is simply a conduit, 
> providing information found in log servers to the Subject, and then 
> the Subject can decide if each new certificate was intentionally issued.
>
I don't think we are fundamentally disagreeing here. I have assumed that 
a Monitor notifies a
Subject when the Monitor detects that a cert with the Subject's name has 
a different key from
the set supplied by the Subject to the Monitor, as reference data. The 
Subject makes the final
determination and acts on that. So, a Montitor is alerting a Subject to 
what appear to be a
mis-issuance. So, if the info that a Monitor passes to a Subject is the 
set of certs that the
Monitor finds in logs, the only difference in my proposal is that the 
Monitor would not pass on
certs that match a set of keys supplied by the Subject.  One could 
transform my model into what
you said by having a Subject provide no keys, but noting that the 
Subject does have one or more
certs issued to it.
>
>
>
> A separate topic is issuance of a bogus cert for a Subject who doesn't 
> have a cert issued legitimately.
> In this case there is no reference cert to present to a Monitor. It 
> may be hard for a Subject who
> doesn't have a cert to convince a 3rd party Monitor to check for certs 
> issued to the Subject name
> in question. Should we classify this as mis-issuance as well?
>
> See my comment above. Must the Monitor be able to decide by itself 
> what is legitimate and what is mis-issued, or is that the role of the 
> Subject, with help from the Monitor? In other words, couldn't we say 
> that it's mis-issuance if the Monitor finds a cert in a log, forwards 
> it to the Subject, and the Subject determines that it's mis-issued?
>
> -Rick
>
The issue here, I think, is that a web site that has no Web PKI cert, 
e.g., because it has a self-signed
cert or is relying on DANE, might not enlist the help of a Monitor, 
especially if there is a cost to do
so.  I'm not sure we need to address this case, but we do need to 
identify it and say that we are
not addressing it if we choose to do so.

Steve

---

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

On 01/10/14 16:05, Stephen Kent wrote:
<snip>
> Rick,
<snip>
> to Monitors, but then we loose the ability to provide immediate feedback
> to CAs that are issuing syntactically malformed certs. I'll have to think
> more about this issue.

Stephen,
The "ability to provide immediate feedback to CAs that are issuing 
syntactically malformed certs" sounds like a nice idea, but surely this 
could be implemented as a stand-alone application or web service?
Why would you want it to be an intrinsic part of CT?

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

---

From: Peter Bowen <[email-masked]>
Date: Wed, 1 Oct 2014 08:45:46 -0700

> Why would you want it to be an intrinsic part of CT?

This feels like an interesting feature for CT log hosts.  An
additional API that allows subscribing to the "firehose" of all log
entries as they happen.  I wonder how many certificates per second
Comodo is issuing these days with the CloudFlare annoucement...

---

From: Rob Stradling <[email-masked]>
Date: Thu, 02 Oct 2014 15:51:36 +0100

On 01/10/14 16:45, Peter Bowen wrote:
> entries as they happen.

Hi Peter.

Are you suggesting making something like [1] an integral part of log 
servers, rather than an optional/separate service?

[1] 
https://groups.google.com/forum/#!topic/certificate-transparency/h4quw0htujs

> I wonder how many certificates per second Comodo is issuing these days with
> the CloudFlare annoucement...

Let's just say that our systems have been unusually busy this week.  :-)

---

From: Peter Bowen <[email-masked]>
Date: Thu, 2 Oct 2014 08:18:06 -0700

> https://groups.google.com/forum/#!topic/certificate-transparency/h4quw0htujs

I was more thinking of a streaming API[2], such that a client could to
an receive immediate notification of _every_ add-chain or
add-pre-chain call that included both the chain and the return values.
Think real-time monitoring instead of fetching the log data using the
get-* calls.

Thanks,
Peter

[2] See https://dev.twitter.com/streaming/public for Twitter's
explanation of streaming API

---

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

Rob,
> syntactically malformed certs" sounds like a nice idea, but surely 
> this could be implemented as a stand-alone application or web service?
The motivation for making it part of CT arose when Ben explained that 
his definition of mis-issuance included syntactic constraints from the 
CABF context.  The notion that immediate feedback is
desirable is consistent with the overall CT goal of forcing CAs to do 
something by threatening
that there certs will be rejected by browsers, only translated to logs :-).

Still, your argument that logs ought not reject certs that fail to meet 
syntactic criteria,
so that all TLS clients can benefit from detection of mis-issued certs 
detection via
examination of logs, is compelling.

I have a suggested solution:

     - require a CA submitting a pre-cert to assert one of the following:
         1. no assertion is made wrt syntactic conformance to CABF 
guudelines
         2. the cert conforms to DV Guidelines <insert guideline version>
         3. the cert conforms to EV guidelines <insert guideline version>

     - require a log to include the CA assertion in its SCT, along with 
one of the following:
         1. this log does not check cert syntax
         2. this log cannot check the specified CABF Guidelne version 
asserted by the CA
         3. this log checked the cert against the CA's assertion and it 
passed
         4. this log checked the cert against the CA's assertion and it 
failed

This would seem to address the concern that rejecting (not logging) a 
submitted cert is
worse than logging a bad cert. It also addresses the concern that Rick 
mentioned, i.e.,
a mismatch between what Guideline version a CA is using vs. what a log 
can verify. It
does not require that every log perform ANY syntax checking, and it lets 
Monitors and
clients know whether a log has elected to no perform such checks. It 
also tells a Monitor
which set of cert syntax rules the CA says it is enforcing, so that the 
Monitor can perform
the checks. If the log doesn't perform checks, or is unable to check a 
specific version of
the syntax checks, the Monitor can step in do so. The Monitor also can 
double check the
log, to detect logs that are not doing the checks properly, e.g., 
because of errors, compromise,
or conspiracy. This provides Monitors and clients with additional info 
when choosing which logs
to use.

Would this mechanism address your concerns?

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 3 Oct 2014 16:10:32 +0100

On 2 October 2014 17:13, Stephen Kent <[email-masked]> wrote:
> The motivation for making it part of CT arose when Ben explained that his
> definition of mis-issuance included syntactic constraints from the CABF
> context.  The notion that immediate feedback is
>         1. no assertion is made wrt syntactic conformance to CABF guudelines
>     - require a log to include the CA assertion in its SCT, along with one
> of the following:

Presumably this would apply to certs as well as precerts, which is the
other reason rejecting isn't particularly helpful (certs are already
issued by the time they're logged!).

> a mismatch between what Guideline version a CA is using vs. what a log can
> verify. It
> clients know whether a log has elected to no perform such checks. It also
> tells a Monitor
> log, to detect logs that are not doing the checks properly, e.g., because of
> errors, compromise,
> or conspiracy. This provides Monitors and clients with additional info when
> choosing which logs
> to use.
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

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

Ben,

> issued by the time they're logged!).
I'm confused by your comment. There is no "rejection" of a cert in the 
text above.
That was the change I made to address the valid concerns that Rob and 
Rick raised.

If the cert failed checking it would still be logged, and an SCT issued,
but the fact that the syntax failed the checks would be noted in the SCT and
the log entry.

Steve

p.s. I realize that one more log-assigned value is needed, i.e., the
CA asserted #1, so the log didn't perform any check in this case

---

From: Ben Laurie <[email-masked]>
Date: Mon, 6 Oct 2014 13:13:25 +0100

On 3 October 2014 20:25, Stephen Kent <[email-masked]> wrote:
>> one
> I'm confused by your comment. There is no "rejection" of a cert in the text
> above.
> That was the change I made to address the valid concerns that Rob and Rick
> raised.

I was adding another valid concern to Rob and Rick's, it was not meant
to be a criticism of the above proposal.

> but the fact that the syntax failed the checks would be noted in the SCT and

Sure, but the language proposed does not cover certs - they may not be
submitted by a CA and obviously they are not pre-certs.

> CA asserted #1, so the log didn't perform any check in this case

Right.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Oct 2014 11:03:49 -0400

Ben,
> On 3 October 2014 20:25, Stephen Kent<[email-masked]>  wrote:
>> Ben,
>>
>>> ...
Sorry, I didn't realize the intent of your comment. But, in any case,
my revised proposal addresses this concern as well.
> submitted by a CA and obviously they are not pre-certs.
Good point. I will revise the proposal to cover certs, as well as 
pre-certs.

Steve