Subject: [Trans] Precertificate format

From: Melinda Shore <[email-masked]>
Date: Mon, 08 Sep 2014 10:50:29 -0800

It seems as if we've been talking about precertificate format for
quite some time, without coming to resolution.  Let's try to find
agreement on how to handle it and close issue 26.

The ticket, with description, is here:
http://trac.tools.ietf.org/wg/trans/trac/ticket/26

The fundamental problem is that because precertificates are currently
encoded as X.509 structures we have the potential for two certificates
to exist with the same issuer and same serial number.  Because the
precertificate is not usable as a TLS certificate in practice, this
may not be an issue.  However, it's a clear violation of section 4.1.2.2
in 5280 (and to be honest I'm a little fuzzy on its implications for
CRL processing).

So, are you all comfortable with letting the X.509 representation
stand, or do you have an alternative proposal?

Thanks,

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Mon, 08 Sep 2014 16:16:16 -0400

Melinda,

The problem is bigger than just the choice of format for the SCT response.

The current pre-cert model requires a CA to be able to issue two certs with
the same serial number. This would, in general, be a very bad thing for a CA
to do. So, mandating this behavior is very worrisome. And, as you noted, it
clearly violates 4.1.2.2 of 5280. (Thanks, I should have noted that.)
Thus, I suggest we use a different format. I suggest sticking with ASN.1,
since the data used to compute the SCT will come from a cert, and ASN.1 is
the native cert format description language. DER encoding is also good for
creating a canonical representation for signature generation.

However, Ben has noted that even if we use a different format for the 
pre-cert data,
the data MUST contain the serial number of the cert that is eventually 
issued.
This is almost as much of a problem for CAs, at least in principle. 
Remember that
the DigiNotar breach (which is a major motivation for CT) was especially 
bad because
the attackers were able erase all evidence of the bogus certs that they 
issued.
Countermeasures to such attacks might preclude a CA from knowing what serial
number will appear in a cert until it is issued. (I mentioned one such 
counter-
measure in a FIPS level 3 HSM from long ago, in a prior post.)

I suggest that the CT designers list which data items from a cert that 
is being
logged need to be in the SCT request, and why each item has to be 
present. Maybe that
will show us how to avoid the concern that I and others have raised. It 
would also
provide us with a starting point for the format of a new data structure 
for the SCT
request, and the set of data that is input to the SCT hash computation.

Steve

---

From: Melinda Shore <[email-masked]>
Date: Mon, 08 Sep 2014 14:09:01 -0800

To be honest I'm a bit concerned that this has been kicked around
for as long as it has, without progress.  This was one of the first
topics to be discussed shortly after working group formation (see
thread starting here:
http://www.ietf.org/mail-archive/web/trans/current/msg00050.html).

It may be worth taking a look at that thread and seeing if you
("you" working group participants, not Steve specifically)
can find something useful.  I do think it's time to start coming
up with concrete counterproposals.

Melinda

---

From: Brian Smith <[email-masked]>
Date: Mon, 8 Sep 2014 16:14:13 -0700

On Mon, Sep 8, 2014 at 1:16 PM, Stephen Kent <[email-masked]> wrote:
> the same serial number.

The CA may use a Precertificate Signing Certificate to sign the
Precertificate, and then sign the final certificate with the
production CA certificate. Then, there would be no duplicate serial
number issues.

Cheers,
Brian

---

From: Rick Andrews <[email-masked]>
Date: Mon, 8 Sep 2014 16:24:26 -0700

> The CA may use a Precertificate Signing Certificate to sign the Precertificate, and then sign the final certificate with the production CA certificate. Then, there would be no duplicate serial number issues.

Brian, even if the CA uses a Precert signing cert, the precert's issuer name has to be that of the ultimate issuer, and the serial number has to be that of the ultimate certificate, so I don't think that solves the problem.

-Rick

---

From: "Hill, Brad" <[email-masked]>
Date: Mon, 8 Sep 2014 23:45:57 +0000

> I suggest that the CT designers list which data items from a cert that is being
> logged need to be in the SCT request, and why each item has to be present. Maybe that
> will show us how to avoid the concern that I and others have raised. It would also
> provide us with a starting point for the format of a new data structure for the SCT

The serial number needs to be part of the logged proof because that is the key on which existing revocation mechanisms operate.  Transparently identifying that a certificate has been issued incorrectly is of little utility unless that certificate can be revoked.

The alternatives are revoking the issuing CA on any leaf mis-issuance or inventing alternate revocation mechanisms. 

The latter may be less of an obstacle than it appears since the major implementers of CT are also in the process of inventing and deploying their own (currently) proprietary revocation systems alongside CT.

Nevertheless, one would need something stable to uniquely identify the certificate for these purposes, which ends up looking a lot like a serial number however you slice it.  (You can't use a cryptograhpic hash of the final cert for this, either, because that would require a preimage in the log.)

-Brad Hill

---

From: Matt Palmer <[email-masked]>
Date: Tue, 9 Sep 2014 10:27:47 +1000

Hi Stephen,

> creating a canonical representation for signature generation.

I'm in agreement that ASN.1/DER should be used wherever we're dealing with
"certificate-like" data.  I know of the concerns regarding the, uh,
"elevated potential", shall we say, for security bugs in DER-handling code,
but that's got to be weighed against the potential for bugs in whatever code
has to be custom-written to deal with whatever *other* encoding format is
used for the data.

> pre-cert data, the data MUST contain the serial number of the cert that is
> eventually issued.  This is almost as much of a problem for CAs, at least
> in principle.  Remember that the DigiNotar breach (which is a major
> motivation for CT) was especially bad because the attackers were able
> erase all evidence of the bogus certs that they issued.  Countermeasures
> to such attacks might preclude a CA from knowing what serial number will
> appear in a cert until it is issued.  (I mentioned one such counter-

I don't know all the specifics of the Diginotar breach, but I'm not
conceiving of a situation in which knowing the serial number of a
certificate in advance helps an attacker erase the evidence of a bogus cert
having been issued.  Knowing a serial number in advance, or being able to
specify a serial (rather than having one auto-generated) shouldn't have any
impact on the tamper-proof log of CA operations which I would expect to be a
fundamental part of any CA.  Also, it'll be awfully hard for a future
attacker to erase proof of issuance if the CA is logging all their certs to
a variety of CT servers.

On the other hand, I can certainly empathise with the sentiment that
removing/modifying reasonable safety checks that prevent a given CA from
issuing two certificates with the same serial is a scary proposition. 
The CT spec has a way to avoid that, though, by issuing pre-certs from a
separate CA to that of the CA issuing the eventual certificate.  That avoids
the need for duplicate serials.

> I suggest that the CT designers list which data items from a cert that is
> being logged need to be in the SCT request, and why each item has to be
> present.  Maybe that will show us how to avoid the concern that I and
> others have raised.  It would also provide us with a starting point for
> the format of a new data structure for the SCT request, and the set of
> data that is input to the SCT hash computation.

I can't speak for Ben, Adam, or the others with significant input into the
CT spec, but for myself I would want to see *everything* that goes into the
final certificate.  The goal of CT is to provide a publically available
database of the data which is being attested to by CAs.  I wouldn't want to
limit what the public is capable of auditing because of a lack of
imagination at the time the specification was codified.

- Matt

-- 
New Yankee Workshop isn't a "how to" for home hobbyists, it's "Baywatch" for
powertool fetishists.
		-- Geoff Kinnel, ASR

---

From: Matt Palmer <[email-masked]>
Date: Tue, 9 Sep 2014 11:14:51 +1000

On Mon, Sep 08, 2014 at 04:24:26PM -0700, Rick Andrews wrote:
> > Precertificate, and then sign the final certificate with the production
> > CA certificate.  Then, there would be no duplicate serial number issues.
> 
> Brian, even if the CA uses a Precert signing cert, the precert's issuer
> name has to be that of the ultimate issuer, and the serial number has to
> be that of the ultimate certificate, so I don't think that solves the
> problem.

As the Wikipedians say, "Citation Needed".  My understanding is that there
is no restriction on the contents of the issuer certificate of a precert,
other than:

    a special-purpose (CA:true, Extended Key Usage: Certificate
    Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing
    Certificate.  The Precertificate Signing Certificate MUST be directly
    certified by the (root or intermediate) CA certificate that will
    ultimately sign the end-entity TBSCertificate yielding the end-entity
    certificate

That's from RFC6962 s3.1, and the wording is identical in rfc6962-bis.xml in
the github repo at the time of writing.

Of all the mentions of "issuer" in 6962, the closest relevant mention I can
find is in s3.2, "Structure of the Signed Certificate Timestamp", in the
paragraph discussing what `tbs_certificate` is, which talks (rather densely)
about how precerts differ from regular certs, and how the TBSCertificate
structure's issuer and AKI extension need to be those of the final
certificate issuer, not the precert issuer.

This variation between the issuer listed in the precert and the *actual*
issuer of the precert would potentially be a problem, if the usual chain
verification methods were employed, but it does mention elsewhere in 6962
(s3.1, para 4) that normal X.509 verification rules "may be relaxed" to
accommodate this sort of situation.  This is reasonable because the chain
verification is for spam prevention, rather than for information security.

For my log implementation, I've just made sure that the signature of the
cert was made by the public key in the next cert up the chain.  I'm not
looking at revocation, notBefore/notAfter, issuer/subject matching, or
anything else of that nature

Nobody other than logs need to verify the chain of the precert, either,
because browsers can verify the signature for the precert and then compare
the contents of the precert (from the log) and the presented cert and make
sure those details match.

- Matt

---

From: Eran Messeri <[email-masked]>
Date: Tue, 9 Sep 2014 10:24:10 +0100

I see two issues:
* What should the precertificate contain.
* What should be the format of the precertificate.

First I'd like to point out that there already is a way to issue
precertificates without violating section 4.1.2.2 in 5280:
As Matt correctly pointed out, when a Precertificate  is signed by a
Precertificate Signing Certificate, then the log produces a signature over
a TBSCertificate that _uses the final issuer's identity_, not the one in
the Precertificate Signing Certificate (hence the requirement that the
Precertificate Signing Certificate will be signed directly by the
certificate that will ultimately sign the end-entity certificate the
Precertificate represents).
That is explained in section 3.2 of RFC6962 ("Structure of the Signed
Certificate Timestamp") or in compliant code
<https://github.com/google/certificate-transparency/blob/master/java/src/org/certificatetransparency/ctlog/LogSignatureVerifier.java#L149>.
 We could do a better job of explaining this in RFC6962-bis (I personally
found it confusing when implementing the Java CT API).

On what precertificates should contain:
Seems like there's a consensus that it should be all data in the final
certificate, except for the serial number, for which there's no agreement.
The argument against including the serial number, raised mostly by Stephen,
is that it may be difficult for CAs who use HSMs to determine/generate the
serial number in advance. I don't recall any CA strongly supporting this
position (and, given precertificates from several CAs have already hit CT
Logs, that's definitely not an issue for several CAs).
The argument for including the serial number is its necessity for revoking
a certificate - Somebody has mentioned alternative revocation mechanisms
that do not require it but have not provided any references, and all
current mechanisms I know of require the serial number.
We all realize the requirement for pre-generating the serial number is a
disruptive one for the certificate issuance process - Given the authors of
RFC6962 have tried hard not to introduce disruptive changes, I think this
is a reasonable given the necessity of the serial number.
Melinda, how do you propose we reach a consensus on the issue if serial
number inclusion?

On the format of precertificates:
As far as I understand the main motivation behind exploring alternative
formats is the desire to avoid two (bitwise-different) X.509 certificates
with the same serial number, signed by the same issuer.
Recall that the log requires a signature over the to-be-issued certificate
as an indicator of the CA's intent to issue a certificate, but that format
does not have to be the same as the one that will be signed by the log
itself.

My proposal is that the structure the log signs would remain the
TBSCertificate as RFC6962-bis describes today, but the data structure for
the Precertificate could be something else:
A structure described using ASN.1 notation or a very crude transformation
over the TBSCertificate (like a signature over the base64-encoded DER
representation of the TBSCertificate).
The main concern here is that CAs should be able to sign this structure
(basically, an arbitrary blob) with the issuer's key.
Which encoding / formats are CAs comfortable with?

The reason for distinguishing the data structure the log signs from the one
the CA submits is simplifying client implementation - to make CT easy to
adopt by as many TLS clients as possible, we should avoid as much as
possible introducing additional requirements on clients. The ability to
manipulate X.509 certificates is an ability a TLS client should already
have, which is why I suggest we stick to that format for the data structure
the log signs.

To sum up, I propose:
* Finding out how to reach a consensus regarding the serial number
inclusion.
* Changing only the Precertificates format that is signed by certificate
issuers, keeping the X.509 TBSCertificate as the data structure signed by
logs.
* Soliciting feedback from certificate issuers on what encoding / formats
are they comfortable signing using the final issuer's key.

Eran

On Tue, Sep 9, 2014 at 2:14 AM, Matt Palmer <[email-masked]> wrote:

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

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 09 Sep 2014 11:49:46 +0200

Hi,

I originally suggested (in the mail thread referenced) the CertTemplate 
format from RFC4211, it has subject, issuer, serialNumber and extensions 
(basically a TBSCertificate).

Although the RFC says that serialNumber MUST be omitted, this is for 
certificate request purposes and can surely be redefined.

Don't remember if there were any other technical issues preventing a 
CertTemplate to be used?

Cheers,
Tomas

---

From: Rob Stradling <[email-masked]>
Date: Tue, 09 Sep 2014 11:17:00 +0100

> stand, or do you have an alternative proposal?

I don't mind us adding an alternative Precertificate format to 6962-bis 
(if we can agree on a suitable format!), but I'd also like to retain the 
RFC6962 Precertificate format as an option.

Several CAs have already deployed code to generate RFC6962 
Precertificates.  Why force these CAs to change to a different format 
just because some other CAs find it hard to implement the RFC6962 format?

Some CAs will actually find it _easier_ to implement the RFC6962 
Precertificate format than to implement some new format that we haven't 
defined yet.  (My experience: When I wrote Comodo's code for RFC6962 
Precertificates, reusing the TBSCertificate format was definitely a 
blessing rather than a curse).

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

---

From: Ben Laurie <[email-masked]>
Date: Tue, 9 Sep 2014 13:07:51 +0100

> Brian, even if the CA uses a Precert signing cert, the precert's issuer name has to be that of the ultimate issuer, and the serial number has to be that of the ultimate certificate, so I don't thin…

Surely it does, since it is actually signed by the precert signing
cert. Changing the issuer name just means its even less of a conflict,
since it then shouldn't even validate according to normal rules.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 09 Sep 2014 12:18:57 -0400

On 9/9/14, 8:07 AM, "Ben Laurie" <[email-masked]> wrote:

>cert. 

I think the point above is that the issuerName/serialNumber is what is
required to be unique, not issuer’s public key/serial number.

>Changing the issuer name just means its even less of a conflict,

It may be worth requiring the pre-certificate signing certificate to omit
the basicConstraints extension to further reduce conflict.

Different question, why must the SKID in the pre signing certificate match
the AKID in the TBSCertificate (as noted in 3.3)?  Seems like a bad idea
to have the same SKID in both the pre-certificate signing certificate and
in the real CA certificate.  Allowing the SKID be calculated as per normal
and placing the SKID of the final issuer in a SAN may be a better
approach.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 13:30:33 -0400

Brian,

Can you re-state your proposal. I'm confused, in part because one does
not sign anything using a cert; one verifies a signed thing using a public
key from a cert.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 13:39:14 -0400

Brad,

> The serial number needs to be part of the logged proof because that is the key on which existing revocation mechanisms operate.  Transparently identifying that a certificate has been issued incorre…
I agree that the serial number is critical if one plans to revoke the 
cert. But ,
the I-D makes no mention of remediation mechanisms, an omission I noted 
in my review
a while ago. In some cases it appears that CT plans to shame CAs into 
submission, in
which case revocation may not be needed ;-).
> The alternatives are revoking the issuing CA on any leaf mis-issuance or inventing alternate revocation mechanisms.
I agree that those mechanisms would effect revocation of the offending 
cert, but they
may be overkill, and so should be avoided if possible.
> The latter may be less of an obstacle than it appears since the major implementers of CT are also in the process of inventing and deploying their own (currently) proprietary revocation systems alon…
I didn't know that. Since the WG does not know how these might work, we 
also don't
know if the cert serial number is required.
> Nevertheless, one would need something stable to uniquely identify the certificate for these purposes, which ends up looking a lot like a serial number however you slice it.  (You can't use a crypt…
I agree that something that uniquely identifies the evil cert is needed, 
which is why
I suggested that we revisit this problem and look at each cert component 
to see what
we need, and why.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 14:20:46 -0400

Matt,

> attacker to erase proof of issuance if the CA is logging all their certs to
Sorry if I was unclear. I intended to say that if the attackers had not
been able to erase evidence of the issuance of bogus certs, then the attack
might have been discovered quickly. Using an HSM that assigns serial 
numbers,
helps with this concern, but such a design is precluded if one is 
required to
issue two certs with the same serial number.
> imagination at the time the specification was codified.
I don't recall seeing the goal you described above in the I-D. More 
importantly
your statement is a description of a mechanism, not a security goal per se.
one would have to follow your statement of transparency with one that says,
then ....

I have suggested we need is a clear statement of the threat and a mapping
of CT to that threat model. I still think this is needed, and that it 
may help
us decide what needs to be covered by the SCT.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 14:23:03 -0400

Rob,
> ...
> I don't mind us adding an alternative Precertificate format to 
> 6962-bis (if we can agree on a suitable format!), but I'd also like to 
> retain the RFC6962 Precertificate format as an option.
>
Commonly in the IETF, there is no preference given to folks who have 
implemented against
an experimental RFC when that RFC is being revised to become a standards 
track doc.

Another way to look at this is to ask why a standards track should have 
to adopt a
design element from an Experimental RFC that received little review?

So, saying that clients, logs, auditors, etc. MUST support both seems 
inappropriate.
> Precertificate format than to implement some new format that we 
> haven't defined yet. (My experience: When I wrote Comodo's code for 
> RFC6962 Precertificates, reusing the TBSCertificate format was 
> definitely a blessing rather than a curse).
I can't argue with your personal experience as a developer. I can argue 
that, on the
basis of 5280 (4.1.2.2), and on my experience as a developer of an HSM, 
the pre-cert
model is very problematic.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 14:23:20 -0400

Tomas,

>
> Hi,
>
> I originally suggested (in the mail thread referenced) the 
> CertTemplate format from RFC4211, it has subject, issuer, serialNumber 
> and extensions (basically a TBSCertificate).
>
I agree that using a redefined (to include the serial number) cert 
template from CRMF would avoid the 5280 issue, but it still requires the 
CA to assign the serial number before
the cert is issued. That is my biggest concern, i.e., it imposes a new 
requirement on
CAs, one that may have adverse security implication for some. 
Nonetheless, I like your suggestion (minus the serial number) as a 
starting point. See my next message.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 14:23:26 -0400

Eran,

> Precertificate Signing Certificate, then the log produces a signature 
> over a TBSCertificate that _uses the final issuer's identity_, not the 
> one in the Precertificate Signing Certificate (hence the requirement 
> that the Precertificate Signing Certificate will be signed directly by 
> the certificate that will ultimately sign the end-entity certificate 
> the Precertificate represents).
Well, since certs are NOT used to sign anything, I can't agree with the 
phrase "As Matt correctly pointed out" ;-).
>  We could do a better job of explaining this in RFC6962-bis (I 
> personally found it confusing when implementing the Java CT API).
6962-bis is what needs to be clear. Also, code is not generally viewed 
as a spec, for IETF purposes.
> The argument against including the serial number, raised
Count me as not part of the consensus. I still want to see an analysis 
of why selected
cert data needs to be part of the SCT.
> mostly by Stephen, is that it may be difficult for CAs who use HSMs to 
> determine/generate the serial number in advance. I don't recall any CA 
> strongly supporting this position (and, given precertificates from 
> several CAs have already hit CT Logs, that's definitely not an issue 
> for several CAs).
On this list, very few CAs seem to be participating. I seem to recall 
one CA commenting that
they had concerns about the per-cert model. I see that one CA, a 
co-author of the doc, says
it was easy to implement. When I was in Beijing last week I spoke with 
folks who deal
with cert issuance there (under CNNIC) and they were completely unaware 
of the TRANS WG.
I wonder how many other CAs outside of the CABF are tracking this activity?
> The argument for including the serial number is its necessity for 
> revoking a certificate - Somebody has mentioned alternative revocation 
> mechanisms that do not require it but have not provided any 
> references, and all current mechanisms I know of require the serial 
> number.
> We all realize the requirement for pre-generating the serial number is 
> a disruptive one for the certificate issuance process - Given the 
> authors of RFC6962 have tried hard not to introduce disruptive 
> changes, I think this is a reasonable given the necessity of the 
> serial number.
here's an off-the-cuff idea on how to have our cake and eat it too.

1. A CA submits a cert template ala CRMF.

2. A log operator generates an SCT* based on this data, and returns it.

3. The SCT* is embedded in a cert by the CA.

4. The CA submits the SCT*, plus the issued cert plus to the same log 
operator, and
a new data item is created, the SCT. It links the serial number to the 
previously-issued
SCT*. If there is a mismatch between the SCT* and the final cert, the 
Monitor will
refuse to issue an SCT.

(A Subject who submits its cert gets an SCT. The serial number is not a 
problem here.)

A TLS client that checks for the presence of an SCT acts as before, but 
with slightly
different processing to match the SCT against the received cert. This 
seems to offer
equivalent (analogous) guarantees to the client, but without a threat 
model I can't be
sure if there is a gap here.

A Monitor will examine a log to determine when an SCT* was issued and no 
SCT was issued subsequently. That is a red flag. An SCT without a 
preceding SCT* is not a problem, as this
is what would occur if a Subject (or OCPS server?) requested an SCT.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 9 Sep 2014 20:00:57 +0100

On 9 September 2014 18:39, Stephen Kent <[email-masked]> wrote:
> I agree that the serial number is critical if one plans to revoke the cert.
> But ,
> the I-D makes no mention of remediation mechanisms, an omission I noted in
> my review
> a while ago.

It makes no mention because they are not in scope. The point of CT is
to allow others to vet certificates and take appropriate action when
needed.

It is not up to us to describe all possible problems and how they are
remedied. If you think that's a valuable exercise, be my guest.

However, when you suggest that inclusion of some particular thing is
problematic, then we can, of course, refer to potential problems CT
might reveal and available remedies as an illustration of why that
thing is needed.

---

From: "Hill, Brad" <[email-masked]>
Date: Tue, 9 Sep 2014 19:12:55 +0000

Whatever is logged ought to be as close as is possible to the actual certificate and ought to include all meaningful information in the certificate other than a preimage-resistant hash.  

Detecting problematic issuance isn't confined just to organizational authority.  Looking at the recent history of bugs in this area, observing a flurry of issuance of certificates of the form "www.legit.com\0www.evil.com", or certificates with large "tumors" in rarely used or obsolete extensions might have been cause to investigate deeper and additionally could've provided evidence of stealthier prior exploitation of such bugs.

We can't predict in advance what such problems will be, so the default stance should be that everything is logged, and the onus fall on those who want to exclude content to justify that action.

With regard particularly to serial numbers it's clear they are necessary as input to revocation mechanisms.

-Brad

On Sep 9, 2014, at 10:39 AM, Stephen Kent <[email-masked]> wrote:

> I agree that the serial number is critical if one plans to revoke the cert. But ,
> the I-D makes no mention of remediation mechanisms, an omission I noted in my review
> a while ago. In some cases it appears that CT plans to shame CAs into submission, in
> I agree that those mechanisms would effect revocation of the offending cert, but they
> I didn't know that. Since the WG does not know how these might work, we also don't
> I agree that something that uniquely identifies the evil cert is needed, which is why
> I suggested that we revisit this problem and look at each cert component to see what
> we need, and why.
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 15:43:24 -0400

Brad,

> Whatever is logged ought to be as close as is possible to the actual certificate and ought to include all meaningful information in the certificate other than a preimage-resistant hash.
Absent a clear description of scope, i.e., what problem is being solved, 
the approach
of "include everything" is understandable. But that doesn't make it the 
best approach.
> Detecting problematic issuance isn't confined just to organizational authority.  Looking at the recent history of bugs in this area, observing a flurry of issuance of certificates of the form "www.…
Again, if the I-D stated what problem is being solved, and the examples 
you cite are
part of that description, then covering everything in a cert makes more 
sense, but ...
> We can't predict in advance what such problems will be, so the default stance should be that everything is logged, and the onus fall on those who want to exclude content to justify that action.
I see your point, and if the I-D clearly stated the sort of very broad 
goals that you
note above, I think your argument would be a good one. We already have 
one example of
folks wanting to exclude info, in the case of redacted certs. I'm not 
yet convinced
that the proposed mechanism is safe, but we'll see.
> With regard particularly to serial numbers it's clear they are necessary as input to revocation mechanisms.
yes, and my suggested alternative mechanism preserves logging of serial 
numbers, as
a separate step for CAs (not for Subjects or others who have a cert for 
which an SCT
is to be created as a post-issuance artifact.) But, I think the I-D 
needs to be clear
about the threat model so that we can see why revocation is part of a 
remediation plan
in some circumstances. The current text is way too vague on this topic, 
as I noted in
my review prior to the Toronto meeting.

Steve

---

From: Brian Smith <[email-masked]>
Date: Tue, 9 Sep 2014 12:56:11 -0700

> Brian, even if the CA uses a Precert signing cert, the precert's issuer name has to be that of the ultimate issuer, and the serial number has to be that of the ultimate certificate, so I don't thin…

Thanks for pointing that out. Basically, the cause of that problem is
that a Precertificate is a syntactically-valid X.509 certificate, and
so it could be considered a duplicate of the final certificate. If the
Precertificate weren't a syntactically-valid X.509 certificate, then
there would be no way it could be considered a duplicate. So, why not
make this simple change to the syntax:

enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;

  struct {
    LogEntryType entry_type;
    select (entry_type) {
      case x509_entry: ASN.1Cert;
      case precert_entry: ASN.1Precert;
    } entry;
    ASN.1Cert certificate_chain<0..2^24-1>;
  } LogEntry;

  opaque ASN.1Cert<1..2^24-1>;
  opaque ASN.1Precert<1..2^24-1>;

where the internal syntax of ASN.1Precert is (in ASN.1):

  ASN1Precert ::=  SEQUENCE  {
    precertSigningCert [0] EXPLICIT OptionalCertificate,
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue BIT STRING }

  OptionalCertificate ::= certificate Certificate OPTIONAL;

In other words, ASN1Precert is exactly an X.509 Certificate except
that it starts with an explicitly-tagged, possibly-empty
precertSigningCert field. Thus, no X.509 certificate parser would
parse a precert as though it were a real certificate, and so the
precert could never be considered a duplicate of the final cert.
Additionally, there would be no need for the "poison extension"
because the added precertSigningCert field serves the same purpose.

This strawman only attempts to solve the "duplicate certificate"
problem, not the "must reserve the serial number in advance" problem.
However, I suspect that this change would make it more difficult for
some CAs to create precertificates.

Cheers,
Brian

---

From: "Hill, Brad" <[email-masked]>
Date: Tue, 9 Sep 2014 19:59:02 +0000

Stephen,

Below was your original question, which I've attempted to answer in as straightforward a manner as possible, including illustrative examples from recent history.  Detecting mis-issuance of certificates through public logging of such is the stated goal of the I-D.  The complex nature of X.509/PKIX and the surrounding technology ecosystem and the history of vulnerabilities in such demonstrates that including everything in the log except that which MUST be excluded furthers that goal.  There is not a specific threat model nor any need to articulate one.  We desire a technology that is useful against as many threats to the broad certificate ecosystem as possible, including those yet to be formally anticipated.

-Brad

---

From: Brian Smith <[email-masked]>
Date: Tue, 9 Sep 2014 13:02:46 -0700

On Tue, Sep 9, 2014 at 12:56 PM, Brian Smith <[email-masked]> wrote:
> precertSigningCert field.

...and where signatureValue covers both precertSigningCert and
tbsCertificate, instead of just tbsCertificate. (This would have been
more clear if I would have wrapped precertSigningCert and
tbsCertificate in a SEQUENCE.)

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Tue, 9 Sep 2014 13:15:22 -0700

On Tue, Sep 9, 2014 at 3:17 AM, Rob Stradling <[email-masked]> wrote:
> I don't mind us adding an alternative Precertificate format to 6962-bis (if
> we can agree on a suitable format!), but I'd also like to retain the RFC6962
> Precertificate format as an option.

If the old form is acceptable, then there would be no point in
defining a new form. The chief issue is that technically the old form
of precertificate is technically a certificate, and since it has the
same issuer name it must (according to RFC 5280) have a different
serial number. It would be good for the group to decide whether or not
that issue is so bad that we cannot accept it. If it is that bad, it
makes sense to define a replacement format. If it isn't so bad that we
can't accept it, then it doesn't make sense to define a replacement
format, IMO.

> Several CAs have already deployed code to generate RFC6962 Precertificates.
> Why force these CAs to change to a different format just because some other
> CAs find it hard to implement the RFC6962 format?

If the only issue is whether it is a little bit tricky to implement
the X.509-certificate form of precertificate, then there's no point in
defining a new format. CAs always have the non-precertificate
mechanism to fall back on.

IMO, the ultimate goal should be to get the non-precertificate
mechanisms working well enough that we can remove (or at least
deprecate) the precertificate mechanism completely.

Cheers,
Brian

---

From: Stephen Kent <[email-masked]>
Date: Tue, 09 Sep 2014 16:17:21 -0400

Brad,
> Stephen,
>
> Below was your original question, which I've attempted to answer in as straightforward a manner as possible, including illustrative examples from recent history.  Detecting mis-issuance of certificates through public logging of such is the stated goal of the I-D.
The I-D fails to describe what constitutes mis-issuance. there appears 
to be many examples
where Web PKI CAs issue certs that do not comply with RFC 5280 (see the 
WPKOPS WG).
Are those certs mis-issued? Or, are certs that are syntactically valid, 
maybe even
5280-compliant, but issued to the "wrong" subject mis-issued? or, ...

The I-D needs to be more precise in defining. Logging, per se, permits 
folks who monitor
logs to detect mis-issuance, but does not solve the problems caused by 
mis-issuance. If detection were sufficient, then there would be no need 
for TLS clients to reject certs w/o
SCTs (as mandated by the current I-D). I'm guessing that there is a 
notion of how the various elements of CT work together to address the 
problems that result from mis-issuance, but the
I-D fails to articulate this notion. That's a serious omission.
> The complex nature of X.509/PKIX and the surrounding technology ecosystem and the history of vulnerabilities in such demonstrates that including everything in the log except that which MUST be excluded furthers that goal.  There is not a specific threat model nor any need to articulate one.
For several years it has been common practice to require a threat model 
for new security efforts in the IETF. Why do uyou believe that TRANS 
should be an exception?
>   We desire a technology that is useful against as many threats to the broad certificate ecosystem as possible, including those yet to be formally anticipated.
The scope here is essentially the Web PKI used with TLS, primarily as 
used by in browsers;
it is not all possible uses of certs with IETF security protocols. So 
the "broad certificate ecosystem" is not universal, right?

Steve

---

From: Brian Smith <[email-masked]>
Date: Tue, 9 Sep 2014 13:23:27 -0700

> not sign anything using a cert; one verifies a signed thing using a public

Rick and Carl did a good job of explaining why my line of reasoning
didn't make sense in the first place, regardless of my poor choice of
terminology.

By the way, in draft -04 there are similar abuses of terminology that
should be cleaned up. Here's one example, "The resulting
TBSCertificate [RFC5280] is then signed with either [...] a
special-purpose [...] Precertificate Signing Certificate [...] or, the
CA certificate that will sign the final certificate." There are
probably more.

Also, it might be worth mentioning in the draft that it doesn't make
sense to use a Precertificate Signing Certificate if it has the same
public key as the issuing certificate.

Cheers,
Brian

---

From: Kyle Hamilton <[email-masked]>
Date: Tue, 09 Sep 2014 16:40:35 -0700

I think the best way to change a Certificate into a Precertificate would be to alter the first field of the tbsCertificate to be non-optional and explicitly tagged as something other than tag [0].  Then, reconstruct the actual tbsCertificate by changing the first field to tag [0], perform any other necessary edits (like, for name redaction), re-encode the validly-tagged tbsCertificate to DER, and digest the encoded data.

But, I also proposed (a few years ago) a way to include an issued certificate list in a CRL extension to mitigate the Diginotar-style "we didn't know it had been issued" problem, and to be able to feed CRL-based OCSP responders with a minimum of code changes. That didn't go anywhere, and I expect this suggestion to go nowhere as well.

-Kyle H

On September 9, 2014 12:56:11 PM PST, Brian Smith <[email-masked]> wrote:
>> Brian, even if the CA uses a Precert signing cert, the precert's
>issuer name has to be that of the ultimate issuer, and the serial
>number has to be that of the ultimate certificate, so I don't think
>that solves the problem.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 9 Sep 2014 18:25:37 -0700

On Tue, Sep 9, 2014 at 4:40 PM, Kyle Hamilton <[email-masked]> wrote:
> I think the best way to change a Certificate into a Precertificate would be
> to alter the first field of the tbsCertificate to be non-optional and
> explicitly tagged as something other than tag [0]. Then, reconstruct the
> actual tbsCertificate by changing the first field to tag [0], perform any
> other necessary edits (like, for name redaction), re-encode the
> validly-tagged tbsCertificate to DER, and digest the encoded data.

Let's back up a bit: we want to ensure that the certificate chains
browsers use are a matter of public record. To do this we need to
record the chain in a log, and give the server back a way to prove
"yes, we've seen this chain" from the log. What I don't understand
here is the role of the CA and the Precertificate in this process.

Sincerely,
Watson Ladd
>
> But, I also proposed (a few years ago) a way to include an issued
> certificate list in a CRL extension to mitigate the Diginotar-style "we
> didn't know it had been issued" problem, and to be able to feed CRL-based
> OCSP responders with a minimum of code changes. That didn't go anywhere, and
> I expect this suggestion to go nowhere as well.
>
> -Kyle H
>
>>>> Precertificate, and then sign the final certificate with the production CA
>>>> certificate. Then, there would be no duplicate serial number issues.
>>>
>>>
>>> name has to be that of the ultimate issuer, and the serial number has to be
>>> that of the ultimate certificate, so I don't think that solves the problem.
>>
>>
>> so it could be
>> considered a duplicate of the final certificate. If the
>> ________________________________
>>
>> Trans mailing list
>> [email-masked]

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 10 Sep 2014 10:01:06 +0200

On 2014-09-09 21:43, Stephen Kent wrote:
> Brad,
>
>> Whatever is logged ought to be as close as is possible to the actual
>> certificate and ought to include all meaningful information in the
>> certificate other than a preimage-resistant hash.
>> Detecting problematic issuance isn't confined just to organizational
>> authority.  Looking at the recent history of bugs in this area,
>> observing a flurry of issuance of certificates of the form
>> "www.legit.com\0www.evil.com", or certificates with large "tumors" in
>> rarely used or obsolete extensions might have been cause to
>> investigate deeper and additionally could've provided evidence of
>> stealthier prior exploitation of such bugs.
>> We can't predict in advance what such problems will be, so the default
>> stance should be that everything is logged, and the onus fall on those
>> who want to exclude content to justify that action.

The question of logging everything is not that clear even today. As 
there is currently drafted how to exclude private domain names in the 
PreCertificates being logged. I see possibility for either:
- Log everything by default, risking to add one item after another that 
can optionally not be logged (=can become complex)
- Define what is to be logged, risking adding new things continuously 
(=can become complex)

In any way, the PreCertificate will most likely (almost)never have 
exactly the same information as the real certificate.

>> With regard particularly to serial numbers it's clear they are
>> necessary as input to revocation mechanisms.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Sep 2014 10:03:13 +0100

> here is the role of the CA and the Precertificate in this process.

Hi Watson.

Without Precertificates, we would have to wait for all of the world's 
TLS Servers to be updated to support the RFC6962 TLS extension and/or 
OCSP Stapling before TLS Clients would then be able/willing to abort TLS 
handshakes when an SCT is not provided.  We don't want to have to wait 
that long!

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Sep 2014 10:23:42 +0100

Hi Stephen.  That's an interesting idea, but I see a few issues.

Step 4 requires the final cert to be logged, so it's incompatible with 
the name redaction mechanism.

Monitors want to detect misissuance (i.e. certs that have been issued 
incorrectly).  I'm not sure that it's reasonable to expect Monitors to 
also take responsibility for detecting non-issuance of certs that should 
have been issued.

-- 
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: Ben Laurie <[email-masked]>
Date: Wed, 10 Sep 2014 10:54:37 +0100

On 9 September 2014 19:23, Stephen Kent <[email-masked]> wrote:
> I agree that using a redefined (to include the serial number) cert template
> from CRMF would avoid the 5280 issue, but it still requires the CA to assign
> the serial number before
> CAs, one that may have adverse security implication for some. Nonetheless, I
> like your suggestion (minus the serial number) as a starting point. See my
> next message.

I have a suggestion: let the RFC say that any certificate which the
log knows can be revoked without knowing its serial number can omit
the serial number.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Sep 2014 11:31:02 +0100

On 09/09/14 21:15, Brian Smith wrote:
> that issue is so bad that we cannot accept it.

Chairs,

Do we have the option of keeping the existing Precertificate format, 
such that once 6962-bis becomes a standards track RFC it would violate 
the serial number uniqueness rule in the RFC5280?
Or, does the IETF process absolutely require that we don't violate any 
rules in existing standards track RFCs?

> If it is that bad, it makes sense to define a replacement format. If it isn't
> so bad that we can't accept it, then it doesn't make sense to define a
> replacement format, IMO.

Brian,

Unless it turns out that there is no single format that all CAs are able 
to use, I agree.

> deprecate) the precertificate mechanism completely.

I'm not convinced that this should be the ultimate goal.  A benefit of 
the Precertificate mechanism is that the certificate holder doesn't need 
to worry about configure their TLS Server for CT, because the CA has 
already taken care of the CT stuff for them.

Also, out of scope for 6962-bis but in scope for discussion on this list...
Precertificates could be useful if/when we extend CT to Code Signing 
certificates, S/MIME certificates, etc, but the RFC6962 TLS Extension 
won't be useful in these contexts.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Sep 2014 11:57:02 -0400

Brian,

> didn't make sense in the first place, regardless of my poor choice of
no problem. people often refer to certs "signing" stuff; I have
a compulsion to note the error every time I see it :-).
> CA certificate that will sign the final certificate." There are
I believe I noted these terminology problems in -03, in my review.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Sep 2014 12:07:19 -0400

tRob,

> OCSP Stapling before TLS Clients would then be able/willing to abort 
> TLS handshakes when an SCT is not provided. We don't want to have to 
> wait that long!
You noted this rationale previously, when I asked whether we really need 
pre-certs, and
I failed to reply to your message. (lost in the inbox clutter)

I understand the desire to reduced the delay in deployment.

However, the specific mechanism you mentioned, a TLS client aborting a 
handshake because
of a lack of an SCT (embedded or passed explicitly in the handshake) is 
still being debated.
Specifically, I noted that this hard fail approach, does not seem 
compatible with an
incremental deployment model, absent a lot of details. During the IETF 
meeting in Toronto,
Ben stated that he agreed that an incremental deployment model was 
desirable, and thus
requirements for TLS client behavior need to be revisited.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Sep 2014 12:08:17 -0400

Ben,

> On 9 September 2014 18:39, Stephen Kent<[email-masked]>  wrote:
As I noted earlier, there is no threat model for the CT mechanism.

And there is no mapping of CT to the threat model.

We usually do not standardize security mechanisms when these two
critical elements are missing.

> remedied. If you think that's a valuable exercise, be my guest.
There is a big difference between "all" and "none."
> might reveal and available remedies as an illustration of why that
I don't know what this last, rather long sentence means. Please elaborate.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Sep 2014 12:08:41 -0400

Rob,

> the name redaction mechanism.
Oops, an oversimplified description on my part. In step 4 I think one 
can apply the whatever redaction mechanisms that we adopt.
> also take responsibility for detecting non-issuance of certs that 
> should have been issued.
The current I-D says
Monitors watch logs and check that they behave correctly.They also

watch for certificates of interest.

The non-issuance of an SCT after issuance of an SCT* for a "certificate 
of interest"
would seem to be within scope, given the somewhat vague description in 
the I-D.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Sep 2014 12:08:58 -0400

Ben,

> On 9 September 2014 19:23, Stephen Kent<[email-masked]>  wrote:
because, as you noted, we have no IETF-standard way to revoke a single
cert w/o knowing its serial number, I don't think this is a good fix.

Nonetheless, I do appreciate your willingness to explore alternative 
approaches
to address the concern I raised.

Steve

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Sep 2014 08:12:01 -0800

> rules in existing standards track RFCs?

We do have the option of keeping the existing format and still see
6962-bis published as a standards-track document.  However, I would
expect that doing so would lead to an unpleasant working group last
call, an unpleasant IETF last call, and possibly an unpleasant IESG
review.  If there's a workable alternative on which we can get broad
(but not necessarily unanimous) agreement, let's do that.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Sep 2014 08:25:43 -0800

> critical elements are missing.

Steve, I think this is a bit of an overstatement of the role of
thread models in the process.  The IETF has recently fallen into
a few process habits that aren't supported by any formal changes.
Some are good, some are awful.  The development of threat models
and discussion of a given mechanism within the framework of a threat
is a good process habit and one we'd encourage, but is not necessarily
required.

As an aside, I'd be grateful if tone could be ratched back a notch.
It's not just that we're working cooperatively to produce a document
and a combative tone makes it more difficult to reach agreement,
but that there's been concerned expressed within the IESG that
harshness and/or combativeness can drive away new participants and
people who'd otherwise be willing to do work.  You're raising good
points and they need to be addressed, but it would be better if they
were expressed in a way unlikely to put their recipients into a
defensive posture.

Thanks,

Melinda

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Sep 2014 12:12:01 +0100

On 10 September 2014 17:08, Stephen Kent <[email-masked]> wrote:
>>> in

I think its pretty clear what the purpose of CT is - to make it
possible to detect mis-issuance of certificates - i.e. that
certificates conform to all the requirements for issuance. And its
also clear that to do this, you need to be able to see the contents of
the certificate. This is the threat model. Or, if you really want it
phrased as a threat, the threat is that some CA might issue a
certificate that does not conform to the requirements for issuance
(which, btw, vary over time) and the mitigation is a public,
append-only, verifiable log of the contents of all issued
certificates.

The I-D clearly states this already, I think, but if you don't like
the text, perhaps you can propose something you'd like better?

> There is a big difference between "all" and "none."

At least one problem is described: "Those who are concerned about
misissue can monitor the logs, asking

   them regularly for all new entries, and can thus check whether
   domains they are responsible for have had certificates issued that
   they did not expect."

I guess we could add some other examples, such as conformance to the
Baseline Requirements.

> I don't know what this last, rather long sentence means. Please elaborate.

What I meant was that mentioning a problem in order to explain why
some field is needed does not mean that we then have to enumerate all
problems, find a problem that justifies every field, etc.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Sep 2014 13:52:07 +0100

> can apply the whatever redaction mechanisms that we adopt.

Steve, can you suggest a name redaction mechanism that would be 
compatible with your idea?

> would seem to be within scope, given the somewhat vague description in

OK, let's explore this avenue and see whether or not we hit any 
roadblocks.  :-)

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Sep 2014 16:15:35 +0100

On 10 September 2014 17:08, Stephen Kent <[email-masked]> wrote:
>>> template
>>> Nonetheless, I
> cert w/o knowing its serial number

Quite.

> I don't think this is a good fix.

Until there is such a mechanism, omitting serial numbers makes it hard
(or impossible?) for anyone to take effective action on violations
discovered via CT. So, CT has to require serial numbers until then.
This language allows that to happen.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Sep 2014 11:21:08 -0400

Ben,
> This language allows that to happen.
I think we're in agreement, which I why I proposed an alternative
mechanism to log serial numbers, without requiring a CA to have
to assign them prior to final cert issuance.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Sep 2014 16:53:06 +0100

> to assign them prior to final cert issuance.

I managed to miss that proposal. I've found it now.

There seems to be a flaw: if I'm an evil CA wishing to issue an evil
certificate, I simply log a precert, minus serial, get an SCT*, log a
certificate containing that SCT*, which I then revoke when requested
to do so,

In order to attack a user with the evil certificate, I simply issue a
second copy with a different serial, containing the original SCT*, and
the certificate works. Yes, the discrepancy should be discovered in
audit, but that is a significantly weaker protection than we get if
the serial is included in the pre-certificate.

Also this adds quite a lot of complexity in order to allow what
appears to be, so far, an entirely theoretical use case.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Sep 2014 14:15:16 -0400

Ben,

> the serial is included in the pre-certificate.
I agree that the attack you describe would work, but it needs to be
evaluated in the overall context of how CT works in the case of several
different types of attack scenarios. The threat model and attack model text
I just submitted provides a first cut at describing such scenarios. Once we
get agreement on that model, let's revisit the question of whether the 
vulnerability
you noted above is significant relative to other residual vulnerabilities.
> appears to be, so far, an entirely theoretical use case.
I do know that when VeriSign used the Safekeyper HSM to issue all of its 
certs
(which it did for several years), it would have been impossible to 
generate a
pre-cert and matching final cert. So, the concern I raise would have 
been a show
stopper for them in that time frame. I guess it depends on how one defines a
"theoretical use case" :-)

Separately, the pre-cert model, requires a CA to issue two certs with 
the same
serial number, which is a bad security practice. I think it makes sense to
re-consider forcing CAs to behave this way.

Steve

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 12 Sep 2014 18:44:51 +0000

Why not use a TBSCertificate from RFC 5280 with no modifications from the final certificate (no poison extension) and sign it with a PKCS7 signature instead of a RFC 5280 signature?  By doing this you are not creating a valid certificate so you are not technically breaking RFC 5280 (re-using serial numbers) and it couldn't be used as a certificate even if some software incorrectly ignored the poison extension.  

Jeremy

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Thursday, September 11, 2014 12:15 PM
To: [email-masked]
Subject: Re: [Trans] Precertificate format

Ben,

> the serial is included in the pre-certificate.
I agree that the attack you describe would work, but it needs to be evaluated in the overall context of how CT works in the case of several different types of attack scenarios. The threat model and attack model text I just submitted provides a first cut at describing such scenarios. Once we get agreement on that model, let's revisit the question of whether the vulnerability you noted above is significant relative to other residual vulnerabilities.
> appears to be, so far, an entirely theoretical use case.
I do know that when VeriSign used the Safekeyper HSM to issue all of its certs (which it did for several years), it would have been impossible to generate a pre-cert and matching final cert. So, the concern I raise would have been a show stopper for them in that time frame. I guess it depends on how one defines a "theoretical use case" :-)

Separately, the pre-cert model, requires a CA to issue two certs with the same serial number, which is a bad security practice. I think it makes sense to re-consider forcing CAs to behave this way.

Steve

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 12 Sep 2014 21:26:56 +0200

Nice idea, solves the RFC5280 concerns, and doesn't require a completely
new data structure.

IIUC, what you propose is that the PreCert is a CMS (RFC5652) with a
signedData content-type, for which the data is the TBSCertificate
(name-redacted or not, no necessary poison extension). The SignerInfo
refers to the PreCert issuer (CA or dedicated issuer, same as now).

It can only work if the log signs the content (=TBSCertificate) and not the
whole CMS, thus ignoring the PreCert issuer signature. Leaving that
signature aside isn't more risky than it is now because it's already the
case (the log removes the poison extension before signing the resulting
certificate, right?).
If the log signs the whole CMS, the SCT covers information unknown to the
browser at connection time (content of SignerInfo, maybe additional
attributes --authenticated or not--, digest algorithm chosen by the PreCert
issuer, etc).

2014-09-12 20:44 GMT+02:00 Jeremy Rowley <[email-masked]>:

> Why not use a TBSCertificate from RFC 5280 with no modifications from the
> final certificate (no poison extension) and sign it with a PKCS7 signature
> instead of a RFC 5280 signature?  By doing this you are not creating a
> valid certificate so you are not technically breaking RFC 5280 (re-using
> serial numbers) and it couldn't be used as a certificate even if some
> software incorrectly ignored the poison extension.
>
> Jeremy
>
> vulnerability you noted above is significant relative to other residual
> vulnerabilities.
> certs (which it did for several years), it would have been impossible to
> generate a pre-cert and matching final cert. So, the concern I raise would
> have been a show stopper for them in that time frame. I guess it depends on
> how one defines a "theoretical use case" :-)
>
> Separately, the pre-cert model, requires a CA to issue two certs with the
> same serial number, which is a bad security practice. I think it makes
> sense to re-consider forcing CAs to behave this way.
>
> Steve
>

-- 
Erwann.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 15 Sep 2014 10:32:06 +0100

On 12/09/14 20:26, Erwann Abalea wrote:
> It can only work if the log signs the content (=TBSCertificate) and not
> the whole CMS, thus ignoring the PreCert issuer signature. Leaving that

Yes.  The log removes the poison extension, and (if a Precertificate 
Signing Certificate was used) it also changes the issuer name and AKI to 
match those of the final certificate's issuing CA.  This behaviour can 
remain the same.

I agree that using CMS to sign the Precert TBSCertificate is a good 
solution to the duplicated certificate serial number problem.  :-)

> If the log signs the whole CMS, the SCT covers information unknown to
> the browser at connection time (content of SignerInfo, maybe additional
> attributes --authenticated or not--, digest algorithm chosen by the
> PreCert issuer, etc).
>
>
> 2014-09-12 20:44 GMT+02:00 Jeremy Rowley <[email-masked]
> <mailto:[email-masked]>>:
>
>     Why not use a TBSCertificate from RFC 5280 with no modifications
>     from the final certificate (no poison extension) and sign it with a
>     PKCS7 signature instead of a RFC 5280 signature?  By doing this you
>     are not creating a valid certificate so you are not technically
>     breaking RFC 5280 (re-using serial numbers) and it couldn't be used
>     as a certificate even if some software incorrectly ignored the
>     poison extension.
>
>     Jeremy
>
>     From: Trans [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Stephen Kent
>     To: [email-masked] <mailto:[email-masked]>
>     evaluated in the overall context of how CT works in the case of
>     several different types of attack scenarios. The threat model and
>     attack model text I just submitted provides a first cut at
>     describing such scenarios. Once we get agreement on that model,
>     let's revisit the question of whether the vulnerability you noted
>     above is significant relative to other residual vulnerabilities.
>     I do know that when VeriSign used the Safekeyper HSM to issue all of
>     its certs (which it did for several years), it would have been
>     impossible to generate a pre-cert and matching final cert. So, the
>     concern I raise would have been a show stopper for them in that time
>     frame. I guess it depends on how one defines a "theoretical use
>     case" :-)
>
>     Separately, the pre-cert model, requires a CA to issue two certs
>     with the same serial number, which is a bad security practice. I
>     think it makes sense to re-consider forcing CAs to behave this way.
>
>     Steve
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 15 Sep 2014 15:27:10 +0200

2014-09-15 11:32 GMT+02:00 Rob Stradling <[email-masked]>:

>> [...]

Concerning these last changes (issuer name and AKI), are they under the
responsibility of the certificate issuer, or of the log signer?
My understanding was that it's the issuer's job. AKI being a variable
extension, how could the log know which one of {issuerName+serialNumber},
{keyIdentifier}, {issuerName+serialNumber+keyIdentifier} content will be
found in the final certificate?
If it's the log signer's job, then in the PreCert signing certificate
situation, there's no non-conformance to RFC5280 (regarding to
issuerName+serialNumber uniqueness).

-- 
Erwann.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 15 Sep 2014 14:55:36 +0100

On 15/09/14 14:27, Erwann Abalea wrote:
> 2014-09-15 11:32 GMT+02:00 Rob Stradling wrote:
>     Signing Certificate was used) it also changes the issuer name and
>     AKI to match those of the final certificate's issuing CA.  This
>     behaviour can remain the same.
>

Hi Erwann.  That was my understanding too until Emilia corrected me a 
few days ago!

> My understanding was that it's the issuer's job.

No, it's the log signer's job.  The Precertificate's Issuer Name and AKI 
need to match the Precertificate Signing Certificate's Subject Name and SKI.

Upon receipt of a Precertificate, the log signer does the following:
   1. Verify the Precertificate's signature.
   2. Extract the TBSCertificate part of the Precertificate.
   3. Remove the poison extension.
   4. Change the Issuer name to match the Issuer name of the final 
cert's issuer.
   5. Change the AKI to match the SKI of the final cert's issuer.
   6. Use that modified TBSCertificate to construct the SCT.
   7. Generate the SCT signature.

> AKI being a variable extension, how could the log know which one of
> {issuerName+serialNumber}, {keyIdentifier},
> {issuerName+serialNumber+keyIdentifier} content will be found in the
> final certificate?

Funny you should mention this.  Right now I'm working on SCT 
verification code for OpenSSL with Steve Henson and Emilia.  Just a few 
minutes ago Steve asked the very same question you've just asked here.

So I just looked at the language in RFC6962 Section 3.2.  I think "the 
TBSCertificate also has its Authority Key Identifier changed to match 
the final issuer" is sufficiently vague that we need to file an erratum 
to RFC6962 to specify exactly how to deal with the optionality of the 
various AKI components.

I also just looked at the certificate-transparency.org code for 
inspiration, but it seems to be doing completely the wrong thing!  It's 
copying the final cert issuer's AKI rather than SKI.  :-(

> issuerName+serialNumber uniqueness).

Correct.  The serialNumber is identical, but the issuerName is different.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2014 14:52:20 -0400

Ben,

> the text, perhaps you can propose something you'd like better?
Here's some suggested text that matches my model for a threat model 

> problems, find a problem that justifies every field, etc.
Thanks for the clarification. I disagree. If one lists every field
to be covered by an SCT, and notes why the field needs to be covered,
then the coverage is clearly justified. Saying that we'll cover every field
because there might be a need to do so, even though we can't articulate
it, can lead to unnecessary complexity. For example, right now TCPINC
WG is performing this exercise for the TCP header, to justify which fields
needs to be integrity-protected. I agree that an X.509 cert is a much
bigger, more complex data structure, but the principle is the same.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2014 14:52:35 -0400

Jeremy,
> Why not use a TBSCertificate from RFC 5280 with no modifications from the final certificate (no poison extension) and sign it with a PKCS7 signature instead of a RFC 5280 signature?  By doing this…
Using either a TBS cert with a different signature format or CRMF would 
avoid the
53280 conflict. It would not, however, address the "know the serial 
number before you issue the
cert" concern that I raised. So, we have a couple of proposals that 
address at least half of
the problem, which is a start.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Tue, 16 Sep 2014 11:25:53 +0100

> On 15/09/14 14:27, Erwann Abalea wrote:
<snip>
> copying the final cert issuer's AKI rather than SKI.  :-(

Sorry, ignore that.  Looks like the certificate-transparency.org code is 
actually copying the Issuer Name and AKI from the Precertificate Signing 
Certificate.  That's correct.

Nonetheless, I still think RFC6962 needs an erratum to deal with the 
optionality of the various AKI components.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 16 Sep 2014 12:37:07 +0200

Bonjour Rob,

Thanks for your valuable comments, we're currently implementing this in our
CA, and the RFC5280 conformance of the PreCert Signing Certificate scenario
is pleasing. No need to remove our constraints or cheat to circumvent
them...

> Certificate.  That's correct.

Ok. So the reference code takes for granted that the CA will use the same
strategy to populate the PreCert Signing Certificate and the final issued

> optionality of the various AKI components.

+1
This should be stated somewhere.

-- 
Erwann.