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:[email protected]] 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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
