Network Working Group G. Rodriguez Internet-Draft Rolab Intended status: Experimental 16 April 2026 Expires: 18 October 2026 Peer-to-Peer Presence Verification for Relationship-Bound Authorization draft-rodriguez-h2h-presence-attestation-00 Abstract Existing protocols authenticate users to services, negotiate session keys, or protect message content from eavesdroppers. None verify that a remote party is the same individual whose key was accepted during an earlier in-person exchange and has just now physically authorized a signature on the device holding that key. Advances in synthetic media make it increasingly difficult to trust unauthenticated audio, video, or text for sensitive authorizations. This document defines transport-independent CBOR- and COSE-based objects that chain every remote interaction back to a bilateral in- person contact exchange -- not a certificate authority, identity provider, or key server. The protocol specifies Key Binding Objects, short-lived Session Credentials, replay-protected Signed Messages, a Presence Challenge requiring fresh platform-mediated user verification, and a Relationship Fingerprint for out-of-band key confirmation. It does not claim to prove biological humanness, legal identity, or voluntary action. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://github.com/rolabtech/h2h. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- rodriguez-h2h-presence-attestation/. Source for this draft and an issue tracker can be found at https://github.com/rolabtech/h2h. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Rodriguez Expires 18 October 2026 [Page 1] Internet-Draft P2P Presence Verification April 2026 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 18 October 2026. Copyright Notice Copyright (c) 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Design Goal . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Reuse and Interoperability Scope . . . . . . . . . . . . 7 1.6. Trust Model Summary . . . . . . . . . . . . . . . . . . . 7 1.7. End-to-End Message Flow . . . . . . . . . . . . . . . . . 7 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 9 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Assurance Values . . . . . . . . . . . . . . . . . . . . 10 2.3. Hardware Attestation . . . . . . . . . . . . . . . . . . 11 2.4. CBOR and COSE Conventions . . . . . . . . . . . . . . . . 12 3. Identity and Binding Model . . . . . . . . . . . . . . . . . 12 3.1. Two-Key Model . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Identity Key Requirements . . . . . . . . . . . . . . . . 13 3.3. Transport Key Rotation . . . . . . . . . . . . . . . . . 14 3.3.1. Offline Rotation . . . . . . . . . . . . . . . . . . 15 4. Contact Object . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Creation . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Verification . . . . . . . . . . . . . . . . . . . . . . 17 Rodriguez Expires 18 October 2026 [Page 2] Internet-Draft P2P Presence Verification April 2026 4.5. Ceremony Requirement . . . . . . . . . . . . . . . . . . 18 4.6. Size Considerations . . . . . . . . . . . . . . . . . . . 19 4.7. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. Replay Protection . . . . . . . . . . . . . . . . . . . . 19 5. Key Binding Object . . . . . . . . . . . . . . . . . . . . . 19 5.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Creation . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Verification . . . . . . . . . . . . . . . . . . . . . . 20 5.5. Renewal . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Session Credential . . . . . . . . . . . . . . . . . . . . . 21 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Creation . . . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Verification . . . . . . . . . . . . . . . . . . . . . . 23 6.5. Credential Lifecycle . . . . . . . . . . . . . . . . . . 24 6.6. Security Note . . . . . . . . . . . . . . . . . . . . . . 24 7. Signed Message . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Message Ordering and Replay Protection . . . . . . . . . 26 7.3.1. Reliable Transports . . . . . . . . . . . . . . . . . 26 7.3.2. Unreliable Transports . . . . . . . . . . . . . . . . 26 7.4. Replay State . . . . . . . . . . . . . . . . . . . . . . 27 7.5. Verification . . . . . . . . . . . . . . . . . . . . . . 27 8. Presence Challenge and Presence Response . . . . . . . . . . 28 8.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Challenge Format . . . . . . . . . . . . . . . . . . . . 29 8.3. Response Format . . . . . . . . . . . . . . . . . . . . . 30 8.4. Verification . . . . . . . . . . . . . . . . . . . . . . 31 8.5. Timing . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Relationship Fingerprint . . . . . . . . . . . . . . . . . . 32 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Computation . . . . . . . . . . . . . . . . . . . . . . . 33 9.3. Properties . . . . . . . . . . . . . . . . . . . . . . . 33 9.4. Key Change Notification . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10.1. Limitations . . . . . . . . . . . . . . . . . . . . . . 34 10.2. Platform Trust, Compromised Applications, and Device State . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.3. Contact Object Capture . . . . . . . . . . . . . . . . . 35 10.4. Key Binding Object Expiry . . . . . . . . . . . . . . . 35 10.5. Assurance Semantics, Policy, and Application Compromise . . . . . . . . . . . . . . . . . . . . . . 35 10.6. Relay Attack on Presence Response . . . . . . . . . . . 36 10.7. Type Confusion . . . . . . . . . . . . . . . . . . . . . 36 10.8. Relationship Fingerprint Limitations . . . . . . . . . . 36 10.9. Privacy Considerations . . . . . . . . . . . . . . . . . 37 Rodriguez Expires 18 October 2026 [Page 3] Internet-Draft P2P Presence Verification April 2026 10.9.1. Identity Key as a Stable Identifier . . . . . . . . 37 10.9.2. Relationship Correlation . . . . . . . . . . . . . . 37 10.9.3. Metadata Exposure . . . . . . . . . . . . . . . . . 37 10.9.4. Fingerprint Handling . . . . . . . . . . . . . . . . 38 10.10. Denial of Service via Presence Challenges . . . . . . . 38 10.11. Post-Quantum Considerations . . . . . . . . . . . . . . 38 10.12. Forward Secrecy of Authentication . . . . . . . . . . . 38 10.13. Session Credential Expiry and In-Flight Messages . . . . 38 10.14. Session Signing Key Compromise . . . . . . . . . . . . . 39 10.15. Device Loss and Recovery . . . . . . . . . . . . . . . . 39 10.16. Terminology Caution . . . . . . . . . . . . . . . . . . 40 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 11.1. Structure Type Values . . . . . . . . . . . . . . . . . 40 11.2. Assurance Values . . . . . . . . . . . . . . . . . . . . 41 11.3. Transport Key Algorithms . . . . . . . . . . . . . . . . 41 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 12.1. Normative References . . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 42 Appendix A. CDDL Schema . . . . . . . . . . . . . . . . . . . . 43 Appendix B. Implementation Considerations . . . . . . . . . . . 46 B.1. Platform Key Store Mapping . . . . . . . . . . . . . . . 46 B.2. App Integrity Attestation . . . . . . . . . . . . . . . . 47 B.3. Payload Size Limits . . . . . . . . . . . . . . . . . . . 47 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction 1.1. Problem Statement Existing protocols authenticate users to services (WebAuthn [WebAuthn], FIDO2 [FIDO2]), services to users (TLS [RFC8446]), or protect message content from eavesdroppers (Signal Protocol [Signal], MLS [RFC9420]). However, some deployments require a narrower but different property: one peer wishes to verify that the remote party is continuing a relationship previously anchored by an in-person exchange, and that the remote party has recently produced a local authorization event on the device bound to that relationship. Examples include high-trust messaging, approval workflows, operator handoffs, and other interactions where account-level authentication alone is insufficient. Rodriguez Expires 18 October 2026 [Page 4] Internet-Draft P2P Presence Verification April 2026 Recent advances in synthetic media and automated impersonation make unauthenticated audio, video, or text unreliable for sensitive approvals. This document does not detect synthetic media or prove biological humanness. Instead, it specifies interoperable signed objects and verification rules that bind sensitive authorizations to a prior relationship ceremony and to a fresh, platform-mediated local user-verification event. 1.2. Design Goal This protocol does not prove a universally valid human identity. It lets a relying peer verify all of the following: 1. A public key was previously accepted during an in-person exchange. 2. The corresponding private key remains non-exportable and device- bound according to the local platform's key store semantics. 3. The remote device recently produced a signature using that key, or a key delegated by it, following a local user-verification event reported by the platform. 1.3. Overview The protocol operates in four logical phases: Phase 1 Phase 2 Phase 3 Phase 4 CONTACT KEY BINDING SESSION DATA EXCHANGE PRESENTATION DELEGATION TRANSFER +----------+ +----------+ +----------+ +----------+ | Meet in | | Connect | | IK signs | | SSK signs| | person, |--->| remotely,|--->| ephemeral|--->| app | | exchange | | present | | SSK via | | units | | Contact | | Key | | Session | | | | Objects | | Binding | |Credential| | | +----------+ +----------+ +----------+ +----------+ [user-verify] [verify chain] [user-verify] [automatic] At any point: Presence Challenge --> fresh IK signature Phases 1 and 3 require platform-mediated user verification (e.g., biometric or PIN) because they use the hardware-bound Identity Key. Phase 4 is automatic because the SSK is a software key delegated during Phase 3 -- no user interaction is needed for signing. Rodriguez Expires 18 October 2026 [Page 5] Internet-Draft P2P Presence Verification April 2026 1. *Contact Exchange*: Two peers meet in person and exchange Contact Objects -- signed structures containing their Identity Keys, Transport Keys, and addressing information. 2. *Key Binding Presentation*: When connecting remotely, peers present Key Binding Objects and verify the trust chain: stored IK (from the in-person ceremony) = IK in binding = key that signed TK = TK of the transport peer. 3. *Session Delegation*: Peers create Session Credentials (IK signs an ephemeral SSK) for efficient signing without repeated user- verification prompts. 4. *Data Transfer*: Peers exchange Signed Messages (SSK signs application-defined units). Every signed unit chains back to the in-person ceremony. At any point, either peer MAY issue a Presence Challenge requesting a fresh IK signature that requires a local user-verification event on the challenged device. 1.4. Scope This document specifies: * The Contact Object format and verification rules (Section 4) * The Key Binding Object format and verification rules (Section 5) * The Session Credential format and verification rules (Section 6) * The Signed Message format and verification rules (Section 7) * The Presence Challenge and Presence Response formats (Section 8) * A Relationship Fingerprint computation (Section 9) * Transport Key rotation guidance (Section 3.3) * Protocol constants for object types, assurance values, and transport key algorithms This document does not specify: * Proof-of-personhood * Legal, civil, or government identity Rodriguez Expires 18 October 2026 [Page 6] Internet-Draft P2P Presence Verification April 2026 * Transport protocol selection or configuration * End-to-end encryption * Multi-party relationships * Revocation or recovery * Application-layer trust policy * UX requirements beyond protocol-visible semantics 1.5. Reuse and Interoperability Scope The objects and verification procedures in this document are intended for reuse across multiple peer-to-peer applications and transports that require relationship-bound authorization. This document does not define a single application protocol or user experience. Instead, it standardizes compact object formats and verification rules that can be embedded into messaging, approval, or rendezvous systems. 1.6. Trust Model Summary This protocol relies on two external trust assumptions. First, peers are assumed to have completed an earlier in-person ceremony and to have accepted each other's Contact Objects during that ceremony. Second, relying parties trust the local platform's key store and user-verification semantics. A valid signature under the stored identity key indicates only that the platform permitted use of that key under its configured policy. It does not, by itself, prove biological humanness, voluntary action, or legal identity. 1.7. End-to-End Message Flow The following ladder diagram shows a complete post-contact session between two peers, Alice and Bob, who have already exchanged Contact Objects in person. Phases 2 through 4 occur each time the peers reconnect remotely. Rodriguez Expires 18 October 2026 [Page 7] Internet-Draft P2P Presence Verification April 2026 Alice Bob | | | ============ Phase 2: Key Binding ============ | | | | --- KBO(IK_A signs TK_A) ----------------------->| | | |<---------------------- KBO(IK_B signs TK_B) --- | | | | Both sides verify: | | - IK in KBO matches stored IK from ceremony | | - TK in KBO matches transport peer key | | - KBO signature valid, not expired | | | | ========= Phase 3: Session Delegation ======== | | | | Alice generates ephemeral SSK_A | | IK_A signs Session Credential(SSK_A) | | [user-verification: biometric/PIN] | | | | --- SessionCredential(SSK_A_pub) --------------->| | | | Bob generates ephemeral SSK_B | | IK_B signs Session Credential(SSK_B) | | [user-verification: biometric/PIN] | | | |<-------------- SessionCredential(SSK_B_pub) --- | | | | Both sides verify: | | - SC signed by stored IK | | - peer_ik_hash matches own IK | | - SC not expired | | - Cache SSK_pub for message verification | | | | =========== Phase 4: Data Transfer =========== | | | | --- SignedMessage(id=1, SSK_A signs content) --->| | | | Bob verifies: | | - SSK_A signature valid | | - message_id > last seen (replay check) | | - Trust chain: SSK_A -> SC -> IK_A | | -> ceremony | | | |<--- SignedMessage(id=1, SSK_B signs content) --- | | | | --- SignedMessage(id=2, SSK_A signs content) --->| | | |<--- SignedMessage(id=2, SSK_B signs content) --- | Rodriguez Expires 18 October 2026 [Page 8] Internet-Draft P2P Presence Verification April 2026 | | | ====== Optional: Presence Challenge ========== | | | | --- PRESENCE_CHALLENGE {nonce} ----------------->| | | | Bob's device prompts biometric/PIN | | IK_B signs nonce + channel_binding | | | |<--------------- PRESENCE_RESPONSE {nonce, sig} ---| | | | Alice verifies: | | - sig valid against stored IK_B | | - nonce matches | | - assurance >= required | | | | ====== Session Credential Renewal ============ | | | | (When SC expires, peer creates a new SC | | requiring fresh user-verification; old SSK | | is discarded from memory) | | | The diagram above is informative. Normative requirements for each object are specified in their respective sections (Section 4, Section 5, Section 6, Section 7, Section 8). 2. Conventions 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. 2.1. Terminology Identity Key (IK): A long-term P-256 ECDSA key pair [FIPS186-5] generated in a platform key store. The private key is non- exportable. Use of the private key requires local user verification according to platform policy. Transport Key (TK): A transport-facing key pair used by a peer-to- peer transport or rendezvous mechanism. The TK is bound to the IK by a Key Binding Object. The algorithm is determined by the transport layer and is not constrained by this document. Session Signing Key (SSK): A short-lived P-256 ECDSA key pair Rodriguez Expires 18 October 2026 [Page 9] Internet-Draft P2P Presence Verification April 2026 generated in software, delegated by the IK for signing application-defined units. The SSK private key MUST be held in memory only and MUST NOT be persisted to disk. Not all application data requires SSK signing; see Section 7.1 for guidance on when Signed Messages add value beyond transport authentication. Platform Key Store: A platform component that generates, stores, and uses cryptographic keys without exposing private key material to application software. Examples include secure enclaves, secure elements, TPMs, and trusted execution environments. Contact Object: A COSE_Sign1 object exchanged during an in-person ceremony that conveys the sender's Identity Key, Transport Key, and related metadata. Key Binding Object (KBO): A COSE_Sign1 object that binds a Transport Key to a previously exchanged Identity Key. Session Credential: A COSE_Sign1 object delegating signing authority from the IK to a short-lived SSK. Analogous to TLS Delegated Credentials [RFC9345]. Signed Message: A COSE_Sign1 object wrapping application content, signed by the SSK and verifiable via the Session Credential trust chain. Presence Response: A COSE_Sign1 object produced in response to a challenge and bound to a connection context. Assurance Value: A protocol-visible value reported by the signer describing the type of local verification event used for a signing operation. Assurance values are claims reported by the platform, not independently verifiable facts. 2.2. Assurance Values This document defines three assurance values. Higher numeric values indicate stronger assurance: Rodriguez Expires 18 October 2026 [Page 10] Internet-Draft P2P Presence Verification April 2026 +=======+===================+====================================+ | Value | Label | Meaning | +=======+===================+====================================+ | 1 | CREDENTIAL | The platform reported knowledge- | | | | based verification (PIN, password, | | | | pattern) for this signing | | | | operation. | +-------+-------------------+------------------------------------+ | 2 | BIOMETRIC | The platform reported biometric | | | | verification (face, fingerprint, | | | | iris) for this signing operation. | +-------+-------------------+------------------------------------+ | 3 | HARDWARE_VERIFIED | The signing operation includes | | | | hardware attestation evidence from | | | | the platform's root of trust, | | | | proving the key is hardware-bound | | | | and the verification event is | | | | genuine. See Section 2.3. | +-------+-------------------+------------------------------------+ Table 1 A response with assurance value N satisfies a requirement for assurance value M if and only if N >= M. Values 4 and above are reserved for future extensions; the N >= M rule ensures forward compatibility. Values 1 and 2 are application-reported claims; a compromised application could misrepresent them. Value 3 includes cryptographic evidence from the platform's hardware root of trust that cannot be forged by a compromised application (see Section 2.3). A verifier MUST treat assurance values as local policy inputs; they do not imply equivalent security across platforms. Relying parties MUST be informed of the assurance value and SHOULD make it visible to the user. 2.3. Hardware Attestation When the assurance value is set to 3 (HARDWARE_VERIFIED), the signed object MUST include hardware attestation evidence in an additional field (attestation_evidence). This evidence is a platform-specific certificate chain or attestation object that allows the verifier to confirm: 1. The Identity Key was generated inside a genuine hardware security module (Secure Enclave, StrongBox, TPM). Rodriguez Expires 18 October 2026 [Page 11] Internet-Draft P2P Presence Verification April 2026 2. The Identity Key is non-exportable, as enforced by the hardware -- not merely claimed by the application. 3. The key is configured to require user verification (biometric or credential) before each signing operation. Implementations running on platforms that support hardware key attestation (e.g., Android Key Attestation, Apple Secure Enclave key attestation) SHOULD include attestation evidence in Contact Objects exchanged during the in-person ceremony. This allows the receiving peer to verify the Identity Key's hardware properties at the moment of initial trust establishment. The attestation evidence is opaque to this specification. Its format and verification procedure are determined by the platform vendor. A verifier that does not recognize or cannot verify the attestation evidence MUST treat the assurance value as 2 (BIOMETRIC) rather than 3. Including hardware attestation introduces a trust dependency on the platform vendor's certificate chain for the specific claim that the key store properties are genuine. It does not replace the in-person ceremony as the trust anchor for identity. 2.4. CBOR and COSE Conventions All protocol payloads in this document are encoded as CBOR maps [RFC8949] with integer keys. All signed objects are encoded as COSE_Sign1 [RFC9052] with algorithm ES256 (ECDSA w/ SHA-256 using P-256, COSE algorithm identifier -7). Implementations MUST use deterministic CBOR encoding as defined in Section 4.2 of [RFC8949] (Core Deterministic Encoding Requirements). This ensures that the same payload always produces the same byte sequence, which is critical for signature verification. Each payload includes a structure_type discriminator at key 0. A verifier MUST check this value before processing any other payload semantics. This prevents type confusion attacks where a signed structure of one type is substituted for another. Identity Key public keys are encoded as COSE_Key structures [RFC9053] with kty=2 (EC2) and crv=1 (P-256). 3. Identity and Binding Model Rodriguez Expires 18 October 2026 [Page 12] Internet-Draft P2P Presence Verification April 2026 3.1. Two-Key Model The protocol uses a long-term Identity Key and a rotatable Transport Key per peer. +--------------------------------------------------+ | Identity Key (IK) | | Algorithm: P-256 ECDSA | | Storage: Platform key store (non-exportable) | | Access: User-verification-gated | | Lifetime: Permanent (until device loss/reset) | | Purpose: Relationship anchor and trust root | +--------------------------------------------------+ | | signs (Key Binding Object) v +--------------------------------------------------+ | Transport Key (TK) | | Algorithm: Transport-determined | | Storage: Software | | Access: No per-operation user verification | | Lifetime: Rotatable | | Purpose: Peer-to-peer transport identity | +--------------------------------------------------+ The Identity Key is the relationship anchor. It is exchanged during the in-person ceremony and later used to verify continuity. Its private key never leaves the platform key store, and every use requires a local user-verification event. The Transport Key identifies the peer at the transport layer. Transport operations (handshakes, session resumption) require a key that the transport library can use without per-operation user verification. A Key Binding Object (Section 5) links the TK to the IK, extending the trust anchor to the transport layer. 3.2. Identity Key Requirements An implementation claiming conformance for IK generation MUST ensure: 1. Non-exportable: No interface SHALL allow extraction of the private key material, including backup, sync, or migration interfaces. Rodriguez Expires 18 October 2026 [Page 13] Internet-Draft P2P Presence Verification April 2026 2. User-verification-gated: The platform MUST enforce local user verification before each IK signing operation, or before each operation within a bounded and explicitly documented platform policy window. The platform MUST NOT cache verification results indefinitely. 3. Enrollment-sensitive: If the device's biometric enrollment data changes (e.g., a new fingerprint is added), the platform SHOULD invalidate the Identity Key. This prevents an attacker who gains temporary physical access from adding their biometric and subsequently producing valid BIOMETRIC-level signatures. 4. The platform MUST expose sufficient information for the implementation to label the resulting signature with one of the defined assurance values. 5. Hardware attestation: On platforms that support hardware key attestation (e.g., Android Key Attestation, Apple Secure Enclave key attestation), implementations SHOULD obtain attestation evidence for the Identity Key at generation time and include it in Contact Objects (see Section 2.3). This document does not require any specific hardware architecture. It intentionally abstracts over secure enclaves, secure elements, TPMs, TEEs, and comparable mechanisms. However, platforms that can provide hardware attestation evidence offer a stronger assurance level (HARDWARE_VERIFIED) that is independently verifiable by the receiving peer. 3.3. Transport Key Rotation The Transport Key MAY be rotated to limit network-level correlation. Rotation comprises: 1. Generate a new Transport Key pair. 2. Sign a new Key Binding Object binding the IK to the new TK (Section 5). 3. Distribute the new KBO to connected peers. 4. Discard old TK private material. Peers that receive a new KBO for a known IK MUST verify the KBO signature. If valid, the peer updates its stored TK for that contact. Rodriguez Expires 18 October 2026 [Page 14] Internet-Draft P2P Presence Verification April 2026 3.3.1. Offline Rotation When the Transport Key is rotated while a contact is offline, the contact will be unable to locate the key holder on the network using the previous Transport Key. Implementations MUST address this using one or more of the following mechanisms: *Stable addressing (RECOMMENDED)*: The addressing field in the Contact Object (Section 4, field 8) SHOULD contain addressing information that survives Transport Key rotation (e.g., a relay server address or discovery service endpoint). When a contact reconnects using the stable address, the key holder presents the current KBO containing the new Transport Key. *Mailbox deposit*: If the implementation supports a mailbox or store- and-forward mechanism, the key holder SHOULD deposit the new KBO at their mailbox. Offline contacts retrieve the updated KBO upon reconnection. *Overlap period*: The key holder MAY continue to accept connections on the old Transport Key for a limited time after rotation (RECOMMENDED: no more than 24 hours). Connections on the old Transport Key SHOULD be used only to deliver the new KBO and redirect the contact. After the overlap period, the old Transport Key MUST be discarded. Implementations MUST NOT rotate the Transport Key without a mechanism for offline contacts to discover the new key. 4. Contact Object 4.1. Purpose The Contact Object is exchanged during an in-person ceremony and anchors the long-term relationship. 4.2. Format The Contact Object is a COSE_Sign1 structure: ContactObject = COSE_Sign1( protected: { 1 (alg): -7 (ES256) }, unprotected: {}, payload: Contact_payload ) Contact_payload is a CBOR map: Rodriguez Expires 18 October 2026 [Page 15] Internet-Draft P2P Presence Verification April 2026 +=====+======================+==========+===========================+ | Key | Name | CBOR | Description | | | | Type | | +=====+======================+==========+===========================+ | 0 | structure_type | uint | MUST be 0x02 | | | | | (CONTACT_OBJECT) | +-----+----------------------+----------+---------------------------+ | 1 | version | uint | MUST be 1 | +-----+----------------------+----------+---------------------------+ | 2 | ik_public | COSE_Key | Sender Identity Key | | | | | (P-256) | +-----+----------------------+----------+---------------------------+ | 3 | tk_public | bstr | Sender Transport Key | | | | | public bytes | +-----+----------------------+----------+---------------------------+ | 4 | tk_algorithm | int | Algorithm identifier | | | | | for tk_public | +-----+----------------------+----------+---------------------------+ | 5 | display_name | tstr | UTF-8, max 64 bytes | +-----+----------------------+----------+---------------------------+ | 6 | timestamp | uint | Unix time in | | | | | milliseconds | +-----+----------------------+----------+---------------------------+ | 7 | nonce | bstr | 16 bytes, | | | | | cryptographically | | | | | random | +-----+----------------------+----------+---------------------------+ | 8 | addressing | bstr | Transport-specific, | | | | | max 1024 bytes | +-----+----------------------+----------+---------------------------+ | 9 | assurance | uint | Assurance value for | | | | | signing | +-----+----------------------+----------+---------------------------+ | 10 | attestation_evidence | bstr | OPTIONAL. Hardware | | | | | attestation evidence | | | | | (platform-specific). | | | | | Present when | | | | | assurance is 3 | | | | | (HARDWARE_VERIFIED). | +-----+----------------------+----------+---------------------------+ Table 2 The tk_public field MUST contain the raw public key bytes in the canonical encoding for the algorithm identified by tk_algorithm. See the transport key algorithm table (Section 11) for defined encodings. Rodriguez Expires 18 October 2026 [Page 16] Internet-Draft P2P Presence Verification April 2026 The addressing field is opaque to this specification. It MUST carry only the minimum information needed for rendezvous or re-contact in the embedding application. Implementations SHOULD prefer application-scoped or short-lived addressing values where practical and SHOULD avoid embedding identifiers that are broader or more stable than operationally required. 4.3. Creation The sender MUST: 1. Generate a 16-byte nonce (field 7) using a cryptographically secure random number generator (CSPRNG). 2. Set timestamp (field 6) to the current time. 3. Populate all other fields. 4. If the platform supports hardware key attestation, obtain attestation evidence for the Identity Key and include it in field 10 (attestation_evidence). Set assurance (field 9) to 3 (HARDWARE_VERIFIED). Otherwise, set assurance (field 9) to the value the platform will report for the signing event (1 for CREDENTIAL, 2 for BIOMETRIC). 5. Serialize Contact_payload as deterministic CBOR. 6. Sign using COSE_Sign1 with the Identity Key. This operation triggers a local user-verification event. 4.4. Verification Upon receiving a Contact Object during the in-person ceremony, the receiver MUST perform the following checks. Checks are ordered so that inexpensive validations precede cryptographic signature verification: 1. Decode the COSE_Sign1 structure. If decoding fails, reject. 2. Extract the Contact_payload. 3. Verify that structure_type (field 0) is 0x02 (CONTACT_OBJECT). If not, reject. 4. Verify that version (field 1) is supported. If unsupported, reject. Rodriguez Expires 18 October 2026 [Page 17] Internet-Draft P2P Presence Verification April 2026 5. Verify that timestamp (field 6) is within a 5-minute window of the receiver's current time: abs(now - timestamp) <= 300000 milliseconds. If outside the window, reject. 6. Verify that nonce (field 7) has not been seen in a previous Contact Object within the current 5-minute window. If duplicate, reject. 7. Verify the COSE_Sign1 signature using ik_public (field 2). If signature verification fails, reject. 8. If attestation_evidence (field 10) is present and assurance (field 9) is 3 (HARDWARE_VERIFIED), verify the attestation evidence against the platform vendor's certificate chain. If the attestation evidence is present but verification fails, reject. If the verifier cannot process the attestation format, it MUST treat the assurance value as 2 (BIOMETRIC) rather than 3 and MAY accept the Contact Object at the reduced assurance level. 9. If all checks pass and the exchange is bidirectional (the local device has also transmitted its own Contact Object to this peer), store the contact: ik_public, tk_public, tk_algorithm, display_name, addressing, assurance value, attestation evidence (if present), and the timestamp of the exchange. A verifier MAY compute and compare a Relationship Fingerprint (Section 9) as an additional defense if the exchange path includes intermediaries. 4.5. Ceremony Requirement The Contact Object exchange MUST be bidirectional: both parties MUST exchange and verify Contact Objects before either party stores the other as a verified contact. An implementation MUST NOT store a contact from a unidirectional exchange. The proximity mechanism MUST satisfy the following requirements: 1. Both parties are physically co-present during the exchange. 2. The mechanism can transfer at least 512 bytes of binary data. 3. The mechanism provides a human-verifiable indication that the exchange is occurring with the intended party (e.g., visual confirmation, physical proximity constraint). Rodriguez Expires 18 October 2026 [Page 18] Internet-Draft P2P Presence Verification April 2026 4. For mechanisms that do not provide visual confirmation of the peer (e.g., wireless discovery), the implementation MUST require explicit user confirmation of the peer's display_name before storing the contact. The choice of proximity mechanism is an implementation decision. 4.6. Size Considerations A Contact Object without attestation evidence typically serializes to 300-500 bytes; with attestation evidence (field 10) it may reach 1-2 KB. Implementations SHOULD ensure their proximity mechanism supports at least 512 bytes, or at least 4,096 bytes when attestation is included. Bandwidth-limited mechanisms (e.g., QR codes) MAY omit attestation evidence from the initial exchange and deliver it over the transport connection after rendezvous. 4.7. Clock Skew The 5-minute timestamp window accommodates reasonable clock skew between devices. Implementations SHOULD use network time synchronization (NTP) when available but MUST NOT reject payloads solely due to minor clock differences within the window. 4.8. Replay Protection The nonce field prevents replay of a captured Contact Object within its validity window. After the 5-minute window expires, the timestamp check prevents replay. Implementations MUST maintain a set of seen nonces for at least 5 minutes and SHOULD discard them after 10 minutes. 5. Key Binding Object 5.1. Purpose The Key Binding Object proves continuity between the stored IK and the currently offered TK. 5.2. Format The Key Binding Object is a COSE_Sign1 structure: KeyBindingObject = COSE_Sign1( protected: { 1 (alg): -7 (ES256) }, unprotected: {}, payload: KBO_payload ) Rodriguez Expires 18 October 2026 [Page 19] Internet-Draft P2P Presence Verification April 2026 KBO_payload is a CBOR map: +=====+================+===========+=============================+ | Key | Name | CBOR Type | Description | +=====+================+===========+=============================+ | 0 | structure_type | uint | MUST be 0x01 (KEY_BINDING) | +-----+----------------+-----------+-----------------------------+ | 1 | version | uint | MUST be 1 | +-----+----------------+-----------+-----------------------------+ | 2 | ik_public | COSE_Key | Identity Key (P-256) | +-----+----------------+-----------+-----------------------------+ | 3 | tk_public | bstr | Transport Key public bytes | +-----+----------------+-----------+-----------------------------+ | 4 | tk_algorithm | int | Algorithm identifier | +-----+----------------+-----------+-----------------------------+ | 5 | timestamp | uint | Unix time in milliseconds | +-----+----------------+-----------+-----------------------------+ | 6 | expiry | uint | Unix time in milliseconds | +-----+----------------+-----------+-----------------------------+ | 7 | assurance | uint | Assurance value for signing | +-----+----------------+-----------+-----------------------------+ Table 3 The tk_public and tk_algorithm fields follow the same encoding rules as in the Contact Object (Section 4). 5.3. Creation The signer MUST: 1. Populate all fields of KBO_payload, including assurance (field 7) based on the key's configured authentication policy. 2. Set expiry (field 6) to no more than 30 days (2,592,000,000 milliseconds) after timestamp (field 5). 3. Serialize KBO_payload as deterministic CBOR. 4. Sign using COSE_Sign1 with the Identity Key. This operation triggers a local user-verification event. 5.4. Verification The verifier MUST perform the following checks. Checks are ordered so that inexpensive validations precede cryptographic signature verification: Rodriguez Expires 18 October 2026 [Page 20] Internet-Draft P2P Presence Verification April 2026 1. Decode the COSE_Sign1 structure. If decoding fails, reject. 2. Verify that structure_type (field 0) is 0x01 (KEY_BINDING). If not, reject. 3. Verify that version (field 1) is supported. If unsupported, reject. 4. Verify that the current time is >= timestamp (field 5) and < expiry (field 6). If outside the window, reject. 5. Verify that expiry (field 6) minus timestamp (field 5) does not exceed 30 days (2,592,000,000 milliseconds). If it does, reject. 6. Extract ik_public (field 2) from the payload. 7. Verify that ik_public matches the expected Identity Key for this contact (from a prior contact exchange, Section 4). If no match, reject. 8. Verify that tk_public (field 3) matches the Transport Key of the transport peer as observed during the transport handshake. If no match, reject. 9. Verify the COSE_Sign1 signature using ik_public. If signature verification fails, reject. If ANY check fails, the verifier MUST reject the KBO and terminate the connection. 5.5. Renewal Implementations MUST re-sign the KBO before its expiry. Renewal requires a fresh user-verification event, providing periodic evidence of continued platform-authorized use. 6. Session Credential 6.1. Purpose The Session Credential allows efficient signing of application- defined units without requiring a fresh IK operation for each unit. Not all data types require this signing; embedding applications determine which content warrants Signed Message protection (see Section 7.1). The delegation pattern is analogous to TLS Delegated Credentials [RFC9345]: a long-term trust anchor (the IK) signs a short-lived operational credential (the Session Credential), which in turn authenticates individual operations (messages, file transfers). Rodriguez Expires 18 October 2026 [Page 21] Internet-Draft P2P Presence Verification April 2026 Stored IK_public (from in-person ceremony) | v verifies Session Credential (COSE_Sign1 signed by IK) | contains SSK_public v verifies Signed Message (COSE_Sign1 signed by SSK) 6.2. Format The Session Credential is a COSE_Sign1 structure: SessionCredential = COSE_Sign1( protected: { 1 (alg): -7 (ES256) }, unprotected: {}, payload: SC_payload ) SC_payload is a CBOR map: +=====+================+===========+======================+ | Key | Name | CBOR Type | Description | +=====+================+===========+======================+ | 0 | structure_type | uint | MUST be 0x03 | | | | | (SESSION_CREDENTIAL) | +-----+----------------+-----------+----------------------+ | 1 | version | uint | MUST be 1 | +-----+----------------+-----------+----------------------+ | 2 | ssk_public | COSE_Key | Ephemeral P-256 | | | | | public key | +-----+----------------+-----------+----------------------+ | 3 | ik_public | COSE_Key | Issuing Identity Key | | | | | (reference) | +-----+----------------+-----------+----------------------+ | 4 | peer_ik_hash | bstr | SHA-256 of peer's | | | | | IK_public | +-----+----------------+-----------+----------------------+ | 5 | timestamp | uint | Unix time in | | | | | milliseconds | +-----+----------------+-----------+----------------------+ | 6 | expiry | uint | Unix time in | | | | | milliseconds | +-----+----------------+-----------+----------------------+ | 7 | assurance | uint | Assurance value | +-----+----------------+-----------+----------------------+ Table 4 Rodriguez Expires 18 October 2026 [Page 22] Internet-Draft P2P Presence Verification April 2026 6.3. Creation The signer MUST: 1. Generate an ephemeral P-256 key pair (the Session Signing Key). The SSK is generated in software; it is not required to reside in the platform key store. 2. Compute peer_ik_hash as SHA-256 of the peer's IK_public encoded as an uncompressed P-256 point (65 bytes starting with 0x04). This encoding MUST match the encoding used in the Relationship Fingerprint computation (Section 9). 3. Set expiry to a value after timestamp. Implementations MUST set a finite expiry (unlimited Session Credentials are prohibited). A RECOMMENDED default is 1 hour. Applications with different risk profiles MAY choose shorter durations (e.g., 5 minutes for financial transactions) or longer durations (e.g., 8 hours for a workday session). 4. Set assurance (field 7) based on the key's configured authentication policy. 5. Serialize SC_payload as deterministic CBOR. 6. Sign using COSE_Sign1 with the Identity Key. This operation triggers a local user-verification event. The SSK private key MUST be held in memory only and MUST NOT be persisted to disk. It MUST be discarded when the session expires or the connection closes. Implementations SHOULD store the SSK in a memory region that is not swappable to disk (e.g., mlock on Linux). 6.4. Verification The verifier MUST: 1. Decode the COSE_Sign1 structure. If decoding fails, reject. 2. Verify that structure_type (field 0) is 0x03 (SESSION_CREDENTIAL). If not, reject. 3. Verify that version (field 1) is supported. If unsupported, reject. 4. Verify that the current time is between timestamp (field 5) and expiry (field 6). If outside the window, reject. Rodriguez Expires 18 October 2026 [Page 23] Internet-Draft P2P Presence Verification April 2026 5. Verify that ik_public (field 3) matches the stored Identity Key for the peer. If no match, reject. 6. Verify that peer_ik_hash (field 4) matches SHA-256 of the verifier's own IK_public (confirms the credential is scoped to this relationship). If no match, reject. 7. Verify the COSE_Sign1 signature using the stored IK_public. If signature verification fails, reject. The Session Credential is typically verified once per session (when first received) and the ssk_public is cached for subsequent message verifications. 6.5. Credential Lifecycle * A Session Credential SHOULD be created at connection establishment, immediately after KBO exchange. * The credential MUST have a finite expiry. The maximum duration is application-defined. RECOMMENDED default: 1 hour. * When a credential expires, the sender MUST create a new one, which requires a fresh user-verification event. * If the connection closes, the SSK private material MUST be discarded immediately. * A peer MAY reject an expired Session Credential and request that the sender re-authenticate by issuing a Presence Challenge (Section 8). 6.6. Security Note Use of the SSK is weaker than direct use of the IK because the SSK is a software key. See Section 10.14 for a detailed analysis of SSK compromise risks and mitigations. Applications SHOULD require direct IK-based Presence Responses for high-risk actions such as key changes or privileged approvals. 7. Signed Message Rodriguez Expires 18 October 2026 [Page 24] Internet-Draft P2P Presence Verification April 2026 7.1. Applicability Not all application data requires Signed Message wrapping. When peers have exchanged and verified Key Binding Objects (Section 5), the transport peer's identity is bound to the stored IK from the ceremony, and data in transit is authenticated by the KBO-verified connection. Signed Messages are useful when content must be verifiable independent of the transport session -- for example, stored messages, forwarded content, or operations requiring non- repudiation. Real-time streams (audio, video) over an authenticated direct connection typically do not require per-unit signatures; the KBO-verified transport and Presence Challenges provide sufficient assurance. Embedding applications define which data types require Signed Messages and which rely solely on transport authentication. When Signed Messages are stored for later verification, implementations MUST also persist the Session Credential that authorized the signing key. The full verification chain -- stored IK (from the ceremony), Session Credential (IK signed SSK), and Signed Message (SSK signed the content) -- is required to verify a message after the transport session has ended. 7.2. Format Application-defined units authenticated by a Session Credential are wrapped in a COSE_Sign1 structure signed by the SSK. A unit MAY be a text message, a video keyframe, a file, a batch of events, or any other application-meaningful boundary. The signing granularity is determined by the embedding application's security requirements: SignedMessage = COSE_Sign1( protected: { 1 (alg): -7 (ES256) }, unprotected: {}, payload: SM_payload ) SM_payload is a CBOR map: Rodriguez Expires 18 October 2026 [Page 25] Internet-Draft P2P Presence Verification April 2026 +=====+================+===========+===============================+ | Key | Name | CBOR Type | Description | +=====+================+===========+===============================+ | 0 | structure_type | uint | MUST be 0x04 (SIGNED_MESSAGE) | +-----+----------------+-----------+-------------------------------+ | 1 | message_id | uint | See message ordering below | +-----+----------------+-----------+-------------------------------+ | 2 | timestamp | uint | Unix time in milliseconds | +-----+----------------+-----------+-------------------------------+ | 3 | content_type | uint | Application-defined (e.g., | | | | | 1=text) | +-----+----------------+-----------+-------------------------------+ | 4 | content | bstr/tstr | Message content | +-----+----------------+-----------+-------------------------------+ Table 5 The SSK signing operation does NOT require a user-verification event (it uses the software-held ephemeral key). This enables signing application units without user interaction. 7.3. Message Ordering and Replay Protection The message_id field MUST be unique among all Signed Messages produced by the same sender within the scope of a single Session Credential. The sender MUST assign message_id values as a strictly increasing sequence starting from 1. 7.3.1. Reliable Transports When the underlying transport guarantees in-order delivery (e.g., TCP, QUIC streams), the receiver MUST reject any Signed Message whose message_id is less than or equal to the highest message_id previously accepted from the same Session Credential. 7.3.2. Unreliable Transports When the underlying transport does not guarantee ordering (e.g., UDP, DTLS, WebRTC data channels in unordered mode), messages MAY arrive out of order or be lost in transit. In this case, the receiver MUST maintain a sliding replay window of at least 64 entries and apply the following rules. Implementations SHOULD size the window to accommodate the expected maximum reordering delay of the transport (e.g., a larger window for high-throughput video streams than for infrequent text messages): 1. If message_id > highest_seen: accept, update highest_seen. Rodriguez Expires 18 October 2026 [Page 26] Internet-Draft P2P Presence Verification April 2026 2. If message_id < highest_seen - window_size: reject (too old). 3. If message_id is within the window and has NOT been seen: accept, mark as seen. 4. If message_id is within the window and HAS been seen: reject (replay). This approach follows the anti-replay mechanism defined in Section 4.5.1 of DTLS 1.3 [RFC9147]. 7.4. Replay State Verifiers MUST maintain replay state scoped to the validated Session Credential. At minimum, a verifier MUST remember the highest accepted message_id (and, for unreliable transports, the sliding window bitmap) for each active Session Credential until that credential expires or is otherwise discarded. If replay state is lost, the verifier MUST treat subsequently received Signed Messages under the affected Session Credential as potentially replayed. In that case, the verifier MUST either reject those messages or require a new Session Credential, or a direct Identity-Key-based re-synchronization step, before accepting further messages in that session. 7.5. Verification The full trust chain from a signed message back to the in-person ceremony: In-person ceremony | v Stored IK_public -----> verifies Session Credential signature | v SSK_public (extracted from SC) | v verifies Signed Message signature | v Message content is authenticated as originating from the peer whose IK was accepted in person To verify a Signed Message, the verifier MUST: Rodriguez Expires 18 October 2026 [Page 27] Internet-Draft P2P Presence Verification April 2026 1. Obtain the sender's Session Credential for this connection. 2. Verify the Session Credential (see Section 6). 3. Extract ssk_public (field 2) from the Session Credential. 4. Decode the Signed Message COSE_Sign1 structure. If decoding fails, reject. 5. Verify that structure_type (field 0) is 0x04 (SIGNED_MESSAGE). If not, reject. 6. Verify that timestamp (field 2) is >= the Session Credential's timestamp and <= the Session Credential's expiry (plus any locally configured grace period; RECOMMENDED: no more than 60 seconds past expiry). If outside the window, reject. 7. Apply the replay check for message_id (field 1) according to the transport type: strict monotonic for reliable transports, or sliding window for unreliable transports (see Section 7.3). If the check fails, reject. 8. Verify the COSE_Sign1 signature using ssk_public. If signature verification fails, reject. If any check fails, the verifier MUST reject the message. 8. Presence Challenge and Presence Response 8.1. Purpose A Presence Challenge requests fresh evidence that the peer can perform an IK operation on the current connection. After a connection is established and authenticated via KBO exchange, either peer MAY issue a Presence Challenge to request on-demand evidence that the remote device has recently produced a locally authorized signature. Rodriguez Expires 18 October 2026 [Page 28] Internet-Draft P2P Presence Verification April 2026 Alice (challenger) Bob (responder) | | | 1. Generate 32-byte random nonce | | | | --- PRESENCE_CHALLENGE {nonce, req} --> | | | | 2. Bob's device prompts | | local user verification | | | | 3. IK signs nonce + binding | | [user-verification event] | | | | <-- PRESENCE_RESPONSE {nonce, sig} --- | | | | 4. Alice verifies: | | - sig valid against Bob's IK | | - nonce matches | | - channel_binding matches | | - assurance >= required | | | | Result: Bob's platform authorized | | an IK operation on this connection | | | 8.2. Challenge Format The Presence Challenge is an unsigned CBOR map: +=====+====================+===========+==========================+ | Key | Name | CBOR Type | Description | +=====+====================+===========+==========================+ | 0 | structure_type | uint | MUST be 0x10 | | | | | (PRESENCE_CHALLENGE) | +-----+--------------------+-----------+--------------------------+ | 1 | challenge_nonce | bstr | 32 bytes, | | | | | cryptographically random | +-----+--------------------+-----------+--------------------------+ | 2 | required_assurance | uint | Minimum required | | | | | assurance value | +-----+--------------------+-----------+--------------------------+ Table 6 The challenger MUST generate challenge_nonce using a cryptographically secure random number generator. Rodriguez Expires 18 October 2026 [Page 29] Internet-Draft P2P Presence Verification April 2026 The required_assurance field allows the challenger to demand a minimum assurance level. If set to 2 (BIOMETRIC), the responder MUST authenticate via biometric or equivalent; a CREDENTIAL-level response to a BIOMETRIC-required challenge MUST be rejected by the challenger. If set to 1 (CREDENTIAL), any assurance level is acceptable. If set to 3 (HARDWARE_VERIFIED), the response MUST include hardware attestation evidence (see Section 2.3). 8.3. Response Format The Presence Response is a COSE_Sign1 structure: PresenceResponse = COSE_Sign1( protected: { 1 (alg): -7 (ES256) }, unprotected: {}, payload: PR_payload ) PR_payload is a CBOR map: +=====+======================+======+===========================+ | Key | Name | CBOR | Description | | | | Type | | +=====+======================+======+===========================+ | 0 | structure_type | uint | MUST be 0x11 | | | | | (PRESENCE_RESPONSE) | +-----+----------------------+------+---------------------------+ | 1 | challenge_nonce | bstr | Echoed from challenge | +-----+----------------------+------+---------------------------+ | 2 | assurance | uint | Reported assurance value | +-----+----------------------+------+---------------------------+ | 3 | channel_binding | bstr | SHA-256 of connection | | | | | context | +-----+----------------------+------+---------------------------+ | 4 | timestamp | uint | Unix time in milliseconds | +-----+----------------------+------+---------------------------+ | 5 | attestation_evidence | bstr | OPTIONAL. Hardware | | | | | attestation evidence. | | | | | Present when assurance is | | | | | 3 (HARDWARE_VERIFIED). | +-----+----------------------+------+---------------------------+ Table 7 The responder signs the response with their Identity Key. This signing operation triggers a local user-verification event. Rodriguez Expires 18 October 2026 [Page 30] Internet-Draft P2P Presence Verification April 2026 The channel_binding field (key 3) MUST contain the SHA-256 hash of a connection-specific value agreed upon during the transport handshake. This prevents relay attacks where an attacker forwards a challenge to the victim's device and relays the response to a different connection. The mandatory-to-implement channel binding computation is: cb_input = sort_lexicographic(TK_local, TK_remote) channel_binding = SHA-256(cb_input[0] || cb_input[1]) where TK_local and TK_remote are the raw Transport Key public bytes (as carried in tk_public fields) and sort_lexicographic orders them by byte-wise lexicographic comparison. Transport profiles MAY define alternative channel binding computations (e.g., a transport-provided session identifier or TLS Exporter value). Both peers MUST agree on the computation method before issuing or responding to challenges. When no transport profile is in effect, implementations MUST use the mandatory-to- implement computation above. 8.4. Verification The challenger MUST: 1. Decode the COSE_Sign1 structure. If decoding fails, reject. 2. Verify that structure_type (field 0) is 0x11 (PRESENCE_RESPONSE). If not, reject. 3. Verify that challenge_nonce (field 1) matches the nonce sent. If no match, reject. 4. Verify that timestamp (field 4) is within 60 seconds of the challenge issuance time. If outside the window, reject. 5. Verify that channel_binding (field 3) matches the expected SHA-256 hash of the current connection context. If no match, reject. 6. Verify that assurance (field 2) is >= required_assurance from the challenge. If not, reject. Rodriguez Expires 18 October 2026 [Page 31] Internet-Draft P2P Presence Verification April 2026 7. If assurance is 3 (HARDWARE_VERIFIED), verify the attestation_evidence (field 5) against the platform vendor's certificate chain. If attestation evidence is present but verification fails, reject. If the verifier cannot process the attestation format, it MUST treat the assurance value as 2 (BIOMETRIC) rather than 3. 8. Verify the COSE_Sign1 signature using the stored Identity Key for the peer. If signature verification fails, reject. 8.5. Timing * Implementations SHOULD NOT issue challenges more frequently than once per 300 seconds (5 minutes). * The responder MUST produce a response within 60 seconds. * If no valid response is received within 60 seconds, the challenger SHOULD inform the user. * Failure to respond MUST NOT automatically terminate the connection. A successful Presence Response demonstrates only that the peer's platform authorized an IK operation on the current connection. See Section 1.6 for scope limitations. 9. Relationship Fingerprint 9.1. Overview The Relationship Fingerprint enables two peers to verify out-of-band that they hold each other's correct Identity Keys, detecting man-in- the-middle key substitution. Fingerprint verification is OPTIONAL. Its necessity depends on the contact exchange mechanism: * When Contact Objects are exchanged via a physical proximity mechanism where both parties can visually confirm the exchange, man-in-the-middle substitution is not feasible and fingerprint verification MAY be skipped. * When the exchange mechanism involves an intermediary (e.g., a code displayed on one device and photographed by another, or a wireless exchange without visual confirmation of the peer), fingerprint verification SHOULD be performed even when both parties are physically co-present. Rodriguez Expires 18 October 2026 [Page 32] Internet-Draft P2P Presence Verification April 2026 This specification does not support Contact Object exchange over channels that do not guarantee physical proximity (e.g., server relay, email, or messaging application). Such usage violates the Ceremony Requirement (Section 4) and falls outside this document's trust model; any security claims in such deployments derive from the relay channel's own authentication, not from this protocol. 9.2. Computation Given two Identity Key public keys, IK_A and IK_B, encoded as uncompressed P-256 points (65 bytes each, starting with 0x04): sorted = sort_lexicographic(IK_A, IK_B) prefix = "H2H-RelationshipFingerprint-v1" digest = SHA-256(prefix || sorted[0] || sorted[1]) SHA-256 is as defined in [FIPS180-4]. This document defines only the digest computation. Any human- readable rendering is application-defined. Implementations MAY encode the digest for human comparison (e.g., as grouped numeric blocks, hexadecimal, base32, or an emoji sequence mapped from digest bits). The security of any such encoding depends on the number of digest bits it exposes. Renderings that expose fewer than 30 bits of the digest offer only weak resistance against man-in-the-middle substitution and SHOULD NOT be used for security- critical comparisons. See Section 10.8 for analysis. 9.3. Properties * The fingerprint is deterministic: the same pair of Identity Keys always produces the same fingerprint. * The fingerprint is symmetric: it is the same regardless of which party computes it (due to the lexicographic sort). * The fingerprint changes if and only if either party's Identity Key changes. 9.4. Key Change Notification Implementations SHOULD alert the user when a stored contact's Identity Key changes (and therefore the fingerprint changes). This may indicate a new device (benign) or a man-in-the-middle attack. 10. Security Considerations Rodriguez Expires 18 October 2026 [Page 33] Internet-Draft P2P Presence Verification April 2026 10.1. Limitations This protocol does not provide: * proof-of-personhood * universal identity proof * protection against coercion * protection against a compromised platform key store * protection against a compromised application falsely describing the platform's assurance event unless the deployment adds attestation * unlinkability across contacts that receive the same IK * revocation or recovery 10.2. Platform Trust, Compromised Applications, and Device State All meaningful security properties of this protocol depend on platform behavior when using the Identity Key. If the platform allows the key operation without the expected local verification event, the protocol cannot detect that failure by itself. A compromised or malicious application can alter what is being signed, misrepresent why a signing operation is requested, or present application-specific content to the user in a misleading way. Unless the deployment provides trusted display, platform attestation, or other out-of-band confirmation of signing intent, a verifier MUST NOT assume that a valid protocol object implies that the signer saw or understood the application semantics associated with that object. Deployments SHOULD distinguish between cryptographic authorization of a protocol object and user consent to higher-level application meaning. If an attacker obtains control of an unlocked device, or if the device holder is coerced into satisfying local verification, the protocol provides no defense against this scenario. Verifiers MUST treat successful verification as evidence only that the platform authorized key use under its current policy (see Section 1.6). Rodriguez Expires 18 October 2026 [Page 34] Internet-Draft P2P Presence Verification April 2026 10.3. Contact Object Capture A captured Contact Object (e.g., photographed visual encoding or intercepted wireless transmission) gives the attacker the victim's public Identity Key and addressing information but the attacker cannot: * Sign as the victim (lacks the device-bound private key). * Replay the payload after 5 minutes (timestamp check). * Replay within 5 minutes if the nonce was already seen. The attacker CAN attempt to connect to the victim's transport address but cannot complete authentication (they lack a KBO for an Identity Key the victim trusts). 10.4. Key Binding Object Expiry A 30-day KBO expiry limits the window during which a compromised Transport Key can be used. Frequent TK rotation (Section 3.3) reduces this window further. 10.5. Assurance Semantics, Policy, and Application Compromise The assurance values defined by this document are signer-reported, platform-mediated claims. They are intentionally coarse and do not capture the full variety of operating-system behavior, biometric modes, passcode fallback rules, trusted-path properties, or reuse windows. A compromised application could request CREDENTIAL-level verification from the platform and then set the assurance field to BIOMETRIC in the payload before signing. The HARDWARE_VERIFIED (3) assurance level mitigates this attack: when hardware attestation evidence is present, the verifier can confirm the key's properties directly against the hardware vendor's certificate chain. A compromised application cannot forge hardware attestation evidence. During the Contact Exchange ceremony, a compromised application could substitute attacker-controlled keys while displaying correct-looking UI. Hardware key attestation proves the Identity Key is hardware- bound but does not prove the application is legitimate. Platform app integrity services (Appendix B.2) can mitigate this additional threat. Without either form of attestation, peers SHOULD use out-of- band Relationship Fingerprint comparison (Section 9) as a defense against key substitution. Rodriguez Expires 18 October 2026 [Page 35] Internet-Draft P2P Presence Verification April 2026 Deployments that require stronger semantics SHOULD require HARDWARE_VERIFIED assurance where platform support is available, and SHOULD define local policy for acceptable platforms, maximum verification age, session credential lifetimes, and when direct IK use is required instead of delegated signing. 10.6. Relay Attack on Presence Response Without channel binding, an attacker positioned between two peers could relay a Presence Challenge from Peer A to the victim's device, collect the signed response, and forward it to Peer A. The channel_binding field in the Presence Response (Section 8) prevents this by binding the response to the specific connection context. 10.7. Type Confusion Without the structure_type discriminator (field 0), an attacker could potentially substitute a signed Contact Object for a Key Binding Object or vice versa, since both are COSE_Sign1 structures signed by the same Identity Key. The structure_type field prevents this: verifiers MUST check that the structure_type matches the expected value before processing any other fields. 10.8. Relationship Fingerprint Limitations The fingerprint is optional and its security depends on the number of digest bits exposed by the encoding chosen by the application. A rendering that exposes N bits of the digest offers approximately N bits of second-preimage resistance against an attacker who generates candidate Identity Key pairs and searches for one whose fingerprint matches the target. Indicative strengths: * A 20-bit rendering (e.g., 6 decimal digits) requires on the order of 10^6 trial key pairs. Trivially brute-forceable on commodity hardware. * A 26-bit rendering (e.g., 8 decimal digits) requires on the order of 10^8 trial key pairs. Feasible on modern GPU hardware within hours. * A 60-bit rendering is practically infeasible to brute-force for realistic attackers. Rodriguez Expires 18 October 2026 [Page 36] Internet-Draft P2P Presence Verification April 2026 For applications requiring strong assurance, implementations SHOULD support machine-readable comparison (for example, a QR code exchanged over a second authenticated channel) that conveys the full 256-bit digest without human error. 10.9. Privacy Considerations 10.9.1. Identity Key as a Stable Identifier The Contact Object transmits the Identity Key public component in cleartext. Any party that observes or captures a Contact Object obtains a persistent, unique identifier for the user. Mitigations: * Contact Objects are exchanged only during deliberate, in-person ceremonies, limiting the exposure surface. * The 5-minute validity window limits the useful lifetime of a captured object. * The Transport Key (used for networking) is a separate key that does not reveal the Identity Key to network observers. 10.9.2. Relationship Correlation If the same Identity Key is reused across multiple relationships or applications, receivers that exchange identifiers or protocol transcripts can determine that the same long-term key participated in multiple relationships. This may reveal social-graph structure or cross-context linkage. Deployments that treat such correlation as sensitive SHOULD consider future profiles that use pairwise-derived relationship identifiers or per-relationship keys. Those mechanisms are not defined by this document. 10.9.3. Metadata Exposure The Contact Object can also reveal metadata through fields such as display_name, addressing, timestamps, and transport key continuity. Even when application payloads are encrypted elsewhere, these fields may reveal account aliases, transport reachability hints, device migration timing, or relationship existence. Applications using this protocol SHOULD minimize metadata disclosure, avoid unnecessary stable identifiers, and avoid embedding data in the addressing field that is broader than required for rendezvous. Rodriguez Expires 18 October 2026 [Page 37] Internet-Draft P2P Presence Verification April 2026 10.9.4. Fingerprint Handling Relationship Fingerprints are intended for optional out-of-band comparison. Applications SHOULD avoid displaying full fingerprints where they could be captured by screenshots, shoulder surfing, or logging. See [RFC6973] for a general discussion of privacy considerations in Internet protocols. 10.10. Denial of Service via Presence Challenges An authenticated peer could issue excessive Presence Challenges, forcing repeated user-verification prompts. The 300-second rate limit (Section 8) mitigates this but does not eliminate it. Implementations SHOULD allow users to disable Presence Challenge responses from specific contacts. 10.11. Post-Quantum Considerations P-256 ECDSA is vulnerable to quantum computers implementing Shor's algorithm. When post-quantum signature algorithms are available in platform key stores, the protocol SHOULD migrate. The version field in all structures enables this transition. 10.12. Forward Secrecy of Authentication This protocol does not provide forward secrecy of authentication. If the Identity Key private key is ever extracted from the platform key store (despite hardware protections), all Key Binding Objects, Session Credentials, and Presence Responses previously signed by that key can be verified by the attacker. Past signed objects remain verifiable indefinitely. Deployments that require forward secrecy of authentication evidence SHOULD layer an ephemeral key agreement protocol (e.g., TLS 1.3 [RFC8446] or a Diffie-Hellman-based transport) beneath this protocol. This document's objects provide authentication, not confidentiality or forward secrecy. 10.13. Session Credential Expiry and In-Flight Messages A Session Credential has a finite expiry. Messages signed by the SSK before the credential expires but received after expiry present a time-of-check/time-of-use consideration. The Signed Message verification procedure (Section 7) requires that the message timestamp falls within the Session Credential's validity window, with an optional grace period for in-flight messages. RECOMMENDED grace Rodriguez Expires 18 October 2026 [Page 38] Internet-Draft P2P Presence Verification April 2026 period: no more than 60 seconds past expiry. After the grace period, verifiers MUST reject the message and require a new Session Credential. 10.14. Session Signing Key Compromise The SSK is a software key held in memory. An attacker who extracts it can forge Signed Messages for the remaining validity period of the Session Credential. A read-only memory disclosure (e.g., a side- channel attack) that reveals the SSK but not the TK private key would allow message forgery without transport impersonation. The Session Credential intentionally omits a channel_binding field because Session Credentials must remain valid across delivery paths, including mailbox deposit. As a consequence, a stolen SSK and SC can be used from any network position for the remaining credential lifetime. Mitigations: * The Session Credential MUST have a finite expiry, limiting the forgery window. * The SSK MUST be discarded when the session ends. * The peer_ik_hash field scopes the credential to a single relationship. * Implementations SHOULD store the SSK in a non-swappable memory region. * For operations requiring the strongest assurance, implementations SHOULD sign directly with the Identity Key rather than delegating to the SSK. 10.15. Device Loss and Recovery When a device is lost or destroyed, the Identity Key is permanently unrecoverable (non-exportable from the platform key store). All contacts verified against that Identity Key become orphaned. Revocation and recovery are out of scope for this document, but that omission has concrete deployment consequences. In such cases, deployments will typically require an out-of-band re-verification ceremony, explicit peer approval of a new Identity Key, or an application-defined recovery mechanism. Rodriguez Expires 18 October 2026 [Page 39] Internet-Draft P2P Presence Verification April 2026 Similarly, if an Identity Key is believed to be compromised, this document does not define a protocol-native revocation object or distribution method. Applications MUST therefore define local policy for suspending trust in a stored key and for handling replacement or termination of the affected relationship. 10.16. Terminology Caution The "h2h" identifier in this document's name refers to the intended use case -- communication between devices held by two specific humans who have met in person -- and is not a claim that the protocol cryptographically verifies biological humanness, legal personhood, or proof-of-personhood in any form. Implementations and profiles built on this document SHOULD avoid using terms such as "proves human" or "non-repudiation" without additional legal and deployment analysis. The protocol produces signed objects that attribute actions to a key; it does not prove those actions were intentional or legally binding. 11. IANA Considerations This document defines protocol constants for structure types, assurance values, and transport key algorithms. No IANA registries are requested. These values are defined in the body of this document and in the CDDL schema (Appendix A). They are summarized here for convenience. 11.1. Structure Type Values +=======+====================+ | Value | Name | +=======+====================+ | 0x01 | KEY_BINDING | +-------+--------------------+ | 0x02 | CONTACT_OBJECT | +-------+--------------------+ | 0x03 | SESSION_CREDENTIAL | +-------+--------------------+ | 0x04 | SIGNED_MESSAGE | +-------+--------------------+ | 0x10 | PRESENCE_CHALLENGE | +-------+--------------------+ | 0x11 | PRESENCE_RESPONSE | +-------+--------------------+ Table 8 Rodriguez Expires 18 October 2026 [Page 40] Internet-Draft P2P Presence Verification April 2026 11.2. Assurance Values +=======+===================+ | Value | Name | +=======+===================+ | 1 | CREDENTIAL | +-------+-------------------+ | 2 | BIOMETRIC | +-------+-------------------+ | 3 | HARDWARE_VERIFIED | +-------+-------------------+ Table 9 11.3. Transport Key Algorithms +==========+=======+================================================+ | COSE alg | Name | tk_public Encoding | +==========+=======+================================================+ | -8 | EdDSA | 32 bytes, Ed25519 public key | | | | (RFC 8032 S5.1.5) | +----------+-------+------------------------------------------------+ | -7 | ES256 | 65 bytes, uncompressed P-256 | | | | point (0x04 || x || y) | +----------+-------+------------------------------------------------+ Table 10 Implementations MUST support at least one of the above transport key algorithms. A future Standards Track document may request the creation of IANA registries for these value spaces if broader interoperability requires coordinated allocation. 12. References 12.1. Normative References [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015. [FIPS186-5] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-5, February 2023. Rodriguez Expires 18 October 2026 [Page 41] Internet-Draft P2P Presence Verification April 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . 12.2. Informative References [AppAttest] Apple, "DeviceCheck | Apple Developer Documentation", 2024, . [FIDO2] FIDO Alliance, "FIDO2: Web Authentication (WebAuthn)", 2024, . [PlayIntegrity] Google, "Play Integrity API Overview", 2024, . Rodriguez Expires 18 October 2026 [Page 42] Internet-Draft P2P Presence Verification April 2026 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS and DTLS", RFC 9345, DOI 10.17487/RFC9345, July 2023, . [RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, . [Signal] Marlinspike, M. and T. Perrin, "The X3DH Key Agreement Protocol", 2016, . [WebAuthn] Balfanz, D., Czeskis, A., Hodges, J., Jones, J.C., Jones, M.B., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, "Web Authentication: An API for accessing Public Key Credentials Level 2", W3C Recommendation, April 2021, . Appendix A. CDDL Schema The following CDDL [RFC8610] schema formally defines all protocol structures. This schema is normative. ; ============================================================ ; P2P Presence Verification CDDL Schema ; Reference: draft-rodriguez-h2h-presence-attestation-00 ; ============================================================ ; -- Common types -- assurance_value = 1 / 2 / 3 ; 1=CREDENTIAL, 2=BIOMETRIC, Rodriguez Expires 18 October 2026 [Page 43] Internet-Draft P2P Presence Verification April 2026 ; 3=HARDWARE_VERIFIED ; P-256 public key as COSE_Key (kty=EC2, crv=P-256) P256_COSE_Key = { 1 => 2, ; kty: EC2 -1 => 1, ; crv: P-256 -2 => bstr .size 32, ; x coordinate -3 => bstr .size 32, ; y coordinate } ; ============================================================ ; COSE_Sign1 wrappers ; Each signed structure is a COSE_Sign1 with ES256 algorithm. ; The payload is a CBOR-encoded map defined below. ; ============================================================ KeyBindingObject = #6.18([ bstr .cbor {1 => -7}, ; protected: alg ES256 {}, ; unprotected bstr .cbor KBO_payload, ; payload bstr, ; signature ]) ContactObject = #6.18([ bstr .cbor {1 => -7}, {}, bstr .cbor Contact_payload, bstr, ]) SessionCredential = #6.18([ bstr .cbor {1 => -7}, {}, bstr .cbor SC_payload, bstr, ]) SignedMessage = #6.18([ bstr .cbor {1 => -7}, {}, bstr .cbor SM_payload, bstr, ]) PresenceResponse = #6.18([ bstr .cbor {1 => -7}, {}, bstr .cbor PR_payload, Rodriguez Expires 18 October 2026 [Page 44] Internet-Draft P2P Presence Verification April 2026 bstr, ]) ; ============================================================ ; Payload definitions (no additional keys permitted) ; ============================================================ ; -- Key Binding Object -- KBO_payload = { 0 => 1, ; structure_type: KEY_BINDING (fixed) 1 => 1, ; version (fixed for v1) 2 => P256_COSE_Key, ; ik_public 3 => bstr, ; tk_public: raw key bytes 4 => int, ; tk_algorithm: COSE alg id 5 => uint, ; timestamp: Unix ms 6 => uint, ; expiry: Unix ms, max +30d 7 => assurance_value, ; assurance } ; -- Contact Object -- Contact_payload = { 0 => 2, ; structure_type: CONTACT_OBJECT (fixed) 1 => 1, ; version (fixed for v1) 2 => P256_COSE_Key, ; ik_public 3 => bstr, ; tk_public: raw key bytes 4 => int, ; tk_algorithm: COSE alg id 5 => tstr .size (0..64), ; display_name: UTF-8, max 64 bytes 6 => uint, ; timestamp: Unix ms 7 => bstr .size 16, ; nonce: 16 random bytes 8 => bstr .size (0..1024), ; addressing: transport-specific 9 => assurance_value, ; assurance ? 10 => bstr, ; attestation_evidence: OPTIONAL } ; -- Session Credential -- SC_payload = { 0 => 3, ; structure_type: SESSION_CREDENTIAL 1 => 1, ; version (fixed for v1) 2 => P256_COSE_Key, ; ssk_public: ephemeral P-256 key 3 => P256_COSE_Key, ; ik_public: issuing Identity Key 4 => bstr .size 32, ; peer_ik_hash: SHA-256 of peer IK 5 => uint, ; timestamp: Unix ms 6 => uint, ; expiry: Unix ms 7 => assurance_value, ; assurance } Rodriguez Expires 18 October 2026 [Page 45] Internet-Draft P2P Presence Verification April 2026 ; -- Signed Message -- SM_payload = { 0 => 4, ; structure_type: SIGNED_MESSAGE (fixed) 1 => uint, ; message_id: >= 1, strictly increasing 2 => uint, ; timestamp: Unix ms 3 => uint, ; content_type: application-defined 4 => bstr / tstr, ; content } ; -- Presence Challenge (not signed, plain CBOR) -- PresenceChallenge = { 0 => 16, ; structure_type: PRESENCE_CHALLENGE 1 => bstr .size 32, ; challenge_nonce: 32 random bytes 2 => assurance_value, ; required_assurance } ; -- Presence Response -- PR_payload = { 0 => 17, ; structure_type: PRESENCE_RESPONSE 1 => bstr .size 32, ; challenge_nonce: echoed 2 => assurance_value, ; assurance 3 => bstr .size 32, ; channel_binding: SHA-256 4 => uint, ; timestamp: Unix ms ? 5 => bstr, ; attestation_evidence: OPTIONAL } Appendix B. Implementation Considerations The following implementation guidance is informative and does not alter the protocol requirements in this document. B.1. Platform Key Store Mapping The abstract "platform key store" requirement commonly maps to mechanisms such as Secure Enclave, StrongBox or TEE-backed Android keys, TPM-backed Windows keys, or TPM- and PKCS#11-based Linux deployments. Implementations MUST verify that their chosen mechanism meets the Identity Key requirements in Section 3.2 regardless of the platform name used in product documentation. Rodriguez Expires 18 October 2026 [Page 46] Internet-Draft P2P Presence Verification April 2026 B.2. App Integrity Attestation Hardware key attestation proves the Identity Key resides in genuine hardware but does not prove the application is legitimate. Platform app integrity services -- such as Android Play Integrity API [PlayIntegrity] and Apple App Attest [AppAttest] -- can verify the application binary is unmodified. These services require online validation against vendor APIs. Implementations that wish to include app integrity attestation SHOULD obtain a token at ceremony time, include it alongside the Contact Object (not in the signed payload), and validate it against the vendor's API. Deployments handling high- value authorizations SHOULD use both hardware key attestation and app integrity attestation where available. B.3. Payload Size Limits Implementations MUST enforce maximum payload sizes to prevent resource-exhaustion attacks. A deployment SHOULD set explicit limits for each structure type before CBOR decoding or signature verification. If a profile does not define stricter limits, a reasonable default is 4,096 bytes for Contact Objects, Key Binding Objects, and Session Credentials; 262,144 bytes for Signed Messages; and 1,024 bytes for Presence Challenges and Presence Responses. Acknowledgements This work builds on COSE [RFC9052], CBOR [RFC8949], WebAuthn [WebAuthn], the FIDO2 framework [FIDO2], delegated-credential patterns [RFC9345], the Signal Protocol [Signal], and prior secure messaging designs. Author's Address Gamil Rodriguez Rolab Email: gamil@rolabtech.com Rodriguez Expires 18 October 2026 [Page 47]