Re: [pkix] a question of cert (and OCSP) extension syntax

["Manger, James" <[e-mail]>]

I came across a real cert with a Certificate Transparency extension the other day and took a look inside.

(I assume) the cert extension complies with RFC6962 "Certificate Transparency", and I believe this is also consistent with the current update draft-ietf-trans-rfc6962-bis-07.

Below are extracts from the certificate in hex: preceded by line numbers; indenting to show structure; and some comments starting with #.

Notable items:

Line 145: start of cert extension holding 3 signed cert timestamps (SCTs).

Line 147: extnValue OCTET STRING

Line 148: Another OCTET STRING, embedded in extnValue. Hence, an "ASN.1 DER encoded structure" (this OCTET STRING) "is the value of the octet string extnValue". That is, the syntax is a valid extension.

Lines 149-182: TLS-style encoding (eg most 2-byte/4-hexdigit items are lengths).

Lines 158-160: A DER-encoding embedded in the TLS-style encoding.

Each SCT has version (1 byte), log id (32 bytes), timestamp (8 bytes, milliseconds since 1970), alg ids (1 byte each), and a signature (DER-encoding of SEQ. {r, s}).
The signature in the extension is calculated over (most of) the tbsCertificate, but the tbsCertificate does NOT appear in the extension.


I suggest keeping this TLS-style-encoding-embedded-in-an-OCTET-STRING. It is a bit Frankenstein-esq, but I don’t think that is avoidable. Certificate Transparency mixes X.500 and TLS, they chose different encoding styles, the styles have to meet somewhere.
The cert extension should definitely have the exact bytes for fields that will be signed, which means TLS-style 1-byte alg ids, 8-byte timestamp, and SCT extensions. Converting each individual field to ASN.1 would just make it more awkward to reconstruct the exact bytes to be signed.


# Certificate Transparency extension
# from the certificate for https://op.certification.openid.net:60054/
# 3 SignedCertificateTimestamps
# from Google 'Pilot' (A4...10), DigiCert (56...DD), Google 'Aviator' (68...C4)

     1	30 82072A # certificate
     2	   30 820612 # tbsCertificate (to be signed)
     3	      A0 03
     4	         02 01 02 # v3
     5	      02 10 0D1C890FBE7061A327B970DA2FC3B90A # cert serial number
...
    74	         31 24
    75	            30 22
    76	               06 03 550403 # cn
    77	               0C 1B 6F702E63657274696669636174696F6E2E6F70656E69642E6E6574 # op.certification.openid.net
...
    86	      A3 8202F5
    87	         30 8202F1
    88	            30 26
    89	               06 03 551D11 # id-ce-subjectAltName
    90	               04 1F
    91	                  30 1D
    92	                     82 1B 6F702E63657274696669636174696F6E2E6F70656E69642E6E6574 # op.certification.openid.net
...
   145	            30 82017C
   146	               06 0A 2B06010401D679020402 # 1.3.6.1.4.1.11129.2.4.2 
   147	               04 82016C
   148	                  04 820168 # PrecertificateSCTList
   149	0166
   150	  0075
   151	    00 # version
   152	    A4B90990B418581487BB13A2CC67700A3C359804F91BDFB8E377CD0EC80DDC10 # id Google Pilot
   153	    0000014B99953C14 # timestamp
   154	    0000 # extensions
   155	    04 # hash sha256
   156	    03 # signature ecdsa
   157	    0046
   158	      30 44
   159	         02 20 11666B9E97E4E4AC6434E4B67C02617A31FB14DAEE4BB018D7B2B178133E1630 # r
   160	         02 20 6A13F32E7C704CDCB7B1D12241AA3E346F4DED5670CA01DA5B850BCFB04285B5 # s
   161	  0075
   162	    00
   163	    5614069A2FD7C2ECD3F5E1BD44B23EC74676B9BC99115CC0EF949855D689D0DD # id DigiCert
   164	    0000014B99953E24
   165	    0000
   166	    04
   167	    03
   168	    0046
   169	      30 44
   170	         02 20 3EC2C5C2408ED171F2D3B8B0FD3DFA8CA09C4BE3A7DD1ADA871444D39B0828A7
   171	         02 20 596955FE3F434579E9CD9144455AE7848094CDA89EED2A5F3DC254B38F2E4335
   172	  0076
   173	    00
   174	    68F698F81F6482BE3A8CEEB9281D4CFC71515D6793D444D10A67ACBB4F4FFBC4 # id Google Aviator
   175	    0000014B99953C08
   176	    0000
   177	    04
   178	    03
   179	    0047
   180	      30 45
   181	         02 21 008E8E239C48C46E0AD1F0B102071B2CA73E199C791654E93B406F9F3BB4EEC967
   182	         02 20 49427C3C633C5D0FC21088921AE2F01BF49D8B21012A0A8EEBD8B2967B72F2B4
   183	
   184	   30 0D
   185	      06 09 2A864886F70D01010B # sha256WithRSAEncryption
   186	      05 00
   187	   03 820101 009710D1B54C9F9241694CF1927223F0AE6901B7AD419685F1DBE39F2959ADCCAD7EB0C1FD10583E1502DE6A52D58078ECEA9F17DA018D203E7EA5A5805FEA2811031776F3EDC02C18A426AC80A76735C69DCC87E885D76E40E75D3FA70F060F967D551CDBC1AECEC8993169BDCA45764B0D2857CCFDF87E0DF0A1594E3EF35EC031D4967F844EFE07C402FEC501DDEA5787D1DD4D6F0EF0E9E1B241E200922A35C279C41F248E62015494FD2820823317C9B08B5EFC5C46943453AB81AB7BC78DAA35B757CAD323F97F8C1DC5A0B69C39FE77A4354685ECB68AE04C5F32B152D39C4DA22A3A16CE395FE0CFC03BF7247265BCD032AF1E5A80D86D38B2F9D749C6 # signature



A few more comments inline below.

--
James Manger



----------
From: pkix [mailto:[e-mail]] On Behalf Of Stephen Kent
Sent: Wednesday, 18 March 2015 6:35 AM
To: pkix
Subject: [pkix] a question of cert (and OCSP) extension syntax

Folks,
 
Stephen Farrell suggested that I pose a question to this list based on an ongoing  debate in another WG.
 
A certificate and OCSP extension has been proposed in TRANS. The extension consists of a few data items, principally:
	version number (an integer)
	a log ID (an octet string)
	a time stamp
	a certificate or TBS certificate 

[JM] No, the cert/tbsCert is NOT in this cert ext

	a hash value (a bit or octet string)

[JM] I think you mean a signature

	an optional set of TBD protocol-specific extensions 
 
The authors of the proposed extension elected to encode all of these data items as one big OCTET STRING, rather than using the existing, base ASN.1 data types. They elected to not use an ASN.1 structure here because one of the three ways to communicate this data to a client is via a TLS handshake. They believe that the TLS handshake will eventually become the predominant means of transporting this data. (I didn’t find the argument for this prediction compelling, but ...). Thus they chose to employ the syntax defined in RFC 5246.
 
Russ Housley and I have argued that using OCTET STRING here is inconsistent with the intent of 5280 (and 2594 and 3280), which defines an extension as:
 
Each extension includes an OID and an ASN.1 structure.  When an extension appears in a certificate, the OID appears as the field extnID and the corresponding ASN.1 DER encoded structure is the value of the octet string extnValue.
 
Since the bulk of the data items have an obvious ASN.1 representation,

[JM] Is the "obvious ASN.1" for the timestamp (ms since 1970) GeneralizedTime or INTEGER or OCTET STRING (SIZE(8))?
[JM] I guess the "obvious ASN.1" for the alg ids is INTEGER {sha256(4), ...}, even though ASN.1 uses OID (or actually AlgorithmIdentifier).
[JM] The ASN.1 for SCT extensions would presumably be SEQUENCE OF OCTET STRING, which still embeds a TLS-style encoding in an OCTET STRING.


 and the certificate or TBS certificate are native ASN.1 structures, we feel that the decision to stuff all of the data items into an OCTET STRING is inappropriate, and that it sets a bad precedent for others developing certificate (and OCSP) extensions in the future
 
I’m soliciting feedback from this list on this topic, to pass on to Stephen, Kathleen, and the TRANS WG.
 
Thanks,
 
Steve