Subject: [Trans] Certificate and Precertificate extensions ordering

From: Erwann Abalea <[email-masked]>
Date: Thu, 11 Sep 2014 12:40:09 +0200

Bonjour,

It seems there's no constraint on the order of extensions in the final
certificate regarding to the Precert.
Won't it be problematic if the browser wants to validate the SCT signatures
by constructing the Precert from the final certificate? Where should a CA
add the poisonous extension? And the future "redactedlabels" extension (it
has no name)?

-- 
Erwann.

---

From: Eran Messeri <[email-masked]>
Date: Thu, 11 Sep 2014 11:56:33 +0100

The poison extension is removed from the Precertificate prior to the log
producing an SCT over it, so a client never has to know about it. What the
TLS client has to do is to remove the "embedded SCTs" extension  from the
certificate prior to validating the signature.

On Thu, Sep 11, 2014 at 11:40 AM, Erwann Abalea <[email-masked]> wrote:

> Won't it be problematic if the browser wants to validate the SCT
> signatures by constructing the Precert from the final certificate? Where
> should a CA add the poisonous extension? And the future "redactedlabels"
> extension (it has no name)?
>
> --
> Erwann.
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

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

> certificate prior to validating the signature.

This does imply that the remaining extensions have to be in the same
order in both precert and cert, I think?

---

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Sep 2014 12:17:11 +0100

On 11/09/14 11:56, Eran Messeri wrote:
> producing an SCT over it, so a client never has to know about it. What
> the TLS client has to do is to remove the "embedded SCTs" extension
>   from the certificate prior to validating the signature.

Ditto for the future "redactedlabels" extension.

> On Thu, Sep 11, 2014 at 11:40 AM, Erwann Abalea <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Bonjour,
>
>     It seems there's no constraint on the order of extensions in the
>     final certificate regarding to the Precert.
>     signatures by constructing the Precert from the final certificate?
>     Where should a CA add the poisonous extension? And the future
>     "redactedlabels" extension (it has no name)?
>
>     --
>     Erwann.
>
>     [email-masked] <mailto:[email-masked]>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Sep 2014 12:26:38 +0100

> order in both precert and cert, I think?

Yes.

I think this bit...
   "The Precertificate is constructed from the certificate to be issued
    by adding a special critical poison extension..."
...implies that the other extensions shouldn't be shuffled, but should 
we make it more explicit?

---

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

> Ditto for the future "redactedlabels" extension.

That one appears in the cert, too, doesn't it?

> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by
> replying to the e-mail containing this attachment. Replies to this email may
> be monitored by COMODO for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no
> liability can be accepted and the recipient is requested to use their own
> virus checking software.
>
>

---

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

> That one appears in the cert, too, doesn't it?

Sorry, ignore that, it is in the cert but not the precert (though that
seems like an arbitrary decision to me).

---

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Sep 2014 12:45:19 +0100

> seems like an arbitrary decision to me).

I was ditto-ing Eran's second sentence, not his first.  Sorry if I 
wasn't clear.

Yes, I think we could put the "redactedlabels" extension in the precert 
too.  Or, might those who wish to use the redaction mechanism also want 
to keep secret the number of redacted domain components?

Hmmm...if we do decide that the number of redacted domain components can 
be revealed by the precert, then it might be simpler to scrap the 
"redactedlabels" extension altogether and instead say that "(PRIVATE)" 
always covers precisely 1 domain component.  Then, if you want to redact 
3 components, you'd put 
"SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the precert.

(To reduce bloat, we could shrink "(PRIVATE)" to "?".  e.g. 
"SAN:dNSName=?.?.?.mydomain.com").

<snip>

---

From: Eran Messeri <[email-masked]>
Date: Thu, 11 Sep 2014 12:52:33 +0100

On Thu, Sep 11, 2014 at 12:45 PM, Rob Stradling <[email-masked]>
wrote:

> I was ditto-ing Eran's second sentence, not his first.  Sorry if I wasn't
> clear.
>
> too.  Or, might those who wish to use the redaction mechanism also want to
> keep secret the number of redacted domain components?
>
> always covers precisely 1 domain component.  Then, if you want to redact 3
> components, you'd put "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.
> com" in the precert.
>
+1 to that - seems like it would significantly simplify the implementation
of redacted domain name label: The risk of misalignment between the values
in the extension that counts the number of redacted subdomains for each SAN
and the actual SANs goes away.