© 2026 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
This document specifies an integrity checking mechanism and related properties for:
vObject (I-D.calconnect-vobject-vformat)
vCard version 4 (vCard v4) (RFC 6350); and
iCalendar (Internet Calendaring and Scheduling Core Object Specification) (RFC 5545)
This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
Add CalDAV mechanisms and recommendations
Fill in missing example hashes
Fully replace normalization process with the vObject one, remove normalization process here
The ubiquitous vCard and iCalendar standards, also known together as the “vObject” family of standards
Integrity
In reality, people are known to exchange vCard and iCalendar data through unreliable means, which could affect data integrity during its data lifecycle:
transport of vObject data, such as over Internet mail
storage of vObject content, such as on disk, can be subject to silent corruption.
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:
vObjects on storage may face silent corruption;
vObjects transmitted over networks or other channels may face network corruption that may go undetected by the underlying transport mechanism.
The standards subject to such risks include:
vObject
vCard versions 2.1
iCalendar
Calendar Availability Extensions
alternative formats for iCalendar and vCard, including xCal
This document provides:
a stable mechanism to calculate vObject equivalence using cryptographic hash functions, valid across alternative representations, such as xCard/jCard and xCal/jCal;
introduces a new property CHECKSUM to vObjects;
usage of the CHECKSUM property on CardDAV
alternative representations of the CHECKSUM property for xCard
guidance to implementers on dealing with integrity concerns and the proper usage of CHECKSUM.
Organizations that implement information security management systems, such as
The decision to update the existing vCard version 4
This work is produced by the CalConnect TC-VCARD
For the purposes of this document, the following terms and definitions apply.
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
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
The definitions from
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.
A CHECKSUM property that includes a PREF property parameter.
The CHECKSUM property that uses the implementation’s preferred checksum parameters.
These functions are REQUIRED and MUST be implemented for compliance to this document.
Sorts an list according to alphabetical order (A-Z).
This function returns a Unicode string (
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.
This function returns a Unicode string (
where: * + indicates concatenation; * key(parameter) is the property parameter key; * normalize(s) is a function that normalizes the key s.
This function returns a Unicode string (
where: * + indicates concatenation; * values(parameter, i) is the i-th property parameter value in parameter.
Converts a property parameter into a string, with its key and values.
This function returns a Unicode string (
where: * + indicates concatenation.
This function returns a Unicode string (
We exclude the VALUE property parameter in this calculation (such as VALUE=TEXT) as this information is represented in PREPHASH-PROPERTY-VALUE-HASHA.
where: * + indicates concatenation; * parameters(property, i) is the i-th parameter of property.
This function returns a Unicode string (
where: * + indicates concatenation; * key(property) is the property key; * normalize(s) is a function that normalizes the key s.
This function returns a Unicode string (
where: * + indicates concatenation; * type(property) is the property value type, if not explicitly provided, it should be filled in according to
This function returns a Unicode string (
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
where: * + indicates concatenation; * values(property, i) is the i-th property value in property.
This function returns a Unicode string (
where: * + indicates concatenation
This function returns a Unicode string (
where: * + indicates concatenation
This function returns a Unicode string (
where: * + indicates concatenation; * property(properties, i) is the i-th property of properties; * HASH(s) is selected cryptographic hash function applied to string s.
This function returns a Unicode string (
where: * name© is the component name of component c.
This function returns a Unicode string (
where: * + indicates concatenation; * properties© returns the properties of the component c in an list;
This function returns a Unicode string (
This function returns the calculated hash of an input string and outputs the hash in string representation.
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.
Property cardinalities are indicated in the same method as provided by
These registration details for the CHECKSUM property adhere to rules specified in
Nil.
CHECKSUM
Allows content integrity detection and verification against data corruption of a vObject.
A single text value.
*
HASHA, HASHP
TEXT
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:
the highest PREF value among all CHECKSUM properties; then
the most applicable HASHA algorithm taking into account collision resistance and application support.
ABNF:
The CHECKSUM allowed property parameters of PID, PREF, ALTID have the same meaning as on other properties
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
Registration details for the HASHA property parameter adhere to rules specified in
Nil.
HASHA
Specify the hash function used for the property value
Possible values are defined in
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.
ABNF:
Certain hash functions such as extendable output functions (XOFs) can be customized:
SHAKE-128, SHAKE-256, cSHAKE-128, cSHAKE256, ParallelHash128, ParallelHash256 support customizable hash value length.
cSHAKE-128, cSHAKE-256, support function name customization.
cSHAKE-128, cSHAKE-256, ParallelHash128, ParallelHash256 support customizable bit strings.
ParallelHash128, ParallelHash256 support customizable block sizes for parallel hashing.
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
Registration details for the HASHP property parameter adhere to rules specified in
Nil.
HASHP
Describe hash function specifiers used for the property value.
Provide specifiers for the HASHA hash function used to calculate the property value.
Possible values are defined in
The HASHP Property Parameter MUST not be applied on properties other than CHECKSUM unless specified.
ABNF:
Example(s):
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:
Immediately prior to saving on target medium, a CHECKSUM is calculated and stored; and
Immediately after retrieval from target medium, the included CHECKSUM is verified to ensure that it has not been corrupted.
An implementation that supports CHECKSUM MUST adhere to the following rules:
If it supports importing of vObjects (including network import), it MUST verify the provided CHECKSUM property value immediately prior to import to ensure the vObject has not been damaged.
If it supports exporting of vObject (including network export), it MUST insert at least one CHECKSUM property with corresponding checksum values to the vObject immediately prior to exporting, to ensure the recipient of the vObject can check against data integrity.
There are 3 validity states of a vObject:
This vObject is not corrupt.
This vObject is corrupt.
This vObject does not provide enough information to make a validity judgement.
Given one CHECKSUM property, an implementation that supports the CHECKSUM property SHOULD reach the following conclusions about the vObject:
Valid. The vObject is intact. Calculation by the implementation of the vObject’s CHECKSUM property value was identical to the provided checksum value.
Invalid. The vObject is corrupted. Calculation by the implementation of the vObject’s CHECKSUM resulted in a different value as the provided checksum value.
Unverified. The implementation is unable to determine data integrity of the vObject.
The vObject did not have a CHECKSUM property and therefore its data integrity cannot be verified.
The vObject had a CHECKSUM property with a blank value and therefore its data integrity cannot be verified. This also signifies that the originator implementation was not able to calculate a CHECKSUM value.
The vObject had a CHECKSUM property with a value but the current implementation does not support the chosen hash function, therefore its data integrity cannot be verified.
If a vObject has more than one non-empty CHECKSUM property, an implementation should validate according to the rules below.
In the order of preference stated (PREF parameter value), validate all supported SPCV until one is verified.
If a vObject can be validated to any SPCV, it is deemed valid.
If all SPCVs are invalid, the vObject fails validation.
If a vObject does not have any SPCV, or the implementation does not support any SPCV, but contains a supported CHECKSUM property
If the CHECKSUM property value is valid, the vObject is deemed valid.
Otherwise, the vObject fails validation.
The following method to calculate CHECKSUM is devised for these desired properties:
Stable across alternative representation formats of the vCard and iCalendar, such as xCard/jCard.
Allows comparison of equivalence of content rather than formatting. E.g., addition of new-lines within a vCard and order of listed properties do not affect the resulting checksum value.
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:
Calculate the hash value of the vObject
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.
Normalize the vObject in data model form (in accordance with
For each normalized property (including the newly added CHECKSUM property):
For each normalized property parameter:
For each normalized property parameter value:
Obtain pre-hash string representation of the property parameter value
Calculate hash value of the string representation of the property parameter value
Obtain pre-hash string representation of the property parameter using hashes of its property parameter values
Calculate hash value of the string representation of the property parameter
For each normalized property value:
Obtain pre-hash string representation of the property value
Calculate hash value of the string representation of the property value
Obtain pre-hash string representation of the property using hashes of its property values and property parameters
Calculate hash value of the string representation of the property
Obtain pre-hash string representation of the vObject itself using hashes of its properties
Calculate hash value of the string representation of the vObject.
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.
If the implementation is unable to calculate the CHECKSUM due to unsupported or unrecognized parameters of a CHECKSUM property, assign the “” (empty string) as its value.
Enter the calculated CHECKSUM value for each CHECKSUM property.
The checksum calculation procedure is complete.
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.
CHECKSUM supports the following hash algorithms.
CHECKSUM supported hash algorithms are listed in the following table.
The CHECKSUM value contains the output of the hash function, which is usually stored in hexadecimal format as the text value type.
The identifier from this table should be put as value of the property parameter HASHA.
Algorithms with a “Variable” message digest size mean its length can be specified by a HASHP specifier.
Algorithms with no specifiers:
| Algorithm | Identifier | Message Digest Size (bits) | Description |
|---|---|---|---|
| SHA-2 SHA-224 | sha224 | 224 | |
| SHA-2 SHA-256 | sha256 | 256 | |
| SHA-2 SHA-384 | sha384 | 384 | |
| SHA-2 SHA-512 | sha512 | 512 | |
| SHA-2 SHA-512/224 | sha512-224 | 224 | |
| SHA-2 SHA-512/256 | sha512-256 | 256 | |
| WHIRLPOOL | whirlpool | 512 | |
| STREEBOG-256 | streebog256 | 256 | |
| STREEBOG-512 | streebog512 | 512 | |
| SHA3-224 | sha3-224 | 224 | |
| SHA3-256 | sha3-256 | 256 | |
| SHA3-384 | sha3-384 | 384 | |
| SHA3-512 | sha3-512 | 512 | |
| SM3 | sm3 | 512 | <<?I-D.shen-sm3-hash>>; |
| 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) | |
| SHAKE-256 | shake256 | Varys | L: integer (default: 512) | |
| cSHAKE-128 | cshake128 | Varys | L: integer (default: 256), N: text (default: “”), S: text (default: “”) | |
| cSHAKE-256 | cshake256 | Varys | L: integer (default: 512), N: text (default: “”), S: text (default: “”) | |
| ParallelHash-128 | parallel128 | Varys | B: integer (default: 64), L: integer (default: 256), S: text (default: “”) | |
| ParallelHash-256 | parallel256 | Varys | B: integer (default: 64), L: integer (default: 256), S: text (default: “”) | |
| IANA registered hash algorithm | iana-token | iana-token | iana-token | IANA |
| Vendor-specific hash algorithm | x-token | Vendor specific | Vendor specific | Vendor specific |
The default algorithm is sha3-256. An implementation that supports this document MUST support at least the sha3-256 function.
Secure Hash Algorithm 2 (SHA-2) is a family of secure hash algorithms defined in
SHA-256 and SHA-512 are the two core hash functions that differ by process parameters, which produce a hash value of 256 and 512 bits respectively.
SHA-224 is identical to SHA-256, except that different initial hash values are used, and the final hash value is truncated to 224 bits.
SHA-384, SHA-512/224, SHA-512/256 are identical to SHA-512, except that different initial hash values are used, and the final hash value is truncated to 384, 224, 256 bits respectively. In particular, SHA-512/224 and SHA-512/256 use initial hash values generated by the “SHA-512/t IV Generation Function” given in
WHIRLPOOL is a hash function that operates on messages less than
It uses Merkle-Damgard strengthening and the Miyaguchi-Preneel hashing
scheme with a dedicated 512-bit block cipher called
SM3 is a hash function <<?I-D.shen-sm3-hash>> standardized by the Chinese Commercial Cryptography Administration Office
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.
Secure Hash Algorithm-3 (SHA-3) is a family of hash functions defined in
four cryptographic hash functions, SHA3-224, SHA3-256, SHA3-384, SHA3-512; and
two extendable-output functions (XOFs), SHAKE128 and SHAKE256.
Each SHA-3 function is based on an instance of the KECCAK algorithm
SHA3-224, SHA3-256, SHA3-384, SHA3-512 produce a hash value output of 224, 256, 384 and 512 bits respectively.
SHAKE128 and SHAKE256 are XOFs that produce output of arbitrary length, which can be specified using the “HASHP” property parameter.
Notes concerning SHA-3 based XOFs
Output of a XOF can be considered as an infinite string, and the “HASHP” property parameter simply determines how many initial bits of the initial string to use.
The SHAKE-256 and -128 functions, as long as at least 2x bits of their output is used, they have generic security strengths of 256 and 128 bits. However, using an excess of 64 or 32 bytes of their output respectively, does not increase their collision-resistance.
Streebog (or Stribog) is a family of two separate hash functions defined in the Russian standard GOST R 34.11-2012
Streebog accepts message block sizes of 512-bits, and both functions only differ in the different IVs used other than the output length
BLAKE2, described in
BLAKE2b is optimized for 64-bit platforms and produces hash values of any size between 1 and 64 bytes
BLAKE2s is optimized for 8- to 32-bit platforms and produces hash values of any size between 1 and 32 bytes
While BLAKE2 allows customizing parameters, including salt and a customization string, implementations that adhere to this specification should adopt BLAKE2 as defined in
cSHAKE-128, cSHAKE-256: customizable SHAKE functions, which take extra inputs of hash value length, a function name string, and a customization string;
ParallelHash128, ParallelHash256: supports efficient hashing of very long strings by taking advantage of the parallelism available in modern processors based on SHAKE. These take the extra inputs of block size, hash value length and a customization string.
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.
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 |
Collision-resistance: higher bit length digests are generally preferable to lower bit length digests due to lower susceptibility to collisions.
Performance: some hash functions are more computation intensive. Higher bit length digests generally require more computation to generate.
History: a hash algorithm that has withstood cryptanalytic attacks provide better confidence than ones that have not been in widespread use.
Availability and interoperability: certain hash algorithms, such as SHA-2 (
Selection of the hash function should be based on a balance of collision resistance, performance, history and interoperability.
The following hash functions are specifically excluded due to stated reasons:
RIPEMD-160
SHA-1
CRC-32
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
An implementation abiding to this specification MUST augment this process according to the following.
When a client issues a PUT to create an address object resource, a CHECKSUM property SHOULD be included in the request.
The CHECKSUM property value MAY be empty if the client wishes the server to calculate the value according to the given HASHA and/or HASHP parameters.
This specification creates an additional precondition and postcondition for the PUT, COPY, and MOVE methods when:
A PUT operation requests an address object resource to be placed into an address book collection; and
A COPY or MOVE operation requests an address object resource to be placed into (or out of) an address book collection.
(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:
The address object resource’s integrity MUST be valid as determined by methods of this specification.
If the resource contains an empty CHECKSUM property value, the server SHOULD fill in the property value with its own calculation.
The CHECKSUM property value SHOULD be stored by the server to enable data integrity verification.
If the resource CHECKSUM is deemed invalid, the server SHOULD respond with a 409 (Conflict) status to indicate to the client so, hence the <CARDDAV:valid-address-data-checksum> condition is not met. In this case, the client may choose to empty the CHECKSUM property value for re-submission.
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.
(CARDDAV:resource-not-modified): The address object resource should not be modified by the server such that its original CHECKSUM value becomes invalid.
After action execution, the server should re-calculate the CHECKSUM property value based on the retrieved address object resource.
If the CHECKSUM property value is now different, the server SHOULD respond to client with the latest address object resource and the new CHECKSUM so that the client knows the resource has been changed by the server.
The CalDAV
A CalDAV server is RECOMMENDED to return iCalendar data with integrity protection.
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.
iTIP
This specification is compatible with iTIP transfer of iCalendar data.
The XML representation
The JSON representation of the CHECKSUM property follows
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
Implementers MUST ignore individual parameter value types in xCard (
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.
If an implementation supports the CHECKSUM property but not certain parameters (e.g., a specified hash function), it MUST leave that property value empty as the insertion of the CHECKSUM property indicates the wish of the user to utilize it.
If an implementation supports the CHECKSUM property, it MUST calculate the checksum values for every CHECKSUM property in the vObject.
The CUA SHOULD honestly reflect checksum validation results to the user to allow further action from the user, e.g., to seek retransmission of the vObject.
Cryptographic hash algorithms can break overtime. There will be a time when best practice designates a better one, CUA SHOULD take this in mind and promote best practice to update its security profile.
The function of the CHECKSUM property depends on the collision-free property of cryptographic hash functions. However, as time passes, today’s recommended cryptographic hash functions may no longer be considered reliable in the future. Implementers MUST take this into account and update its security profile according to the latest best practice on cryptographic hash functions.
The CHECKSUM property is not designed to protect against intentional and unauthorized modification. A malicious party with access to the vObject (such as a “man-in-the-middle attack”
The CHECKSUM property is not designed to address data authenticity (
While many vObject properties can be used to transport URIs, the CHECKSUM property specifically does not allow setting a URI as its value due to extra security risks raised during the reference step to a URI (
Security considerations around vObject formats in the following documents MUST be adhered to:
vCard:
iCalendar:
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.
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
The registry policy is Specification Required; any newly proposed registration MUST be reviewed by the designated expert.
The registry SHOULD contain the following note:
A Hash Function is defined by completing the following template.
The identifier of the hash function.
A short but clear description of the hash function, with any special notes about it.
One or more examples of input and output of the hash function.
The following table has been used to initialize the Hash Functions registry.
| Identifier | Description | Example(s) |
|---|---|---|
| sha224 | SHA-2 SHA-224 |
|
| sha256 | SHA-2 SHA-256 |
|
| sha384 | SHA-2 SHA-384 |
|
| sha512 | SHA-2 SHA-512 |
|
| sha512-224 | SHA-2 SHA-512/224 |
|
| sha512-256 | SHA-2 SHA-512/256 |
|
| whirlpool | WHIRLPOOL |
|
| streebog256 | GOST R 34.11-2012 256 bits |
|
| streebog512 | GOST R 34.11-2012 512 bits |
|
| sha3-224 | SHA-3-224 |
|
| sha3-256 | SHA-3-256 |
|
| sha3-384 | SHA-3-384 |
|
| sha3-512 | SHA-3-512 |
|
| blake2b-256 | BLAKE2b-256 |
|
| blake2b-384 | BLAKE2b-384 |
|
| blake2b-512 | BLAKE2b-512 |
|
| blake2s-224 | BLAKE2s-224 |
|
| blake2s-256 | BLAKE2s-256 |
|
| sm3 | OSCCA SM3 |
|
| shake128 | SHAKE-128 |
|
| shake256 | SHAKE-256 |
|
| cshake128 | cSHAKE-128 |
|
| cshake256 | cSHAKE-256 |
|
| parallel128 | ParallelHash128 |
|
| parallel256 | ParallelHash256 |
The registry policy is Specification Required; any newly proposed registration MUST be reviewed by the designated expert.
The registry SHOULD contain the following note:
The “Specifier(s)” column in the registry SHOULD adhere to the following format:
ABNF:
A Hash Function Specifier is defined by completing the following template.
Identifier of the hash function that this specifier applies to.
A short but clear description of the hash function specifier.
In which position in the specifier list should this specifier be found.
The type of specifier value (e.g., text).
One or more examples of input and output of the hash function.
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 | |
| shake256 | 1 | L: output bit length | integer | |
| cshake128 | 1 | L: output bit length | integer | |
| cshake128 | 2 | N: function-name | text | |
| cshake128 | 3 | S: customization string | text | |
| cshake256 | 1 | L: output bit length | integer | |
| cshake256 | 2 | N: function-name | text | |
| cshake256 | 3 | S: customization string | text | |
| parallel128 | 1 | B: block size in bytes | text | |
| parallel128 | 2 | L: output bit length | integer | |
| parallel128 | 3 | S: customization string | text | |
| parallel256 | 1 | B: block size in bytes | text | |
| parallel256 | 2 | L: output bit length | integer | |
| parallel256 | 3 | S: customization string | text |
This document defines the following new properties to be added to the registries defined in:
vCard registry,
iCalendar registry,
| Property | Status | Reference |
|---|---|---|
| CHECKSUM | Current | This document: |
This document defines the following new property parameters to be added to the registries defined in:
vCard registry,
iCalendar registry,
| Parameter | Status | Reference |
|---|---|---|
| HASHA | Current | This document: |
| HASHP | Current | This document: |
This document defines the following new parameter values to be added to the registries defined in:
vCard registry,
iCalendar registry,
| Property | Parameter | Value | Reference |
|---|---|---|---|
| CHECKSUM | HASHA | sha224 | This document: |
| CHECKSUM | HASHA | sha256 | This document: |
| CHECKSUM | HASHA | sha384 | This document: |
| CHECKSUM | HASHA | sha512 | This document: |
| CHECKSUM | HASHA | sha512-224 | This document: |
| CHECKSUM | HASHA | sha512-256 | This document: |
| CHECKSUM | HASHA | whirlpool | This document: |
| CHECKSUM | HASHA | streebog256 | This document: |
| CHECKSUM | HASHA | streebog512 | This document: |
| CHECKSUM | HASHA | sha3-224 | This document: |
| CHECKSUM | HASHA | sha3-256 | This document: |
| CHECKSUM | HASHA | sha3-384 | This document: |
| CHECKSUM | HASHA | sha3-512 | This document: |
| CHECKSUM | HASHA | sm3 | This document: |
| CHECKSUM | HASHA | blake2b256 | This document: |
| CHECKSUM | HASHA | blake2b384 | This document: |
| CHECKSUM | HASHA | blake2b512 | This document: |
| CHECKSUM | HASHA | blake2s224 | This document: |
| CHECKSUM | HASHA | blake2s256 | This document: |
| CHECKSUM | HASHA | shake128 | This document: |
| CHECKSUM | HASHA | shake256 | This document: |
| CHECKSUM | HASHA | cshake128 | This document: |
| CHECKSUM | HASHA | cshake256 | This document: |
| CHECKSUM | HASHA | parallel128 | This document: |
| CHECKSUM | HASHA | parallel256 | This document: |
The authors wish to thank the following parties who helped this materialize and for their support of a better world.
their families
the CalConnect TC-VCARD committee
members and the Board of Directors of CalConnect
This specification was developed by the CalConnect TC-VCARD committee.
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:
This is the final checksum of this component using the sha3-256 hash method.
The final vCard:
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]
This specification defines “xCal”, an XML format for iCalendar data. [STANDARDS-TRACK]
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]
This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]
This specification defines “jCard”, a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.
This specification defines “jCal”, a JSON format for iCalendar data. The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).
To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.
This is the third edition of this document; it obsoletes RFC 5226.
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]
This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]
The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.
All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the “calendar-access” feature of CalDAV. [STANDARDS-TRACK]
This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; © use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of “electronic mail” messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, “Standard for the Format of ARPA Internet Text Messages”, updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]
Federal Information Processing Standard, FIPS
This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.
This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).
This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).
This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.
This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.