PreCertificates, how will that work in practice?

[Tomas Gustavsson]

Hi,

I didn't find any discussions about PreCertificates in the group to my surprise. The PreCertificates is something I'm a bit dubious about in the spec.

I wrote this at blog.ejbca.org, and really like to understand PreCertificate better...

-----

PreCertificates are defined in section "3.1. Log Entries" as (text trimed by me) "The Precertificate is constructed from the certificate to be issued by adding a special critical poison extension to the end-entity TBSCertificate". Then it describes how it can be produced and it is mentioned throughout the spec in many places.
A PreCertificate is a essentially a certificate signed with one of two options:

1. PreCertificates signed by the real CA.
This sounds very dangerous as will break the fundamental X.509 rule of unique issuerDN/serialNumber pairs. The consequences of having two "certificates" with the same issuerDN/serialNumber in the wild can not possibly be estimated, making this practice quite dangerous imho.

2. PreCertificates signed by a separate PreCertificate signing CA, which is a SubCA to the real signing CA. This is a less scary, since it is normal practice that different CAs can issue certificate with the same subjectDN/serialNumber, just not the same issuerDN.

The actual implementation of issuing PreCertificates makes it quite impractical. I would believe that most CA implementations creates the TBSCertificate as part of the actual certificate issuance. The CA will not create the TBSCertificate to have is lying around for a couple of days before using it to issue the real certificate.
Thus, if the CA is to create a PreCertificate to send to the CT log, it might as well issue the real certificate and send it to the log. The time difference should be in the milliseconds for most CAs.
If the CA wants to wait before distributing the real certificate, to make sure it's in the logs before put into production, it can surely do so as well.

The PreCertificate imho suffers from several complicating factors for implementers, both on the CA and the CT log side. The TBSCertificate must have a poison extension inserted, and removed, effectively re-encoding the ASN.1 TBSCertificate several times, all these are points of failure.

The reason for PreCertificates are not clearly explained. Why would you want to use PreCertificates?

Fine combing through the spec gives me some ideas on why, for example to be able to embed the Certificate extension from PreCertificate CT logs in the final certificate (section 3.3). But the the TBSCertificate of the PreCertificate is then no longer the real TBSCertificate? In that case, why is the PreCertificate the TBSCertificate at all, and not just a new data structure with the data the CT log wants?

The PreCertificate complicates the CT spec by orders of magnitude, which is not a good thing. There are so many ifs and buts about PreCertificate the RFC is not even itself consitent about what it is.

Ok, I know the PreCertificate is is optional, but the best standards, who gets fast, wide and robust deployment, are the simpler ones (KISS). Skipping PreCertificates from the CT spec makes it so much simpler.

My suggestion:
- Skip PreCertificates altogether

I see though why people will not accept that just because I say something...so in that case

- Explain the purpose behind PreCertificates well
- Describe what the actual information fro PreCertificate are used
- Be consistent throughout in the RFC

-----

Cheers,

Tomas

[Ben Laurie]

On 18 September 2013 10:15, Tomas Gustavsson <tomass...@gmail.com> wrote:
> Hi,
>
> I didn't find any discussions about PreCertificates in the group to my
> surprise. The PreCertificates is something I'm a bit dubious about in the
> spec.
>
> I wrote this at blog.ejbca.org, and really like to understand PreCertificate
> better...
>
> -----
> PreCertificates are defined in section "3.1. Log Entries" as (text trimed by
> me) "The Precertificate is constructed from the certificate to be issued by
> adding a special critical poison extension to the end-entity
> TBSCertificate". Then it describes how it can be produced and it is
> mentioned throughout the spec in many places.
> A PreCertificate is a essentially a certificate signed with one of two
> options:
>
> 1. PreCertificates signed by the real CA.
> This sounds very dangerous as will break the fundamental X.509 rule of
> unique issuerDN/serialNumber pairs. The consequences of having two
> "certificates" with the same issuerDN/serialNumber in the wild can not
> possibly be estimated, making this practice quite dangerous imho.

Two things:

1. The precertificate will also have the same SubjectDN/SANs, so the
consequences of duplication don't seem that bad, and...

2. The precertificate contains a critical extension that no verifier
should understand, and therefore will not verify.

>
> 2. PreCertificates signed by a separate PreCertificate signing CA, which is
> a SubCA to the real signing CA. This is a less scary, since it is normal
> practice that different CAs can issue certificate with the same
> subjectDN/serialNumber, just not the same issuerDN.
>
> The actual implementation of issuing PreCertificates makes it quite
> impractical. I would believe that most CA implementations creates the
> TBSCertificate as part of the actual certificate issuance. The CA will not
> create the TBSCertificate to have is lying around for a couple of days
> before using it to issue the real certificate.
> Thus, if the CA is to create a PreCertificate to send to the CT log, it
> might as well issue the real certificate and send it to the log. The time
> difference should be in the milliseconds for most CAs.

If you are issuing precertificates, its because you want to include an
SCT in the real certificate. Since the real certificate cannot be
issued until the SCT has been issued, you can't send the real
certificate to the log instead of the precertficate. This is exactly
why precertificates exist.

> If the CA wants to wait before distributing the real certificate, to make
> sure it's in the logs before put into production, it can surely do so as
> well.
>
> The PreCertificate imho suffers from several complicating factors for
> implementers, both on the CA and the CT log side. The TBSCertificate must
> have a poison extension inserted, and removed, effectively re-encoding the
> ASN.1 TBSCertificate several times, all these are points of failure.
>
> The reason for PreCertificates are not clearly explained. Why would you want
> to use PreCertificates?
>
> Fine combing through the spec gives me some ideas on why, for example to be
> able to embed the Certificate extension from PreCertificate CT logs in the
> final certificate (section 3.3). But the the TBSCertificate of the
> PreCertificate is then no longer the real TBSCertificate? In that case, why
> is the PreCertificate the TBSCertificate at all, and not just a new data
> structure with the data the CT log wants?

Because it seemed simpler, but if there's a different format that
really is better for people, we'd be happy to consider it.

> The PreCertificate complicates the CT spec by orders of magnitude, which is
> not a good thing. There are so many ifs and buts about PreCertificate the
> RFC is not even itself consitent about what it is.

I believe it is, but if there are inconsistencies, please point them
out and we'll correct them.

> Ok, I know the PreCertificate is is optional, but the best standards, who
> gets fast, wide and robust deployment, are the simpler ones (KISS). Skipping
> PreCertificates from the CT spec makes it so much simpler.
>
> My suggestion:
> - Skip PreCertificates altogether
>
> I see though why people will not accept that just because I say
> something...so in that case
>
> - Explain the purpose behind PreCertificates well
> - Describe what the actual information fro PreCertificate are used
> - Be consistent throughout in the RFC
> -----
>
> Cheers,
> Tomas
>

> --
> You received this message because you are subscribed to the Google Groups
> "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to certificate-transp...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Eran Messeri]

A few more points:

There's already Java API for sending certificates and precertificates to logs! This was done a while ago but I never got around to creating a patch for EJBCA.

I entirely agree with you that PreCertificates complicate the CT spec - it definitely made my head hurt on several occasions while implementing said Java API...

However, having PreCertificates makes deployment much easier: no need to modify any of the server software stack to support CT (compared to changes to Apache and OpenSSL needed to serve the SCT via the TLS handshake).

As for delay adding the certificate to the log: no need to wait for a couple of days: Logs are supposed to be highly-available, adding any cert to the log is meant to be immediate (hence the allowance of a merge delay window: The log can add the certificate to the merkle tree after providing a SCT for it).

Encoding and re-encoding certificates is a bit of a pain, but the code mentioned above does most of the work for you. The only bit missing is building a TBSCertificate that incorporates the CT extension with the SCT. If that's the only thing blocking EJBCA from supporting CT, I'll be happy to collaborate on that.

[Rob Stradling]

On 18/09/13 10:47, Eran Messeri wrote:
<snip>

> However, having PreCertificates makes deployment much easier: no need to
> modify any of the server software stack to support CT (compared to
> changes to Apache and OpenSSL needed to serve the SCT via the TLS
> handshake).

And since deployment is much easier, it'll hopefully happen much quicker!

The OCSP Stapling TLS Extension was defined over 10 years ago (in
RFC3546), but <20% [1] of deployed servers actually support it yet.
Support for OCSP Stapling only reached Firefox within the last few months.
The Secure Renegotiation TLS Extension has fared better (presumably
because it addresses a security vulnerability rather than adding an
optional protocol feature). After 4 years, it's now supported by ~80%
[2] of deployed servers.

At some point, CT-enabled browsers will presumably start blocking
connections (or downgrading the EV UI, or displaying a warning, or
whatever) when an SSL certificate is presented without an accompanying
SCT. When that time comes, we really need 100% of servers to have at
least one option available for sending SCTs!

If a CA supports PreCertificates, then that CA's customers will have at
least one option available for sending SCTs. Those customers won't even
need to worry about configuring any CT-related options on their webserver.

PreCertificates are a hack, but IMHO a necessary one if we're going to
see CT fully deployed before Ben retires. ;-)

One downside to PreCertificates is that we'll only achieve 100% coverage
any time soon if each and every CA supports PreCertificates, and my
guess is that some CAs will be unable and/or unwilling.
(I have a proposal to improve this situation, but I'll start another
thread...)


[1] In June 2013 I extracted all of the domains from all of the certs
that were then present in the CT Pilot Log. Then I scanned each
<domain>:443 to see how many sent a stapled OCSP response.

[2] https://www.trustworthyinternet.org/ssl-pulse/

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

[Tomas Gustavsson]

Thanks for the quick answers. Glad to hear it was approximately as I thought.

I agree that including the extensions in the certificate might be the quickest way to actually get CT in use.

I have a few suggestions how to make the spec better (imho of course).

Step 1:

1. Add a separate section, 3.1.1, explaining the PreCertificates and the different options. 

2. In this section describe why PreCertificates are needed. No need to read all through to the end to figure it out.

3. Describe that TBSCertificate is not _really_ the TBSCertificate of the finally issued certificate, it is just a convenient data structure.

4. Describe what information in the PreCertificate is actually required to be the same as in the finally issued certificate.

5. Add in Security Considerations the scary issuerDN/serialNumber equality.

Step 2 (wishful):

- I would prefer if the PreCertificate was it's own data structure that could not be confused with a real certificate.

- The PreCertificate could be signed by a PreCertificate Signer instead of a PreCertificate CA, like an OCSP signer but for PreCertificates. The delegation method is well known.

Inconsistencies for me are around the TBSCertificate. In 3.1 it describes the PreCertificate as the TBS of the certificate to be issued. But later on i 3.3 it describes how extra extensions are inserted into the certificate that is issued, so the PreCertificate is not at all the TBSCertificate to be issued. This should be clear (see my suggestion In Step 1-3 above).

Cheers,

Tomas

[Rob Stradling]

On 18/09/13 14:20, Tomas Gustavsson wrote:
<snip>

> 5. Add in Security Considerations the scary issuerDN/serialNumber equality.
>
> Step 2 (wishful):
> - I would prefer if the PreCertificate was it's own data structure that
> could not be confused with a real certificate.

Alternatively, could we avoid this confusion by simply changing the
first byte in the PreCertificate's TBSCertificate (always 0x30) to some
other value before computing the hash?

<snip>

> - The PreCertificate could be signed by a PreCertificate Signer instead
> of a PreCertificate CA, like an OCSP signer but for PreCertificates. The
> delegation method is well known.

Hmmm...the RFC doesn't say whether a "Precertificate Signing
Certificate" needs to contain basicConstraints:CA=TRUE and
keyUsage=keyCertSign, or not.

[Tomas Gustavsson]

On Wednesday, September 18, 2013 4:02:33 PM UTC+2, Rob Stradling wrote:

On 18/09/13 14:20, Tomas Gustavsson wrote:
<snip>
> 5. Add in Security Considerations the scary issuerDN/serialNumber equality.
>
> Step 2 (wishful):
> - I would prefer if the PreCertificate was it's own data structure that
> could not be confused with a real certificate.

Alternatively, could we avoid this confusion by simply changing the
first byte in the PreCertificate's TBSCertificate (always 0x30) to some
other value before computing the hash?

<snip>
> - The PreCertificate could be signed by a PreCertificate Signer instead
> of a PreCertificate CA, like an OCSP signer but for PreCertificates. The
> delegation method is well known.

Hmmm...the RFC doesn't say whether a "Precertificate Signing
Certificate" needs to contain basicConstraints:CA=TRUE and
keyUsage=keyCertSign, or not.

Hmm, Section 3.1:

"a special-purpose (CA:true, Extended Key Usage: Certificate Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing Certificate" 

[Rob Stradling]

On 18/09/13 15:10, Tomas Gustavsson wrote:
<snip>

> Hmmm...the RFC doesn't say whether a "Precertificate Signing
> Certificate" needs to contain basicConstraints:CA=TRUE and
> keyUsage=keyCertSign, or not.
>
>
> Hmm, Section 3.1:
> "a special-purpose (CA:true

Ooops, I missed that. Thanks.

Since a Precertificate is arguably not a Certificate, why don't we
require Precertificate Signing Certificates to contain...
basicConstraints: CA=TRUE
and
keyUsage: digitalSignature (keyCertSign MUST NOT be set)

RFC5280 says...
"4.2.1.9. Basic Constraints
...
This extension MAY appear as a critical or non-
critical extension in CA certificates that contain public keys used
exclusively for purposes other than validating digital signatures on
certificates. Such CA certificates include ones that contain public
keys used exclusively for validating digital signatures on CRLs and
ones that contain key management public keys used with certificate
enrollment protocols."
...and...
"4.2.1.3. Key Usage
...
The digitalSignature bit is asserted when the subject public key
is used for verifying digital signatures, other than signatures on
certificates (bit 5) and CRLs (bit 6), such as those used in an
entity authentication service, a data origin authentication
service, and/or an integrity service."

Would that solve the problem?

[Rob Stradling]

On 18/09/13 18:02, Emilia Kasper wrote:
<snip>
> 2. "Since a Precertificate is arguably not a Certificate, why don't we

> require Precertificate Signing Certificates to contain...
> basicConstraints: CA=TRUE
> and
> keyUsage: digitalSignature (keyCertSign MUST NOT be set)"
>

> I'm trying to wrap my head around what this achieves. What's the benefit
> of using the more generic digitalSignature key usage vs the CT-specific EKU?

I wasn't suggesting dropping the CT-specific EKU. Sorry if I wasn't clear.

The (small) benefit is that any certificate validating software that
deliberately or inadvertently fails to trip over the Critical
CT-specific EKU should hopefully trip over the lack of keyCertSign.

> I am also wondering whether "keyCertSign MUST NOT be set" is something
> that should be mandated by the CT log, or something that would be left
> up to CAs. Thoughts?

Let the CT log mandate it.

> 3. ""Alternatively, could we avoid this confusion by simply changing the

> first byte in the PreCertificate's TBSCertificate (always 0x30) to some
> other value before computing the hash?"
>

> This sounds like a hack with unforeseen consequences.

Fair enough.

> If reusing the TBS
> is an insurmountable problem then I would rather have a dedicated
> structure. Though I suspect it'll further complicate client code...

Let's hope that reusing the TBS won't be an insurmountable problem. :-)

> Cheers,
> Emilia

> --
> You received this message because you are subscribed to the Google
> Groups "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to

> certificate-transpa...@googlegroups.com
> <mailto:certificate-transparency%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to certificate-transp...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

[Emilia Kasper]

The only requirement Precertificate Signing Certificates have to fulfill for CT is to unambiguously bind the pre-cert to the final certificate and its issuer. For everything else - how to implement this safely, in a non-confusing way for clients and in compliance with CA policies and software - we are completely open to suggestions, and I'm glad to see this discussion!

I'll try to comment on a few points raised.

1. "The PreCertificate could be signed by a PreCertificate Signer instead of a PreCertificate CA, like an OCSP signer but for PreCertificates. The delegation method is well known."

I figured we should require CA:True because a) it is aligned with also allowing precertificates to be directly signed by CA certificates; and b) relying only on the EKU seemed brittle. OCSP is a somewhat different story - the PreCertificate Signing CA is effectively fulfilling CA functionality.

But then I am clueless when it comes to your (hypothetical) Precertificate Signing Certificate issuance process. Are there problems with this approach?

2. "Since a Precertificate is arguably not a Certificate, why don't we require Precertificate Signing Certificates to contain...

  basicConstraints: CA=TRUE
  and
  keyUsage: digitalSignature  (keyCertSign MUST NOT be set)"

I'm trying to wrap my head around what this achieves. What's the benefit of using the more generic digitalSignature key usage vs the CT-specific EKU?

I am also wondering whether "keyCertSign MUST NOT be set" is something that should be mandated by the CT log, or something that would be left up to CAs. Thoughts?

3. ""Alternatively, could we avoid this confusion by simply changing the first byte in the PreCertificate's TBSCertificate (always 0x30) to some other value before computing the hash?"

This sounds like a hack with unforeseen consequences. If reusing the TBS is an insurmountable problem then I would rather have a dedicated structure. Though I suspect it'll further complicate client code...

Cheers,

Emilia

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.

[Tomas Gustavsson]

On Wednesday, September 18, 2013 7:02:47 PM UTC+2, Emilia Kasper wrote:

The only requirement Precertificate Signing Certificates have to fulfill for CT is to unambiguously bind the pre-cert to the final certificate and its issuer. For everything else - how to implement this safely, in a non-confusing way for clients and in compliance with CA policies and software - we are completely open to suggestions, and I'm glad to see this discussion!

I'll try to comment on a few points raised.

1. "The PreCertificate could be signed by a PreCertificate Signer instead of a PreCertificate CA, like an OCSP signer but for PreCertificates. The delegation method is well known."

I figured we should require CA:True because a) it is aligned with also allowing precertificates to be directly signed by CA certificates; and b) relying only on the EKU seemed brittle. OCSP is a somewhat different story - the PreCertificate Signing CA is effectively fulfilling CA functionality.

But then I am clueless when it comes to your (hypothetical) Precertificate Signing Certificate issuance process. Are there problems with this approach?

Why not only have only one method to sign a PreCertificate? Let's say a PreCertificate signer certificate with {CA:False, KU:digitalSignature, EKU: CT}. Since the PreCertificate is not a certificate, let's not sign it with a CA.

Many audit and certification schemes requires the CA private key to _only_ be used for cert and CRL signing. I expect public SSL CAs to be among the CAs where some (many?) operates under these schemes.

Having multiple different options looks all nice and flexible, but often it just complicates things without much benefit. Especially when it's not really an option in most cases.

 

2. "Since a Precertificate is arguably not a Certificate, why don't we require Precertificate Signing Certificates to contain...

  basicConstraints: CA=TRUE
  and
  keyUsage: digitalSignature  (keyCertSign MUST NOT be set)"

I'm trying to wrap my head around what this achieves. What's the benefit of using the more generic digitalSignature key usage vs the CT-specific EKU?

I am also wondering whether "keyCertSign MUST NOT be set" is something that should be mandated by the CT log, or something that would be left up to CAs. Thoughts?

3. ""Alternatively, could we avoid this confusion by simply changing the first byte in the PreCertificate's TBSCertificate (always 0x30) to some other value before computing the hash?"

This sounds like a hack with unforeseen consequences. If reusing the TBS is an insurmountable problem then I would rather have a dedicated structure. Though I suspect it'll further complicate client code...

It's only the CT log that verifies PreCertificates right, the clients like browsers will not process PreCertificates. Since the CT log will be a special software anyhow, it's already pretty complex.

I'm also not in favor of changing only one byte on the TBS. If it's only the CA and CT log that sees the PreCertificate I don't think it's very complex with a new struct unless we invent a very complex structure.

I'm not totally against using the TBS any more though, if we fix the issues with the signing above...

Cheers,

Emilia

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsubscr...@googlegroups.com.

[Rob Stradling]

On 19/09/13 10:16, Tomas Gustavsson wrote:
<snip>

> Why not only have only one method to sign a PreCertificate? Let's say a
> PreCertificate signer certificate with {CA:False, KU:digitalSignature,
> EKU: CT}. Since the PreCertificate is not a certificate, let's not sign
> it with a CA.

I want to be able to sign PreCertificates using the CA Private Key. I
don't want the administrative hassle of having to issue PreCertificate
Signing Certificates for all of the many Intermediate CAs that we operate.

> Many audit and certification schemes requires the CA private key to
> _only_ be used for cert and CRL signing.

Which ones?

We already sign OCSP Responses using CA private keys too.

[Tomas Gustavsson]

On Thursday, September 19, 2013 2:07:00 PM UTC+2, Rob Stradling wrote:

On 19/09/13 10:16, Tomas Gustavsson wrote:
<snip>
> Why not only have only one method to sign a PreCertificate? Let's say a
> PreCertificate signer certificate with {CA:False, KU:digitalSignature,
> EKU: CT}. Since the PreCertificate is not a certificate, let's not sign
> it with a CA.

I want to be able to sign PreCertificates using the CA Private Key.  I
don't want the administrative hassle of having to issue PreCertificate
Signing Certificates for all of the many Intermediate CAs that we operate.

Ok, good with the CA perspective :-) Let's hope the PreCertificate will not be a "Certificate" then.

 

 

> Many audit and certification schemes requires the CA private key to
> _only_ be used for cert and CRL signing.

Which ones?

We already sign OCSP Responses using CA private keys too.

CWA14167-1 (I guess then also ETSI 101456?) says:

The key used to sign a QC SHOULD ONLY be used for signing QCs and, optionally, the related

Revocation Status Data.

So OCSP is ok of course. Anyhow, these standard does not (currently) extend to SSL certificates, so I was a bit hasty, unless there is something similar for SSL (I guess not). 

(In the new proposed EU regulation there is also "Qualified Web Server Certificates", but I don't understand that concept so I don't want to touch that issue).

[Rob Stradling]

On 18/09/13 11:39, Rob Stradling wrote:
<snip>

> One downside to PreCertificates is that we'll only achieve 100% coverage
> any time soon if each and every CA supports PreCertificates, and my
> guess is that some CAs will be unable and/or unwilling.
> (I have a proposal to improve this situation, but I'll start another
> thread...)

I've already run this idea past Ben, and he thinks it sounds like it
should work. What do other folks think?

1. CA X issues a publicly-trusted certificate (C1).

2. Somebody adds C1 to a CT Log and so SCT(C1) is generated.

3. CA Y issues a publicly-trusted certificate (C2, the
"PostCertificate") that contains C1 and SCT(C1) in certificate
extensions. The Subject, Subject Public Key Infos, validity periods,
Subject Key Identifiers, Basic Constraints, Key Usage bits and EKU OIDs
(and probably some other fields too) of C1 and C2 must exactly match.
Assuming CA Y != CA X, C2 must also contain the Intermediate(s) that
chain C1 up to a Trusted Root Certificate.

4. In each TLS handshake, the TLS Server sends C2 plus whatever
Intermediates are required to chain C2 up to a Trusted Root Certificate.

5a. CT-aware clients spot C1 inside C2, verify that all of the relevant
fields in C1 and C2 match, and verify that SCT(C1) is valid. Any
Intermediate(s) inside C2 are extracted, and then C2 is discarded. The
client then proceeds as if the TLS Server had sent SCT(C1), C1 and the
Intermediate(s) to chain C1 up to a Trusted Root Certificate.
5b. CT-unaware clients simply see C2 plus the Intermediate(s) to chain
C2 up to a Trusted Root Certificate.

From the point-of-view of protecting CT-aware clients, C2 never needs
to be logged by CT. However, Ben reminded me that "Part of the point of
CT is that it provides herd immunity, and I'm very reluctant to remove
that part". Therefore, SCT(C2) would also need to be presented to
browsers, and the most obvious way to do that would be for C2 to also be
a PreCertificate.

For PostCertificates to be viable, I think CAs offering
PostCertification services would need to do so for free or at minimal
cost. Since CA X has already performed the necessary validation, IMHO
it would be reasonable to allow CA Y to 100% automate the production of
PostCertificates - just as long as CA Y checks that C1 chains to a
Trusted Root Certificate and hasn't at that time been revoked. (There
would need to be updates to browser root program requirements, CABForum
requirements and audit criteria in order to allow this).

So, in conclusion, what would PostCertificates achieve? Well, if just 1
CA offers a PostCertification service, then _every_ customer of _every_
CA would have at least 1 option for getting SCTs to browsers that
doesn't require any updates to webserver software. And I think this
would hasten the day when CT-aware browsers can start blocking
connections when no SCT is provided.

[Brad Hill]

1. For a CA that wants to give the issued certificate to the client immediately, it really doesn't do anything to address the complaints that CT is in the middle of the issuance process. It still is if you expect C2 to be the one that the customer eventually receives.  (C1 will be useless as more and more browsers require SCTs)

3. If we allow CA X != CA Y, you might be able to move the market, but this requires a great deal of sophistication and agency on the part of the customer.  Why wouldn't a customer prepared to get C2 from a different CA just go to to that issuer to begin with?  I question if this incentive would ever actually be exercised.

2. This more than doubles the size of the certificate the customer has to present, instead of just adding the incremental size of the SCT extension.  For 2048 bit RSA keys, this is pretty undesirable as you're then quite likely to overflow even a larger-than-normal ICW and add a RT to the TLS handshake.

-Brad Hill

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.

[Rob Stradling]

Thanks for your comments, Brad. Replies inline...

On 20/09/13 17:58, Brad Hill wrote:
>
> 1. For a CA that wants to give the issued certificate to the client
> immediately, it really doesn't do anything to address the complaints
> that CT is in the middle of the issuance process. It still is if you
> expect C2 to be the one that the customer eventually receives. (C1 will
> be useless as more and more browsers require SCTs)

Agreed. This idea doesn't attempt to address the "in the middle of the
issuance process" concerns.

> 3. If we allow CA X != CA Y, you might be able to move the market, but
> this requires a great deal of sophistication and agency on the part of
> the customer. Why wouldn't a customer prepared to get C2 from a
> different CA just go to to that issuer to begin with? I question if
> this incentive would ever actually be exercised.

Yes, some customers probably would go straight to a different CA, but
others might not (e.g. various governments who operate a Root CA and
issue certs to themselves).

> 2. This more than doubles the size of the certificate the customer has
> to present, instead of just adding the incremental size of the SCT
> extension. For 2048 bit RSA keys, this is pretty undesirable as you're
> then quite likely to overflow even a larger-than-normal ICW and add a RT
> to the TLS handshake.

C1 plus Intermediate(s) could be compressed inside C2. Since most of
the fields in C1 and C2 must match, the results should be fairly good.

I think it's unlikely that PostCertificates would be anyone's first
choice for an SCT distribution mechanism. But that's fine, since the
whole point of the idea is to provide a mechanism where none of the
other mechanisms would be available.

<snip>

[Rob Stradling]

On 18/09/13 10:15, Tomas Gustavsson wrote:
<snip>

> 1. PreCertificates signed by the real CA.
> This sounds very dangerous as will break the fundamental X.509 rule of
> unique issuerDN/serialNumber pairs. The consequences of having two
> "certificates" with the same issuerDN/serialNumber in the wild can not
> possibly be estimated, making this practice quite dangerous imho.

The CABForum BRs Appendix B (4) says:
"All other fields and extensions MUST be set in accordance with RFC 5280."
Although the title of Appendix B is "Certificate Extensions", I think
"fields and extensions" must surely imply that "fields" are the
non-extension parts of a certificate (such as the serial number).
And since certificate serial numbers are not explicitly mentioned in
Appendix B, I conclude that certificate serial numbers "MUST be set in
accordance with RFC 5280".
RFC 5280 Section 4.1.2.2 says:
"The serial number...MUST be unique for each certificate issued by a
given CA".

I therefore have to conclude that CT Precertificates "signed by the real
CA" are currently _illegal_ under the BRs. Given that the
publicly-trusted CAs MUST follow the BRs, this is a problem (for CAs
that would want to use this option for Precertificates).

I've been discussing this with Ben over the last few days, and we've
come up with 2 possible ways forward...

1. Try to persuade the CABForum to update the BRs so that a
Precertificate/Certificate are permitted to share the same serial
number. (CABForum isn't afraid to break compatibility with RFC5280 when
it wants to: the BRs permit non-critical Name Constraints and prohibit
OCSP "good" for "non-issued certificates", for example).

2. In RFC6962-bis, allow the certificate serial numbers of a
Precertificate/Certificate to be either:
a. identical (as per RFC6962), or...
b. consecutive (i.e. if the Precertificate Serial Number = X, then
the Certificate Serial Number = X+1).
- CAs would obviously need to make sure that both X and X+1 have
not been used as serial numbers in any previously issued certificates
(and if they have, then choose a different value for X!)
- Both the Precertificate and the Certificate would need to contain
a flag to signal that option 2b has been used. (This could be achieved
without increasing the size of either cert by simply using different
OIDs for the Poison and SCT List extensions).

Option 1 seems preferable, but option 2 wouldn't be a big deal.

Any comments?

[Erwann Abalea]

Le vendredi 15 novembre 2013 23:30:06 UTC+1, Rob Stradling a écrit :

On 18/09/13 10:15, Tomas Gustavsson wrote:
<snip>
> 1. PreCertificates signed by the real CA.
> This sounds very dangerous as will break the fundamental X.509 rule of
> unique issuerDN/serialNumber pairs. The consequences of having two
> "certificates" with the same issuerDN/serialNumber in the wild can not
> possibly be estimated, making this practice quite dangerous imho.

The CABForum BRs Appendix B (4) says:
"All other fields and extensions MUST be set in accordance with RFC 5280."
Although the title of Appendix B is "Certificate Extensions", I think
"fields and extensions" must surely imply that "fields" are the
non-extension parts of a certificate (such as the serial number).
And since certificate serial numbers are not explicitly mentioned in
Appendix B, I conclude that certificate serial numbers "MUST be set in
accordance with RFC 5280".
RFC 5280 Section 4.1.2.2 says:
"The serial number...MUST be unique for each certificate issued by a
given CA".

I therefore have to conclude that CT Precertificates "signed by the real
CA" are currently _illegal_ under the BRs.  Given that the
publicly-trusted CAs MUST follow the BRs, this is a problem (for CAs
that would want to use this option for Precertificates).

 

That unicity comes from X.509 itself:

- page 4, definition of the certificate serial number: "An integer value, unique within the issuing authority, which is unambiguously associated with a certificate issued by that authority."

- page 13, description of the elements composing a certificate: "serialNumber is an integer assigned by the CA to each certificate. The value of serialNumber shall be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate)."

RFC5280 couldn't have changed it.

I've been discussing this with Ben over the last few days, and we've
come up with 2 possible ways forward...

1. Try to persuade the CABForum to update the BRs so that a
Precertificate/Certificate are permitted to share the same serial
number.  (CABForum isn't afraid to break compatibility with RFC5280 when
it wants to: the BRs permit non-critical Name Constraints and prohibit
OCSP "good" for "non-issued certificates", for example).

That didn't break X.509 (this extension is either critical or non critical, at the option of the certificate issuer).

 

2. In RFC6962-bis, allow the certificate serial numbers of a
Precertificate/Certificate to be either:
   a. identical (as per RFC6962), or...
   b. consecutive (i.e. if the Precertificate Serial Number = X, then
the Certificate Serial Number = X+1).
     - CAs would obviously need to make sure that both X and X+1 have
not been used as serial numbers in any previously issued certificates
(and if they have, then choose a different value for X!)
     - Both the Precertificate and the Certificate would need to contain
a flag to signal that option 2b has been used.  (This could be achieved
without increasing the size of either cert by simply using different
OIDs for the Poison and SCT List extensions).

Option 1 seems preferable, but option 2 wouldn't be a big deal.

I'm really not in favor of option 1.

How about an option 3 that uses something other than a certificate structure for the "precert" role? IIRC, the certificate format was chosen because it's convenient.

[Tomas Gustavsson]

From an implementation perspective.

- I can live with option 1, implementation wise. From a lot of views it looks dangerous though (audit, CABForum etc). It sounds like a gamble for the future.

- Option 2 sounds very dangerous and costly implementation wise. There are probably a large range of different implementations for ensuring unique serial numbers. Introducing a second unique serial will have consequences nobody can foresee.

- Option 3 is a little more work to implement, but not a lot. This really looks like the safest option IMHO. Very few unforeseen consequences, and implementing a small asn.1 structure is not very hard.

Cheers,
Tomas

[Ben Laurie]

The danger is notional: the two certificates are essentially identical.

> - Option 2 sounds very dangerous and costly implementation wise. There are
> probably a large range of different implementations for ensuring unique
> serial numbers. Introducing a second unique serial will have consequences
> nobody can foresee.

Surely at least some implementations can handle this easily.

> - Option 3 is a little more work to implement, but not a lot. This really
> looks like the safest option IMHO. Very few unforeseen consequences, and
> implementing a small asn.1 structure is not very hard.

If there is any CA who is going to deploy CT that wants to use this
option, I will happily add it to the spec.

Note that if you issue the Precertificate from an intermediate instead
of directly (as is permitted by RFC 6962), this becomes a non-problem.

[Rob Stradling]

On 17/11/13 16:48, Erwann Abalea wrote:
<snip>

> That unicity comes from X.509 itself:
> - page 4, definition of the certificate serial number: "An integer
> value, unique within the issuing authority, which is unambiguously
> associated with a certificate issued by that authority."
> - page 13, description of the elements composing a certificate:
> "serialNumber is an integer assigned by the CA to each certificate. The
> value of serialNumber shall be unique for each certificate issued by a
> given CA (i.e., the issuer name and serial number identify a unique
> certificate)."
>
> RFC5280 couldn't have changed it.

Even though RFC5280 only cites X.509 as an Informative (not Normative)
reference? ;-)

<snip>

> I'm really not in favor of option 1.
> How about an option 3 that uses something other than a certificate
> structure for the "precert" role? IIRC, the certificate format was
> chosen because it's convenient.

Yes, it's very convenient. I wrote our code for generating
Precertificate tbsCertificates the other day. Pretty much all I had to
do was add an "add poison extension" flag to our existing Certificate
tbsCertificate generation code. Easy!

[Rob Stradling]

On 18/11/13 11:28, Ben Laurie wrote:
> On 18 November 2013 08:48, Tomas Gustavsson <tomass...@gmail.com> wrote:

<snip>

>> - Option 2 sounds very dangerous and costly implementation wise. There are
>> probably a large range of different implementations for ensuring unique
>> serial numbers. Introducing a second unique serial will have consequences
>> nobody can foresee.
>
> Surely at least some implementations can handle this easily.

Yes.

>> - Option 3 is a little more work to implement, but not a lot. This really
>> looks like the safest option IMHO. Very few unforeseen consequences, and
>> implementing a small asn.1 structure is not very hard.
>
> If there is any CA who is going to deploy CT that wants to use this
> option, I will happily add it to the spec.

How about Option 4...

Precert Serial Number = Cert Serial Number || 0x4354
(that's "CT" in hex)

Some CAs are already using 20 octet Serial Numbers, so this option
wouldn't work for them (because RFC5280 specifies a maximum length of 20
octets).

But many CAs use a fixed number of octets for their Serial Numbers,
which is always <=18. For those CAs, appending 0x4354 (to give a
different fixed number of octets <=20) would ensure uniqueness.

[Tomas Gustavsson]

<snip>

They are certainly not identical according to the current RFC. Lets have well defined text with no ambiguities in the spec and no vague "essentially identical". In the current RFC the PreCertificates are described inconsistently and ambiguously. 

As I said though, I'm all for it if:

1. The RFC is updated with unambiguous and consistent language

2. The CAs, CA/B Forum and auditors agree there is no issue (If Rod casts doubts relating to BRs I have no choice than to also doubt and consider it adventurous).

 

> - Option 2 sounds very dangerous and costly implementation wise. There are
> probably a large range of different implementations for ensuring unique
> serial numbers. Introducing a second unique serial will have consequences
> nobody can foresee.

Surely at least some implementations can handle this easily.

I'll assume this was just a generic comment and not a support for how this option should go into the spec.

Any standards attempt who is based on "I know one implementation who can do this and I don't care about the other 50" should be banned from standards.

> - Option 3 is a little more work to implement, but not a lot. This really
> looks like the safest option IMHO. Very few unforeseen consequences, and
> implementing a small asn.1 structure is not very hard.

If there is any CA who is going to deploy CT that wants to use this
option, I will happily add it to the spec.

I would assume that whatever CT specifies is what will be used. I would expect there to be _either_  option 1 or option 3 in the spec, not both. Both would be very smelly imho.

[Ben Laurie]

Have I missed something? What is ambiguous and inconsistent?

> 2. The CAs, CA/B Forum and auditors agree there is no issue (If Rod casts
> doubts relating to BRs I have no choice than to also doubt and consider it
> adventurous).
>
>>
>>
>> > - Option 2 sounds very dangerous and costly implementation wise. There
>> > are
>> > probably a large range of different implementations for ensuring unique
>> > serial numbers. Introducing a second unique serial will have
>> > consequences
>> > nobody can foresee.
>>
>> Surely at least some implementations can handle this easily.
>
>
> I'll assume this was just a generic comment and not a support for how this
> option should go into the spec.
> Any standards attempt who is based on "I know one implementation who can do
> this and I don't care about the other 50" should be banned from standards.

As I said earlier, the RFC has another option, that is, issue the
Precertificate from an intermediate.

>> > - Option 3 is a little more work to implement, but not a lot. This
>> > really
>> > looks like the safest option IMHO. Very few unforeseen consequences, and
>> > implementing a small asn.1 structure is not very hard.
>>
>> If there is any CA who is going to deploy CT that wants to use this
>> option, I will happily add it to the spec.
>
>
> I would assume that whatever CT specifies is what will be used. I would
> expect there to be _either_ option 1 or option 3 in the spec, not both.
> Both would be very smelly imho.

What matters is what helps CAs to implement CT, not your sense of smell.

>> Note that if you issue the Precertificate from an intermediate instead
>> of directly (as is permitted by RFC 6962), this becomes a non-problem.
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to certificate-transp...@googlegroups.com.

[Tomas Gustavsson]

> 1. The RFC is updated with unambiguous and consistent language 

Have I missed something? What is ambiguous and inconsistent?

This was actualyl what I tried to explain starting this thread :-)

I also created this:

https://code.google.com/p/certificate-transparency/issues/detail?id=18

I realize it's might be not bullet point clear so I'll give it a try:

- PreCertificates are introduced in the spec without explaining why they are there, You have to read through up and down a couple of times to figure it out.

  Explain in the beginning, when introducing it, why we need a PreCertificates.

- If is claimed in the beginning that the PreCertificate is the actual TBSCertificate of the certificate to be signed. This is not true, since more stuff is added to the real certificate afterwards.

  Describe the PreCertificate as using the TBSStructure for simplicity (as it could actually be any structure).

  Describe what is the actual data that is critical in the PreCertificate, so it is clear what can be added later and what can not be.

 

(I added the bullet point to the issue as well).

> 2. The CAs, CA/B Forum and auditors agree there is no issue (If Rod casts
> doubts relating to BRs I have no choice than to also doubt and consider it
> adventurous).
>
>>
>>
>> > - Option 2 sounds very dangerous and costly implementation wise. There
>> > are
>> > probably a large range of different implementations for ensuring unique
>> > serial numbers. Introducing a second unique serial will have
>> > consequences
>> > nobody can foresee.
>>
>> Surely at least some implementations can handle this easily.
>
>
> I'll assume this was just a generic comment and not a support for how this
> option should go into the spec.
> Any standards attempt who is based on "I know one implementation who can do
> this and I don't care about the other 50" should be banned from standards.

As I said earlier, the RFC has another option, that is, issue the
Precertificate from an intermediate.

Yes, that's fine. Then we don't need to other options do we?

 

>> > - Option 3 is a little more work to implement, but not a lot. This
>> > really
>> > looks like the safest option IMHO. Very few unforeseen consequences, and
>> > implementing a small asn.1 structure is not very hard.
>>
>> If there is any CA who is going to deploy CT that wants to use this
>> option, I will happily add it to the spec.
>
>
> I would assume that whatever CT specifies is what will be used. I would
> expect there to be _either_  option 1 or option 3 in the spec, not both.
> Both would be very smelly imho.

What matters is what helps CAs to implement CT, not your sense of smell.

You are correct of course. I'm am just judging from my experience working with many RFCs. When options starts to swell up, interoperability and costs (overall costs not my costs) skyrocket. And interoperability usually becomes a case-by-case thing requiring testing with all implementations in existance. This in contrast to what you are hoping for, that interoperability comes from the standard, which is only the case for the simplest of standard, with few options.

Too many options don't help, it hurts. That's my experience. We need the exact right amount of options no more and no less ;-)

[Tomas Gustavsson]

> 1. The RFC is updated with unambiguous and consistent language 

Have I missed something? What is ambiguous and inconsistent?

This was actualyl what I tried to explain starting this thread :-)

I also created this:

https://code.google.com/p/certificate-transparency/issues/detail?id=18

I realize it's might be not bullet point clear so I'll give it a try:

- PreCertificates are introduced in the spec without explaining why they are there, You have to read through up and down a couple of times to figure it out.

  Explain in the beginning, when introducing it, why we need a PreCertificates.

- If is claimed in the beginning that the PreCertificate is the actual TBSCertificate of the certificate to be signed. This is not true, since more stuff is added to the real certificate afterwards.

  Describe the PreCertificate as using the TBSStructure for simplicity (as it could actually be any structure).

  Describe what is the actual data that is critical in the PreCertificate, so it is clear what can be added later and what can not be.

 

(I added the bullet point to the issue as well).

> 2. The CAs, CA/B Forum and auditors agree there is no issue (If Rod casts
> doubts relating to BRs I have no choice than to also doubt and consider it
> adventurous).
>
>>
>>
>> > - Option 2 sounds very dangerous and costly implementation wise. There
>> > are
>> > probably a large range of different implementations for ensuring unique
>> > serial numbers. Introducing a second unique serial will have
>> > consequences
>> > nobody can foresee.
>>
>> Surely at least some implementations can handle this easily.
>
>
> I'll assume this was just a generic comment and not a support for how this
> option should go into the spec.
> Any standards attempt who is based on "I know one implementation who can do
> this and I don't care about the other 50" should be banned from standards.

As I said earlier, the RFC has another option, that is, issue the
Precertificate from an intermediate.

Yes, that's fine. Then we don't need to other options do we?

 

>> > - Option 3 is a little more work to implement, but not a lot. This
>> > really
>> > looks like the safest option IMHO. Very few unforeseen consequences, and
>> > implementing a small asn.1 structure is not very hard.
>>
>> If there is any CA who is going to deploy CT that wants to use this
>> option, I will happily add it to the spec.
>
>
> I would assume that whatever CT specifies is what will be used. I would
> expect there to be _either_  option 1 or option 3 in the spec, not both.
> Both would be very smelly imho.

What matters is what helps CAs to implement CT, not your sense of smell.

You are correct of course. I'm am just judging from my experience working with many RFCs. When options starts to swell up, interoperability and costs (overall costs not my costs) skyrocket. And interoperability usually becomes a case-by-case thing requiring testing with all implementations in existance. This in contrast to what you are hoping for, that interoperability comes from the standard, which is only the case for the simplest of standard, with few options.

Too many options don't help, it hurts. That's my experience. We need the exact right amount of options no more and no less ;-)

[Tomas Gustavsson]

But of course, I didn't mean to be dismissive (right word?).

I'm actually all for lining up the different options and then deciding what to include, based on all CAs preferences. I'll just toss in my implementation based comments on the fire...

Cheers,

Tomas

--

You received this message because you are subscribed to a topic in the Google Groups "certificate-transparency" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/certificate-transparency/1tWzSXKe3gQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to certificate-transp...@googlegroups.com.

[Ben Laurie]

On 18 November 2013 12:55, Tomas Gustavsson <tomass...@gmail.com> wrote:
>> 1. The RFC is updated with unambiguous and consistent language
>>
>>
>> Have I missed something? What is ambiguous and inconsistent?
>>
>
> This was actualyl what I tried to explain starting this thread :-)
> I also created this:
> https://code.google.com/p/certificate-transparency/issues/detail?id=18
>
> I realize it's might be not bullet point clear so I'll give it a try:
> - PreCertificates are introduced in the spec without explaining why they are
> there, You have to read through up and down a couple of times to figure it
> out.
> Explain in the beginning, when introducing it, why we need a
> PreCertificates.
> - If is claimed in the beginning that the PreCertificate is the actual
> TBSCertificate of the certificate to be signed. This is not true, since more
> stuff is added to the real certificate afterwards.
> Describe the PreCertificate as using the TBSStructure for simplicity (as
> it could actually be any structure).

Thanks for these, all reasonable points.

> Describe what is the actual data that is critical in the PreCertificate,
> so it is clear what can be added later and what can not be.

Our position is that it is all critical. If there are reasons to
remove/change any part, then we'd need to talk about it.

We heard from some CAs that they'd like to not use the intermediate.
We introduced the intermediate in the first place because of exactly
the serial number issue (because some s/w will not issue the same
serial twice).

>
>>
>>
>> >> > - Option 3 is a little more work to implement, but not a lot. This
>> >> > really
>> >> > looks like the safest option IMHO. Very few unforeseen consequences,
>> >> > and
>> >> > implementing a small asn.1 structure is not very hard.
>> >>
>> >> If there is any CA who is going to deploy CT that wants to use this
>> >> option, I will happily add it to the spec.
>> >
>> >
>> > I would assume that whatever CT specifies is what will be used. I would
>> > expect there to be _either_ option 1 or option 3 in the spec, not both.
>> > Both would be very smelly imho.
>>
>> What matters is what helps CAs to implement CT, not your sense of smell.
>
>
> You are correct of course. I'm am just judging from my experience working
> with many RFCs. When options starts to swell up, interoperability and costs
> (overall costs not my costs) skyrocket. And interoperability usually becomes
> a case-by-case thing requiring testing with all implementations in
> existance. This in contrast to what you are hoping for, that
> interoperability comes from the standard, which is only the case for the
> simplest of standard, with few options.
>
> Too many options don't help, it hurts. That's my experience. We need the
> exact right amount of options no more and no less ;-)

Agreed. But its difficult to know what the exact right amount is until
we've got more experience. This is exactly why we decided to release
an experimental RFC early.

>> >> Note that if you issue the Precertificate from an intermediate instead
>> >> of directly (as is permitted by RFC 6962), this becomes a non-problem.
>

[Ben Laurie]

On 18 November 2013 13:07, Tomas Gustavsson <tomass...@gmail.com> wrote:
> But of course, I didn't mean to be dismissive (right word?).
>
> I'm actually all for lining up the different options and then deciding what
> to include, based on all CAs preferences. I'll just toss in my
> implementation based comments on the fire...

Great, thanks.

For EJBCA, I'd suggest using the intermediate CA, since that path does
not violate BRs. Is there a problem with doing that?

BTW, I read your blog post, which still suggests skipping Precerts,
but surely that's not actually your position? Without Precerts, SCTs
cannot be included in certs...

> You received this message because you are subscribed to the Google Groups
> "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Rob Stradling]

On 18/11/13 12:07, Rob Stradling wrote:
<snip>

>> If there is any CA who is going to deploy CT that wants to use this
>> option, I will happily add it to the spec.
>
> How about Option 4...
>
> Precert Serial Number = Cert Serial Number || 0x4354
> (that's "CT" in hex)
>
> Some CAs are already using 20 octet Serial Numbers, so this option
> wouldn't work for them (because RFC5280 specifies a maximum length of 20
> octets).
>
> But many CAs use a fixed number of octets for their Serial Numbers,
> which is always <=18. For those CAs, appending 0x4354 (to give a
> different fixed number of octets <=20) would ensure uniqueness.

Additionally, how about Option 4b, for CAs that always use a fixed
number of octets >18 for their Cert Serial Numbers...

Cut off the last 2 octets of the Cert Serial Number to produce the
Precert Serial Number. What are the chances of an accidental collision
in >=16 random bytes?

[Ben Laurie]

The problem with this is that monitors need to be able to specify a
serial number for a certificate so it can be revoked.

But why would an SN > 20 octets be a problem for a Precertificate?

[Rob Stradling]

Doh, I keep forgetting that!

Option 4 (not 4b) could work though, right?

> But why would an SN > 20 octets be a problem for a Precertificate?

>20 is an RFC5280 violation. Existing software may or may not care
about that. However, current audit regimes and browser policies
presumably do care, because Precertificates (as currently defined) are
publicly trusted X.509v3 certificates.

[Ben Laurie]

On 18 November 2013 14:05, Ben Laurie <be...@google.com> wrote:
>> I realize it's might be not bullet point clear so I'll give it a try:
>> - PreCertificates are introduced in the spec without explaining why they are
>> there, You have to read through up and down a couple of times to figure it
>> out.
>> Explain in the beginning, when introducing it, why we need a
>> PreCertificates.
>> - If is claimed in the beginning that the PreCertificate is the actual
>> TBSCertificate of the certificate to be signed. This is not true, since more
>> stuff is added to the real certificate afterwards.
>> Describe the PreCertificate as using the TBSStructure for simplicity (as
>> it could actually be any structure).
>
> Thanks for these, all reasonable points.

I've tweaked the language to deal with these, see the change here:
https://codereview.appspot.com/28410043.

What do you think?

[Ben Laurie]

Yes, though, of course, it doesn't guarantee no collisions.

>> But why would an SN > 20 octets be a problem for a Precertificate?
>
>
> >20 is an RFC5280 violation. Existing software may or may not care about
> that. However, current audit regimes and browser policies presumably do
> care, because Precertificates (as currently defined) are publicly trusted
> X.509v3 certificates.

Since we're looking for an option that doesn't involve changing the
BRs, I guess I have to agree with this.

[Rob Stradling]

On 18/11/13 14:33, Ben Laurie wrote:
> On 18 November 2013 14:29, Rob Stradling <rob.st...@comodo.com> wrote:

<snip>

>>>>> How about Option 4...
>>>>>
>>>>> Precert Serial Number = Cert Serial Number || 0x4354
>>>>> (that's "CT" in hex)
>>>>>
>>>>> Some CAs are already using 20 octet Serial Numbers, so this option
>>>>> wouldn't work for them (because RFC5280 specifies a maximum length of 20
>>>>> octets).
>>>>>
>>>>> But many CAs use a fixed number of octets for their Serial Numbers,
>>>>> which is always <=18. For those CAs, appending 0x4354 (to give a
>>>>> different fixed number of octets <=20) would ensure uniqueness.

<snip>

>> Option 4 (not 4b) could work though, right?
>
> Yes, though, of course, it doesn't guarantee no collisions.

Yes it does, when used correctly.

A 16-octet Serial Number (for example) _cannot_ collide with an 18-octet
Serial Number!
If a CA is certain that every Certificate Serial Number they generate
has a length of exactly 16-octets, then they would be able to use this
option safely without adding any extra code to check the uniqueness of
serial numbers.
But if a CA generates Serial Numbers that are 14-, 15- or 16-octets,
then that wouldn't be the case, because a 14+"CT"-octet Precert serial
number might clash with a 16-octet Cert serial number.

It would be nice to have 1 option that suits everybody, but it's looking
like this isn't going to happen. So, as Tomas said...

"I'm actually all for lining up the different options and then deciding
what to include, based on all CAs preferences."

[Tomas Gustavsson]

On Mon, Nov 18, 2013 at 3:10 PM, Ben Laurie <be...@google.com> wrote:

On 18 November 2013 13:07, Tomas Gustavsson <tomass...@gmail.com> wrote:
> But of course, I didn't mean to be dismissive (right word?).
>
> I'm actually all for lining up the different options and then deciding what
> to include, based on all CAs preferences. I'll just toss in my
> implementation based comments on the fire...

Great, thanks.

For EJBCA, I'd suggest using the intermediate CA, since that path does
not violate BRs. Is there a problem with doing that?

I don't think so. Thanks, will add that suggestion to our implementation notes (for upcoming impl).

 

BTW, I read your blog post, which still suggests skipping Precerts,
but surely that's not actually your position? Without Precerts, SCTs
cannot be included in certs...

Right. I'm not 100% convinced SCTs are the savior of the world yet :-) But my initial doubts have been dampened. I had put two "Update" notes in the beginning pointing to this discussion. I added a third pointing out that the blog post was an initial impression, and that anyone reading should go to this thread to get updated.

 

<snip>

[Tomas Gustavsson]

Yes, much improved, really. Great. 

[Erwann Abalea]

Le lundi 18 novembre 2013 12:46:16 UTC+1, Rob Stradling a écrit :

On 17/11/13 16:48, Erwann Abalea wrote:
<snip>
> That unicity comes from X.509 itself:

[...]

> RFC5280 couldn't have changed it.

Even though RFC5280 only cites X.509 as an Informative (not Normative)
reference?  ;-)

Even (I didn't notice that). They're still talking about X.509 certificates, not RFC5280 certificates ;)

X.520, X.660, and X.683 are also listed as Informative References, but I don't think IETF would take the risk of producing things incompatible with these standards while keeping the names, OID, etc.

Mozilla CA policy also forbids duplicate issuer and serial numbers.

<snip>
> I'm really not in favor of option 1.
> How about an option 3 that uses something other than a certificate
> structure for the "precert" role? IIRC, the certificate format was
> chosen because it's convenient.

Yes, it's very convenient.  I wrote our code for generating
Precertificate tbsCertificates the other day.  Pretty much all I had to
do was add an "add poison extension" flag to our existing Certificate
tbsCertificate generation code.  Easy!

We use XML templates for certificate generation here, with support for arbitrary extensions (arbitrary OID, criticity flag, and content expressed as Base64).

The SCT needs more work, but we'll leave that to the RA, and only change the CA code to allow the RA to specify the serial number (with appropriate restrictions and unicity controls).

So option 1 (with intermediate CA) is a viable solution, with larger certificates. Then, OCSPStapling+SCT is best once servers and browsers support is deployed.

[Ben Laurie]

On 19 November 2013 01:38, Erwann Abalea <eab...@gmail.com> wrote:
> We use XML templates for certificate generation here, with support for
> arbitrary extensions (arbitrary OID, criticity flag, and content expressed
> as Base64).
> The SCT needs more work, but we'll leave that to the RA, and only change the
> CA code to allow the RA to specify the serial number (with appropriate
> restrictions and unicity controls).
>
> So option 1 (with intermediate CA) is a viable solution, with larger
> certificates.

A little confused: option 1 was to change the BR to allow duplicate
serials in this case. But with an intermediate, there's no need for
any change. Also, the intermediate does not make the certificate
larger...

[Erwann Abalea]

Sorry, you're right.

 

Also, the intermediate does not make the certificate
larger...

Not the intermediate, but the 3 SCTs, compared to only 1 in an OCSP response. 

[Ben Laurie]

Right.

[Eran Messeri]

Somewhat off-topic: Just wanted to make sure you're aware of the Java CT client implementation:

https://code.google.com/p/certificate-transparency/source/browse/src/java/src/org/certificatetransparency/ctlog/CTLogClient.java

Which can send both certificate and precertificates to the log and verify the log's response.

Eran

[Rob Stradling]

On 15/11/13 22:30, Rob Stradling wrote:
<snip>

> The CABForum BRs Appendix B (4) says:
> "All other fields and extensions MUST be set in accordance with RFC 5280."
> Although the title of Appendix B is "Certificate Extensions", I think
> "fields and extensions" must surely imply that "fields" are the
> non-extension parts of a certificate (such as the serial number).
> And since certificate serial numbers are not explicitly mentioned in
> Appendix B, I conclude that certificate serial numbers "MUST be set in
> accordance with RFC 5280".
> RFC 5280 Section 4.1.2.2 says:
> "The serial number...MUST be unique for each certificate issued by a
> given CA".
>
> I therefore have to conclude that CT Precertificates "signed by the real
> CA" are currently _illegal_ under the BRs. Given that the
> publicly-trusted CAs MUST follow the BRs, this is a problem (for CAs

> that would want to use this option for Precertificates).

We discussed several possible ways forward on this list a few weeks ago,
but I don't think we reached a consensus.

After some further discussion with Ben this week, here's what we're
thinking...

Plan A: attempt to legalise RFC6962 Precertificates that are "signed by
the real CA".

Plan B (new!): add a particular attribute to the end of the Issuer Name
in the Precertificate tbsCertificate, just before signing it.
RFC6962-bis would define the OID and syntax for this attribute. This
would mean that the Precertificate/Certificate serial numbers could
match without violating RFC5280's requirement that the serial number...
"...MUST be unique for each certificate issued by a given CA (i.e.,

the issuer name and serial number identify a unique certificate)."

Plan C: define a different data format for PreCertificates (i.e. not the
X.509v3 certificate format).

The option to use a Precertificate Signing Certificate would of course
remain available.

I'm planning to carry out Plan A on the CABForum Public mailing list
next week.

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