| Internet-Draft | Mesh Notarized Signatures | October 2024 |
| Hallam-Baker | Expires 17 April 2025 | [Page] |
Creation and verification of Mesh Notarized Signatures is described . A notarized signature is a signature whose time of creation is attested by one or more parties in addition to the signer. In the case of Mesh Notarized Signatures, the attesting parties is the set of all parties participating in a Notarization Mesh. This ideally includes the relying parties.¶
Each participant in a Notarization Mesh maintains their own notary log in the form of a DARE sequence authenticated by a Merkle tree. Participants periodically cross notarize their personal notary log with those maintained by other parties. A Mesh Notarized Signature is bound in time as having being created after time T1 by including one or more sequence apex values as signed attributes. A Mesh Notarized Signature is bound in time as having being created before time T2 by enrolling it in the signer's personal notarization log and engaging in cross-notarization with a sufficient number of Notarization Mesh participants to establish the desired proof.¶
Defection is controlled through an accountability model. If a trusted notary produces multiple inconsistent signed cross Notarization tokens, this provides non-repudiable evidence of a default.¶
https://mailarchive.ietf.org/arch/browse/mathmesh/Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at .¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 April 2025.¶
Copyright (c) 2024 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.¶
This draft specifies the creation and verification of Mesh Notarized Signatures. A notarized signature is a signature whose time of creation is attested by one or more parties in addition to the signer. In the case of Mesh Notarized Signatures, the attesting parties is the set of all parties participating in a Notarization Mesh. This ideally includes the relying parties.¶
This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].¶
Proof of inclusion presented in a protected header, i.e. within the signature scope¶
A notarized signature over¶
This document requires no IANA actions.¶