idnits 2.17.1 draft-irtf-icnrg-ccnxmessages-05.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 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2017) is 2412 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 466 -- Looks like a reference, but probably isn't: '1' on line 466 -- Looks like a reference, but probably isn't: '2' on line 466 == Missing Reference: 'KeyIdRestr' is mentioned on line 525, but not defined == Missing Reference: 'ContentObjectHashRestr' is mentioned on line 525, but not defined == Unused Reference: 'CCN' is defined on line 1700, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1721, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1731, but no explicit reference was found in the text == Unused Reference: 'RFC6920' is defined on line 1737, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-mosko-icnrg-ccnxsemantics is -01, but you're referring to -04. -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft PARC, Inc. 4 Intended status: Experimental I. Solis 5 Expires: March 15, 2018 LinkedIn 6 C. Wood 7 University of California Irvine 8 September 11, 2017 10 CCNx Messages in TLV Format 11 draft-irtf-icnrg-ccnxmessages-05 13 Abstract 15 This document specifies version "1" of CCNx message TLV packet 16 format, including the TLV types used by each message element and the 17 encoding of each value. The semantics of CCNx messages follow the 18 CCNx Semantics specification. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 15, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 4 58 3.1. Overall packet format . . . . . . . . . . . . . . . . . . 5 59 3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 7 61 3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 8 62 3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 8 63 3.2.3. InterestReturn Fixed Header . . . . . . . . . . . . . 8 64 3.2.3.1. InterestReturn HopLimit . . . . . . . . . . . . . 9 65 3.2.3.2. InterestReturn Flags . . . . . . . . . . . . . . 9 66 3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 9 67 3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 10 68 3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.3.2. Organization Specific TLVs . . . . . . . . . . . . . 11 70 3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 11 71 3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 12 72 3.4. Hop-by-hop TLV headers . . . . . . . . . . . . . . . . . 12 73 3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 13 74 3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 13 75 3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 14 76 3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 15 77 3.6. CCNx Message . . . . . . . . . . . . . . . . . . . . . . 15 78 3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 79 3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 17 80 3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 18 81 3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 19 82 3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 19 83 3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 20 84 3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 22 85 3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 22 86 3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 22 87 3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 28 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 89 4.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 29 90 4.2. Interest Return Code Registry . . . . . . . . . . . . . . 29 91 4.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 31 92 4.4. Top-Level Type Registry . . . . . . . . . . . . . . . . . 31 93 4.5. Name Segment Type Registry . . . . . . . . . . . . . . . 32 94 4.6. Message Type Registry . . . . . . . . . . . . . . . . . . 33 95 4.7. Payload Type Registry . . . . . . . . . . . . . . . . . . 34 96 4.8. Validation Algorithm Type Registry . . . . . . . . . . . 35 97 4.9. Validation Dependent Data Type Registry . . . . . . . . . 36 98 4.10. Hash Function Type Registry . . . . . . . . . . . . . . . 37 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 100 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 101 6.1. Normative References . . . . . . . . . . . . . . . . . . 39 102 6.2. Informative References . . . . . . . . . . . . . . . . . 39 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 105 1. Introduction 107 This document specifies a Type-Length-Value (TLV) packet format and 108 the TLV type and value encodings for CCNx messages. A full 109 description of the CCNx network protocol, providing an encoding-free 110 description of CCNx messages and message elements, may be found in 111 [CCNSemantics]. Several additional protocols specified in their own 112 documents are in use that extend this specification. 114 This document specifies: 116 o The TLV packet format. 118 o The overall packet format for CCNx messages. 120 o The TLV types used by CCNx messages. 122 o The encoding of values for each type. 124 o Top level types that exist at the outermost containment. 126 o Interest TLVs that exist within Interest containment. 128 o Content Object TLVs that exist within Content Object containment. 130 This document is supplemented by this document: 132 o Message semantics: see [CCNSemantics] for the protocol operation 133 regarding Interest and Content Object, including the Interest 134 Return protocol. 136 o URI notation: see [CCNxURI] for the CCNx URI notation. 138 The type values in Section 4 represent the values in common usage 139 today. These values may change pending IANA assignments. All type 140 values are relative to their parent containers. It is possible for a 141 TLV to redefine a type value defined by its parent. For example, 142 each level of a nested TLV structure might define a "type = 1" with a 143 completely different meaning. 145 Packets are represented as 32-bit wide words using ASCII art. Due to 146 the nested levels of TLV encoding and the presence of optional fields 147 and variable sizes, there is no concise way to represent all 148 possibilities. We use the convention that ASCII art fields enclosed 149 by vertical bars "|" represent exact bit widths. Fields with a 150 forward slash "/" are variable bit widths, which we typically pad out 151 to word alignment for picture readability. 153 1.1. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 2. Definitions 161 o Name: A hierarchically structured variable length identifier. It 162 is an ordered list of path segments, which may be variable length 163 octet strings. In human-readable form, it is represented in URI 164 format as ccnx:/path/part. There is no host or query string. See 165 [CCNxURI] for complete details. 167 o Interest: A message requesting a Content Object with a matching 168 Name and other optional selectors to choose from multiple objects 169 with the same Name. Any Content Object with a Name and optional 170 selectors that matches the Name and optional selectors of the 171 Interest is said to satisfy the Interest. 173 o Content Object: A data object sent in response to an Interest 174 request. It has an (optional) Name and a content payload that are 175 bound together via cryptographic means. 177 3. Type-Length-Value (TLV) Packets 179 We use 16-bit Type and 16-bit Length fields to encode TLV based 180 packets. This provides 64K different possible types and value field 181 lengths of up to 64KiB. With 64K possible types, there should be 182 sufficient space for basic protocol types, while also allowing ample 183 room for experimentation, application use, and growth. 185 Specifically, the TLV types in the range 0x1000 - 0x1FFF are reserved 186 for experimental use. These type values are reserved in all TLV 187 container contexts. In the event that more space is needed, either 188 for types or for length, a new version of the protocol would be 189 needed. See Section 3.3.2 for more information about organization 190 specific TLVs. 192 +--------+-------------------------+--------------------------------+ 193 | Abbrev | Name | Description | 194 +--------+-------------------------+--------------------------------+ 195 | T_ORG | Vendor Specific | Information specific to a | 196 | | Information (Section | vendor implementation (see | 197 | | 3.3.2) | below). | 198 | | | | 199 | n/a | Experimental | Experimental use. | 200 +--------+-------------------------+--------------------------------+ 202 Table 1: Reserved TLV Types 204 1 2 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +---------------+---------------+---------------+---------------+ 207 | Type | Length | 208 +---------------+---------------+---------------+---------------+ 210 The Length field contains the length of the Value field in octets. 211 It does not include the length of the Type and Length fields. They 212 length MAY be zero. 214 TLV structures are nestable, allowing the Value field of one TLV 215 structure to contain additional TLV structures. The enclosing TLV 216 structure is called the container of the enclosed TLV. 218 Type values are context-dependent. Within a TLV container, one may 219 re-use previous type values for new context-dependent purposes. 221 3.1. Overall packet format 223 Each packet includes the 8 byte fixed header described below, 224 followed by a set of TLV fields. These fields are optional hop-by- 225 hop headers and the Packet Payload. 227 1 2 3 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 229 +---------------+---------------+---------------+---------------+ 230 | Version | PacketType | PacketLength | 231 +---------------+---------------+---------------+---------------+ 232 | PacketType specific fields | HeaderLength | 233 +---------------+---------------+---------------+---------------+ 234 / Optional Hop-by-hop header TLVs / 235 +---------------+---------------+---------------+---------------+ 236 / PacketPayload TLVs / 237 +---------------+---------------+---------------+---------------+ 238 The packet payload is a TLV encoding of the CCNx message, followed by 239 optional Validation TLVs. 241 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +---------------+---------------+---------------+---------------+ 244 | CCNx Message TLV / 245 +---------------+---------------+---------------+---------------+ 246 / Optional CCNx ValidationAlgorithm TLV / 247 +---------------+---------------+---------------+---------------+ 248 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 249 +---------------+---------------+---------------+---------------+ 251 This document describes the Version "1" TLV encoding. 253 After discarding the fixed and hop-by-hop headers the remaining 254 PacketPayload should be a valid protocol message. Therefore, the 255 PacketPayload always begins with a 4 byte TLV defining the protocol 256 message (whether it is an Interest, Content Object, or other message 257 type) and its total length. The embedding of a self-sufficient 258 protocol data unit inside the fixed and hop-by-hop headers allows a 259 network stack to discard the headers and operate only on the embedded 260 message. 262 The range of bytes protected by the Validation includes the CCNx 263 Message and the ValidationAlgorithm. 265 The ContentObjectHash begins with the CCNx Message and ends at the 266 tail of the packet. 268 3.2. Fixed Headers 270 CCNx messages begin with an 8 byte fixed header (non-TLV format). 271 The HeaderLength field represents the combined length of the Fixed 272 and Hop-by-hop headers. The PacketLength field represents the entire 273 Packet length. 275 A specific PacketType may assign meaning to the "PacketType specific 276 fields". 278 The PacketPayload of a CCNx packet is the protocol message itself. 279 The Content Object Hash is computed over the PacketPayload only, 280 excluding the fixed and hop-by-hop headers as those might change from 281 hop to hop. Signed information or Similarity Hashes should not 282 include any of the fixed or hop-by-hop headers. The PacketPayload 283 should be self-sufficient in the event that the fixed and hop-by-hop 284 headers are removed. 286 1 2 3 287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 288 +---------------+---------------+---------------+---------------+ 289 | Version | PacketType | PacketLength | 290 +---------------+---------------+---------------+---------------+ 291 | PacketType specific fields | HeaderLength | 292 +---------------+---------------+---------------+---------------+ 294 o Version: defines the version of the packet. 296 o HeaderLength: The length of the fixed header (8 bytes) and hop-by- 297 hop headers. The minimum value MUST be "8". 299 o PacketType: describes forwarder actions to take on the packet. 301 o PacketLength: Total octets of packet including all headers (fixed 302 header plus hop-by-hop headers) and protocol message. 304 o PacketType Specific Fields: specific PacketTypes define the use of 305 these bits. 307 The PacketType field indicates how the forwarder should process the 308 packet. A Request Packet (Interest) has PacketType PT_INTEREST, a 309 Response (Content Object) has PacketType PT_CONTENT, and an 310 InterestReturn Packet has PacketType PT_RETURN. 312 HeaderLength is the number of octets from the start of the packet 313 (Version) to the end of the hop-by-hop headers. PacketLength is the 314 number of octets from the start of the packet to the end of the 315 packet. 317 The PacketType specific fields are reserved bits whose use depends on 318 the PacketType. They are used for network-level signaling. 320 3.2.1. Interest Fixed Header 322 If the PacketType in the Fixed Header is PT_INTEREST, it indicates 323 that the PacketPayload should be processed as an Interest message. 324 For this type of packet, the Fixed Header includes a field for a 325 HopLimit as well as Reserved and Flags fields. The Reserved field 326 MUST be set to 0 in an Interest - this field will be set to a return 327 code in the case of an Interest Return. There are currently no Flags 328 defined, so this field MUST be set to 0. 330 1 2 3 331 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 332 +---------------+---------------+---------------+---------------+ 333 | Version | PT_INTEREST | PacketLength | 334 +---------------+---------------+---------------+---------------+ 335 | HopLimit | Reserved | Flags | HeaderLength | 336 +---------------+---------------+---------------+---------------+ 338 3.2.1.1. Interest HopLimit 340 For an Interest message, the HopLimit is a counter that is 341 decremented with each hop. It limits the distance an Interest may 342 travel on the network. The node originating the Interest MAY put in 343 any value - up to the maximum of 255. Each node that receives an 344 Interest with a HopLimit decrements the value upon reception. If the 345 value is 0 after the decrement, the Interest MUST NOT be forwarded 346 off the node. 348 It is an error to receive an Interest with a 0 hop-limit from a 349 remote node. 351 3.2.2. Content Object Fixed Header 353 If the PacketType in the Fixed Header is PT_CONTENT, it indicates 354 that the PacketPayload should be processed as a Content Object 355 message. A Content Object defines a Flags field, however there are 356 currently no flags defined, so the Flags field must be set to 0. 358 1 2 3 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 360 +---------------+---------------+---------------+---------------+ 361 | Version | PT_CONTENT | PacketLength | 362 +---------------+---------------+---------------+---------------+ 363 | Reserved | Flags | HeaderLength | 364 +---------------+---------------+---------------+---------------+ 366 3.2.3. InterestReturn Fixed Header 368 If the PacketType in the Fixed Header is PT_RETURN, it indicates that 369 the PacketPayload should be processed as a returned Interest message. 370 The only difference between this InterestReturn message and the 371 original Interest is that the PacketType is changed to PT_RETURN and 372 a ReturnCode is is put into the Reserved octet. All other fields are 373 unchanged. The purpose of this encoding is to prevent packet length 374 changes so no additional bytes are needed to return an Interest to 375 the previous hop. See [CCNSemantics] for a protocol description of 376 this packet type. 378 1 2 3 379 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 380 +---------------+---------------+---------------+---------------+ 381 | Version | PT_RETURN | PacketLength | 382 +---------------+---------------+---------------+---------------+ 383 | HopLimit | ReturnCode | Flags | HeaderLength | 384 +---------------+---------------+---------------+---------------+ 386 3.2.3.1. InterestReturn HopLimit 388 This is the original Interest's HopLimit, as received. It is the 389 value before being decremented at the current node (i.e. the received 390 value). 392 3.2.3.2. InterestReturn Flags 394 These are the original Flags as set in the Interest. 396 3.2.3.3. Return Code 398 The numeric value assigned to the return types is defined below. 399 This value is set by the node creating the Interest Return. 401 A return code of "0" MUST NOT be used, as it indicates that the 402 returning system did not modify the Return Code field. 404 +-------------------------------------+-----------------------------+ 405 | Type | Return Type | 406 +-------------------------------------+-----------------------------+ 407 | T_RETURN_NO_ROUTE | No Route | 408 | | | 409 | T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded | 410 | | | 411 | T_RETURN_NO_RESOURCES | No Resources | 412 | | | 413 | T_RETURN_PATH_ERROR | Path Error | 414 | | | 415 | T_RETURN_PROHIBITED | Prohibited | 416 | | | 417 | T_RETURN_CONGESTED | Congested | 418 | | | 419 | T_RETURN_MTU_TOO_LARGE | MTU too large | 420 | | | 421 | T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa | 422 | ON | shRestriction | 423 | | | 424 | T_RETURN_MALFORMED_INTEREST | Malformed Interest | 425 +-------------------------------------+-----------------------------+ 427 Table 2: Return Codes 429 3.3. Global Formats 431 This section defines global formats that may be nested within other 432 TLVs. 434 3.3.1. Pad 436 The pad type may be used by protocols that prefer word-aligned data. 437 The size of the word may be defined by the protocol. Padding 4-byte 438 words, for example, would use a 1-byte, 2-byte, and 3-byte Length. 439 Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length. 441 A pad MAY be inserted after any TLV in the CCNx Message or in the 442 Validation Dependent Data In the remainder of this document, we will 443 not show optional pad TLVs. 445 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +---------------+---------------+---------------+---------------+ 448 | T_PAD | Length | 449 +---------------+---------------+---------------+---------------+ 450 / variable length pad MUST be zeros / 451 +---------------+---------------+---------------+---------------+ 453 3.3.2. Organization Specific TLVs 455 Organization specific TLVs MUST use the T_ORG type. The Length field 456 is the length of the organization specific information plus 3. The 457 Value begins with the 3 byte organization number derived from the 458 last three digits of the IANA Private Enterprise Numbers 459 [EpriseNumbers], followed by the organization specific information. 461 1 2 3 462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 463 +---------------+---------------+---------------+---------------+ 464 | T_ORG | Length (3+value length) | 465 +---------------+---------------+---------------+---------------+ 466 | PEN[0] | PEN[1] | PEN[2] | / 467 +---------------+---------------+---------------+ + 468 / Vendor Specific Value / 469 +---------------+---------------+---------------+---------------+ 471 3.3.3. Hash Format 473 Hash values are used in several fields throughout a packet. This TLV 474 encoding is commonly embedded inside those fields to specify the 475 specific hash function used and it's value. Note that the reserved 476 TLV types are also reserved here for user-defined experimental 477 functions. 479 The LENGTH field of the hash value MUST be less than or equal to the 480 hash function length. If the LENGTH is less than the full length, it 481 is taken as the left LENGTH bytes of the hash function output. Only 482 the specified truncations are allowed. 484 This nested format is used because it allows binary comparison of 485 hash values for certain fields without a router needing to understand 486 a new hash function. For example, the KeyIdRestriction is bit-wise 487 compared between an Interest's KeyIdRestriction field and a 488 ContentObject's KeyId field. This format means the outer field 489 values do not change with differing hash functions so a router can 490 still identify those fields and do a binary comparison of the hash 491 TLV without need to understand the specific hash used. An 492 alternative approach, such as using T_KEYID_SHA512-256, would require 493 each router keep an up-to-date parser and supporting user-defined 494 hash functions here would explode the parsing state-space. 496 A CCN entity MUST support the hash type T_SHA-256. An entity MAY 497 support the remaining hash types. 499 +-----------+------------------------+ 500 | Abbrev | Lengths (octets) | 501 +-----------+------------------------+ 502 | T_SHA-256 | 32 | 503 | | | 504 | T_SHA-512 | 64, 32 | 505 | | | 506 | n/a | Experimental TLV types | 507 +-----------+------------------------+ 509 Table 3: CCNx Hash Functions 511 1 2 3 512 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 513 +---------------+---------------+---------------+---------------+ 514 | T_FOO | 36 | 515 +---------------+---------------+---------------+---------------+ 516 | T_SHA512 | 32 | 517 +---------------+---------------+---------------+---------------+ 518 / 32-byte hash value / 519 +---------------+---------------+---------------+---------------+ 521 Example nesting inside type T_FOO 523 3.3.4. Link 525 A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. 526 It is a general encoding that is used in both the payload of a 527 Content Object with PayloadType = "Link" and in the KeyLink field in 528 a KeyLocator. 530 1 2 3 531 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 532 +---------------+---------------+-------------------------------+ 533 / Mandatory CCNx Name / 534 +---------------+---------------+-------------------------------+ 535 / Optional KeyIdRestriction / 536 +---------------------------------------------------------------+ 537 / Optional ContentObjectHashRestriction / 538 +---------------------------------------------------------------+ 540 3.4. Hop-by-hop TLV headers 542 Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached 543 to their ordering. Three hop-by-hop headers are described in this 544 document: 546 +-------------+-------------------+---------------------------------+ 547 | Abbrev | Name | Description | 548 +-------------+-------------------+---------------------------------+ 549 | T_INTLIFE | Interest Lifetime | The time an Interest should | 550 | | (Section 3.4.1) | stay pending at an intermediate | 551 | | | node. | 552 | | | | 553 | T_CACHETIME | Recommended Cache | The Recommended Cache Time for | 554 | | Time (Section | Content Objects. | 555 | | 3.4.2) | | 556 | | | | 557 | T_MSGHASH | Message Hash | The hash of the CCNx Message to | 558 | | (Section 3.4.3) | end of packet using Section | 559 | | | 3.3.3 format. | 560 +-------------+-------------------+---------------------------------+ 562 Table 4: Hop-by-hop Header Types 564 Additional hop-by-hop headers are defined in higher level 565 specifications such as the fragmentation specification. 567 3.4.1. Interest Lifetime 569 The Interest Lifetime is the time that an Interest should stay 570 pending at an intermediate node. It is expressed in milliseconds as 571 an unsigned, network byte order integer. 573 A value of 0 (encoded as 1 byte %x00) indicates the Interest does not 574 elicit a Content Object response. It should still be forwarded, but 575 no reply is expected. 577 1 2 3 578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 579 +---------------+---------------+---------------+---------------+ 580 | T_INTLIFE | Length | 581 +---------------+---------------+---------------+---------------+ 582 / / 583 / Lifetime (length octets) / 584 / / 585 +---------------+---------------+---------------+---------------+ 587 3.4.2. Recommended Cache Time 589 The Recommended Cache Time (RCT) is a measure of the useful lifetime 590 of a Content Object as assigned by a content producer or upstream 591 node. It serves as a guideline to the Content Store cache in 592 determining how long to keep the Content Object. It is a 593 recommendation only and may be ignored by the cache. This is in 594 contrast to the ExpiryTime (described in Section 3.6.2.2.2)which 595 takes precedence over the RCT and must be obeyed. 597 Because the Recommended Cache Time is an optional hop-by-hop header 598 and not a part of the signed message, a content producer may re-issue 599 a previously signed Content Object with an updated RCT without 600 needing to re-sign the message. There is little ill effect from an 601 attacker changing the RCT as the RCT serves as a guideline only. 603 The Recommended Cache Time (a millisecond timestamp) is a network 604 byte ordered unsigned integer of the number of milliseconds since the 605 epoch in UTC of when the payload expires. It is a 64-bit field. 607 1 2 3 608 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 609 +---------------+---------------+---------------+---------------+ 610 | T_CACHETIME | 8 | 611 +---------------+---------------+---------------+---------------+ 612 / / 613 / Recommended Cache Time / 614 / / 615 +---------------+---------------+---------------+---------------+ 617 3.4.3. Message Hash 619 Within a trusted domain, an operator may calculate the message hash 620 at a border device and insert that value into the hop-by-hop headers 621 of a message. An egress device should remove the value. This 622 permits intermediate devices within that trusted domain to match 623 against a ContentObjectHashRestriction without calculating it at 624 every hop. 626 The message hash is a cryptographic hash from the start of the CCNx 627 Message to the end of the packet. It is used to match against the 628 ContentObjectHashRestriction (Section 3.6.2.1.2). The Message Hash 629 may be of longer length than an Interest's restriction, in which case 630 the device should use the left bytes of the Message Hash to check 631 against the Interest's value. 633 The Message Hash may only carry one hash type and there may only be 634 one Message Hash header. 636 The Message Hash header is unprotected, so this header is only of 637 practical use within a trusted domain, such as an operator's 638 autonomous system. 640 1 2 3 641 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 642 +---------------+---------------+---------------+---------------+ 643 | T_MSGHASH | (length + 4) | 644 +---------------+---------------+---------------+---------------+ 645 | (hash type) | length | 646 +---------------+---------------+---------------+---------------+ 647 / hash value / 648 +---------------+---------------+---------------+---------------+ 650 Message Hash Header 652 3.5. Top-Level Types 654 The top-level TLV types listed below exist at the outermost level of 655 a CCNx protocol message. 657 +----------------------+-------------------+------------------------+ 658 | Abbrev | Name | Description | 659 +----------------------+-------------------+------------------------+ 660 | T_INTEREST | Interest (Section | An Interest | 661 | | 3.6) | MessageType. | 662 | | | | 663 | T_OBJECT | Content Object | A Content Object | 664 | | (Section 3.6) | MessageType | 665 | | | | 666 | T_VALIDATION_ALG | Validation | The method of message | 667 | | Algorithm | verification such as | 668 | | (Section 3.6.4.1) | Message Integrity | 669 | | | Check (MIC), a Message | 670 | | | Authentication Code | 671 | | | (MAC), or a | 672 | | | cryptographic | 673 | | | signature. | 674 | | | | 675 | T_VALIDATION_PAYLOAD | Validation | The validation output, | 676 | | Payload (Section | such as the CRC32C | 677 | | 3.6.4.2) | code or the RSA | 678 | | | signature. | 679 +----------------------+-------------------+------------------------+ 681 Table 5: CCNx Top Level Types 683 3.6. CCNx Message 685 This is the format for the CCNx protocol message itself. The CCNx 686 message is the portion of the packet between the hop-by-hop headers 687 and the Validation TLVs. The figure below is an expansion of the 688 "CCNx Message TLV" depicted in the beginning of Section 3. The CCNx 689 message begins with MessageType and runs through the optional 690 Payload. The same general format is used for both Interest and 691 Content Object messages which are differentiated by the MessageType 692 field. The first enclosed TLV of a CCNx Message is always the Name 693 TLV. This is followed by an optional Message TLVs and an optional 694 Payload TLV. 696 1 2 3 697 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 698 +---------------+---------------+---------------+---------------+ 699 | MessageType | MessageLength | 700 +---------------+---------------+---------------+---------------+ 701 | Name TLV (Type = T_NAME) | 702 +---------------+---------------+---------------+---------------+ 703 / Optional Message TLVs (Various Types) / 704 +---------------+---------------+---------------+---------------+ 705 / Optional Payload TLV (Type = T_PAYLOAD) / 706 +---------------+---------------+---------------+---------------+ 708 +-----------+-----------------+-------------------------------------+ 709 | Abbrev | Name | Description | 710 +-----------+-----------------+-------------------------------------+ 711 | T_NAME | Name (Section | The CCNx Name requested in an | 712 | | 3.6.1) | Interest or published in a Content | 713 | | | Object. | 714 | | | | 715 | T_PAYLOAD | Payload | The message payload. | 716 | | (Section 3.6.3) | | 717 +-----------+-----------------+-------------------------------------+ 719 Table 6: CCNx Message Types 721 3.6.1. Name 723 A Name is a TLV encoded sequence of segments. The table below lists 724 the type values appropriate for these Name segments. A Name MUST NOT 725 include PAD TLVs. 727 As described in CCNx Semantics [CCNSemantics], using the CCNx URI 728 [CCNxURI] notation, a T_NAME with 0 length corresponds to ccnx:/ (the 729 default route) and is distinct from a name with one zero length 730 segment, such as ccnx:/NAME=. In the TLV encoding, ccnx:/ 731 corresponds to T_NAME with 0 length, while ccnx:/NAME= corresponds to 732 T_NAME with 4 length and T_NAMESEGMENT with 0 length. 734 1 2 3 735 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 736 +---------------+---------------+---------------+---------------+ 737 | T_NAME | Length | 738 +---------------+---------------+---------------+---------------+ 739 / Name segment TLVs / 740 +---------------+---------------+---------------+---------------+ 742 +---------------+-------------------+-------------------------------+ 743 | Symbolic Name | Name | Description | 744 +---------------+-------------------+-------------------------------+ 745 | T_NAMESEGMENT | Name segment | A generic name Segment. | 746 | | (Section 3.6.1.1) | | 747 | | | | 748 | T_IPID | Interest Payload | An identifier that represents | 749 | | ID (Section | the Interest Payload field. | 750 | | 3.6.1.2) | As an example, the Payload ID | 751 | | | might be a hash of the | 752 | | | Interest Payload. This | 753 | | | provides a way to | 754 | | | differentiate between | 755 | | | Interests based on their | 756 | | | payloads without having to | 757 | | | parse all the bytes of the | 758 | | | payload itself; instead using | 759 | | | only this Payload ID Name | 760 | | | segment. | 761 | | | | 762 | T_APP:00 - | Application | Application-specific payload | 763 | T_APP:4096 | Components | in a name segment. An | 764 | | (Section 3.6.1.1) | application may apply its own | 765 | | | semantics to the 4096 | 766 | | | reserved types. | 767 +---------------+-------------------+-------------------------------+ 769 Table 7: CCNx Name Types 771 3.6.1.1. Name Segments 773 4096 special application payload name segments are allocated. These 774 have application semantics applied to them. A good convention is to 775 put the application's identity in the name prior to using these name 776 segments. 778 For example, a name like "ccnx:/foo/bar/hi" would be encoded as: 780 1 2 3 781 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 782 +---------------+---------------+---------------+---------------+ 783 | (T_NAME) | %x14 (20) | 784 +---------------+---------------+---------------+---------------+ 785 | (T_NAME_SEGMENT) | %x03 (3) | 786 +---------------+---------------+---------------+---------------+ 787 | f o o |(T_NAME_SEGMENT) 788 +---------------+---------------+---------------+---------------+ 789 | | %x03 (3) | b | 790 +---------------+---------------+---------------+---------------+ 791 | a r | (T_NAME_SEGMENT) | 792 +---------------+---------------+---------------+---------------+ 793 | %x02 (2) | h | i | 794 +---------------+---------------+---------------+---------------+ 796 3.6.1.2. Interest Payload ID 798 The InterestPayloadID is a name segment created by the origin of an 799 Interest to represent the Interest Payload. This allows the proper 800 multiplexing of Interests based on their name if they have different 801 payloads. A common representation is to use a hash of the Interest 802 Payload as the InterestPayloadID. 804 As part of the TLV 'value', the InterestPayloadID contains a one 805 identifier of method used to create the InterestPayloadID followed by 806 a variable length octet string. An implementation is not required to 807 implement any of the methods to receive an Interest; the 808 InterestPayloadID may be treated only as an opaque octet string for 809 purposes of multiplexing Interests with different payloads. Only a 810 device creating an InterestPayloadID name segment or a device 811 verifying such a segment need to implement the algorithms. 813 It uses the Section 3.3.3 encoding of hash values. 815 In normal operations, we recommend displaying the InterestPayloadID 816 as an opaque octet string in a CCNx URI, as this is the common 817 denominator for implementation parsing. 819 The InterestPayloadID, even if it is a hash, should not convey any 820 security context. If a system requires confirmation that a specific 821 entity created the InterestPayload, it should use a cryptographic 822 signature on the Interest via the ValidationAlgorithm and 823 ValidationPayload or use its own methods inside the Interest Payload. 825 3.6.2. Message TLVs 827 Each message type (Interest or Content Object) is associated with a 828 set of optional Message TLVs. Additional specification documents may 829 extend the types associated with each. 831 3.6.2.1. Interest Message TLVs 833 There are two Message TLVs currently associated with an Interest 834 message: the KeyIdRestriction selector and the ContentObjectHashRestr 835 selector are used to narrow the universe of acceptable Content 836 Objects that would satisfy the Interest. 838 1 2 3 839 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 840 +---------------+---------------+---------------+---------------+ 841 | MessageType | MessageLength | 842 +---------------+---------------+---------------+---------------+ 843 | Name TLV | 844 +---------------+---------------+---------------+---------------+ 845 / Optional KeyIdRestriction TLV / 846 +---------------------------------------------------------------+ 847 / Optional ContentObjectHashRestriction TLV / 848 +---------------------------------------------------------------+ 850 +----------------+------------------------------+-------------------+ 851 | Abbrev | Name | Description | 852 +----------------+------------------------------+-------------------+ 853 | T_KEYIDRESTR | KeyIdRestriction (Section | A Section 3.3.3 | 854 | | 3.6.2.1.1) | representation of | 855 | | | the KeyId | 856 | | | | 857 | T_OBJHASHRESTR | ContentObjectHashRestriction | A Section 3.3.3 | 858 | | (Section 3.6.2.1.2) | representation of | 859 | | | the hash of the | 860 | | | specific Content | 861 | | | Object that would | 862 | | | satisfy the | 863 | | | Interest. | 864 +----------------+------------------------------+-------------------+ 866 Table 8: CCNx Interest Message TLV Types 868 3.6.2.1.1. KeyIdRestriction 870 An Interest MAY include a KeyIdRestriction selector. This ensures 871 that only Content Objects with matching KeyIds will satisfy the 872 Interest. See Section 3.6.4.1.4.1 for the format of a KeyId. 874 3.6.2.1.2. ContentObjectHashRestriction 876 An Interest MAY contain a ContentObjectHashRestriction selector. 877 This is the hash of the Content Object - the self-certifying name 878 restriction that must be verified in the network, if an Interest 879 carried this restriction. It is calculated from the beginning of the 880 CCNx Message to the end of the packet. The LENGTH MUST be from one 881 of the allowed values for that hash (see Section 3.3.3). 883 The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of 884 length 32 bytes. 886 1 2 3 887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 888 +---------------+---------------+---------------+---------------+ 889 | T_OBJHASHRESTR | LENGTH+4 | 890 +---------------+---------------+---------------+---------------+ 891 | | LENGTH | 892 +---------------+---------------+---------------+---------------+ 893 / LENGTH octets of hash / 894 +---------------+---------------+---------------+---------------+ 896 3.6.2.2. Content Object Message TLVs 898 The following message TLVs are currently defined for Content Objects: 899 PayloadType (optional) and ExpiryTime (optional). 901 1 2 3 902 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 903 +---------------+---------------+---------------+---------------+ 904 | MessageType | MessageLength | 905 +---------------+---------------+---------------+---------------+ 906 | Name TLV | 907 +---------------+---------------+---------------+---------------+ 908 / Optional PayloadType TLV / 909 +---------------------------------------------------------------+ 910 / Optional ExpiryTime TLV / 911 +---------------------------------------------------------------+ 912 +-------------+---------------------+-------------------------------+ 913 | Abbrev | Name | Description | 914 +-------------+---------------------+-------------------------------+ 915 | T_PAYLDTYPE | PayloadType | Indicates the type of Payload | 916 | | (Section 3.6.2.2.1) | contents. | 917 | | | | 918 | T_EXPIRY | ExpiryTime (Section | The time at which the Payload | 919 | | 3.6.2.2.2) | expires, as expressed in the | 920 | | | number of milliseconds since | 921 | | | the epoch in UTC. If | 922 | | | missing, Content Object may | 923 | | | be used as long as desired. | 924 +-------------+---------------------+-------------------------------+ 926 Table 9: CCNx Content Object Message TLV Types 928 3.6.2.2.1. PayloadType 930 The PayloadType is a network byte order integer representing the 931 general type of the Payload TLV. 933 o T_PAYLOADTYPE_DATA: Data (possibly encrypted) 935 o T_PAYLOADTYPE_KEY: Key 937 o T_PAYLOADTYPE_LINK: Link 939 The Data type indicate that the Payload of the ContentObject is 940 opaque application bytes. The Key type indicates that the Payload is 941 a DER encoded public key. The Link type indicates that the Payload 942 is one or more Link (Section 3.3.4). If this field is missing, a 943 "Data" type is assumed. 945 1 2 3 946 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 947 +---------------+---------------+---------------+---------------+ 948 | T_PAYLDTYPE | Length | 949 +---------------+---------------+---------------+---------------+ 950 | PayloadType / 951 +---------------+ 953 3.6.2.2.2. ExpiryTime 955 The ExpiryTime is the time at which the Payload expires, as expressed 956 by a timestamp containing the number of milliseconds since the epoch 957 in UTC. It is a network byte order unsigned integer in a 64-bit 958 field. A cache or end system should not respond with a Content 959 Object past its ExpiryTime. Routers forwarding a Content Object do 960 not need to check the ExpiryTime. If the ExpiryTime field is 961 missing, the Content Object has no expressed expiration and a cache 962 or end system may use the Content Object for as long as desired. 964 1 2 3 965 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 966 +---------------+---------------+---------------+---------------+ 967 | T_EXPIRY | 8 | 968 +---------------+---------------+---------------+---------------+ 969 / ExpiryTime / 970 / / 971 +---------------+---------------+---------------+---------------+ 973 3.6.3. Payload 975 The Payload TLV contains the content of the packet. It MAY be of 976 zero length. If a packet does not have any payload, this field MAY 977 be omitted, rather than carrying a zero length. 979 1 2 3 980 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 981 +---------------+---------------+---------------+---------------+ 982 | T_PAYLOAD | Length | 983 +---------------+---------------+---------------+---------------+ 984 / Payload Contents / 985 +---------------+---------------+---------------+---------------+ 987 3.6.4. Validation 989 Both Interests and Content Objects have the option to include 990 information about how to validate the CCNx message. This information 991 is contained in two TLVs: the ValidationAlgorithm TLV and the 992 ValidationPayload TLV. The ValidationAlgorithm TLV specifies the 993 mechanism to be used to verify the CCNx message. Examples include 994 verification with a Message Integrity Check (MIC), a Message 995 Authentication Code (MAC), or a cryptographic signature. The 996 ValidationPayload TLV contains the validation output, such as the 997 CRC32C code or the RSA signature. 999 An Interest would most likely only use a MIC type of validation - a 1000 crc, checksum, or digest. 1002 3.6.4.1. Validation Algorithm 1004 The ValidationAlgorithm is a set of nested TLVs containing all of the 1005 information needed to verify the message. The outermost container 1006 has type = T_VALIDATION_ALG. The first nested TLV defines the 1007 specific type of validation to be performed on the message. The type 1008 is identified with the "ValidationType" as shown in the figure below 1009 and elaborated in the table below. Nested within that container are 1010 the TLVs for any ValidationType dependent data, for example a Key Id, 1011 Key Locator etc. 1013 Complete examples of several types may be found in Section 3.6.4.1.5 1015 1 2 3 1016 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1017 +---------------+---------------+---------------+---------------+ 1018 | T_VALIDATION_ALG | ValidationAlgLength | 1019 +---------------+---------------+---------------+---------------+ 1020 | ValidationType | Length | 1021 +---------------+---------------+---------------+---------------+ 1022 / ValidationType dependent data / 1023 +---------------+---------------+---------------+---------------+ 1025 +---------------+---------------------+-----------------------------+ 1026 | Abbrev | Name | Description | 1027 +---------------+---------------------+-----------------------------+ 1028 | T_CRC32C | CRC32C (Section | Castagnoli CRC32 (iSCSI, | 1029 | | 3.6.4.1.1) | ext4, etc.), with normal | 1030 | | | form polynomial 0x1EDC6F41. | 1031 | | | | 1032 | T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) using | 1033 | | (Section 3.6.4.1.2) | SHA256 hash. | 1034 | | | | 1035 | T_RSA-SHA256 | RSA-SHA256 (Section | RSA public key signature | 1036 | | 3.6.4.1.3) | using SHA256 digest. | 1037 | | | | 1038 | EC-SECP-256K1 | SECP-256K1 (Section | Elliptic Curve signature | 1039 | | 3.6.4.1.3) | with SECP-256K1 parameters | 1040 | | | (see [ECC]). | 1041 | | | | 1042 | EC-SECP-384R1 | SECP-384R1 (Section | Elliptic Curve signature | 1043 | | 3.6.4.1.3) | with SECP-384R1 parameters | 1044 | | | (see [ECC]). | 1045 +---------------+---------------------+-----------------------------+ 1047 Table 10: CCNx Validation Types 1049 3.6.4.1.1. Message Integrity Checks 1051 MICs do not require additional data in order to perform the 1052 verification. An example is CRC32C that has a "0" length value. 1054 3.6.4.1.2. Message Authentication Checks 1056 MACs are useful for communication between two trusting parties who 1057 have already shared private keys. Examples include an RSA signature 1058 of a SHA256 digest or others. They rely on a KeyId. Some MACs might 1059 use more than a KeyId, but those would be defined in the future. 1061 3.6.4.1.3. Signature 1063 Signature type Validators specify a digest mechanism and a signing 1064 algorithm to verify the message. Examples include RSA signature og a 1065 SHA256 digest, an Elliptic Curve signature with SECP-256K1 1066 parameters, etc. These Validators require a KeyId and a mechanism 1067 for locating the publishers public key (a KeyLocator) - optionally a 1068 PublicKey or Certificate or KeyLink. 1070 3.6.4.1.4. Validation Dependent Data 1072 Different Validation Algorithms require access to different pieces of 1073 data contained in the ValidationAlgorithm TLV. As described above, 1074 Key Ids, Key Locators, Public Keys, Certificates, Links and Key Names 1075 all play a role in different Validation Algorithms. Any number of 1076 Validation Dependent Data containers can be present in a Validation 1077 Algorithm TLV. 1079 Following is a table of CCNx ValidationType dependent data types: 1081 +-------------+-----------------------+-----------------------------+ 1082 | Abbrev | Name | Description | 1083 +-------------+-----------------------+-----------------------------+ 1084 | T_KEYID | SignerKeyId (Section | An identifier of the shared | 1085 | | 3.6.4.1.4.1) | secret or public key | 1086 | | | associated with a MAC or | 1087 | | | Signature. | 1088 | | | | 1089 | T_PUBLICKEY | Public Key (Section | DER encoded public key. | 1090 | | 3.6.4.1.4.2) | | 1091 | | | | 1092 | T_CERT | Certificate (Section | DER encoded X509 | 1093 | | 3.6.4.1.4.3) | certificate. | 1094 | | | | 1095 | T_KEYLINK | KeyLink (Section | A CCNx Link object. | 1096 | | 3.6.4.1.4.4) | | 1097 | | | | 1098 | T_SIGTIME | SignatureTime | A millsecond timestamp | 1099 | | (Section 3.6.4.1.4.5) | indicating the time when | 1100 | | | the signature was created. | 1101 +-------------+-----------------------+-----------------------------+ 1103 Table 11: CCNx Validation Dependent Data Types 1105 3.6.4.1.4.1. KeyId 1107 The KeyId is the publisher key identifier. It is similar to a 1108 Subject Key Identifier from X509 [RFC 5280, Section 4.2.1.2]. It 1109 should be derived from the key used to sign, such as from the SHA-256 1110 hash of the key. It applies to both public/private key systems and 1111 to symmetric key systems. 1113 The KeyId is represented using the Section 3.3.3. If a protocol uses 1114 a non-hash identifier, it should use one of the reserved values. 1116 1 2 3 1117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1118 +---------------+---------------+---------------+---------------+ 1119 | T_KEYID | LENGTH+4 | 1120 +---------------+---------------+---------------+---------------+ 1121 | | LENGTH | 1122 +---------------+---------------+---------------+---------------+ 1123 / LENGTH octets of hash / 1124 +---------------+---------------+---------------+---------------+ 1126 3.6.4.1.4.2. Public Key 1128 A Public Key is a DER encoded Subject Public Key Info block, as in an 1129 X509 certificate. 1131 1 1132 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1133 +---------------+---------------+---------------+---------------+ 1134 | T_PUBLICKEY | Length | 1135 +---------------+---------------+---------------+---------------+ 1136 / Public Key (DER encoded SPKI) / 1137 +---------------+---------------+---------------+---------------+ 1139 3.6.4.1.4.3. Certificate 1141 1 2 3 1142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1143 +---------------+---------------+---------------+---------------+ 1144 | T_CERT | Length | 1145 +---------------+---------------+---------------+---------------+ 1146 / Certificate (DER encoded X509) / 1147 +---------------+---------------+---------------+---------------+ 1149 3.6.4.1.4.4. KeyLink 1151 A KeyLink type KeyLocator is a Link. 1153 The KeyLink ContentObjectHashRestr, if included, is the digest of the 1154 Content Object identified by KeyLink, not the digest of the public 1155 key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the 1156 ContentObject, not necessarily of the wrapped key. 1158 1 2 3 1159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1160 +---------------+---------------+-------------------------------+ 1161 | T_KEYKINK | Length | 1162 +---------------+---------------+-------------------------------+ 1163 / Link / 1164 +---------------------------------------------------------------+ 1166 3.6.4.1.4.5. SignatureTime 1168 The SignatureTime is a millisecond timestamp indicating the time at 1169 which a signature was created. The signer sets this field to the 1170 current time when creating a signature. A verifier may use this time 1171 to determine whether or not the signature was created during the 1172 validity period of a key, or if it occurred in a reasonable sequence 1173 with other associated signatures. The SignatureTime is unrelated to 1174 any time associated with the actual CCNx Message, which could have 1175 been created long before the signature. The default behavior is to 1176 always include a SignatureTime when creating an authenticated message 1177 (e.g. HMAC or RSA). 1179 SignatureTime is a network byte ordered unsigned integer of the 1180 number of milliseconds since the epoch in UTC of when the signature 1181 was created. It is a fixed 64-bit field. 1183 1 2 3 1184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1185 +---------------+---------------+-------------------------------+ 1186 | T_SIGTIME | 8 | 1187 +---------------+---------------+-------------------------------+ 1188 / SignatureTime / 1189 +---------------------------------------------------------------+ 1191 3.6.4.1.5. Validation Examples 1193 As an example of a MIC type validation, the encoding for CRC32C 1194 validation would be: 1196 1 2 3 1197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1198 +---------------+---------------+---------------+---------------+ 1199 | T_VALIDATION_ALG | 4 | 1200 +---------------+---------------+---------------+---------------+ 1201 | T_CRC32C | 0 | 1202 +---------------+---------------+---------------+---------------+ 1204 As an example of a MAC type validation, the encoding for an HMAC 1205 using a SHA256 hash would be: 1207 1 2 3 1208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1209 +---------------+---------------+---------------+---------------+ 1210 | T_VALIDATION_ALG | 40 | 1211 +---------------+---------------+---------------+---------------+ 1212 | T_HMAC-SHA256 | 36 | 1213 +---------------+---------------+---------------+---------------+ 1214 | T_KEYID | 32 | 1215 +---------------+---------------+---------------+---------------+ 1216 / KeyId / 1217 /---------------+---------------+-------------------------------+ 1219 As an example of a Signature type validation, the encoding for an RSA 1220 public key signing using a SHA256 digest and Public Key would be: 1222 1 2 3 1223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1224 +---------------+---------------+---------------+---------------+ 1225 | T_VALIDATION_ALG | 44 + Variable Length | 1226 +---------------+---------------+---------------+---------------+ 1227 | T_RSA-SHA256 | 40 + Variable Length | 1228 +---------------+---------------+---------------+---------------+ 1229 | T_KEYID | 32 | 1230 +---------------+---------------+---------------+---------------+ 1231 / KeyId / 1232 /---------------+---------------+-------------------------------+ 1233 | T_PUBLICKEY | Variable Length (~ 160) | 1234 +---------------+---------------+---------------+---------------+ 1235 / Public Key (DER encoded SPKI) / 1236 +---------------+---------------+---------------+---------------+ 1238 3.6.4.2. Validation Payload 1240 1 2 3 1241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1242 +---------------+---------------+---------------+---------------+ 1243 | T_VALIDATION_PAYLOAD | ValidationPayloadLength | 1244 +---------------+---------------+---------------+---------------+ 1245 / Type-dependent data / 1246 +---------------+---------------+---------------+---------------+ 1248 The ValidationPayload contains the validation output, such as the 1249 CRC32C code or the RSA signature. 1251 4. IANA Considerations 1253 This section details each kind of protocol value that can be 1254 registered. Each type registry can be updated by incrementally 1255 expanding the type space, i.e., by allocating and reserving new 1256 types. As per [RFC5226] this section details the creation of the 1257 "CCNx Registry" and several sub-registries. 1259 +----------+---------------+ 1260 | Property | Value | 1261 +----------+---------------+ 1262 | Name | CCNx Registry | 1263 | | | 1264 | Abbrev | CCNx | 1265 +----------+---------------+ 1267 Registry Creation 1269 4.1. Packet Type Registry 1271 The following packet types should be allocated. A PacketType MUST be 1272 1 byte. New packet types are allocated via "RFC Required" action. 1274 +----------------+----------------------+ 1275 | Property | Value | 1276 +----------------+----------------------+ 1277 | Name | Packet Type Registry | 1278 | | | 1279 | Parent | CCNx Registry | 1280 | | | 1281 | Review process | RFC Required | 1282 | | | 1283 | Syntax | 1 octet (decimal) | 1284 +----------------+----------------------+ 1286 Registry Creation 1288 +------+-------------+----------------------------------+ 1289 | Type | Name | Reference | 1290 +------+-------------+----------------------------------+ 1291 | 0 | PT_INTEREST | Fixed Header Types (Section 3.2) | 1292 | | | | 1293 | 1 | PT_CONTENT | Fixed Header Types (Section 3.2) | 1294 | | | | 1295 | 2 | PT_RETURN | Fixed Header Types (Section 3.2) | 1296 +------+-------------+----------------------------------+ 1298 Packet Type Namespace 1300 4.2. Interest Return Code Registry 1302 The following InterestReturn code types should be allocated. 1304 +--------------+----------------------------------------------------+ 1305 | Property | Value | 1306 +--------------+----------------------------------------------------+ 1307 | Name | Interest Return Code | 1308 | | | 1309 | Parent | CCNx Registry | 1310 | | | 1311 | Review | Expert Review, should include public standard | 1312 | process | leading to RFC. | 1313 | | | 1314 | Syntax | 1 octet (decimal) | 1315 +--------------+----------------------------------------------------+ 1317 Registry Creation 1319 +------+---------------------------------------+--------------------+ 1320 | Type | Name | Reference | 1321 +------+---------------------------------------+--------------------+ 1322 | 1 | T_RETURN_NO_ROUTE | Fixed Header Types | 1323 | | | (Section 3.2.3.3) | 1324 | | | | 1325 | 2 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types | 1326 | | | (Section 3.2.3.3) | 1327 | | | | 1328 | 3 | T_RETURN_NO_RESOURCES | Fixed Header Types | 1329 | | | (Section 3.2.3.3) | 1330 | | | | 1331 | 4 | T_RETURN_PATH_ERROR | Fixed Header Types | 1332 | | | (Section 3.2.3.3) | 1333 | | | | 1334 | 5 | T_RETURN_PROHIBITED | Fixed Header Types | 1335 | | | (Section 3.2.3.3) | 1336 | | | | 1337 | 6 | T_RETURN_CONGESTED | Fixed Header Types | 1338 | | | (Section 3.2.3.3) | 1339 | | | | 1340 | 7 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types | 1341 | | | (Section 3.2.3.3) | 1342 | | | | 1343 | 8 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types | 1344 | | | (Section 3.2.3.3) | 1345 | | | | 1346 | 9 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types | 1347 | | | (Section 3.2.3.3) | 1348 +------+---------------------------------------+--------------------+ 1350 Interest Return Type Namespace 1352 4.3. Hop-by-Hop Type Registry 1354 The following hop-by-hop types should be allocated. 1356 +----------------+----------------------------+ 1357 | Property | Value | 1358 +----------------+----------------------------+ 1359 | Name | Hop-by-Hop Type Registry | 1360 | | | 1361 | Parent | CCNx Registry | 1362 | | | 1363 | Review process | RFC Required | 1364 | | | 1365 | Syntax | 2 octet TLV type (decimal) | 1366 +----------------+----------------------------+ 1368 Registry Creation 1370 +---------------+-------------+-------------------------------------+ 1371 | Type | Name | Reference | 1372 +---------------+-------------+-------------------------------------+ 1373 | 1 | T_INTLIFE | Hop-by-hop TLV headers (Section | 1374 | | | 3.4) | 1375 | | | | 1376 | 2 | T_CACHETIME | Hop-by-hop TLV headers (Section | 1377 | | | 3.4) | 1378 | | | | 1379 | 3 | T_MSGHASH | Hop-by-hop TLV headers (Section | 1380 | | | 3.4) | 1381 | | | | 1382 | 4 - 7 | Reserved | | 1383 | | | | 1384 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1385 | | | | 1386 | %x0FFF | T_ORG | Organization-Specific TLVs (Section | 1387 | | | 3.3.2) | 1388 | | | | 1389 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1390 +---------------+-------------+-------------------------------------+ 1392 Hop-by-Hop Type Namespace 1394 4.4. Top-Level Type Registry 1396 The following top-level types should be allocated. 1398 +----------------+----------------------------+ 1399 | Property | Value | 1400 +----------------+----------------------------+ 1401 | Name | Top-Level Type Registry | 1402 | | | 1403 | Parent | CCNx Registry | 1404 | | | 1405 | Review process | RFC Required | 1406 | | | 1407 | Syntax | 2 octet TLV type (decimal) | 1408 +----------------+----------------------------+ 1410 Registry Creation 1412 +------+----------------------+-------------------------------+ 1413 | Type | Name | Reference | 1414 +------+----------------------+-------------------------------+ 1415 | 1 | T_INTEREST | Top-Level Types (Section 3.5) | 1416 | | | | 1417 | 2 | T_OBJECT | Top-Level Types (Section 3.5) | 1418 | | | | 1419 | 3 | T_VALIDATION_ALG | Top-Level Types (Section 3.5) | 1420 | | | | 1421 | 4 | T_VALIDATION_PAYLOAD | Top-Level Types (Section 3.5) | 1422 +------+----------------------+-------------------------------+ 1424 Top-Level Type Namespace 1426 4.5. Name Segment Type Registry 1428 The following name segment types should be allocated. 1430 +----------------+-----------------------------------------+ 1431 | Property | Value | 1432 +----------------+-----------------------------------------+ 1433 | Name | Name Segment Type Registry | 1434 | | | 1435 | Parent | CCNx Registry | 1436 | | | 1437 | Review process | Expert Review with public specification | 1438 | | | 1439 | Syntax | 2 octet TLV type (decimal) | 1440 +----------------+-----------------------------------------+ 1442 Registry Creation 1444 +--------------+------------------+---------------------------------+ 1445 | Type | Name | Reference | 1446 +--------------+------------------+---------------------------------+ 1447 | 1 | T_NAMESEGMENT | Name (Section 3.6.1) | 1448 | | | | 1449 | 2 | T_IPID | Name (Section 3.6.1) | 1450 | | | | 1451 | 16 - 19 | Reserved | Used in other drafts | 1452 | | | | 1453 | %x0FFF | T_ORG | Organization-Specific TLVs | 1454 | | | (Section 3.3.2) | 1455 | | | | 1456 | %x1000 - | T_APP:00 - | Application Components (Section | 1457 | %x1FFF | T_APP:4096 | 3.6.1) | 1458 +--------------+------------------+---------------------------------+ 1460 Name Segment Type Namespace 1462 4.6. Message Type Registry 1464 The following CCNx message segment types should be allocated. 1466 +----------------+----------------------------+ 1467 | Property | Value | 1468 +----------------+----------------------------+ 1469 | Name | Message Type Registry | 1470 | | | 1471 | Parent | CCNx Registry | 1472 | | | 1473 | Review process | RFC Required | 1474 | | | 1475 | Syntax | 2 octet TLV type (decimal) | 1476 +----------------+----------------------------+ 1478 Registry Creation 1480 +---------------+----------------+----------------------------------+ 1481 | Type | Name | Reference | 1482 +---------------+----------------+----------------------------------+ 1483 | 0 | T_NAME | Message Types (Section 3.6) | 1484 | | | | 1485 | 1 | T_PAYLOAD | Message Types (Section 3.6) | 1486 | | | | 1487 | 2 | T_KEYIDRESTR | Message Types (Section 3.6) | 1488 | | | | 1489 | 3 | T_OBJHASHRESTR | Message Types (Section 3.6) | 1490 | | | | 1491 | 5 | T_PAYLDTYPE | Content Object Message Types | 1492 | | | (Section 3.6.2.2) | 1493 | | | | 1494 | 6 | T_EXPIRY | Content Object Message Types | 1495 | | | (Section 3.6.2.2) | 1496 | | | | 1497 | 7 - 12 | Reserved | Used in other RFC drafts | 1498 | | | | 1499 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1500 | | | | 1501 | %x0FFF | T_ORG | Organization-Specific TLVs | 1502 | | | (Section 3.3.2) | 1503 | | | | 1504 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1505 +---------------+----------------+----------------------------------+ 1507 CCNx Message Type Namespace 1509 4.7. Payload Type Registry 1511 The following payload types should be allocated. 1513 +----------------+--------------------------------------------+ 1514 | Property | Value | 1515 +----------------+--------------------------------------------+ 1516 | Name | PayloadType Registry | 1517 | | | 1518 | Parent | CCNx Registry | 1519 | | | 1520 | Review process | Expert Review with public specification | 1521 | | | 1522 | Syntax | Variable length unsigned integer (decimal) | 1523 +----------------+--------------------------------------------+ 1525 Registry Creation 1527 +------+--------------------+-----------------------------------+ 1528 | Type | Name | Reference | 1529 +------+--------------------+-----------------------------------+ 1530 | 0 | T_PAYLOADTYPE_DATA | Payload Types (Section 3.6.2.2.1) | 1531 | | | | 1532 | 1 | T_PAYLOADTYPE_KEY | Payload Types (Section 3.6.2.2.1) | 1533 | | | | 1534 | 2 | T_PAYLOADTYPE_LINK | Payload Types (Section 3.6.2.2.1) | 1535 +------+--------------------+-----------------------------------+ 1537 Payload Type Namespace 1539 4.8. Validation Algorithm Type Registry 1541 The following validation algorithm types should be allocated. 1543 +---------------+---------------------------------------------------+ 1544 | Property | Value | 1545 +---------------+---------------------------------------------------+ 1546 | Name | Validation Algorithm Type Registry | 1547 | | | 1548 | Parent | CCNx Registry | 1549 | | | 1550 | Review | Expert Review with public specification of the | 1551 | process | algorithm | 1552 | | | 1553 | Syntax | 2 octet TLV type (decimal) | 1554 +---------------+---------------------------------------------------+ 1556 Registry Creation 1558 +---------------+---------------+-----------------------------------+ 1559 | Type | Name | Reference | 1560 +---------------+---------------+-----------------------------------+ 1561 | 2 | T_CRC32C | Validation Algorithm (Section | 1562 | | | 3.6.4.1) | 1563 | | | | 1564 | 4 | T_HMAC-SHA256 | Validation Algorithm (Section | 1565 | | | 3.6.4.1) | 1566 | | | | 1567 | 5 | T_RSA-SHA256 | Validation Algorithm (Section | 1568 | | | 3.6.4.1) | 1569 | | | | 1570 | 6 | EC-SECP-256K1 | Validation Algorithm (Section | 1571 | | | 3.6.4.1) | 1572 | | | | 1573 | 7 | EC-SECP-384R1 | Validation Algorithm (Section | 1574 | | | 3.6.4.1) | 1575 | | | | 1576 | %x0FFE | T_PAD | Pad (Section 3.3.1) | 1577 | | | | 1578 | %x0FFF | T_ORG | Organization-Specific TLVs | 1579 | | | (Section 3.3.2) | 1580 | | | | 1581 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1582 +---------------+---------------+-----------------------------------+ 1584 Validation Algorithm Type Namespace 1586 4.9. Validation Dependent Data Type Registry 1588 The following validation dependent data types should be allocated. 1590 +----------------+-----------------------------------------+ 1591 | Property | Value | 1592 +----------------+-----------------------------------------+ 1593 | Name | Validation Dependent Data Type Registry | 1594 | | | 1595 | Parent | CCNx Registry | 1596 | | | 1597 | Review process | RFC Required | 1598 | | | 1599 | Syntax | 2 octet TLV type (decimal) | 1600 +----------------+-----------------------------------------+ 1602 Registry Creation 1604 +---------------+----------------+----------------------------------+ 1605 | Type | Name | Reference | 1606 +---------------+----------------+----------------------------------+ 1607 | 9 | T_KEYID | Validation Dependent Data | 1608 | | | (Section 3.6.4.1.4) | 1609 | | | | 1610 | 10 | T_PUBLICKEYLOC | Validation Dependent Data | 1611 | | | (Section 3.6.4.1.4) | 1612 | | | | 1613 | 11 | T_PUBLICKEY | Validation Dependent Data | 1614 | | | (Section 3.6.4.1.4) | 1615 | | | | 1616 | 12 | T_CERT | Validation Dependent Data | 1617 | | | (Section 3.6.4.1.4) | 1618 | | | | 1619 | 13 | T_LINK | Validation Dependent Data | 1620 | | | (Section 3.6.4.1.4) | 1621 | | | | 1622 | 14 | T_KEYLINK | Validation Dependent Data | 1623 | | | (Section 3.6.4.1.4) | 1624 | | | | 1625 | 15 | T_SIGTIME | Validation Dependent Data | 1626 | | | (Section 3.6.4.1.4) | 1627 | | | | 1628 | %x0FFF | T_ORG | Organization-Specific TLVs | 1629 | | | (Section 3.3.2) | 1630 | | | | 1631 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1632 +---------------+----------------+----------------------------------+ 1634 Validation Dependent Data Type Namespace 1636 4.10. Hash Function Type Registry 1638 The following CCNx hash function types should be allocated. 1640 +--------------+----------------------------------------------------+ 1641 | Property | Value | 1642 +--------------+----------------------------------------------------+ 1643 | Name | Hash Function Type Registry | 1644 | | | 1645 | Parent | CCNx Registry | 1646 | | | 1647 | Review | Expert Review with public specification of the | 1648 | process | hash function | 1649 | | | 1650 | Syntax | 2 octet TLV type (decimal) | 1651 +--------------+----------------------------------------------------+ 1653 Registry Creation 1655 +---------------+-----------+---------------------------------------+ 1656 | Type | Name | Reference | 1657 +---------------+-----------+---------------------------------------+ 1658 | 1 | T_SHA-256 | Hash Format (Section 3.3.3) | 1659 | | | | 1660 | 2 | T_SHA-512 | Hash Format (Section 3.3.3) | 1661 | | | | 1662 | %x0FFF | T_ORG | Organization-Specific TLVs (Section | 1663 | | | 3.3.2) | 1664 | | | | 1665 | %x1000-%x1FFF | Reserved | Experimental Use (Section 3) | 1666 +---------------+-----------+---------------------------------------+ 1668 CCNx Hash Function Type Namespace 1670 5. Security Considerations 1672 The CCNx message format includes the ability to attach MICs, MACs, 1673 and Signatures to all packet types. This does not mean that it is a 1674 good idea to use an arbitrary ValidationAlgorithm, nor to include 1675 computationally expensive algorithms in Interest packets, as that 1676 could lead to computational DoS attacks. Application protocols 1677 should use an explicit protocol to guide their use of packet 1678 signatures. 1680 The CCNx message format does not include explicit guidance for 1681 encryption. This is covered by other specifications. 1683 Because some implementations may store the entire Name at 1684 intermediate hops, application designers should use concise names and 1685 not store large fields there. Deployments may choose to use their 1686 own guidelines for name limitations. There is currently no 1687 recommended practices for Interest deployments. 1689 6. References 1691 6.1. Normative References 1693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1694 Requirement Levels", BCP 14, RFC 2119, 1695 DOI 10.17487/RFC2119, March 1997, . 1698 6.2. Informative References 1700 [CCN] PARC, Inc., "CCNx Open Source", 2007, 1701 . 1703 [CCNSemantics] 1704 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics 1705 (Internet draft)", 2017, . 1708 [CCNxURI] Mosko, M. and C. Wood, "The CCNx URI Scheme (Internet 1709 draft)", 2017, 1710 . 1712 [ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve 1713 Domain Parameters", 2010, 1714 . 1716 [EpriseNumbers] 1717 IANA, "IANA Private Enterprise Numbers", 2015, 1718 . 1721 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1722 Text on Security Considerations", BCP 72, RFC 3552, 1723 DOI 10.17487/RFC3552, July 2003, . 1726 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1727 IANA Considerations Section in RFCs", RFC 5226, 1728 DOI 10.17487/RFC5226, May 2008, . 1731 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1732 Housley, R., and W. Polk, "Internet X.509 Public Key 1733 Infrastructure Certificate and Certificate Revocation List 1734 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1735 . 1737 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1738 Keranen, A., and P. Hallam-Baker, "Naming Things with 1739 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1740 . 1742 Authors' Addresses 1744 Marc Mosko 1745 PARC, Inc. 1746 Palo Alto, California 94304 1747 USA 1749 Phone: +01 650-812-4405 1750 Email: marc.mosko@parc.com 1752 Ignacio Solis 1753 LinkedIn 1754 Mountain View, California 94043 1755 USA 1757 Email: nsolis@linkedin.com 1759 Christopher A. Wood 1760 University of California Irvine 1761 Irvine, California 92697 1762 USA 1764 Phone: +01 315-806-5939 1765 Email: woodc1@uci.edu