idnits 2.17.00 (12 Aug 2021) /tmp/idnits25556/draft-zhang-trans-ct-binary-codes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 59 has weird spacing: '...ponents of Ce...' == Line 265 has weird spacing: '...oftware the b...' -- The document date (December 23, 2014) is 2706 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 213 == Outdated reference: draft-ietf-trans-rfc6962-bis has been published as RFC 9162 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft Huawei 4 Intended status: Experimental D. Gillmor 5 Expires: June 26, 2015 CMRG 6 D. He 7 Huawei 8 December 23, 2014 10 CT for Binary Codes 11 draft-zhang-trans-ct-binary-codes-01 13 Abstract 15 This document proposes a solution to use CT for publishing softwares/ 16 binary codes and their signatuers. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 26, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Cryptographic Components of Certificate Transparency . . . . 3 60 3. Motivation Scenarios . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Dealing with Customized Backdoors in Firmwares . . . . . 3 62 3.2. Another Scenarios . . . . . . . . . . . . . . . . . . . . 3 63 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 3 64 4.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 3 65 4.2. Structure of the Signed Certificate Timestamp . . . . . . 5 66 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Add Binary and Certificate Chain to Log . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Digital signatures have been widely used in software distributions to 77 demonstrate the authenticity of softwares. Through verifying 78 signatures, end users can could ensure that the softwares they got 79 are provided by legal organizations and never modified during the 80 delivery. If an end user does not have a direct trust relationship 81 with the software provider, an authentication chain need to be 82 generated from the key used for generating the signature to a trust 83 anchor that the user trusts. That is why many signature mechanisms 84 for software distribution are based on PKI. 86 However, signatures cannot prevent a software developer from 87 distributing softwares with customized backdoors/drawbacks. In some 88 circumstances, it may be hard for a user to detect the differences 89 between the software it got and the software provided to other users. 91 This draft describe a mechanism to extend Certificate Transparency 92 specified in [I-D.ietf-trans-rfc6962-bis] to support logging binary 93 codes. A software provider can publish its softwares (or digests of 94 binary codes in the cases the softwares are non-trival) to one or 95 more logs. Therefore, a user can easily detect the customized 96 backdoors through monitor the log entries. 98 In this mechanism, after a section of binary codes is published to a 99 log, the log will return a ticket (called Signed Certificate 100 Timestamp (SCT) in this case) to the software provider. The software 101 without the ticket will not be trusted even it is associated with a 102 proper signature. This approach will force providers to publish 103 their binary codes to logs. 105 2. Cryptographic Components of Certificate Transparency 107 The introduction of cryptographic components of CT is in Section 2 of 108 [I-D.ietf-trans-rfc6962-bis]. When applying CT for binary codes, a 109 log is a single, ever-growing, append-only Merkle Tree of DS RRs. 111 3. Motivation Scenarios 113 3.1. Dealing with Customized Backdoors in Firmwares 115 The disclosed documents have raised the concerns of people on the 116 vulnerability of the network devices to the passive attacks performed 117 by NSA or other organizations. Some vendors have met problems in the 118 abroad markets because their products are suspected to have 119 customized backdoors for adversaries to perform attacks. It is 120 desired for vendors to publish the design details of the products and 121 provide sufficient functions for clients to check whether certain 122 hardware or software of a device has been improperly modified. There 123 are various techniques that could be used for this purpose. One way 124 is to force a vendor to publish the binary codes of its firmwares. 125 Therefore, customers can easily detect whether the vendor is 126 releasing the same firmware to everyone. In addition, the binary 127 transparency, customer will have more confidence on the quality of 128 firmwares. Since the same codes are used by different customers all 129 over the world, the drawbacks in firmwares will be easier to be 130 detected. 132 3.2. Another Scenarios 134 Ben suggested to us CT for publishing FreeBSD. Can you contribute 135 some ideas here? 137 4. Log Format and Operation 139 4.1. Log Entries 141 A developer of a sfotware can submit the signed software (or the 142 digest of the software to save space) to any preferred logs before 143 distributing it. In order to enable attribution of each logged RR to 144 its issuer, the log SHALL publish a list of certificates to construct 145 an authentication chain connecting the trust anchor and the 146 certfiicate used to sign the software. 148 Logs MUST verify that the authentication chain and make sure it leads 149 back to a trusted certificate, using the chain of certificates 150 provided by the submitter. Logs MUST refuse to publish a signed 151 software without a valid chain. If the software and the signature 152 are accepted and an SCT issued, the accepting log MUST store the 153 entire chain used for verification, including the signed software 154 itself and including the trusted zone signing key used to verify the 155 chain, and MUST present this chain for auditing upon request. 157 To comply with the certificate entries specified in 158 [I-D.ietf-trans-rfc6962-bis],Each software entry in a log MUST 159 include the following components: 161 enum { x509_entry(0), precert_entry(1), BIN_entry(TBD1), (65535) } LogEntryType; 163 struct { 164 LogEntryType entry_type; 165 select (entry_type) { 166 case x509_entry: X509ChainEntry; 167 case precert_entry: PrecertChainEntry; 168 case BINARY_entry:SigSoft_Chain_Entry 169 } entry; 170 } LogEntry; 172 opaque BINARY<1..2^24-1>; 173 struct { 174 BINARY signed_software; 175 ASN.1Cert certificate_chain<0..2^24-1>; 176 } BINARY_Chain_Entry; 178 "entry_type" is the type of this entry. the type value of a binary 179 log entry is TBD1. 181 "signed_software" include the binary codes, the signature, and any 182 other additional information used to describe the software and the 183 signer publishing the software. The current version of the document 184 does not specify how to structure such information. (CMS[RFC5652] 185 can be used.) This work will be left for future work. 187 "certificate_chain" include the certificates constructing a chain 188 from the certificate of signer to a certificate trusted by the 189 log.The first certificate MUST be the certificate of signer. Each 190 following certificate MUST directly certify the one preceding it. 192 The final certificate MUST either be, or be issued by, a root 193 certificate accepted by the log. 195 4.2. Structure of the Signed Certificate Timestamp 197 This work reuses the structure of Signed Certificate Timestamp 198 specified in Section 3.3 of [I-D.ietf-trans-rfc6962-bis] but make 199 necessary extensions. 201 enum { certificate_timestamp(0), tree_hash(1),BINARY_timestamp(TBD2), (255) } 202 SignatureType; 204 enum { v1(0), (255) } 205 Version; 207 struct { 208 opaque key_id[32]; 209 } LogID; 211 opaque digestcodes<0..2^24-1>; 212 struct { 213 opaque issuer_key_hash[32]; 214 digestcodes binary_digest; 215 } Binary_Codes; 217 opaque CtExtensions<0..2^16-1>; 219 "key_id" and "issuer_key_hash" are defined in Section 3.3 of 220 [I-D.ietf-trans-rfc6962-bis]. 222 binary_digest is the SHA-256 hash of binary codes. (Open question: 223 In the future version of the this document, do we need to support 224 other digest algorithms? If so, maybwe we should provie an digest 225 identifier field here. ) 226 struct { 227 Version sct_version; 228 LogID id; 229 uint64 timestamp; 230 CtExtensions extensions; 231 digitally-signed struct { 232 Version sct_version; 233 SignatureType signature_type = DSRR_timestamp; 234 uint64 timestamp; 235 LogEntryType entry_type; 236 select(entry_type) { 237 case x509_entry: ASN.1Cert; 238 case precert_entry: PreCert; 239 case BINARY_entry: Binary_Codes; 240 } signed_entry; 241 CtExtensions extensions; 242 }; 243 } SignedCertificateTimestamp; 245 "sct_version", "timestamp", "entry_type and extensions" are are 246 identical to what is defined in Section 3.3 of 247 [I-D.ietf-trans-rfc6962-bis].. 249 "extensions" are future extensions to this protocol version (v1). 250 Currently, no extensions are specified. 252 5. Log Client Messages 254 In Section 4 of [I-D.ietf-trans-rfc6962-bis], a set of messages is 255 defined for clients to query and verfiy the correctness of the log 256 entries they are interested in. In this memo, two new messages are 257 defined for CT to support binary transparency. 259 5.1. Add Binary and Certificate Chain to Log 261 POST https:///ct/v1/add-Binary-chain 263 Inputs: 265 software the binary code, the signature, and the information used 266 to describe the software and the signer publishing the software 268 chain: An array of base64-encoded certificates. The first 269 element is the certificate used to sign the binary codes; the 270 second chains to the first and so on to the last, which is 271 either the root certificate or a certificate that chains to a 272 known root certificate. 274 Outputs: 276 sct_version: The version of the SignedCertificateTimestamp 277 structure, in decimal. A compliant v1 implementation MUST NOT 278 expect this to be 0 (i.e., v1). 280 id: The log ID, base64 encoded. 282 timestamp: The SCT timestamp, in decimal. 284 extensions: An opaque type for future expansion. It is likely 285 that not all participants will need to understand data in this 286 field. Logs should set this to the empty string. Clients 287 should decode the base64-encoded data and include it in the 288 SCT. 290 signature: The SCT signature, base64 encoded. 292 6. IANA Considerations 294 This document makes no request of IANA. 296 Note to RFC Editor: this section may be removed on publication as an 297 RFC. 299 7. Security Considerations 301 8. Acknowledgements 303 9. Normative References 305 [I-D.ietf-trans-rfc6962-bis] 306 Laurie, B., Langley, A., Kasper, E., and R. Stradling, 307 "Certificate Transparency", draft-ietf-trans- 308 rfc6962-bis-04 (work in progress), July 2014. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 314 RFC 5652, September 2009. 316 Authors' Addresses 318 Dacheng Zhang 319 Huawei 321 Email: zhangdacheng@huawei.com 323 Daniel Kahn Gillmor 324 CMRG 326 Email: dkg@fifthhorseman.net 328 Danping He 329 Huawei 331 Email: ana.hedanping@huawei.com