Calendaring Extensions R. Tse
Internet-Draft P. Tam
Updates: Ribose
5545,6321,6350,6351,7953,7265,7 April 19, 2018
095 (if approved)
Intended status: Standards Track
Expires: October 21, 2018

Integrity Protection for vObject, vCard and iCalendar
draft-calconnect-vobject-integrity-01

Abstract

This document specifies an integrity checking mechanism and related properties for:

This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 21, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. TODOs

2. Introduction

The ubiquitous vCard and iCalendar standards, also known together as the "vObject" family of standards [I-D.calconnect-vobject-vformat], powers digital contact exchanges, calendaring and scheduling on billions of devices today.

Integrity 2.1.2 is a key property of "information security" defined as the "preservation of confidentiality, integrity and availability of information" 2.33. When provided with a vObject, however, there is no inherent method to detect its own data integrity.

In reality, people are known to exchange vCard and iCalendar data through unreliable means, which could affect data integrity during its data lifecycle:

Previous standards were established in a time where integrity concerns were less widespread, and relied solely on data transport, application and storage integrity without considering on whether the content transmitted, processed or retrieved was as intended without modification or corruption.

This document specifically deals with information integrity in face of the following risks:

The standards subject to such risks include:

This document provides:

Organizations that implement information security management systems, such as [ISO-IEC-27001], MAY find this document applicable to their own processes.

The decision to update the existing vCard version 4 [RFC6350] and iCalendar [RFC5545] standards were chosen to maintain maximum backwards compatibility.

This work is produced by the CalConnect TC-VCARD [CALCONNECT-VCARD] and TC-CALENDAR [CALCONNECT-CALENDAR] committees.

3. Terms and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The key words "Private Use", "Experimental Use", "Hierarchical Allocation", "First Come First Served", "Expert Review", "Specification Required", "RFC Required", "IETF Review", "Standards Action" and "IESG Approval" in this document are to be interpreted as described in 4.

The definitions from [I-D.calconnect-vobject-vformat] are inherited in this document unless explicitly overriden.

3.1. Definitions

Implementation Supported Checksum

An implementation is considered to support checksum calculation if it is able to calculate the checksum without external aid, i.e., it supports the parameters specified to calculate the checksum value.
Source Preferred Checksum Value (SPCV)

A CHECKSUM property that includes a PREF property parameter.
Receiver Preferred Checksum Value (RPCV)

The CHECKSUM property that uses the implementation’s preferred checksum parameters.

4. Symbols And Abbreviations

4.1. Functions

These functions are REQUIRED and MUST be implemented for compliance to this document.

4.1.1. SORT

Sorts an list according to alphabetical order (A-Z).

4.1.2. LIST-TO-TEXT

This function returns a Unicode string (7) containing a string representation of a list of string values, each followed by a selected delimiter character.

LIST-TO-TEXT(list, delimiter) =
  value(list, 1) + delimiter +
  value(list, 2) + delimiter +
  ...
  value(list, last-element-position(list))

where: * + indicates concatenation; * value(l, i) is the i-th value in the list l in string representation; * last-element-position(a) returns the last element position of list l.

4.1.3. PREPHASH-PROPERTY-PARAMETER-KEY

This function returns a Unicode string (7) representation of the normalized property parameter key.

PREPHASH-PROPERTY-PARAMETER-KEY(parameter) = normalize(key(parameter))

where: * + indicates concatenation; * key(parameter) is the property parameter key; * normalize(s) is a function that normalizes the key s.

4.1.4. PREPHASH-PROPERTY-PARAMETER-VALUES

This function returns a Unicode string (7) representation of the normalized property parameter values.

PREPHASH-PROPERTY-PARAMETER-VALUES(parameter) =
  LIST-TO-TEXT(
    SORT(
      values(parameter, 1),
      values(parameter, 2),
      ...
    ),
    ";"
  )

where: * + indicates concatenation; * values(parameter, i) is the i-th property parameter value in parameter.

4.1.5. PREPHASH-PROPERTY-PARAMETER

Converts a property parameter into a string, with its key and values.

This function returns a Unicode string (7) containing a sequence of zero or more list values in string format, each followed by a ';' character.

PREPHASH-PROPERTY-PARAMETER(parameter) =
  "{" +
    PREPHASH-PROPERTY-PARAMETER-KEY(property) + ":" +
    PREPHASH-PROPERTY-PARAMETER-VALUES(property) +
  "}"

where: * + indicates concatenation.

4.1.6. PREPHASH-PROPERTY-PARAMETERS

This function returns a Unicode string (7) representation of a set of property parameters.

We exclude the VALUE property parameter in this calculation (such as VALUE=TEXT) as this information is represented in PREPHASH-PROPERTY-VALUE-HASHA.

PREPHASH-PROPERTY-PARAMETERS(property) =
  "#" +
  LIST-TO-TEXT(
    SORT([
      PREPHASH-PROPERTY-PARAMETER(parameter(property, 1)),
      PREPHASH-PROPERTY-PARAMETER(parameter(property, 2)),
      ...
    ]),
    ";"
  )

where: * + indicates concatenation; * parameters(property, i) is the i-th parameter of property.

4.1.7. PREPHASH-PROPERTY-KEY

This function returns a Unicode string (7) representation of the normalized property key.

PREPHASH-PROPERTY-KEY(property) = normalize(key(property))

where: * + indicates concatenation; * key(property) is the property key; * normalize(s) is a function that normalizes the key s.

4.1.8. PREPHASH-PROPERTY-VALUE-HASHA

This function returns a Unicode string (7) representation of the normalized property value type. Since the property value type is represented here, we exclude the VALUE property parameter in PREPHASH-PROPERTY-PARAMETERS (such as VALUE=TEXT)

PREPHASH-PROPERTY-VALUE-HASHA(property) = UPCASE(type(property))

where: * + indicates concatenation; * type(property) is the property value type, if not explicitly provided, it should be filled in according to [RFC6350]; * normalize(s) is a function that normalizes the property value type s.

4.1.9. PREPHASH-PROPERTY-VALUES

This function returns a Unicode string (7) representation of the normalized property values.

Certain content types allow storing multiple values (as a list) in the same property line. For example, in the ADR and N properties, values are separated by the ";" delimiter, while in NICKNAME and CATEGORIES they are separated by the "," delimiter 3.3.

PREPHASH-PROPERTY-VALUES(property) =
  LIST-TO-TEXT(
    SORT(
      values(property, 1),
      values(property, 2),
      ...
    ),
    ";"
  )

where: * + indicates concatenation; * values(property, i) is the i-th property value in property.

4.1.10. PREPHASH-PROPERTY

This function returns a Unicode string (7) representation of a single property.

PREPHASH-PROPERTY(property) =
  PREPHASH-PROPERTY-KEY(property) + ":" +
  PREPHASH-PROPERTY-VALUE-HASHA(property) + "/" +
  PREPHASH-PROPERTY-VALUES(property) + "?" +
  PREPHASH-PROPERTY-PARAMETERS(property)

where: * + indicates concatenation

4.1.11. HASH-PROPERTY

This function returns a Unicode string (7) representation of a single property.

HASH-PROPERTY-TO-TEXT(property) =
  PREPHASH-PROPERTY-KEY(property) + ":" +
  HASH(PREPHASH-PROPERTY(property)

where: * + indicates concatenation

4.1.12. HASH-AND-PREPHASH-PROPERTIES

This function returns a Unicode string (7) representation of a set of properties.

HASH-AND-PREPHASH-PROPERTIES(properties) =
  LIST-TO-TEXT(
    SORT([
      HASH-PROPERTY(property(properties, 1)),
      HASH-PROPERTY(property(properties, 2)),
      ...
    ]),
    CRLF
  )

where: * + indicates concatenation; * property(properties, i) is the i-th property of properties; * HASH(s) is selected cryptographic hash function applied to string s.

4.1.13. PREPHASH-COMPONENT-NAME

This function returns a Unicode string (7) representation of the normalized vObject name.

PREPHASH-COMPONENT-NAME(component) = normalize(name(component))

where: * name(c) is the component name of component c.

4.1.14. PREPHASH-COMPONENT

This function returns a Unicode string (7) representation of a vObject. The similarity of this representation with the vObject structure is intentional for readability purposes.

PREPHASH-COMPONENT(component) =
  "BEGIN:" + PREPHASH-COMPONENT-NAME(component) + ":CHECKSUM" + CRLF +
    HASH-AND-PREPHASH-PROPERTIES(properties(component)) + CRLF +
  "END:" + PREPHASH-COMPONENT-NAME(component) + ":CHECKSUM"

where: * + indicates concatenation; * properties(c) returns the properties of the component c in an list;

4.1.15. HASH-COMPONENT

This function returns a Unicode string (7) as the output of a selected cryptographic hash function applied on a vObject.

HASH-COMPONENT(component) = HASH(PREPHASH-COMPONENT(component))

4.1.16. HASH

This function returns the calculated hash of an input string and outputs the hash in string representation.

HASH(string) = generate-hash-function(
                 selected-hash-function,
                 selected-hash-parameters
               )(string)

where: * generate-hash-function(a, p) creates a new cryptographic hash function that uses the hash algorithm a with algorithm parameters p which takes a string input and generates the hash using a string output; * selected-hash-function is the selected cryptographic hash algorithm selected by the user (and/or CUA); * selected-hash-parameters are the selected parameters for the selected cryptographic hash function by the user (and/or CUA), and could be different per algorithm.

5. Properties

Property cardinalities are indicated in the same method as provided by [RFC6350] based on ABNF 3.6.

5.1. CHECKSUM

These registration details for the CHECKSUM property adhere to rules specified in 10.2.1.

5.1.1. Namespace

Nil.

5.1.2. Property name

CHECKSUM

5.1.3. Purpose

Allows content integrity detection and verification against data corruption of a vObject.

5.1.4. Value type

A single text value.

5.1.5. Cardinality

*

5.1.6. Property parameters

HASHA, HASHP

5.1.7. Value

TEXT

5.1.8. Description

CHECKSUM is an OPTIONAL property of a vObject. There can be multiple CHECKSUM properties within the same vObject. vObject client implementations are RECOMMENDED to implement CHECKSUM for a basic level of integrity guarantee.

The CHECKSUM value used to compare the checksum of data should be selected in this way:

5.1.9. Format definition

ABNF:

CHECKSUM-param =  "VALUE=text"
CHECKSUM-param =  pid-param / pref-param / altid-param /
                  checksum-param-hasha / checksum-param-hashp /
                  iana-token

CHECKSUM-value = TEXT
  ; Value type and VALUE parameter MUST match.

5.1.10. Examples

CHECKSUM:
  ad58ca4f14b317dea48987f4991bdcd56fdf0f6a95049623f0fe5c4453d157e0

CHECKSUM;PREF=99:
  3ac0e03cccda6663ed32052749cc5c607d88e381f9cfcb795317bc39a57909e3

CHECKSUM;HASHA=sha224:
  22e92efac9d7b0e63695a9d960376ace1e69eb317e3d42c5c94f1401

6. Property Parameters

The CHECKSUM allowed property parameters of PID, PREF, ALTID have the same meaning as on other properties [RFC6350].

6.1. PREF Property Parameter

The PREF property parameter indicates the preference of the vCard author on which CHECKSUM value to put most weight on.

Usage of this parameter is further explained in Section 7.

6.2. HASHA Property Parameter

Registration details for the HASHA property parameter adhere to rules specified in 10.2.1

6.2.1. Namespace

Nil.

6.2.2. Parameter name

HASHA

6.2.3. Purpose

Specify the hash function used for the property value

6.2.4. Description

Possible values are defined in Section 14.3.

The HASHA Property Parameter MUST not be applied on properties other than CHECKSUM unless specified.

New HASHA hash functions MUST be specified in a Standards Track RFC.

6.2.5. Format definition

ABNF:

hasha-param = "HASHA=" hasha-value *("," hasha-value)

hasha-value = "sha3-256" / iana-token / x-name
; This is further defined in <<checksum_functions>>

6.2.6. Examples:

CHECKSUM;HASHA=sha384:
  4055b176af753e251bc269007569c8f9633e6227a5f9727381cfba0bbb44a0c9
  25b8d31d72083d9cb4dc1da278f3a4e4
CHECKSUM;HASHA=streebog256:
  TODO

6.3. HASHP Property Parameter

Certain hash functions such as extendable output functions (XOFs) can be customized:

Since each hash function may take different specifiers, each hash function identifier MAY specify its own set of HASHP specifiers in a particular order. The parameter value(s) entered MUST conform to the hash function’s specification in a Standards Track RFC. An implementation MUST follow the value type interpretation specified for the hash function.

For example, in Section 9.1.1, the cSHAKE-128 algorithm (with the identifier cshake128) takes (L, N, S) as input, where L is an integer to specify the output bit length, N is a text string representing the function name, S is a text string for customization purposes. When given a HASHP parameter value "512,address book,Orange", for the HASHA identifier cshake128, the implementation MUST recognize that L is the integer 512, N is the string "address book", and S is the string "Orange".

Registration details for the HASHP property parameter adhere to rules specified in 10.2.1

6.3.1. Namespace

Nil.

6.3.2. Parameter name

HASHP

6.3.3. Purpose

Describe hash function specifiers used for the property value.

6.3.4. Description

Provide specifiers for the HASHA hash function used to calculate the property value.

Possible values are defined in Section 14.4.

The HASHP Property Parameter MUST not be applied on properties other than CHECKSUM unless specified.

6.3.5. Format definition

ABNF:

hashp-param = "HASHP=" hashp-value *("," hashp-value)

hashp-value = param-value
; This list of values must be specified in the exact order and value
  type defined in <<supported_table>>

Example(s):

CHECKSUM;HASHA=shake128;HASHP=512,"Directory Service Identifier":
  TODO
CHECKSUM;HASHA=parallelhash128;HASHP=64,512:
  TODO

7. Integrity Validation

7.1. Integrity In The vObject Life Cycle

Data integrity is important during storage and transmission of a vObject.

If an implementation stores vObjects directly on disk or in memory, it is RECOMMENDED that:

An implementation that supports CHECKSUM MUST adhere to the following rules:

7.2. vObject Validity States

There are 3 validity states of a vObject:

Valid

This vObject is not corrupt.
Invalid

This vObject is corrupt.
Unable to determine

This vObject does not provide enough information to make a validity judgement.

7.3. Integrity Validity When Presented With A Single CHECKSUM Property

Given one CHECKSUM property, an implementation that supports the CHECKSUM property SHOULD reach the following conclusions about the vObject:

7.4. Integrity Validity When Presented With Multiple CHECKSUM Properties

If a vObject has more than one non-empty CHECKSUM property, an implementation should validate according to the rules below.

  1. In the order of preference stated (PREF parameter value), validate all supported SPCV until one is verified.
  2. If a vObject does not have any SPCV, or the implementation does not support any SPCV, but contains a supported CHECKSUM property

8. Method of CHECKSUM Value Calculation

The following method to calculate CHECKSUM is devised for these desired properties:

For implementations that handle CHECKSUM, its calculation MUST be performed after all property updates including REV, which is often updated during save.

Steps to calculate CHECKSUM:

  1. Calculate the hash value of the vObject
    1. Determine the need to add a new CHECKSUM property.
      • If there is no existing CHECKSUM property, add it as the last property of the vObject, with the selected cryptographic hash algorithm type and the selected hash parameters. Its value should be set to "" (empty string).
      • If there is an existing CHECKSUM property:
        • If its parameters are identical to the user’s current settings (or the CUA’s defaults), there is no need to add an extra CHECKSUM property. Set its value to "" (empty string).
        • Otherwise, add the extra CHECKSUM property as described above.
    2. Normalize the vObject in data model form (in accordance with [I-D.calconnect-vobject-vformat])
    3. For each normalized property (including the newly added CHECKSUM property):
      i.
      For each normalized property parameter:
      A.
      For each normalized property parameter value:
      I.
      Obtain pre-hash string representation of the property parameter value
      II.
      Calculate hash value of the string representation of the property parameter value
      B.
      Obtain pre-hash string representation of the property parameter using hashes of its property parameter values
      C.
      Calculate hash value of the string representation of the property parameter
      ii.
      For each normalized property value:
      A.
      Obtain pre-hash string representation of the property value
      B.
      Calculate hash value of the string representation of the property value
      iii.
      Obtain pre-hash string representation of the property using hashes of its property values and property parameters
      iv.
      Calculate hash value of the string representation of the property
    4. Obtain pre-hash string representation of the vObject itself using hashes of its properties
    5. Calculate hash value of the string representation of the vObject.
  2. This procedure is repeated to calculate the value for every CHECKSUM property (which may specify different cryptographic hash algorithms and parameters), with all CHECKSUM values set to "" (empty string) for calculation consistency.
  3. Enter the calculated CHECKSUM value for each CHECKSUM property.
  4. The checksum calculation procedure is complete.

9. Cryptographic Hash Functions

The CHECKSUM value is calculated by a chosen cryptographic hash function specified in the HASHA property parameter. Certain hash functions accept customization specifiers, which can be specified in the HASHP property parameter.

9.1. Supported Hash Functions

CHECKSUM supports the following hash algorithms.

9.1.1. Hash Function Specifiers

CHECKSUM supported hash algorithms are listed in the following table.

Algorithms with no specifiers:

Algorithm Identifier Message Digest Size (bits) Description
SHA-2 SHA-224 sha224 224 [RFC6234]; [NIST-FIPS-180-4]; [ISO-IEC-10118-3] Dedicated Hash-Function 8 (SHA-224)
SHA-2 SHA-256 sha256 256 [RFC6234]; [NIST-FIPS-180-4]; [ISO-IEC-10118-3] Dedicated Hash-Function 4 (SHA-256)
SHA-2 SHA-384 sha384 384 [RFC6234]; [NIST-FIPS-180-4]; [ISO-IEC-10118-3] Dedicated Hash-Function 6 (SHA-384)
SHA-2 SHA-512 sha512 512 [RFC6234]; [NIST-FIPS-180-4]; [ISO-IEC-10118-3] Dedicated Hash-Function 5 (SHA-512)
SHA-2 SHA-512/224 sha512-224 224 [NIST-FIPS-180-4]; [ISO-IEC-10118-3] Dedicated Hash-Function 9 (SHA-512/224)
SHA-2 SHA-512/256 sha512-256 256 [NIST-FIPS-180-4]; [ISO-IEC-10118-3] Dedicated Hash-Function 10 (SHA-512/256)
WHIRLPOOL whirlpool 512 [WHIRLPOOL]; [ISO-IEC-10118-3] Dedicated Hash-Function 7 (WHIRLPOOL)
STREEBOG-256 streebog256 256 [STREEBOG] GOST R 34.11-2012; [RFC6986]; [ISO-IEC-10118-3] Dedicated Hash-Function 12 (STREEBOG-256)
STREEBOG-512 streebog512 512 [STREEBOG] GOST R 34.11-2012; [RFC6986]; [ISO-IEC-10118-3] Dedicated Hash-Function 11 (STREEBOG-512)
SHA3-224 sha3-224 224 [NIST-FIPS-202]; [ISO-IEC-10118-3] Dedicated Hash-Function 13 (SHA3-224)
SHA3-256 sha3-256 256 [NIST-FIPS-202]; [ISO-IEC-10118-3] Dedicated Hash-Function 14 (SHA3-256)
SHA3-384 sha3-384 384 [NIST-FIPS-202]; [ISO-IEC-10118-3] Dedicated Hash-Function 15 (SHA3-384)
SHA3-512 sha3-512 512 [NIST-FIPS-202]; [ISO-IEC-10118-3] Dedicated Hash-Function 16 (SHA3-512)
SM3 sm3 512 <<?I-D.shen-sm3-hash>>; [SM3]; [ISO-IEC-10118-3] Dedicated Hash-Function 17 (SM3)
IANA registered hash algorithm iana-token iana-token IANA
Vendor-specific hash algorithm x-token Vendor specific Vendor specific

Algorithms with specifiers:

Algorithm Identifier Message Digest Size (bits) Specifier(s) Description
SHAKE-128 shake128 Varys L: integer (default: 256) [NIST-FIPS-202]
SHAKE-256 shake256 Varys L: integer (default: 512) [NIST-FIPS-202]
cSHAKE-128 cshake128 Varys L: integer (default: 256), N: text (default: ""), S: text (default: "") [NIST-SP-800-185]
cSHAKE-256 cshake256 Varys L: integer (default: 512), N: text (default: ""), S: text (default: "") [NIST-SP-800-185]
ParallelHash-128 parallel128 Varys B: integer (default: 64), L: integer (default: 256), S: text (default: "") [NIST-SP-800-185]
ParallelHash-256 parallel256 Varys B: integer (default: 64), L: integer (default: 256), S: text (default: "") [NIST-SP-800-185]
IANA registered hash algorithm iana-token iana-token iana-token IANA
Vendor-specific hash algorithm x-token Vendor specific Vendor specific Vendor specific

9.1.1.1. Example

sha3-256('BEGIN:VCARD') = "f1fcbc9bddcd44b1e50db99a277bc868" +
                          "61736eb32cb30ef7e7a2c9ef95c05d50"

The default algorithm is sha3-256. An implementation that supports this document MUST support at least the sha3-256 function.

9.1.2. The SHA-2 Hash Functions

Secure Hash Algorithm 2 (SHA-2) is a family of secure hash algorithms defined in [NIST-FIPS-180-4]: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256.

9.1.3. The WHIRLPOOL Hash Function

WHIRLPOOL is a hash function that operates on messages less than 2^256 bits in length, and produces a hash value of 512 bits [WHIRLPOOL].

It uses Merkle-Damgard strengthening and the Miyaguchi-Preneel hashing scheme with a dedicated 512-bit block cipher called W [WHIRLPOOL].

9.1.4. The SM3 Hash Function

SM3 is a hash function <<?I-D.shen-sm3-hash>> standardized by the Chinese Commercial Cryptography Administration Office [SM3] for the use of electronic authentication service systems.

SM3 is an iterated hash function based on a Merkle-Damgard design, processes on 512-bit input message blocks with a 256-bit state, and produces a 256-bit hash value.

9.1.5. The SHA-3 Hash Functions

Secure Hash Algorithm-3 (SHA-3) is a family of hash functions defined in [NIST-FIPS-202] consisting of:

Each SHA-3 function is based on an instance of the KECCAK algorithm [KECCAK] which won the SHA-3 Cryptographic Hash Algorithm Competition [NIST-FIPS-202].

Notes concerning SHA-3 based XOFs [NIST-FIPS-202]:

9.1.6. The STREEBOG Hash Functions

Streebog (or Stribog) is a family of two separate hash functions defined in the Russian standard GOST R 34.11-2012 [STREEBOG] where the functions differ in their output lengths, which are 256- and 512-bits respectively.

Streebog accepts message block sizes of 512-bits, and both functions only differ in the different IVs used other than the output length [STREEBOG].

9.1.7. The BLAKE2 Hash Functions

BLAKE2, described in [BLAKE2] and [RFC7693], is a hash algorithm that comes in two flavors, BLAKE2b and BLAKE2s. It is the successor of BLAKE [BLAKE] which was a NIST SHA-3 competition finalist.

While BLAKE2 allows customizing parameters, including salt and a customization string, implementations that adhere to this specification should adopt BLAKE2 as defined in [RFC7693].

9.1.8. The SHA-3 Extension Hash Functions

[NIST-SP-800-185] defines a number of additional hash algorithms based on algorithms defined in [NIST-FIPS-202], including:

Both cSHAKE and ParallelHash are XOFs that can produce variable length output. The number suffix at their names mean the security strength bits of the algorithm.

9.2. Selection Considerations

9.2.1. Collision Resistance of Hash Function Families

For our purposes we specify the following strength families of hash algorithms. Hash functions placed in the higher bracket are considered "more resistant" in algorithm selection.

Strength Hash Function Identifier
1 sha224, sha256, sha384, sha512, sha512-224, sha512-256
2 whirlpool, streebog256, streebog512
3 blake2b256, blake2b384, blake2b512, blake2s224, blake2s256, sm3, shake128, shake256, sha3-224, sha3-256, sha3-384, sha3-512

9.2.2. Guidelines for Hash Function Selection

Selection of the hash function should be based on a balance of collision resistance, performance, history and interoperability.

9.2.3. Hash Functions Considered Unsuitable

The following hash functions are specifically excluded due to stated reasons:

10. Using CHECKSUM With Server Support

10.1. Usage of CHECKSUM in vCards on CardDAV servers

CardDAV servers are RECOMMENDED to calculate and provide an extra CHECKSUM property for al vCard retrieval requests in order to provide a base level of integrity guarantee.

The CHECKSUM property and its parameters are fully compatible with the CardDAV mechanism described in [RFC6352].

10.1.1. Creating And Updating Address Object Resources

6.3.2 specifies how to create address object resources.

An implementation abiding to this specification MUST augment this process according to the following.

10.1.1.1. Client Implementations Should Transmit With CHECKSUM

10.1.2. Additional Server Semantics for PUT, COPY and MOVE

This specification creates an additional precondition and postcondition for the PUT, COPY, and MOVE methods when:

10.1.2.1. Only Admit Valid vCard Data From Client

10.1.2.2. Additional Precondition

(CARDDAV:valid-address-data-checksum) The address object resource submitted in the PUT request, or targeted by a COPY or MOVE request, contains a CHECKSUM property:

10.1.2.3. Resolve Discrepancy Between Server And Client vCard Data

Certain servers perform silent changes or cleanups of client provided vCard data when stored as address object resources, such as the order of property parameters or scrubbed values.

The resulting vCard data stored on the server (and when returned back to the client) may end up different than that of the client without its knowledge. It is therefore necessary for the client to be reported on such modifications.

10.1.2.4. Additional Postcondition

(CARDDAV:resource-not-modified): The address object resource should not be modified by the server such that its original CHECKSUM value becomes invalid.

10.2. Usage of CHECKSUM with CalDAV

The CalDAV [RFC4791] calendar access protocol allows clients and servers to exchange iCalendar data. iCalendar data is typically stored in calendar object resources on a CalDAV server.

A CalDAV server is RECOMMENDED to return iCalendar data with integrity protection.

10.2.1. Creating Calendar Resources

A CalDAV client typically updates the calendar object resource data via an HTTP PUT request, which requires sending the entire iCalendar object in the HTTP request body.

10.3. Usage of CHECKSUM with iTIP

iTIP [RFC5546] defines how iCalendar data can be sent between calendar user agents to schedule calendar components between calendar users.

This specification is compatible with iTIP transfer of iCalendar data.

11. Alternative vObject Representations

11.1. xCard

The XML representation [RFC6351] of the CHECKSUM property follows the example shown below. For this property, the value type MUST be set to "text" and parameter "type" MUST also be set to "text".

<checksum>
  <parameters>
    <hasha>
      <text>sha224</text>
    </hasha>
    <pref>
      <integer>99</integer>
    </pref>
  </parameters>
  <text>22e92efac9d7b0e63695a9d960376ace1e69eb317e3d42c5c94f1401</text>
</checksum>

11.2. jCard

The JSON representation of the CHECKSUM property follows [RFC7095] as the example shown below.

["checksum",
  { "hasha": "sha224", "pref": "99" },
  "text",
  "22e92efac9d7b0e63695a9d960376ace1e69eb317e3d42c5c94f1401"
]

12. Implementation Notes

12.1. vCard REV Update Guidelines For The CHECKSUM Property

Updating of the CHECKSUM property value should not affect the REV value of a vCard. However, if a CHECKSUM property is newly inserted, or its parameters changed (such as HASHA or HASHP), then the REV value should be updated according to [RFC6350].

12.2. Calculating CHECKSUM From An xCard

Implementers MUST ignore individual parameter value types in xCard (6, Appendix A 4.1) during CHECKSUM value calculation to be compatible with vCard and jCard, as individual parameter value types are implicit (not explicitly represented) in both vCard and jCard properties.

12.3. Backwards Compatibility Concerns

If an implementation does not support the CHECKSUM property, it MUST ignore the CHECKSUM property entirely without providing it any value. If an incorrect value is provided, the receiving end of this vObject may falsely assume that the vObject is broken.

12.4. Unsupported Property Parameters

12.5. Recommendations for Client User Applications

12.5.1. User Experience

12.5.2. Ongoing Improvements

13. Security Considerations

14. IANA Considerations

14.1. Common vObject Registries

The IANA has created and will maintain the following registries under the heading "vObject Common Elements".

The registry policy is Specification Required; any newly proposed specification MUST be reviewed by the designated expert.

14.2. Registration Procedure For New Hash Functions And Hash Function Specifiers

This section defines the process for registering new or modified hash functions and hash function specifiers with IANA.

The IETF mailing lists for vObject (vobject@ietf.org), CardDAV (vcarddav@ietf.org) and CalDAV (vcaldav@ietf.org) SHOULD be used for public discussion of additional hash functions and hash function specifiers for the CHECKSUM property prior to registration.

The registration procedure specified in [RFC6350] should be followed to register additional hash functions and hash function specifiers for vObjects.

14.3. vObject Hash Functions Registry

The registry policy is Specification Required; any newly proposed registration MUST be reviewed by the designated expert.

The registry SHOULD contain the following note:

Note: Experts are to verify that the proposed registration
*SHOULD* provide benefits for the wider vObject community,
and provides a publicly-available standard that can be implemented in
an interoperable way. Hash functions are preferrably approved by the CFRG
with references to IETF-published documents. The "Reference" value should
point to a document that details the implementation of this hash function
in the vObject context.

14.3.1. Registration Template for vObject Hash Functions

A Hash Function is defined by completing the following template.

Identifier

The identifier of the hash function.
Description

A short but clear description of the hash function, with any special notes about it.
Example(s)

One or more examples of input and output of the hash function.

14.3.2. Initial Registrations

The following table has been used to initialize the Hash Functions registry.

Identifier Description Example(s)
sha224 SHA-2 SHA-224 Section 9.1.2 Appendix A.2.1
sha256 SHA-2 SHA-256 Section 9.1.2 Appendix A.2.2
sha384 SHA-2 SHA-384 Section 9.1.2 Appendix A.2.3
sha512 SHA-2 SHA-512 Section 9.1.2 Appendix A.2.4
sha512-224 SHA-2 SHA-512/224 Section 9.1.2 Appendix A.2.5
sha512-256 SHA-2 SHA-512/256 Section 9.1.2 Appendix A.2.6
whirlpool WHIRLPOOL Section 9.1.3 Appendix A.2.7
streebog256 GOST R 34.11-2012 256 bits Section 9.1.6 Appendix A.2.8
streebog512 GOST R 34.11-2012 512 bits Section 9.1.6 Appendix A.2.9
sha3-224 SHA-3-224 Section 9.1.5 Appendix A.2.10
sha3-256 SHA-3-256 Section 9.1.5 Appendix A.2.11
sha3-384 SHA-3-384 Section 9.1.5 Appendix A.2.12
sha3-512 SHA-3-512 Section 9.1.5 Appendix A.2.13
blake2b-256 BLAKE2b-256 Section 9.1.7 Appendix A.2.15
blake2b-384 BLAKE2b-384 Section 9.1.7 Appendix A.2.15.1
blake2b-512 BLAKE2b-512 Section 9.1.7 Appendix A.2.16
blake2s-224 BLAKE2s-224 Section 9.1.7 Appendix A.2.17
blake2s-256 BLAKE2s-256 Section 9.1.7 Appendix A.2.18
sm3 OSCCA SM3 Section 9.1.4 Appendix A.2.14
shake128 SHAKE-128 Section 9.1.5 Appendix A.2.19
shake256 SHAKE-256 Section 9.1.5 Appendix A.2.20
cshake128 cSHAKE-128 Section 9.1.8 Appendix A.2.21
cshake256 cSHAKE-256 Section 9.1.8 Appendix A.2.22
parallel128 ParallelHash128 Section 9.1.8 Appendix A.2.23
parallel256 ParallelHash256 Section 9.1.8 Appendix A.2.24

14.4. vObject Hash Function Specifier Registry

The registry policy is Specification Required; any newly proposed registration MUST be reviewed by the designated expert.

The registry SHOULD contain the following note:

Note: Experts are to verify that the proposed registration
*SHOULD* provide benefits for the wider vObject community,
and provides a publicly-available standard that can be implemented in
an interoperable way. Hash function specifiers are preferrably approved by the CFRG
with references to IETF-published documents. The "Reference" value should
point to a document that details the implementation of this hash function
in the vObject context.

The "Specifier(s)" column in the registry SHOULD adhere to the following format:

ABNF:

specifier = specifier-tuple *("," specifier-tuple)

specifier-tuple = specifier-key ": " specifier-value-type +
                  "(default: " specifier-description ")"
specifier-key = text
specifier-value-type = value-type
specifier-description = text

14.4.1. Registration Template for vObject Hash Function Specifiers

A Hash Function Specifier is defined by completing the following template.

Identifier

Identifier of the hash function that this specifier applies to.
Description

A short but clear description of the hash function specifier.
Order

In which position in the specifier list should this specifier be found.
Value Type

The type of specifier value (e.g., text).
Example(s)

One or more examples of input and output of the hash function.

14.4.2. Initial Registrations

The following table has been used to initialize the Hash Function Specifier registry.

ID Order Description Value Type Example(s)
shake128 1 L: output bit length integer Appendix A.2.19
shake256 1 L: output bit length integer Appendix A.2.20
cshake128 1 L: output bit length integer Appendix A.2.21
cshake128 2 N: function-name text Appendix A.2.21
cshake128 3 S: customization string text Appendix A.2.21
cshake256 1 L: output bit length integer Appendix A.2.22
cshake256 2 N: function-name text Appendix A.2.22
cshake256 3 S: customization string text Appendix A.2.22
parallel128 1 B: block size in bytes text Appendix A.2.23
parallel128 2 L: output bit length integer Appendix A.2.23
parallel128 3 S: customization string text Appendix A.2.23
parallel256 1 B: block size in bytes text Appendix A.2.24
parallel256 2 L: output bit length integer Appendix A.2.24
parallel256 3 S: customization string text Appendix A.2.24

14.5. Property Registrations

This document defines the following new properties to be added to the registries defined in:

Property Status Reference
CHECKSUM Current This document: Section 5.1

14.6. Parameter Registrations

This document defines the following new property parameters to be added to the registries defined in:

Parameter Status Reference
HASHA Current This document: Section 6.2
HASHP Current This document: Section 6.3

14.6.1. Parameter Value Registrations

This document defines the following new parameter values to be added to the registries defined in:

Property Parameter Value Reference
CHECKSUM HASHA sha224 This document: Section 6.2
CHECKSUM HASHA sha256 This document: Section 6.2
CHECKSUM HASHA sha384 This document: Section 6.2
CHECKSUM HASHA sha512 This document: Section 6.2
CHECKSUM HASHA sha512-224 This document: Section 6.2
CHECKSUM HASHA sha512-256 This document: Section 6.2
CHECKSUM HASHA whirlpool This document: Section 6.2
CHECKSUM HASHA streebog256 This document: Section 6.2
CHECKSUM HASHA streebog512 This document: Section 6.2
CHECKSUM HASHA sha3-224 This document: Section 6.2
CHECKSUM HASHA sha3-256 This document: Section 6.2
CHECKSUM HASHA sha3-384 This document: Section 6.2
CHECKSUM HASHA sha3-512 This document: Section 6.2
CHECKSUM HASHA sm3 This document: Section 6.2
CHECKSUM HASHA blake2b256 This document: Section 6.2
CHECKSUM HASHA blake2b384 This document: Section 6.2
CHECKSUM HASHA blake2b512 This document: Section 6.2
CHECKSUM HASHA blake2s224 This document: Section 6.2
CHECKSUM HASHA blake2s256 This document: Section 6.2
CHECKSUM HASHA shake128 This document: Section 6.2
CHECKSUM HASHA shake256 This document: Section 6.2
CHECKSUM HASHA cshake128 This document: Section 6.2
CHECKSUM HASHA cshake256 This document: Section 6.2
CHECKSUM HASHA parallel128 This document: Section 6.2
CHECKSUM HASHA parallel256 This document: Section 6.2

15. References

15.1. Normative References

[I-D.calconnect-vobject-vformat] Tse, R., Tam, P., Daboo, C. and K. Murchison, "The vObject Model and vFormat Syntax", Internet-Draft draft-calconnect-vobject-vformat-00, April 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009.
[RFC6321] Daboo, C., Douglass, M. and S. Lees, "xCal: The XML Format for iCalendar", RFC 6321, DOI 10.17487/RFC6321, August 2011.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011.
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011.
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, DOI 10.17487/RFC6352, August 2011.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014.
[RFC7265] Kewisch, P., Daboo, C. and M. Douglass, "jCal: The JSON Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 2014.
[RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

15.2. Informative References

[BLAKE] Aumasson, J-P., Meier, W., Phan, R. and L. Henzen, "The Hash Function BLAKE", January 2015.
[BLAKE2] Aumasson, J-P., Neves, S., Wilcox-O'Hearn, Z. and C. Winnerlein, "BLAKE2: simpler, smaller, fast as MD5", January 2013.
[CALCONNECT-CALENDAR] The Calendaring and Scheduling Consortium, "CalConnect CALENDAR Technical Committee", April 2018.
[CALCONNECT-VCARD] The Calendaring and Scheduling Consortium, "CalConnect VCARD Technical Committee", April 2018.
[ISO-IEC-10118-3] ISO/IEC, "ISO/IEC DIS 10118-3:2017 Information technology -- Security techniques -- Hash-functions — Part 3: Dedicated hash-functions", April 2017.
[ISO-IEC-13239] ISO/IEC, "ISO/IEC 13239:2002, Information technology -- Telecommunications and information exchange between systems -- High-level data link control (HDLC) procedures", July 2002.
[ISO-IEC-18004] ISO/IEC, "ISO/IEC 18004:2015, Information technology -- Telecommunications and information exchange between systems -- High-level data link control (HDLC) procedures", February 2015.
[ISO-IEC-27000] ISO/IEC, "ISO/IEC 27000:2016, Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary", February 2016.
[ISO-IEC-27001] ISO/IEC, "ISO/IEC 27001:2013", October 2015.
[KECCAK] Bertoni, G., Daemen, J., Peeters, M. and G. Van Assche, "The KECCAK sponge function family", December 2016.
[NIST-FIPS-180-4] Dang, Q., "FIPS PUB 180-4, Secure Hash Standard", August 2015.
[NIST-FIPS-202] Dworkin, M., "FIPS PUB 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", August 2015.
[NIST-SP-800-185] Kelsey, J., Chang, S. and R. Perlner, "SP 800-185, SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash", December 2016.
[RFC2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for Directory Information", RFC 2425, DOI 10.17487/RFC2425, September 1998.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, DOI 10.17487/RFC2426, September 1998.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC4791] Daboo, C., Desruisseaux, B. and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008.
[RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/RFC5546, December 2009.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011.
[RFC6986] Dolmatov, V. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 2013.
[RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated-Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May 2014.
[RFC7693] Saarinen, M-J. and J-P. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, DOI 10.17487/RFC7693, November 2015.
[RFC7953] Daboo, C. and M. Douglass, "Calendar Availability", RFC 7953, DOI 10.17487/RFC7953, August 2016.
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017.
[RIPEMD160] Dobbertin, H., Bosselaers, A. and B. Preneel, "RIPEMD-160: A Strengthened Version of RIPEMD", April 1996.
[SM3] State Cryptography Administration of China, "SM3 Cryptographic Hash Algorithm", December 2010.
[STREEBOG] Federal Agency on Technical Regulation and Metrology, Information technology, "Information technology – Cryptographic data security – Hash-function, National Standard of the Russian Federation GOST R 34.11-2012", January 2013.
[vCard21] Internet Mail Consortium, "vCard - The Electronic Business Card Version 2.1", September 1996.
[WHIRLPOOL] Rijmen, V. and P. Barreto, "The WHIRLPOOL Hashing Function", November 2000.

Appendix A. Examples

A.1. vCard CHECKSUM

A.1.1. Original vCard

BEGIN:VCARD
VERSION:4.0
KIND:individual
FN:Martin Van Buren
N:Van Buren;Martin;;;Hon.
TEL;VALUE=uri;PREF=1;HASHA="voice,home":tel:+1-888-888-8888;ext=8888
END:VCARD

A.1.2. Setup

Location of the CHECKSUM property within the VCARD component does not matter as the method of calculation is agnostic with regards to line location of a property.

vCard extended with CHECKSUM property for CHECKSUM calculation at the last line, specifying the sha512 algorithm and value type STRING:

BEGIN:VCARD
VERSION:4.0
KIND:individual
FN:Martin Van Buren
N:Van Buren;Martin;;;Hon.
TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-888-888-8888;ext=8888
CHECKSUM;VALUE=TEXT;HASHA=sha3-256:
END:VCARD

A.1.3. Normalization: Properties

PREPHASH-PROPERTY("VERSION:4.0") =
  "VERSION:TEXT/[4.0]?#[]"

PREPHASH-PROPERTY("KIND:individual") =
  "KIND:TEXT/[individual]?#[]"

PREPHASH-PROPERTY("FN:Martin Van Buren") =
  "FN:TEXT/[Martin Van Buren]?#[]"

PREPHASH-PROPERTY("N:Van Buren;Martin;;;Hon.") =
  "N:TEXT/[Van Buren;Martin;;;Hon.]?#[]"

PREPHASH-PROPERTY("TEL;VALUE=uri;PREF=1;HASHA="voice,home":") =
  "TEL:URI/[tel:+1-888-888-8888;ext=8888]" +
  "?#[{PREF:[1]};{TYPE:[home;voice]}]"

PREPHASH-PROPERTY("CHECKSUM;VALUE=TEXT;HASHA=sha512:") =
  "CHECKSUM:TEXT/[]?#[{HASHA:[sha512]}]"

A.1.4. Cryptographic Hashing: Properties

HASH("VERSION:TEXT/[4.0]?#[]") =
  "de2a19b21ce6dbbafd3feedebf7560966242d4af0bac8e380024135809729ba4"

HASH("KIND:TEXT/[individual]?#[]") =
  "25603f59dc07e045b470e3d773da10e2485c078c80f4a048c2e1cbeb678ab406"

HASH("FN:TEXT/[Martin Van Buren]?#[]") =
  "a9124e1bd40c8a2cb4031b4140629e2472046f837dddc379a257d5f6e7bceedd"

HASH("N:TEXT/[Van Buren;Martin;;;Hon.]?#[]") =
  "c11eadabeee1252502ddc6c085e5bd7fd48ae183f50399b953bb78a927172dc5"

HASH(
  "TEL:URI/[tel:+1-888-888-8888;ext=8888]" +
  "?#[{PREF:[1]};{HASHA:[home;voice]}]"
) = "dc22433d7cb2445dd9f083a1d998ee00e8f2f369f0e18ddb827f8135f0d7b30d"

HASH("CHECKSUM:TEXT/[]?#[{HASHA:[sha512]}]") =
  "65d32764ab8c9fcdd324f24409c65a45529f4a6df5cd070378463a177de04917"

A.1.5. Normalization: Component

HASH-AND-PREPHASH-PROPERTIES(properties) = LIST-TO-TEXT(
  [
    "CHECKSUM:" +
      HASH("CHECKSUM:TEXT/[]?#[{HASHA:[sha512];VALUE:[TEXT]}]"),
    "FN:" +
      HASH("FN:TEXT/[Martin Van Buren]?#[{VALUE:[TEXT]}]"),
    "KIND:" +
      HASH("KIND:TEXT/[individual]?#[{VALUE:[TEXT]}]"),
    "N:" +
      HASH("N:TEXT/[Van Buren;Martin;;;Hon.]?#[{VALUE:[TEXT]}]"),
    "TEL:" +
      HASH(
        "TEL:URI/[tel:+1-888-888-8888;ext=8888]?" +
        "#[{PREF:[1]};{HASHA:[voice;home]};{VALUE:[TEXT]}]"
      ),
    "VERSION:" +
      HASH("VERSION:TEXT/[4.0]?#[{VALUE:[TEXT]}]")
  ],
  CRLF
)
PREPHASH-COMPONENT(component) =
"BEGIN:VCARD:CHECKSUM
CHECKSUM:65d32764ab8c9fcdd324f24409c65a45529f4a6df5cd070378463a177de04917
FN:a9124e1bd40c8a2cb4031b4140629e2472046f837dddc379a257d5f6e7bceedd
KIND:25603f59dc07e045b470e3d773da10e2485c078c80f4a048c2e1cbeb678ab406
N:c11eadabeee1252502ddc6c085e5bd7fd48ae183f50399b953bb78a927172dc5
TEL:dc22433d7cb2445dd9f083a1d998ee00e8f2f369f0e18ddb827f8135f0d7b30d
VERSION:de2a19b21ce6dbbafd3feedebf7560966242d4af0bac8e380024135809729ba4
END:VCARD:CHECKSUM
"

A.1.6. Cryptographic Hashing: Component

HASH-COMPONENT(component) =
  "212f3486f968df73dc9b9f909e8dfedae866135aeef2ceeaa3393675806960d1"

A.1.7. Final Checksum

This is the final checksum of this component using the sha3-256 hash method.

The final vCard:

BEGIN:VCARD
VERSION:4.0
KIND:individual
FN:Martin Van Buren
N:Van Buren;Martin;;;Hon.
TEL;VALUE=uri;PREF=1;HASHA="voice,home":tel:+1-888-888-8888;ext=8888
CHECKSUM;VALUE=TEXT;HASHA=sha3-512:
  212f3486f968df73dc9b9f909e8dfedae866135aeef2ceeaa3393675806960d1
END:VCARD

A.2. Hash Functions Registry Examples

A.2.1. SHA-2 SHA-224

input("BEGIN:VCARD") = "22e92efac9d7b0e63695a9d960376ace" +
                       "1e69eb317e3d42c5c94f1401"

A.2.2. SHA-2 SHA-256

input("BEGIN:VCARD") = "99e3e442c1a5cbd115baa26d077c6bbb" +
                       "423310cd4990051d8974c3b2d581c3d4"

A.2.3. SHA-2 SHA-384

input("BEGIN:VCARD") = "4055b176af753e251bc269007569c8f9" +
                       "633e6227a5f9727381cfba0bbb44a0c9" +
                       "25b8d31d72083d9cb4dc1da278f3a4e4"

A.2.4. SHA-2 SHA-512

input("BEGIN:VCARD") = "a2d5b1339599039a7058d8446442f2cb" +
                       "341a149064eacb31fdc410e57e239849" +
                       "88efffc6f15842a6a6ae08fb4d791d2f" +
                       "9dd9dab4cf724f8e75b9fff2c21d3e1c"

A.2.5. SHA-2 SHA-512/224

input("BEGIN:VCARD") = ""

A.2.6. SHA-2 SHA-512/256

input("BEGIN:VCARD") = ""

A.2.7. WHIRLPOOL (512-bit)

input("BEGIN:VCARD") = "6e9ca195e4e87afcc624fa88334088fb" +
                       "71038273b16cb1e47888072c03cfaf79" +
                       "29539375c5ff92fbd82b73924ed60b1d" +
                       "c9bb17bdb1bd2447cf2d3218a356736a"

A.2.8. STREEBOG-256

input("BEGIN:VCARD") = ""

A.2.9. STREEBOG-512

input("BEGIN:VCARD") = ""

A.2.10. SHA-3-224

input("BEGIN:VCARD") = "630d7879cac76d221565dcc335bff595" +
                       "158b3496713910cc92166762"

A.2.11. SHA-3-256

input("BEGIN:VCARD") = "f1fcbc9bddcd44b1e50db99a277bc868" +
                       "61736eb32cb30ef7e7a2c9ef95c05d50"

A.2.12. SHA-3-384

input("BEGIN:VCARD") = "2d27f6dccb17bf6da9800386aae4a991" +
                       "cfdebc4f3a971f7d0e5264aa0c7b1394" +
                       "514c2eb5bd724f0702062935de9fd92d"

A.2.13. SHA-3-512

input("BEGIN:VCARD") = "ceb5ab39356ce3440d99375a3098cfa5" +
                       "20db3d54a3c15184be9f19f6483165e7" +
                       "8769d4cf2e7f0976422ed4856122c957" +
                       "d22a3c4b922b733ccefc802eed753027"

A.2.14. SM3 (256-bits)

input("BEGIN:VCARD") = ""

A.2.15. BLAKE2b-256

input("BEGIN:VCARD") = ""

A.2.15.1. BLAKE2b-384

input("BEGIN:VCARD") = ""

A.2.16. BLAKE2b-512

input("BEGIN:VCARD") = ""

A.2.17. BLAKE2s-224

input("BEGIN:VCARD") = ""

A.2.18. BLAKE2s-256

input("BEGIN:VCARD") = ""

A.2.19. SHAKE-128

input("BEGIN:VCARD") = ""

A.2.20. SHAKE-256

input("BEGIN:VCARD") = ""

A.2.21. cSHAKE-128

input("BEGIN:VCARD", L, N, S) = ""

A.2.22. cSHAKE-256

input("BEGIN:VCARD", L, N, S) = ""

A.2.23. ParallelHash128

input("BEGIN:VCARD", B, L, S) = ""

A.2.24. ParallelHash256

input("BEGIN:VCARD", B, L, S) = ""

Appendix B. Acknowledgements

The authors wish to thank the following parties who helped this materialize and for their support of a better world.

This specification was developed by the CalConnect TC-VCARD committee.

Authors' Addresses

Ronald Henry Tse Ribose Suite 1111, 1 Pedder Street Central, Hong Kong EMail: ronald.tse@ribose.com URI: https://www.ribose.com
Peter Kwan Yu Tam Ribose Suite 1111, 1 Pedder Street Central, Hong Kong EMail: peter.tam@ribose.com URI: https://www.ribose.com