]> Transmute

orie@transmute.industries

Security Secure Patterns for Internet CrEdentials vcard contacts digital credentials vCard is a file format for digital business cards. This document enables vCards to be used as a transport for digital credentials. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Public key based identity systems require users to obtain cryptographic keys, and use them to verify digital signatures produced by a private key, or decrypt data with a private key that was encrypted to a public key. The public key cryptographic operations are a foundational building block for building secure systems capable of providing confidentiality, integrity and authenticity. Applications supporting protocols such as OAUTH, OpenSSH, and OpenPGP rely on different public key formats. To enable interoperability, useful public key formats have media types registered with IANA . A common challenge in working with applications that require key management is obtaining cryptographic keys. vCards as decribed in can address this challenge, for keys that are embedded by value or by reference in digital business cards.

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Transports vCARDs can be transported over various channels, including through NFC and QR Codes, as decribed in .

Optical QR Codes are well supported in modern smartphones and frequently displayed on physical products, providing additional information to consumers. Anyone who can see a QR Code can access the data encoded in it. Sensitive plaintext data MUST NOT be encoded in vCARD QR Codes. Encryption formats, such as JSON Web Encryption as decribed in MAY be used to secure confidential credentials. QR Codes can be removed, altered, or replaced on physical products, and in video streams. Additional security checks MUST be performed before accepting any data transported by QR Codes. For example, confirming serial numbers or other presented identifiers are consistent with the claims in credentials presented through the vCard QR Code.

A vCard containing a public key by reference

Key Transparency In cases where a key is communicated by reference, and a service is used to dereference the key material, key transparency can mitigate threats related to duplicity, censorship, and consistency. In the context of this document, key references are URIs. Any key transparency system capable of deliverying key material for a URI as described in MAY be used.

Public Keys Section 6.8.1 of defines how to embed a key in a vCARD. The following informative example is provided:

A vCard containing public keys

In this example, the same credentials are encoded by value and by reference, and the fields "CATEGORIES", "UID" and "FN" are not integrity protected, software systems MAY leverage this property to alter these values, will preserving the integrity protected values. The credential encoded by reference is using a URI built from a thumbprint using .

Digital Credentials A verifiable credential, as defined in and , is a special kind of public key, that a holder can prove possession of in order to convince a verifier, that an issuer has asserted attributes about a subject.

Verifiable Credentials A verifiable credential, is a special kind of digital credential, defined in . The following informative example is provided:

A vCard containing Verifiable Credentials

In this example, all fields except for "KEY" are not protected. KEY encodes a verifiable credential expressing a hypothetical university degree. Public credentials are often shared on social, or professional networks, however, they may still contain sensitive information which SHOULD NOT be disclosed such as student identification numbers, or other details about the credential subject. This example is for demonstration purposes only.

Compression Suffixes In order to reduce the size of Data URIs encoded in vCards, compression MAY be applied using structured suffixed, including using . Any suffixes registered in MAY be used. When encoding data formats, such as JSON Web Tokens, that are already URI safe, the base64 data encoding MUST be ommited. The examples that follow have line wrapping for readability. The following example is informative:

A data uri for sd-jwt with no base64 encoding.

When applying compression to content with a well defined media type, the result of the compression and decompression operations are bytes, which MUST be made URI safe through base64 encoding. The following example used zstd as defined in , and is informative:

A data uri for a zstd compressed sd-jwt with base64 encoding.

The following example used gzip as defined in , and is informative:

A data uri for a gzip compressed sd-jwt with base64 encoding.

Quid Pro Quo Compression is a technique that reduces storage costs by increasing computation costs. The best choice for a compression algorithm is use case specific. Compression is often applied at the transport layer, making message level compression redundant in some cases. For many use cases choosing no compression is the simplest, safest, and fastest solution. A detailed analysis of compression algorithms is beyond the scope of this document. In the examples in the section above, the storage costs are as follows: Content length in bytes

Media Type	Number of Bytes
application/sd-jwt	1981
application/sd-jwt+zstd	1276
application/sd-jwt+gzip	1204

Security Considerations TODO Security

Deserialization of Untrusted Data Several layers of application processing, relevant to occur before a integrity protected data can be verified. The QR Code processing layer could have vulnerabilities that are exploitable before the vCard layer is even reached. The vCard processing layer could have vulnerabilities that are exploitable before the credential can be selected. The credential processing layer might require deserialization of parts or all of the encoded credentials before the verification process can occur. After verification has occurred, the credential structure can be validated further, for example checking the lengths of strings, or ranges on integers expressing date times. After all this validation, processing, verification and processing has occurred, the end result is the credential data as the issuer intended for it to be delivered to the verifier. Implementations should avoid exposing unverified, unvalidated fields to users, because they can be altered without detection. In cases were data is repeated without protection outside the credential, the guidance provided regarding unprotected headers in and MUST be followed.

IANA Considerations This document has no IANA actions.

References Normative References 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 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] JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes. Digital Bazaar Digital Bazaar This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to describe how to interpret subtypes with multiple suffixes. 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. 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. Informative References IANA IANA This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs. This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME. Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. This document replaces and obsoletes RFC 8478. Authlete Microsoft Ping Identity This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims. Spruce Systems, Inc. Authlete Inc. This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format.

Acknowledgments TODO acknowledge.