Bad structure at HEX SCT

[Javier Olmo Gil]

Hello!

I'm trying to implement CT as a CA and I have some troubles when generating the SCT in DER format from the log timestamps.

I got 2 SCTs when I submitted the precert in first instance to the logs. The domain that i'm testing is https://servicio.dfirma.com. I used submit_chain.py (from ct_python project) to get the file with the json SCTs converted in DER format. Then I use php to get the hexadecimal value of that file. So I got this:

00EF00760068F698F81F6482BE3A8CEEB9281D4CFC71515D6793D444D10A67ACBB4F4FFBC40000015124F97E690000040300473045022071087DC1567558FABCAF3D308334C3599A1D395FCAFC129708CCBBAD0208B9AB0221009D7ABFB50A8E03E21C552581F5349511F2012ADB6033A0E2569D577E070EF93F007500A4B90990B418581487BB13A2CC67700A3C359804F91BDFB8E377CD0EC80DDC100000015124F9718B00000403004630440220029916CFEC29F0EBE129AA4929793890165F67F276E406A89CD36389A56F8FDC02203B9895857A97731BCEF21D7B079D829FF727C3382E18ABE250490430F662487D

In order to issue a certificate I put this hex into a openssl config file in the CT OID and issue the certificate and sign it with my CA. It seems that the generated SSL certificate it's not being recognized by chrome as a valid CT since I don't get the transparency validation from the client (chrome).

In my struggle to learn how CT works and what is the info that flows between client and logs so I can use this to know what is wrong with the HEX data I tried to split this to see if there's missing data according SCT structure:

00EF // I don't really know what is this and maybe this is what is failing
0076 // don't know what is this pattern but it seems to be repeating as 0075, 0076, 0077 and so on
00   // CT version
68F698F81F6482BE3A8CEEB9281D4CFC71515D6793D444D10A67ACBB4F4FFBC4 // <-- log id
0000015124F97E69  // <-- unix timestamp in hex format
0000  // ct textension, seems to be  0000 in any valid SCT I'm testing <-- extension, normalmente viene a 0
0403  // undiscovered pattern, but seems to be ct version related and it's fixed!
0047  // sign size, 0047 is 142 chars
3045022071087DC1567558FABCAF3D308334C3599A1D395FCAFC129708CCBBAD0208B9AB0221009D7ABFB50A8E03E21C552581F5349511F2012ADB6033A0E2569D577E070EF93F // ct sign

0075  // <--- new log. From what I've tried, the next block has a similar structure to the first one
00    // ct version..
A4B90990B418581487BB13A2CC67700A3C359804F91BDFB8E377CD0EC80DDC10
0000015124F9718B
0000
0403
0046
30440220029916CFEC29F0EBE129AA4929793890165F67F276E406A89CD36389A56F8FDC02203B9895857A97731BCEF21D7B079D829FF727C3382E18ABE250490430F662487D

So... I've compared this SCT with the one in the bank of america website,and it seems that is pretty similar!

0481F300F1 // <-- ??????
0077
00
A4B90990B418581487BB13A2CC67700A3C359804F91BDFB8E377CD0EC80DDC10
0000014BA2EED813
0000
0403
0048
3046022100C508E447075C2E50C33D26BAF2E945F6C00B5DC054F88BBCF5404E01FDD2D142022100B7A334CCE98F538B097DB356637D56050B469B23EBA0B0F9F804B78E98E25F73

0076
00
5614069A2FD7C2ECD3F5E1BD44B23EC74676B9BC99115CC0EF949855D689D0DD
0000014BA2EEDA4D
0000
0403
0047
3045022100EFF4268CDB79B691E8AA64771FEAD6779B0EA8920FE01A2460CEEAF023080AE60220334952C45DB7E041BA2F0CABF75B2CA3F5109801CF3C77A2E706E34DCD497D39

The only thing that is unknown for me is the first hex values (0481F300F1) that i don't know what they are and seems has a different size comparing with the start of the sct in hex value that  I've got in the domain I've tested: (00EF)

I'm not sure what I've done wrong when I generated the hex value, but for what I see in other generated and valid SCTs is that the Info that I generate is really similar to the good ones.

Could someone please check if the generated cert or the hex data from the SCTS at https://servicio.dfirma.com has something really wrong that is preventing chrome to detecting it as a valid CT certificate?

Many, many thanks! I'm trying to get this working since months.

[Paul Hadfield]

Hi Javier

I think some of the bytes (0403) you don't recognize are the TLS encoding used to sign SCTs.

https://tools.ietf.org/html/rfc6962#page-12 and https://tools.ietf.org/html/rfc5246#page-12 mention the digitally-signed structure which includes a SignatureAndHashAlgorithm.  That is defined here: https://tools.ietf.org/html/rfc5246#page-45

So bytes 0403 are probably the hash and signature algorithms: SHA256 and ECDSA.

Those are then followed by the run-length encoded signature content.

The early bytes you don't recognise are I believe run lengths for the structures that follow.

0076 being the length of the first SCT, and 0075 the length of the second.

That's a list of 2 SCTs, so I think the first two bytes 00EF are the run length of the two SCT blocks together.

I'm not a TLS expert so my reading of that RFC may not be correct, but I hope this helps somewhat.

regards

Paul

 

--
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/d/optout.

[Ben Laurie]

On Mon, 30 Nov 2015 at 10:30 'Paul Hadfield' via certificate-transparency <certificate-...@googlegroups.com> wrote:

Hi Javier

I think some of the bytes (0403) you don't recognize are the TLS encoding used to sign SCTs.

https://tools.ietf.org/html/rfc6962#page-12 and https://tools.ietf.org/html/rfc5246#page-12 mention the digitally-signed structure which includes a SignatureAndHashAlgorithm.  That is defined here: https://tools.ietf.org/html/rfc5246#page-45

So bytes 0403 are probably the hash and signature algorithms: SHA256 and ECDSA.

Those are then followed by the run-length encoded signature content.

The early bytes you don't recognise are I believe run lengths for the structures that follow.

0076 being the length of the first SCT, and 0075 the length of the second.

That's a list of 2 SCTs, so I think the first two bytes 00EF are the run length of the two SCT blocks together.

I'm not a TLS expert so my reading of that RFC may not be correct, but I hope this helps somewhat.

Paul is correct. Except remove the words "probably", "I believe" and "I think". :-)

Your mystery bytes in the BoA cert, 0481F300F1, are:

04  // ASN.1 octetstring (http://www.itu.int/rec/T-REC-X.690-201508-I)

81F3  // ASN.1 length (0xf3)

00F1 // TLS length of SCT list (0xf1)

[Javier Olmo Gil]

Hi again! And thanks for the help.

So, now that I know that 0076,0077 etc seems to be the length of the following SCT structure still I don't know what is failing at my cert. Also I've calculated the value (converting from hex to dec  to get the lenght) and it seems that these values correctly represents the total size of the sct that follows so seems this is not failing.

Also seems that 00EF correctly represents the length of the whole sct (I've checked this and it's correct for my surprise!), also this byte is well represented in the bank of america sct.

So the structure that I've discovered (with your help) is

00EF // lenght of the whole SCT blocks
0076 // length of the first SCT
00 // sct version
68F698F81F6482BE3A8CEEB9281D4CFC71515D6793D444D10A67ACBB4F4FFBC4 // log id
0000015124F97E69  // hex unix timestamp
0000  // CT extension, seems to be 0
0403  // hash and signature alghorithm
0047  // sign length
3045022071087DC1567558FABCAF3D308334C3599A1D395FCAFC129708CCBBAD0208B9AB0221009D7ABFB50A8E03E21C552581F5349511F2012ADB6033A0E2569D577E070EF93F // sign

007500A4B90990B418581487BB13A2CC67700A3C359804F91BDFB8E377CD0EC80DDC100000015124F9718B00000403004630440220029916CFEC29F0EBE129AA4929793890165F67F276E406A89CD36389A56F8FDC02203B9895857A97731BCEF21D7B079D829FF727C3382E18ABE250490430F662487D // second log entry, has a similar pattern with the first log entry

Still there are 6 characters in the first block of the bank of america SCT that i don't recognize

0481F3 // ?????
00F1 // total length of SCT block
0077 // length of first log entry
00 // ct version
A4B90990B... // rest of sct block, starting with the log id

Maybe someone could help with my trouble? As I said i'm just trying to figure what is wrong with the structure that I've generated. I'm trying my best to understand what i'm doing wrong.

Many thanks!

[Javier Olmo Gil]

Oh Ben Laure.

Many thanks for the help, and Sorry. Seems  I was writing the response when you replied :)


So, now the "mystery" is resolved and these 6 characters are:

04  // ASN.1 octetstring (http://www.itu.int/rec/T-REC-X.690-201508-I)

81F3  // ASN.1 length (0xf3)

So as I see my der is wrong and does not contain these.

Seems If I issue a certificate with these missing values the SCT will be recognized with chrome. I'm right? :)

Many many thanks!