Venture Cryptography.

phill@hallambaker.com

Threshold Cryptography Elliptic Curve Threshold Encryption Threshold Key Generation Notary 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 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 .

The implementation status of the reference code base is described in the companion document .

Proof of inclusion presented in a protected header, i.e. within the signature scope

Proof of inclusion presented in the signature header or an external assertion.

A notarized signature over

This document requires no IANA actions.