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