Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT

From: Ben Laurie <[email-masked]>
Date: Tue, 1 Jul 2014 14:00:51 +0100

Sorry for the delay.

On 4 June 2014 20:52, Doug Beattie <[email-masked]> wrote:
>
> Those CAs that want to use a Precertificate Signing Certificate need to
> follow a more complicated process for signing and I don't think it's well
> documented or thought out.
>
> 1) What chain does the Precertificate Signing Certificate need to be issued
> under?
>
> RFC 6962 states: "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 (note that the log *may* relax standard validation rules to
> allow this, so long as the issued certificate will be valid)"
>
> Point 1.1: Normally CAs have path length set to 0, so CAs are not able to
> issue CA certificates under them, and this looks like a CA certificate
> because CA:TRUE.

As you point out, the log can relax validation rules, which deals with
this problem (and we do, indeed, do that in our implementation).

> Point 1.2: The also RFC States: "If the Precertificate is not signed with
> the CA certificate that will issue the final certificate, then the
> TBScertificate also has its issuer changed to that of the CA that will issue
> the final certificate. "
>
> This makes the Precertificate Signing Certificate look even less like a CA
> certificate.  How do we convince a compliant/certified CA application to use
> an Issuer DN other than the one that was used to sign the certificate?
> Compliant CAs won't.

I agree that this could be troublesome, though no-one has reported it
as a blocker for them. If it turns out that no-one uses this option,
perhaps we should drop it?

> Point 1.3: The "may" above needs to be MUST, or validation will fail due to
> the Issuer DN not matching what was posted.

I guess so. File a bug?

> Recommendation 1: At a minimum, remove CA:true from the Certificate Signing
> Certificate profile.  Ideally the profile should be updated to be more like
> a Document/Code signing certificate than a CA certificate.

I am not sure I understand how this helps? The path length constraint
is a constraint on the length of the path, surely - regardless of what
bits are set in certs in the path?

> The signed TBScertificates posted to the log specifies the final
> certificate's issuer DN, but the cert chain for the Precertificate Signing
> Certificate is supplied so the CT log can validate that chain using relaxed
> validation rules.  What's the relationship between the hierarchy of the
> Precertificate Signing Certificate and the final certificate? I struggle to
> find any relationship except they both chain to publicly trusted roots.  Is
> that the intent of the RFC?

Yes. The intent is for a CA to state its intention to issue a
particular certificate.

> Recommendation 2: The Precertificate Signing Certificate used by a CA may be
> issued under any one of its roots and be used to sign all entries to be
> posted to the log.  Unless there is a requirement to validate that the
> chains use the same root/hierarchy, there is no reason to require that.

The requirement is that we can track down the issuer and that we can
reconstruct the precert from the cert. Its not clear to me that this
meets that requirement.

> 2) Does the certificate serial number need to be the same in the
> TBScertificate and the final certificate?

Yes.

> CAs that randomly generate serial numbers during issuance can't pre-generate
> serial numbers to be used in the TBScertificate, then subsequently in the
> final certificate. Is the serial number *that* important that it MUST be
> included in the SCT?  The issuer for the TBScertificate does not match the
> value of the certificate that signed it, so what's the point of the serial
> number?  The CN, SAN, signing algorithms and keys are the most critical
> components.  Can we limit the SCT to these values?

Serial numbers are used for revocation, so we need to know what they are.

> Recommendation 3: Don't require that the TBScertificate and the final
> certificate contain the same serial number.

See above.

> Summary: The CT Log validation rules need to be clearly defined so that the
> CAs can post valid entries to the CT logs.
>
> * Currently I don't believe that the RFC is implementable by compliant CAs
> that want to use Precertificate Signing Certificate.

This may be so, but I don't think you've found a way to fix this, if it is so.

> * Compliant CAs won't issue certificates with duplicate issuer DNs and
> serial numbers, so that model is also broken - the Precertificate Signing
> Certificate needs to be a non-CA certificate.

Surely a different CA cert is equivalent to a different CA, and
therefore the issuer DN/serial is _not_ a duplicate?

> * CAs that randomly generate serial numbers during issuance can't
> pre-generate serial numbers to be used in the TBScertificate, then
> subsequently in the final certificate, so serial numbers need to be removed
> from the content hashed by the SCT.

See above.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Jul 2014 13:34:41 -0400

Ben,
> ...
My comments noted that relaxing rules in an unspecified fashion creates 
potential
problems for those submitting pre-certs. The specific changes needed to 
enable
acceptance oif pre-certs need to be spelled out.
> ...
I understand the desire to have the serial number be submitted as part
of the pre-cert, but the problem raised by Doug is a valid one that
cannot be ignored.
>> certificate contain the same serial number.
see my comment above as well :-).
> This may be so, but I don't think you've found a way to fix this, if it is so.
The burden on fixing it is not on Doug; it is on the authors of the doc!
>> from the content hashed by the SCT.
Ben, it's not reasonable to tell CAs that their extant serial number 
management
mechanism has to change to accommodate the CT design. It is the 
responsibility
of the CT designers to figure out how to accommodate valid CA operation 
models.
The RFC that forms the basis of the WG effort was experimental; there is no
presumption that a final, standards track doc will be the same in every 
detail.
The pre-cert serial number problem may be one aspect of the design that 
needs
to change.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Jul 2014 15:01:35 -0400

Brad,

> All that is really needed is a well-defined and easily reversible transformation of the serial number that can be applied to verify the proof.
>
> As issuing non-randomized serial numbers is no longer an acceptable practice for CAs, it could be as simple as:
>
> certSerialNum = preCertSerialNum++;
>
I don't think I understand your suggested solution.

I believe the fundamental problem is that CA software/hardware may
1 not allow a CA to assign or even predict the serial number that 
appears in a cert
2 prevent assignment of duplicate serial numbers by the same CA
3 provide no way to coordinate serial numbers between two distinct CA 
instances

This suggests that the serial number assigned to a precert may not be 
algorithmically related to the
serial number that is assigned to the real cert that will contain the 
SCT based on the precert.

If #1 is true, then I don't think the alg you indicated in your equation 
can be employed.
If #2 is true, the precert and cert serial numbers can't be the same 
unless different
CAs are emplpoyed for the precet and cert issuance. If different CAs are 
employed because of #2,
then #1 or #3 would preclude the alg you suggested.

Steve

---

From: "Hill, Brad" <[email-masked]>
Date: Tue, 1 Jul 2014 17:40:15 +0000

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Tuesday, July 01, 2014 10:35 AM
To: [email-masked]
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT

Ben,
> this problem (and we do, indeed, do that in our implementation).
My comments noted that relaxing rules in an unspecified fashion creates potential problems for those submitting pre-certs. The specific changes needed to enable acceptance oif pre-certs need to be spelled out.
> ...
>> CAs that randomly generate serial numbers during issuance can't 
>> subsequently in the final certificate. Is the serial number *that* 
>> important that it MUST be included in the SCT?  The issuer for the 
>> TBScertificate does not match the value of the certificate that 
>> signed it, so what's the point of the serial number?  The CN, SAN, 
>> signing algorithms and keys are the most critical components.  Can we limit the SCT to these values?
I understand the desire to have the serial number be submitted as part of the pre-cert, but the problem raised by Doug is a valid one that cannot be ignored.
>
>> Summary: The CT Log validation rules need to be clearly defined so 
>> that the CAs can post valid entries to the CT logs.
>>
>> * Currently I don't believe that the RFC is implementable by 
>> compliant CAs that want to use Precertificate Signing Certificate.
>> subsequently in the final certificate, so serial numbers need to be 
>> removed from the content hashed by the SCT.
> See above.
Ben, it's not reasonable to tell CAs that their extant serial number management mechanism has to change to accommodate the CT design. It is the responsibility of the CT designers to figure out how to accommodate valid CA operation models.
The RFC that forms the basis of the WG effort was experimental; there is no presumption that a final, standards track doc will be the same in every detail.
The pre-cert serial number problem may be one aspect of the design that needs to change.

Steve

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

---

From: Ben Laurie <[email-masked]>
Date: Fri, 4 Jul 2014 13:24:34 +0100

> acceptance oif pre-certs need to be spelled out.

Hmm. What we do is check the signatures validate all the way up the
chain. That's it. I'm not sure we need anything tighter than that, so
I guess we could specify that?

>>> pre-generate

My response is that, yes, the serial number is *that* important that
is MUST be included in the SCT.

> The burden on fixing it is not on Doug; it is on the authors of the doc!

Our position is that compliant CAs _can_ use Precertificate Signing
Certificates - though possibly not with the exact toolchain they use
to issue certificates. If someone wants to propose a mechanism that is
compatible with whatever restrictions their s/w imposes, we'd be happy
to consider it.

> of the CT designers to figure out how to accommodate valid CA operation

I don't agree. If things have to change in order to achieve the agreed
goals, then they have to change. It is not our obligation to preserve
the world in its current perfection.

> The pre-cert serial number problem may be one aspect of the design that

The serial number is required to fulfil the purpose of CT. If you want
to not have serial numbers in the log, then we must also change the
revocation mechanisms.

---

From: Stephen Kent <[email-masked]>
Date: Sat, 05 Jul 2014 08:50:56 -0400

Ben,
> I guess we could specify that?
Ok, that's what _you_ do, but 5280 describes a long list of cert path 
validation rules
and your doc just says that these can be relaxed. It does not prohibit a 
log from
performing  the full set dictated by PKIX and X.509 path validation 
procedures, nor
does it provide guidance of which subset SHOULD/MUST be performed. 
Absent such guidance
different log operators can legitimately perform different checks, 
resulting in chaos.
> is MUST be included in the SCT.
If we had a agreed-upon  requirements doc that explained why the serial 
number is
critical, and if it discussed the impact on CAs that may use serial 
number management
techniques that preclude pre-determining the serial number assigned to a 
cert, then
we would be in good shape. But we don't. So, I think we may have a 
serious problem
with this aspect of the precert model.
> compatible with whatever restrictions their s/w imposes, we'd be happy
"Compliant" with what set of specs? I noted an aspect of a design for a 
CA-focused
HSM that, for several years, was used by VeriSign to issue every cert. 
It is a powerful
feature for high assurance cert issuance. It is also incompatible with 
the precert design.
The precert design seems to preclude use of some approaches to serial 
number management
that may reduce CA secruity. Thus it appears to be a tradeoff, one that 
this WG has not
discussed. Please describe what you mean by a "complaint" CA.
> the world in its current perfection.
Agreed goals? As I noted, this WG does not have a agreed-upon set of 
requirements.
We have an experimental RFC (that does not appear to have been carefully 
reviewed
prior to publication, not unreasonable for an experimental RFC, but ...) 
as a starting
point. The RFC identifies 3 different ways to convey SCTs. One of these 
appears to
be problematic. So, maybe it's time to discuss why there are three ways 
to deliver
SCTs, and why the precert method is critical.
> to not have serial numbers in the log, then we must also change the
I don't recall the doc mentioning revocation as a remediation mechanism. 
On this
list someone suggested that CT is a reputation mechanism, and one might 
infer that
the primary remediation mechanism is shaming CAs into submission. If we 
had an architecture
doc, not just a description of a set of mechanisms, we would not have to 
guess what
aspects of CT are critical and agreed upon by the WG (not just the 
document authors).

Steve

---

From: Carl Wallace <[email-masked]>
Date: Sat, 05 Jul 2014 14:34:57 -0400

From:  Stephen Kent <[email-masked]>
Date:  Saturday, July 5, 2014 at 8:50 AM
To:  Ben Laurie <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Trans] Using a Precertificate Signing Certificate to sign
TBScertificates for CT

>  
>      On 1 July 2014 18:34, Stephen Kent <[email-masked]>
><mailto:[email-masked]> wrote:
>          ...
>
>    Ok, that's what you do, but 5280 describes a long list of
>    cert path validation rules
>    and your doc just says that these can be relaxed. It does not
>    prohibit a log from

Seems easy enough to specify and justify the relaxed rules (signature
checking only) for this application but is it worth supporting the
highlighting of errors, like name constraint violations, to draw the
attention of log monitors?  An indication could probably be represented as
a CTExtension.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 7 Jul 2014 15:14:00 +0100

On 5 July 2014 13:50, Stephen Kent <[email-masked]> wrote:

>  Ben,
>
>  On 1 July 2014 18:34, Stephen Kent <[email-masked]> <[email-masked]> wrote:
>
>  Ben,
>
>  ...
>
>  Ok, that's what *you* do, but 5280 describes a long list of cert path
> validation rules
> does it provide guidance of which subset SHOULD/MUST be performed. Absent
> such guidance

I don't believe it will result in chaos, but anyway, the purpose of
checking signatures on log submissions is to combat spam. I don't think we
should tightly define exactly what checks are performed to that end,
because that's a great way to leave yourself unable to defend against some
kind of unforeseen spam. We can certainly clarify that. I've added a ticket.

> critical, and if it discussed the impact on CAs that may use serial number
> management
> we would be in good shape. But we don't. So, I think we may have a serious
> problem

The purpose of CT is to detect mis-issuance so that it can be rectified. As
already explained, some revocation mechanisms require the serial number of
the revoked cert. I don\t think we need a separate requirements doc for it
to be obvious that without the serial number, we have a problem.

> HSM that, for several years, was used by VeriSign to issue every cert. It
> is a powerful
> feature for high assurance cert issuance. It is also incompatible with the
> precert design.

I do not believe that the use of an HSM in any way constrains a CA's
ability to deal with serial numbers as needed. The issue of compliance is a
red herring.

> be problematic. So, maybe it's time to discuss why there are three ways to
> deliver

Precerts are critical because otherwise server s/w has to be updated to
deliver SCTs to clients. We know that isn't going to happen universally any
time soon. I agree the I-D should mention this.

>  I don't recall the doc mentioning revocation as a remediation mechanism.

The latest version does, though its pretty obvious - what do you think
remediation mechanisms are for mis-issuance in PKIX? Surely these are
already specified by existing RFCs?

I notice, BTW, we've slipped past the cutoff date without updating, which
is unfortunate.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 7 Jul 2014 15:14:59 +0100

> attention of log monitors?  An indication could probably be represented as

Seems to me that it would be better to share the rules for checking such
things (ideally as open source software) than to have people rely on third
parties to correctly flag...

---

From: Doug Beattie <[email-masked]>
Date: Mon, 7 Jul 2014 11:57:12 -0400

> parties to correctly flag...

I’m not connecting the logic from the last couple of emails.  We know that
path validation *cannot* follow PKIX and path validation procedures
 because when a Pre-certificate signing certificate is used the Issuer DN,
AIA and Auth Key ID will *all* not correctly point to the pre-certificate.

We need to change “may” to “must” in this parenthetical note in 3.1:

   “(note that the log may relax standard validation rules to allow this,
so long as the issued certificate will be valid),”

and we need to specify exactly which rules can be relaxed.

The use of pre-signing certificates is a good thing from a security
perspective.  It lets you off-load the external communications from you CA
and you can locate this in a different security zone in your infrastructure
with different security requirements.  Specifying how log operators handle
these chains is essential or the ability to obtain SCTs will vary from one
log operator to another.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 8 Jul 2014 16:54:34 +0100

On 7 July 2014 16:57, Doug Beattie <[email-masked]> wrote:
> path validation *cannot* follow PKIX and path validation procedures  because
> when a Pre-certificate signing certificate is used the Issuer DN, AIA and
> Auth Key ID will *all* not correctly point to the pre-certificate.
>
>
>    “(note that the log may relax standard validation rules to allow this, so
> long as the issued certificate will be valid),”
>

As I've said, any rules can be relaxed - inclusion in the log says
nothing about the validity of certificates. Clearly there are some
rules that MUST be relaxed, and I guess we can attempt to enumerate
them.

> these chains is essential or the ability to obtain SCTs will vary from one

I don't think we can make that impossible - for example, what is the
definitive set of CAs that all logs should accept?

---

From: Carl Wallace <[email-masked]>
Date: Tue, 08 Jul 2014 12:07:02 -0400

From:  Ben Laurie <[email-masked]>
Date:  Monday, July 7, 2014 at 10:14 AM
To:  Carl Wallace <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Trans] Using a Precertificate Signing Certificate to sign
TBScertificates for CT

> <snip>    Ok, that's what you do, but 5280 describes a long list of

I was not suggesting that the log be relied upon to do the check.  The point
was the log is in a position to observe when things have gone wrong across a
broad range of certs and highlighting these instances as a courtesy may be
worth doing.    Monitoring for names is probably sufficient to capture name
constraints violations of interest to a given monitor but drawing attention
to violations may cast some doubt on a CA's operations in general.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jul 2014 15:39:53 -0400

Ben,

> ... Ok, that's what _you_ do, but 5280 describes a long list of cert 
> path validation rules
>
>     performing  the full set dictated by PKIX and X.509 path
>     validation procedures, nor
> checking signatures on log submissions is to combat spam. I don't 
> think we should tightly define exactly what checks are performed to 
> that end, because that's a great way to leave yourself unable to 
> defend against some kind of unforeseen spam. We can certainly clarify 
> that. I've added a ticket.
Perhaps I have not been clear enough in specifying my concern. A CA (or 
cert Subject) submitting
a cert chain to a log needs to know, unambiguously, what checks will be 
performed. This specificity
is needed to ensure that submissions to multiple logs will all be 
accepted or rejected (assuming
that the root CA for the chain is advertised as acceptable by the log 
operator).
>
>     ...
>     If we had a agreed-upon  requirements doc that explained why the
>     serial number is
>     critical, and if it discussed the impact on CAs that may use
>     serial number management
>     techniques that preclude pre-determining the serial number
>     assigned to a cert, then
> The purpose of CT is to detect mis-issuance so that it can be 
> rectified. As already explained, some revocation mechanisms require 
> the serial number of the revoked cert. I don\t think we need a 
> separate requirements doc for it to be obvious that without the serial 
> number, we have a problem.
I think we do need a document that specifies what remediation mechanisms 
are required. I
saw no reference to revocation in the doc. Some list members have 
speculated that CT is
a reputation mechanism, and a recent response from you supported that 
notion. A reputation
mechanism need not make use of revocation as per X.509 mechanisms. For 
example, one might
have an auditor distribute a list of "bad" certs to clients, where the 
public key was the
means of identifying the bad cert. I agree that one remediation 
mechanism calls for the
issuing CA to put a detected, bad cert onto a CRL. But, that presumes 
that the mis-issuance
was an error or the result of an attack. Since there is no attack model 
for CT, I don't
know if that is the only sort of mis-issuance event it is supposed to 
counter.
>
>>     ...
>     "Compliant" with what set of specs? I noted an aspect of a design
>     for a CA-focused
>     HSM that, for several years, was used by VeriSign to issue every
>     cert. It is a powerful
>     feature for high assurance cert issuance. It is also incompatible
>     with the precert design.
>     The precert design seems to preclude use of some approaches to
>     serial number management
>     that may reduce CA secruity. Thus it appears to be a tradeoff, one
>     that this WG has not
> ability to deal with serial numbers as needed. The issue of compliance 
> is a red herring.
You introduced the term "complaint" into this issue, not me, so if it is 
a red herring, it's yours!
More to the point, I identified a legitimate way for HSMs to operate, to 
reduce the vulnerability
of a CA to the sort of attack that DigiNotar experienced. And, that 
model of operation has been
used by large CAs in the past. Your offhand dismissal of this issue is 
inappropriate. In essence
you are saying that Google has developed a rough model of how to make CT 
work and CAs need to
'make changes to their operational processes, and to software and maybe 
hardware, to accommodate
your model. This is an inappropriate mindset for working in the IETF.
>
>     ...
>
>
> Precerts are critical because otherwise server s/w has to be updated 
> to deliver SCTs to clients. We know that isn't going to happen 
> universally any time soon. I agree the I-D should mention this.
So, the designer have decided that it is appropriate to require CAs to 
change their software,
rather than asking server software developers to change theirs. I 
acknowledge that there are
more servers in operation than CAs, but that's not really the right 
metric. The issue is how
many sources of server software are used by the vast majority of 
servers. I'm guessing that
that number is small, especially compared to the number of CAs, many of 
which have had to
write all or most of their provisining software. This is a critical 
design decision that
ought to be articulated in the document, and agreed upon by the WG, not 
just the CT design team.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 28 Jul 2014 22:30:44 +0100

On 23/07/14 20:39, Stephen Kent wrote:
<snip>
> change their software, rather than asking server software developers
> to change theirs.

Actually, RFC6962 and 6962-bis do ask server software developers to 
change their software too.

> I acknowledge that there are more servers in operation than CAs, but
> that's not really the right metric. The issue is how many sources of
> server software are used by the vast majority of servers.

The vast majority of deployed servers are running old versions of the 
server software.  And in many cases, the server operators would find it 
very difficult to upgrade to the latest version even if they really, 
really wanted to.  e.g. Linux distros that still ship Apache httpd 2.2.x 
and not 2.4.x, and which are very unlikely to ship 2.6.x until N years 
after its initial release.

According to [1], the IETF's mission includes (emphasis mine):
   - Identifying, and proposing solutions to, _pressing_ operational and 
technical problems in the Internet.
   - Specifying the development or usage of protocols and the 
_near-term_ architecture to solve such technical problems for the Internet.

[1] http://www.ietf.org/tao.html

> I'm guessing that that number is small, especially compared to the
> number of CAs, many of which have had to write all or most of their
> provisining software.

Google can incentivize CAs to implement CT, simply by changing the rules 
for CAs that have trust anchors in Chrome.  Google have no such power 
over the server software authors or server software users, AFAICT.

The CAs that have written all or most of their provisioning software are 
the CAs that should find it easiest to add CT support to their 
platforms.  (It's only the CAs that use third-party CA software that 
aren't in control of this part of their own destiny).

I think it's clear that updating CA software is the only way we're 
likely to see CT deployed in the _near-term_.  Do you disagree?

> This  is a critical design decision that ought to be articulated in the
> document,  and agreed upon by the WG, not just the CT design team.

Well, if this WG is going to disagree with the very idea of 
Precertificates, then it would be nice to know sooner rather than later!

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