idnits 2.17.00 (12 Aug 2021) /tmp/idnits61752/draft-zhang-trans-ct-binary-codes-04.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 15 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-trans-RFC6962-bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2017) is 1895 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5280' is mentioned on line 298, but not defined == Missing Reference: 'RFC5246' is mentioned on line 356, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: draft-ietf-trans-rfc6962-bis has been published as RFC 9162 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRANS L. Xia, Ed. 3 Internet-Draft D. Zhang 4 Intended status: Standards Track Huawei 5 Expires: September 7, 2017 D. Gillmor 6 CMRG 7 B. Sarikaya 8 Huawei USA 9 March 6, 2017 11 CT for Binary Codes 12 draft-zhang-trans-ct-binary-codes-04 14 Abstract 16 This document proposes a solution extending the Certificate 17 Transparency protocol [I-D.ietf-trans-rfc6962-bis] for transparently 18 logging the software binary codes (BC)or its digest with their 19 signature, to enable anyone to monitor and audit the software 20 provider activity and notice the distribution of suspect software as 21 well as to audit the BC logs themselves. The solution is called 22 "Binary Transparency" in this document. 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 September 7, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Cryptographic Components of Binary Transparency . . . . . . . 3 61 3. Motivation Scenarios . . . . . . . . . . . . . . . . . . . . 3 62 4. Log Format and Operation Extensions . . . . . . . . . . . . . 4 63 4.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. TransItem Structure . . . . . . . . . . . . . . . . . . . 5 65 4.3. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 6 66 4.4. Structure of the Signed Binary Timestamp . . . . . . . . 7 67 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 9 68 5.1. Add Binary Code and Certificate Chain to Log . . . . . . 9 69 5.2. Retrieve Entries and STH from Log . . . . . . . . . . . . 9 70 5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Digital signatures have been widely used in software distributions to 82 prove the authenticity of software. Through verifying signature, an 83 end user can ensure that the gotten software is developed by a legal 84 provider (e.g., Microsoft) and is not tampered during the 85 distribution. If an end user does not have a direct trust 86 relationship with the software provider, an certificate chain to a 87 trust anchor that the user trusts should be provided. That is why 88 many signature mechanisms for software distribution are based on 89 public key infrastructure (PKI). However, signature mechanisms 90 cannot prevent software provider from distributing software either 91 with customized backdoors/drawbacks, or they do not own the right to 92 distribute. Besides, it may be hard for a user to detect the 93 differences between the software it got and the software provided to 94 other users.. 96 This draft describes the Binary Transparency mechanism which extends 97 the Certificate Transparency (CT) protocol specified in [I-D.ietf- 98 trans-rfc6962-bis] to support logging binary codes. A software 99 provider can submit its software Binary Codes (BC) (or digests of 100 codes in order to e.g., save space or avoid violating license 101 restrictions) with associated signature to one or more CT logs. 102 Therefore, a user can easily detect the existence of software BC with 103 customized backdoors, by comparing with the according CT log entries. 104 The software provider can monitor the logs all the time to detect 105 whether there are tempered copies of its software in the log, or its 106 software is submitted into the log by other software providers 107 without authority. In summary, the end users should be informed when 108 all the above situations happen, how to achieve it is beyond the 109 scope of this document. 111 With this mechanism, when a section of binary codes and associated 112 signature has been submitted to a log, if the provided certificate 113 chain ends with a trust anchor that is accepted by the log, the log 114 will accept it and return the Signed Binary Timestamp (SBT) to the 115 software provider as the evidence of its acceptance provided to the 116 users later. Thus, the users should only trust the software 117 accompanied by SBT, even if it is associated with a proper signature. 118 This approach then forces the software providers to submit their 119 binary codes to logs before distributing them. 121 Binary Transparency is an extension to Certificate Transparency, 122 which comply with most of the specification in [I-D.ietf-trans- 123 rfc6962-bis]. This document only focuses on the extension part of 124 Binary Transparency mechanisms. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Cryptographic Components of Binary Transparency 134 When applying CT for binary codes, a log is a single, ever-growing, 135 append-only binary Merkle Hash Tree of software BC, with associated 136 signature and certificate chain, complying with the Merkle Hash Tree 137 specification in Section 2 of [I-D.ietf-trans-rfc6962-bis]. 139 3. Motivation Scenarios 141 The documents disclosed by Edward Snowden have raised the concerns of 142 people on the vulnerability of the network devices to the passive 143 attacks performed by NSA or other organizations. Meanwhile, the 144 network device vendors are also concerned in their foreign markets 145 because their products are suspected to have customized backdoors for 146 adversaries to perform attacks. It is desired for vendors to publish 147 the design details of the products and provide sufficient facilities 148 for clients to check whether certain hardware or software of a device 149 has been improperly modified. There are various techniques that 150 could be used for this purpose. One way is to force a vendor to 151 submit the binary codes of its firmwares to the public CT logs. 152 Therefore, anyone can verify the correctness of each log entry and 153 monitor when new software BCs are added to it. Specially, customers 154 can easily detect whether the vendor is releasing the same firmware 155 to everyone. In addition, under the assistance of the Binary 156 Transparency, customer will have more confidence on the quality of 157 firmware. Since the same codes are used by different customers all 158 over the world, the drawbacks in firmware will be easier to be 159 detected. 161 There are similar requirements to detect the customized backdoors or 162 misdistribution in the software market. Besides the software itself, 163 a user may also concern whether there are customized backdoors in the 164 patches. The Binary Transparency can help address such concerns in 165 the same way. In addition, this mechanism can also show some 166 advantages in the scenarios where the signer is not aware that their 167 keys have been compromised. If their update system is required to 168 use a CT log, they have the chance to find out about their 169 compromise. 171 4. Log Format and Operation Extensions 173 The software provider can submit the software and the associated 174 signature to any preferred CT logs before distributing it. In some 175 cases, the software provider may select only to submit the signed 176 digest of the software because of the license restriction or the 177 space restriction of log entry. In order to verify the attribution 178 of each log entry, a log SHALL publish a set of certificates that it 179 trusts to benefit an software provider to construct an certificate 180 chain connecting a trust anchor and the certificate containing the 181 key used to sign the software. 183 A log needs to verify the certificate chain provided by the software 184 provider, and MUST refuse to accept the signed software/digest if the 185 chain cannot lead back to a trusted anchor. If the software/digest 186 and the signature are accepted by a log and an SBT is issued, the log 187 MUST store the entire chain and MUST present this chain for auditing 188 upon request. 190 Complying with the log format definition in [I-D.ietf-trans- 191 rfc6962-bis], some definitions remain the same: "Log ID", "Merkle 192 Tree Head", "Signed Tree Head", "Merkle Consistency Proofs", "Merkle 193 Inclusion Proofs", "Shutting down a log"... The other required log 194 format extension for Binary Transparency are specified in the 195 following sections: 197 4.1. Log Entries 199 Each software entry in a log MUST include a "BinaryChainEntryV2" 200 structure as below: 202 enum { binary(TBD1), binary_digest(TBD2) } BIN_Signed_Type; 204 opaque BINARY<1..2^24-1>; 205 opaque ASN.1Cert<1..2^24-1>; 206 struct { 207 BIN_Signed_Type bin_signed_type; 208 BINARY signed_software; 209 ASN.1Cert certificate_chain<1..2^24-1>; 210 } BinaryChainEntryV2; 212 "bin_signed_type" indicates whether the signature is generated based 213 on the software or its digest. 215 "signed_software" consists a ContentInfo structure specified in 216 CMS[RFC5652]. Specifically, this field includes the binary codes/ 217 digest, the signature, and any other additional information used to 218 describe the software and the issuer publishing the software. The 219 software SHOULD be encapsulated and signed following the ways 220 specified in CMS[RFC5652] . If signed_type is TBD1, the software 221 binary code is encapsulated in this field. If signed_type is TBD2, 222 the SHA-256 digest of software binary code is encapsulated in this 223 field. 225 "certificate_chain" includes the certificates constructing a chain 226 from the certificate of software provider to a certificate trusted by 227 the log. The first certificate MUST be the certificate of software 228 provider. Each following certificate MUST directly certify the one 229 preceding it. The final certificate MUST either be, or be issued by, 230 a root certificate accepted by the log. If the certificate chain is 231 provided in the "signed_software" field structure, this field is set 232 to empty. 234 4.2. TransItem Structure 236 The extended "TransItem" structure is defined as below: 238 enum { 239 reserved(0), 240 x509_entry_v2(1), precert_entry_v2(2), 241 x509_sct_v2(3), precert_sct_v2(4), 242 signed_tree_head_v2(5), consistency_proof_v2(6), 243 inclusion_proof_v2(7), x509_sct_with_proof_v2(8), 244 precert_sct_with_proof_v2(9), BIN_entry_v2(TBD3), 245 BIN_sbt_v2(TBD4), BIN_sbt_with_proof_v2(TBD5), 246 (65535) 247 } VersionedTransType; 249 struct { 250 VersionedTransType versioned_type; 251 select (versioned_type) { 252 case x509_entry_v2: TimestampedCertificateEntryDataV2; 253 case precert_entry_v2: TimestampedCertificateEntryDataV2; 254 case x509_sct_v2: SignedCertificateTimestampDataV2; 255 case precert_sct_v2: SignedCertificateTimestampDataV2; 256 case signed_tree_head_v2: SignedTreeHeadDataV2; 257 case consistency_proof_v2: ConsistencyProofDataV2; 258 case inclusion_proof_v2: InclusionProofDataV2; 259 case x509_sct_with_proof_v2: SCTWithProofDataV2; 260 case precert_sct_with_proof_v2: SCTWithProofDataV2; 261 case BIN_entry_v2: TimestampedBinaryEntryDataV2; 262 case BIN_sbt_v2: SignedBinaryTimestampDataV2; 263 case BIN_sbt_with_proof_v2: SBTWithProofDataV2; 264 } data; 265 } TransItem; 267 "versioned_type " is the type of the encapsulated data structure of 268 TransItem. Three new values are added to it -- BIN_entry_v2(TBD3), 269 BIN_sbt_v2(TBD4), BIN_sbt_with_proof_v2(TBD5). 271 For "data" structure, a new type structure of 272 TimestampedBinaryEntryDataV2 is added. 274 4.3. Merkle Tree Leaves 276 Each Merkle Tree leaf is defined as the hash value of a "TransItem" 277 structure of according type. Here, a new type ("BIN_entry_v2") of 278 "TransItem" structure is created, which encapsulates a new 279 "TimestampedBinaryEntryDataV2" structure defined as below: 281 opaque TBSCertificate<1..2^24-1>; 282 struct { 283 uint64 timestamp; 284 opaque issuer_key_hash<32..2^8-1>; 285 BIN_Signed_Type bin_signed_type; 286 TBSSignedSoftware tbs_signed_software; 287 SbtExtension sbt_extensions<0..2^16-1>; 288 } TimestampedBinaryEntryDataV2; 290 "timestamp" is the NTP Time [RFC5905] at which the software binary 291 code was accepted by the log, measured in milliseconds since the 292 epoch (January 1, 1970, 00:00 UTC), ignoring leap seconds. Note that 293 the leaves of a log's Merkle Tree are not required to be in strict 294 chronological order. 296 "issuer_key_hash" is the HASH of the public key of the software 297 provider that signed the software, calculated over the DER encoding 298 of the key represented as SubjectPublicKeyInfo [RFC5280]. This is 299 needed to bind the software provider to the software binary code, 300 making it impossible for the corresponding SBT to be valid for any 301 other software whose TBSSignedSoftware matches "tbs_signed_software". 302 The length of the "issuer_key_hash" MUST match HASH_SIZE. 304 "bin_signed_type" indicates whether the signature is generated based 305 on the software or its digest. 307 "tbs_signed_software" is the DER encoded TBSSignedSoftware from the 308 "signed_software" in the case of a "BinaryChainEntryV2". 310 4.4. Structure of the Signed Binary Timestamp 312 An SBT is a "TransItem" structure of type "bin_sbt_v2", which 313 encapsulates a "SignedBinaryTimestampDataV2" structure: 315 enum { 316 reserved(65535) 317 } SbtExtensionType; 319 struct { 320 SbtExtensionType sbt_extension_type; 321 opaque sbt_extension_data<0..2^16-1>; 322 } SbtExtension; 324 struct { 325 LogID log_id; 326 uint64 timestamp; 327 SbtExtension sbt_extensions<0..2^16-1>; 328 digitally-signed struct { 329 TransItem timestamped_entry; 330 } signature; 331 } SignedBinaryTimestampDataV2; 333 "log_id" is this log's unique ID, encoded in an opaque vector. 335 "timestamp" is equal to the timestamp from the 336 "TimestampedBinaryEntryDataV2" structure encapsulated in the 337 "timestamped_entry". 339 "sbt_extension_type" identifies a single extension from the IANA 340 registry in Section 6. At the time of writing, no extensions are 341 specified. 343 The interpretation of the "sbt_extension_data" field is determined 344 solely by the value of the "sbt_extension_type" field. Each document 345 that registers a new "sbt_extension_type" must describe how to 346 interpret the corresponding "sbt_extension_data". 348 "sbt_extensions" is a vector of 0 or more SBT extensions. This 349 vector MUST NOT include more than one extension with the same 350 "sbt_extension_type". The extensions in the vector MUST be ordered 351 by the value of the "sbt_extension_type" field, smallest value first. 352 If an implementation sees an extension that it does not understand, 353 it SHOULD ignore that extension. Furthermore, an implementation MAY 354 choose to ignore any extension(s) that it does understand. 356 The encoding of the digitally-signed element is defined in [RFC5246]. 358 "timestamped_entry" is a "TransItem" structure that MUST be of type 359 "BIN_entry_v2". 361 5. Log Client Messages 363 In Section 5 of [I-D.ietf-trans-rfc6962-bis], a set of messages is 364 defined for clients to query and verify the correctness of the log 365 entries they are interested in. In this document, a new message is 366 defined and an existing message is extended for CT to support Binary 367 Transparency. 369 5.1. Add Binary Code and Certificate Chain to Log 371 POST https:///ct/v1/add-Binary-chain 373 Inputs: 374 bin_signed_type: indicates whether the input parameter "software" 375 is constructed by the binary code or its digest. 376 software: the binary code (or digest), the signature, and the 377 information used to describe the software and the software 378 provider publishing the software, which are encapsulated 379 following the way specified in CMS[RFC5652] . The submitter 380 desires a SBT for this element. 381 chain: An array of base64-encoded certificates. The first element is 382 the certificate used to sign the binary code (or digest); the 383 second certifies the first and so on to the last, which either is, 384 or is certified by, an accepted trust anchor.If the certificate 385 chain information has been included in the "software" field, this 386 field could be empty. 388 Outputs: 389 sbt: A base64 encoded "TransItem" of type "BIN_sbt_v2", signed by this 390 log, that corresponds to the submitted software. 392 Error codes: 393 Be identical with the according part in Section 5.1 (Add Chain to Log) of 394 [I-D.ietf-trans-rfc6962-bis]. 396 5.2. Retrieve Entries and STH from Log 397 GET https:///ct/v2/get-entries 398 Inputs: 399 start: 0-based index of first entry to retrieve, in decimal. 400 end: 0-based index of last entry to retrieve, in decimal. 401 Outputs: 402 entries: An array of objects, each consisting of 403 leaf_input: The base64 encoded "TransItem" structure of type 404 "x509_entry_v2" or "precert_entry_v2" or "BIN_entry_v2" 405 (see Section 4.3). 406 log_entry: The base64 encoded log entry (see Section 4.1). In the 407 case of an "x509_entry_v2" entry, this is the whole 408 "X509ChainEntry"; and in the case of a "precert_entry_v2", 409 this is the whole "PrecertChainEntryV2"; and in the case of a 410 "BIN_entry_v2", this is the whole "BinaryChainEntryV2". 411 sct: The base64 encoded "TransItem" of type "x509_sct_v2" or "precert_sct_v2" 412 or "BIN_sbt_v2"corresponding to this log entry. 413 sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", signed 414 by this log. 416 More details are identical with Section 5.7 of [I-D.ietf-trans- 417 rfc6962-bis]. 419 5.3. Summary 421 In summary, the above extensions of Binary Transparency enable the 422 software providers, the end users, and anyone to monitor and audit 423 the CT logs to mitigate the possible attacks induced by tampered 424 software, or software misdistribution. 426 This section gives a brief introduction to all the other aspects of 427 Binary Transparency mechanisms for the reason of completeness, since 428 they comply with the basic CT protocol specification. For more 429 details please refer to the corresponding sections of [I-D.ietf- 430 trans-rfc6962-bis]. 432 Software providers act the same as TLS servers in CT protocol. They 433 present one or more SBTs from one or more logs to each end user while 434 distributing the software, where each SBT corresponds to the 435 software. Software providers SHOULD also present corresponding 436 inclusion proofs and STHs. In which way the software providers 437 present this information is beyond the scope of this document. 439 The end users of software acts the same as Clients of logs described 440 in CT protocol. They can perform various different functions, such 441 as: get log metadata, exchange STHs they see, receive and validate 442 SBTs, Validate inclusion proofs. 444 Binary Transparency also provides monitoring and auditing functions 445 with the same algorithms defined for CT protocol. 447 Binary Transparency supports the same algorithm agility feature for 448 signature algorithm and hash algorithm as CT protocol. 450 6. Acknowledgements 452 7. IANA Considerations 454 To be added. 456 8. Security Considerations 458 To be added. 460 9. References 462 9.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 470 RFC 5652, DOI 10.17487/RFC5652, September 2009, 471 . 473 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 474 "Network Time Protocol Version 4: Protocol and Algorithms 475 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 476 . 478 9.2. Informative References 480 [I-D.ietf-trans-rfc6962-bis] 481 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 482 Stradling, "Certificate Transparency Version 2.0", draft- 483 ietf-trans-rfc6962-bis-24 (work in progress), December 484 2016. 486 Authors' Addresses 488 Liang Xia (editor) 489 Huawei 491 Email: frank.xialiang@huawei.com 492 Dacheng Zhang 493 Huawei 495 Email: dacheng.zhang@huawei.com 497 Daniel Kahn Gillmor 498 CMRG 500 Email: dkg@fifthhorseman.net 502 Behcet Sarikaya 503 Huawei USA 504 5340 Legacy Dr. Building 3 505 Plano, TX 75024 507 Email: sarikaya@ieee.org