Pre-certificate log without final certificate issuance

[Tomas Gustavsson]

Hi,

I'd like to discuss a policy clarification. Based on the following section in RFC6962:

" The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate)."

It's a bit ambiguous, what does it really mean?

If we submit a pre-certificate to a couple of logs, but fail to get the required number of SCTs back, my pragmatic approach would be to not issue the final certificate since it will not be valid for use. Some logs may then have the pre-certificate logged, but there will be no final certificate in existence. I think it's ok, as there will be no certificate ever used seen anywhere. 

You could interpret the above as that you must issue the final certificate however, but discard it as it will not be possible to use anyhow.

You could also interpret the above to just mean that the community can monitor logs with pre-certificates to look for misissuance (format or domains or whatever) and request the issuing CA to fix the problem.

What is the policy stance of the community?

Regards,

Tomas

[Eran Messeri]

As far as I know this is the latter - the community can monitor logs with pre-certificates to look for misissuance. 

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/ec806dbd-342c-4ff7-8f59-2730e832d95c%40chromium.org.

[Ryan Hurst]

Hi Tomas,

What I have said in the past is that the certificate should be issued, not released (discard) and revoked. 

I do not recall any public conversations about this topic though.

Ryan

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.

[Tomas Gustavsson]

You still stand with that Ryan? Seems like a waste of internet bits (and milliseconds) :-)

[Rob Stradling]

I think the CA can decide to not issue the final certificate. 6962 says
"intent to issue", not "commitment to issue".

"This intent is considered binding" doesn't imply that we should read
"intent" as "commitment". Rather, it means what is written within the
parentheses, which I will paraphrase as: if you misissue the
precertificate, the community will act as if you've also misissued the
corresponding certificate (regardless of whether or not you actually
issued the corresponding certificate at all).

https://www.quora.com/What-is-the-difference-between-intention-and-commitment
"Intention is an energized plan to do something. Once you go out and
discover what the actual circumstances are, you might possibly adjust
that intention, if you find that something else would be more desirable
or less difficult. Intention is flexible. You set a flight plan, but if
you run into unexpected turbulence along the way, you might choose a
different route, or in the worst case, a different destination.

Commitment, while equally energized, is fixed and somewhat blind. You
promise to do something in a particular manner before you know what
circumstances you will run into. And you keep going, even if it no
longer is the best choice, even if it is very hard. This is often
considered more noble. It is a symbolic attitude, not a pragmatic one.
You act out of principle, no matter what the reality is."

> it, send an email to ct-policy+...@chromium.org <javascript:>.

> To post to this group, send email to ct-p...@chromium.org

> <javascript:>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/ec806dbd-342c-4ff7-8f59-2730e832d95c%40chromium.org

> <https://groups.google.com/a/chromium.org/d/msgid/ct-policy/ec806dbd-342c-4ff7-8f59-2730e832d95c%40chromium.org?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ct-policy+...@chromium.org

> <mailto:ct-policy+...@chromium.org>.

> To post to this group, send email to ct-p...@chromium.org

> <mailto:ct-p...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/59429224-1d09-4397-8a95-39316a1a1fe0%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/ct-policy/59429224-1d09-4397-8a95-39316a1a1fe0%40chromium.org?utm_medium=email&utm_source=footer>.

--
Rob Stradling
Senior Research & Development Scientist
Email: R...@ComodoCA.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.

[Ryan Hurst]

I could go either way to be honest.

What I like about my past position on this topic is that there is a clear mapping of the pre-certificates lifecycle, either a cert was issued or it was not and it was revoked.

This way it is trackable.

I agree it is "wasteful" in that that final certificate did not need to be issued and the associated CRL/OCSP did not need to be produced but this cost comes with the benefit of a clearer view into the lifecycle.

In any event I am glad you have brought this issue up.

Ryan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/59429224-1d09-4397-8a95-39316a1a1fe0%40chromium.org.

[Fotis Loukos]

Hello Rob,

I do not agree with this interpretation. Based on the quoted text from
quora,

"Once you go out and discover what the actual circumstances are, you
might possibly adjust that intention"

Thus, if between precertificate signing and certificate signing I
discover that a field in the subject is wrong, I can adjust my intention
and issue with a different subject.
I think that the RFC6962 language should be commitment to issue and not
intent to issue.

Regards,
Fotis

Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com

[Al Cutter]

On Thu, May 24, 2018 at 12:46 PM Fotis Loukos <fot...@ssl.com> wrote:

Hello Rob,

I do not agree with this interpretation. Based on the quoted text from
quora,
"Once you go out and discover what the actual circumstances are, you
might possibly adjust that intention"
Thus, if between precertificate signing and certificate signing I
discover that a field in the subject is wrong, I can adjust my intention
and issue with a different subject.

If you did that your previously fetched SCTs would of course be invalid; you'd need to create and log a precert for the newly updated values too; i.e. express a new intent to issue.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/69d59e46-70dc-9b44-f95f-9a323e2f0abd%40ssl.com.

[Fotis Loukos]

On 24/05/2018 03:43 μμ, 'Al Cutter' via Certificate Transparency Policy
wrote:

>
>
> On Thu, May 24, 2018 at 12:46 PM Fotis Loukos <fot...@ssl.com
> <mailto:fot...@ssl.com>> wrote:
>
> Hello Rob,
>
> I do not agree with this interpretation. Based on the quoted text from
> quora,
> "Once you go out and discover what the actual circumstances are, you
> might possibly adjust that intention"
> Thus, if between precertificate signing and certificate signing I
> discover that a field in the subject is wrong, I can adjust my intention
> and issue with a different subject.
>
>
> If you did that your previously fetched SCTs would of course be invalid;
> you'd need to create and log a precert for the newly updated values too;
> i.e. express a new intent to issue.

I totally agree that the PreCert will be changed and thus the signature
will be invalid.

However, if the language is actually intent and I can abort issuance, we
can have the following cases:
1) I try to issue a certificate with serial number 0x123 and I need 2
SCTs. I can log to just a single log, so I abort. In the future, I try
to issue a new certificate for a different subject. Even if it is a
remote chance due to the randomization requirements, I select once again
the serial number 0x123 which does not exist in my database of issued
certificates. I then issue a new certificate and issuance succeeds. I
will have 2 logged precertificates with the serial number 0x123 under
the same CA, and also a certificate with the serial number 0x123 and a
logged precertificate with the same serial number but for a different
subject.
2) I try to issue a certificate for a subject. I cannot collect all
SCTs, so I abort. I retry after some time by creating a new
tbsCertificate with a new serial number but with the same public key and
this time issuance succeeds. Then, the subject requests revocation due
to key compromise. There will be 2 precertificates logged with the same
compromised public key and only a single one of them will have it's
serial number in the CRL.

Is this the expected outcome from both cases?

Regards,
Fotis

> >>     <tomas.gu...@primekey.com <mailto:tomas.gu...@primekey.com>

> <mailto:ct-policy%2B...@chromium.org> <javascript:>.

> >>         To post to this group, send email to ct-p...@chromium.org

> <mailto:ct-p...@chromium.org>

> >>         <javascript:>.
> >>         To view this discussion on the web visit
> >>        
> >>
> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/ec806dbd-342c-4ff7-8f59-2730e832d95c%40chromium.org
> >>
> >>        
> >>
> <https://groups.google.com/a/chromium.org/d/msgid/ct-policy/ec806dbd-342c-4ff7-8f59-2730e832d95c%40chromium.org?utm_medium=email&utm_source=footer>.
> >>
> >>
> >> -- 
> >> You received this message because you are subscribed to the Google
> >> Groups "Certificate Transparency Policy" group.
> >> To unsubscribe from this group and stop receiving emails from it,
> send
> >> an email to ct-policy+...@chromium.org

> <mailto:ct-policy%2Bunsu...@chromium.org>
> >> <mailto:ct-policy+...@chromium.org
> <mailto:ct-policy%2Bunsu...@chromium.org>>.

> >> To post to this group, send email to ct-p...@chromium.org
> <mailto:ct-p...@chromium.org>

> >> <mailto:ct-p...@chromium.org <mailto:ct-p...@chromium.org>>.

> >> To view this discussion on the web visit
> >>
> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/59429224-1d09-4397-8a95-39316a1a1fe0%40chromium.org
> >>
> <https://groups.google.com/a/chromium.org/d/msgid/ct-policy/59429224-1d09-4397-8a95-39316a1a1fe0%40chromium.org?utm_medium=email&utm_source=footer>.
> >>
> >
>
>
> --
> Fotis Loukos, PhD
> Director of Security Architecture
> SSL Corp

> e: fot...@ssl.com <mailto:fot...@ssl.com>

> w: https://www.ssl.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ct-policy+...@chromium.org

> <mailto:ct-policy%2Bunsu...@chromium.org>.

> To post to this group, send email to ct-p...@chromium.org
> <mailto:ct-p...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/69d59e46-70dc-9b44-f95f-9a323e2f0abd%40ssl.com.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ct-policy+...@chromium.org
> <mailto:ct-policy+...@chromium.org>.
> To post to this group, send email to ct-p...@chromium.org
> <mailto:ct-p...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACM%3D_Od__rHDkRb_zfDJZGHzkOZvKvAkqSnNyUERftw5gotnUQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACM%3D_Od__rHDkRb_zfDJZGHzkOZvKvAkqSnNyUERftw5gotnUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Ryan Sleevi]

No.

Once you have logged a single PreCert, you have made a statement to the world that "For all intents and purposes, I have issued an equivalent certificate". That's because no one in the world will actually be able to prove you *didn't* issue such a certificate (unless we trust you, which the whole goal is to reduce that trust component).

This means that if you 'reuse' that serial number, the world sees it as if you've issued two certificates with the same serial number - one they can prove you issued, and one that they can't prove you didn't issue.

The same applies to the CRLs - the world sees it as if you've issued two certificates with the same public key - one they can prove you issued, and one they can't prove you didn't issue.

To Tomas' original question, no, you're not required to actually issue the certificate - presumably, signing the tbsCertificate. However, every one of your systems absolutely needs to treat it as if you did - tracking for CRLs, serial numbers, etc. The easiest way to do that is to actually issue it. But that's not required. And the easiest way to signal intent of 'don't actually use this' is what Ryan mentioned - to not release, and to revoke.

But for all intents and purposes, the moment you log a precertificate, that is meant to be a binding statement to the world that "For all intents and purposes, I have issued an equivalent certificate" - even if it takes the gathering of the SCTs for that to actually be a reality. 

[Ryan Sleevi]

On Thu, May 24, 2018 at 9:39 AM, Tomas Gustavsson <tomas.gu...@primekey.com> wrote:

Revocation should not be relevant for pre-certificates. Since they are not used for anything, you don't check revocation on a pre-certificate. A revoked or non-revoked pre-certificate feels like a concept that doesn't exist?

I don't think that's quite correct, though.

If you accept that the expectation is that for any pre-certificate that exists, it's assumed that there exists a corresponding identical certificate, then revocation is just as relevant as revoking the real certificate.

In terms of bad metaphors, think of a pre-certificate as a shadow of a certificate. Yes, the shadow is not the same as the real thing, but you expect that if you see the shadow, the real thing exists - and if you were to see, say, the shadow of someone right behind your shadow, you'd probably react with a startled fright.

Yes, it's a bad metaphor, yes, it doesn't stretch well, but by thinking of pre-certificates as something that goes hand-in-hand with a real cert - even if you never see the real cert, even if the real cert was never actually signed ("trust me, I pinky-promise") - treating it as 'live bomb' or 'hot mic' or 'loaded weapon' or whatever "handle with extreme care" parallel you prefer is probably the best outcome.