Subject: [Trans] Empty extra_data

From: Linus Nordberg <[email-masked]>
Date: Tue, 12 May 2015 12:35:03 +0200

Hi,

I'd like to doublecheck that our reading of RFC6962 is correct regarding
how to store a submitted root cert.

--8<---------------cut here---------------start------------->8---
3.1.  Log Entries
...
   "leaf_certificate" is the end-entity certificate submitted for
   auditing.

   "certificate_chain" is a chain of additional certificates required to
   verify the end-entity certificate.  The first certificate MUST
   certify the end-entity certificate.  Each following certificate MUST
   directly certify the one preceding it.  The final certificate MUST be
   a root certificate accepted by the log.
--8<---------------cut here---------------end--------------->8---

In the case of a root certificate, our implementation treats the (only)
certificate as the leaf_certificate and sees certificate_chain as
empty.

v1/get-entries accordingly returns the cert in leaf_input and nothing in
extra_data.

Do you think that this is conformant with the specification?

---

From: Rob Stradling <[email-masked]>
Date: Tue, 12 May 2015 11:40:33 +0100

Hi Linus.  There's at least one root cert that has an entry in Google's 
Pilot log...

$ wget -q -O/dev/stdout 
"https://ct.googleapis.com/pilot/ct/v1/get-entries?start=2284426&end=2284426" 

{"entries":[{"leaf_input":"AAAAAAE/rhvJDwAAAALrMIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5avIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zfN1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwbP7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQC1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMMj4Qssxs
odyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0PdAAA=","extra_data":"AAAA"}]}

$ echo AAAA | base64 -d | xxd
0000000: 0000 00                                  ...

On 12/05/15 11:35, Linus Nordberg wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
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: Linus Nordberg <[email-masked]>
Date: Tue, 12 May 2015 13:44:56 +0200

Rob Stradling <[email-masked]> wrote
Tue, 12 May 2015 11:40:33 +0100:

| Hi Linus.  There's at least one root cert that has an entry in
| Google's Pilot log...

Hi Rob,

This is how we present a root cert too. Thanks.

Now we know how the authors meant it to be. :)

The wording is not crystal clear but as the meaning is pretty intuitive
I'll not insist on a clarification.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 May 2015 08:27:11 -0400 (EDT)

> I'll not insist on a clarification.

As an implementer, can you offer improved text? We are in the process of
writing a bis document after all - now is a good time.

Paul

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 14 May 2015 06:42:54 +0200

Paul Wouters <[email-masked]> wrote
Tue, 12 May 2015 08:27:11 -0400 (EDT):

| As an implementer, can you offer improved text? We are in the process of
| writing a bis document after all - now is a good time.

Current 6962bis:

   "certificate_chain" is a chain of additional certificates required to
   verify the end-entity certificate.  The first certificate MUST
   certify the end-entity certificate.  Each following certificate MUST
   directly certify the one preceding it.  The final certificate MUST
   either be, or be issued by, a root certificate accepted by the log.
--8<---------------cut here---------------end--------------->8---

Proposed 6962bis:

   "certificate_chain" is a chain of additional certificates required to
   verify the end-entity certificate.  A root certificate has an empty
   certificate_chain.  If present, the first certificate MUST
   certify the end-entity certificate.  Each following certificate MUST
   directly certify the one preceding it.  The final certificate MUST
   either be, or be issued by, a root certificate accepted by the log.
--8<---------------cut here---------------end--------------->8---

---

From: Eran Messeri <[email-masked]>
Date: Thu, 14 May 2015 10:25:10 +0100

Looks good, except I'd move the sentence about a root certificate having an
empty certificate_chain to the end (since it's not the common case).

Linus, mind filing a ticket in trac.tools.ietf.org/wg/trans/trac/ so we can
track this change?

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 21 May 2015 17:27:55 +0200

Looks like I dropped the ball on this.

#84 created.

Eran Messeri <[email-masked]> wrote
Thu, 14 May 2015 10:25:10 +0100:

| Looks good, except I'd move the sentence about a root certificate having an
| empty certificate_chain to the end (since it's not the common case).
| 
| Linus, mind filing a ticket in trac.tools.ietf.org/wg/trans/trac/ so we can
| track this change?
| 
| On Thu, May 14, 2015 at 5:42 AM, Linus Nordberg <[email-masked]> wrote:
| 
| > Paul Wouters <[email-masked]> wrote
| > Tue, 12 May 2015 08:27:11 -0400 (EDT):
| >
| > | As an implementer, can you offer improved text? We are in the process of
| > | writing a bis document after all - now is a good time.
| >
| > Current 6962bis:
| > --8<---------------cut here---------------start------------->8---
| >    "leaf_certificate" is the end-entity certificate submitted for
| >    auditing.
| >
| >    "certificate_chain" is a chain of additional certificates required to
| >    verify the end-entity certificate.  The first certificate MUST
| >    certify the end-entity certificate.  Each following certificate MUST
| >    directly certify the one preceding it.  The final certificate MUST
| >    either be, or be issued by, a root certificate accepted by the log.
| > --8<---------------cut here---------------end--------------->8---
| >
| > Proposed 6962bis:
| > --8<---------------cut here---------------start------------->8---
| >    "leaf_certificate" is the end-entity certificate submitted for
| >    auditing.
| >
| >    "certificate_chain" is a chain of additional certificates required to
| >    verify the end-entity certificate.  A root certificate has an empty
| >    certificate_chain.  If present, the first certificate MUST
| >    certify the end-entity certificate.  Each following certificate MUST
| >    directly certify the one preceding it.  The final certificate MUST
| >    either be, or be issued by, a root certificate accepted by the log.
| > --8<---------------cut here---------------end--------------->8---
| >
| > _______________________________________________
| > Trans mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/trans>
| _______________________________________________
| Trans mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/trans