RFC 2802
Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)
1. Introduction 💖
okay bestie, this is RFC 2802 🎀 It's titled Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP), it's from the Network Working Group, and it's dated April 2000. The authors are K. Davidson (Differential) and Y. Kawatsura (Hitachi). It's Informational, and there's no Obsoletes or Updates line in the header. 🧚
Status of This Memo 📋
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 🔒
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract ✨
so the vibe is: this doc describes a syntax and procedures for computing and verifying digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). 🖊️
Acknowledgment 🫶
this doc is based on work originally done on general XML digital signatures by:
Richard Brown of GlobeSet, Inc. <rdbrown@GlobeSet.com>
other contributors to the design of the IOTP DSIG DTD include, in alphabetic order:
- David Burdett, Commerce One
- Andrew Drapp, Hitachi
- Donald Eastlake 3rd, Motorola, Inc.
Table of Contents 🗂️
1. Introduction............................................3
2. Objective and Requirements..............................3
3. Signature Basics........................................3
3.1 Signature Element......................................3
3.2 Digest Element.........................................4
3.3 Originator and Recipient Information Elements..........5
3.4 Algorithm Element......................................5
4. Detailed Signature Syntax...............................6
4.1 Uniform Resource Names.................................6
4.2 IotpSignatures.........................................6
4.3 Signature Component....................................6
4.3.1 Signature............................................6
4.3.2 Manifest.............................................7
4.3.3 Algorithm............................................9
4.3.4 Digest...............................................9
4.3.5 Attribute...........................................10
4.3.6 OriginatorInfo......................................11
4.3.7 RecipientInfo.......................................11
4.3.8 KeyIdentifier.......................................12
4.3.9 Parameter...........................................13
4.4 Certificate Component.................................13
4.4.1 Certificate.........................................13
4.4.2 IssuerAndSerialNumber...............................14
4.5 Common Components.....................................15
4.5.1 Value...............................................15
4.5.2 Locator.............................................15
5. Supported Algorithms...................................16
5.1 Digest Algorithms.....................................16
5.1.1 SHA1................................................16
5.1.2 DOM-HASH............................................17
5.2 Signature Algorithms..................................17
5.2.1 DSA.................................................17
5.2.2 HMAC................................................18
5.2.3 RSA.................................................20
5.2.4 ECDSA...............................................20
6. Examples...............................................21
7. Signature DTD..........................................23
8. Security Considerations................................25
References................................................26
Authors' Addresses........................................28
Full Copyright Statement..................................291. Introduction 🌸
the Internet Open Trading Protocol (IOTP) gives you a payment system independent, interoperable framework for Internet commerce, as documented in [RFC 2801]. all IOTP messages are XML documents. XML, the Extensible Markup Language [XML], is a syntactical standard promulgated by the World Wide Web Consortium. XML is intended primarily for structuring data exchanged and served over the World Wide Web. 💅
although IOTP assumes that any payment system used with it provides its own security, there are numerous cases where IOTP requires authentication and integrity services for portions of the XML messages it specifies. 🔐
2. Objective and Requirements 🎯
this document covers how digital signatures may be used with XML documents to provide authentication and tamper-proof protocol messages, specifically for Version 1.0 of the IOTP protocol. the reader should recognize that an effort towards general XML digital signatures exists but is unlikely to produce its final result in time for IOTP Version 1.0. Future versions of IOTP will probably adopt by reference the results of this general XML digital signature effort. 👀
the objective of this document is to propose syntax and procedures for the computation and verification of digital signatures applicable to Version 1.0 IOTP protocol messages, providing for:
- Authentication of IOTP transactions
- Provide a means by which an IOTP message may be made "tamper-proof", or detection of tampering is made evident
- Describe a set of available digest and signature algorithms at least one of which is mandatory to implement for interoperability
- Easily integrate within the IOTP 1.0 Specification
- Provide lightweight signatures with minimal redundancy
- Allow signed portions of IOTP message to be "forwarded" to another trading roles with different signature algorithms than the original recipient
3. Signature Basics 🧩
3.1. Signature Element 🖋️
this spec is mostly about defining an XML element called the Signature element. it has two sub-elements. The first is a set of authenticated attributes, called the signature Manifest. The Manifest has things like a unique reference to the resources being authenticated, and an indication of the keying material and algorithms being used. The second sub-element is the digital signature value. 🔥
<Signature>
<Manifest>
(resource information block)
(originator information block)
(recipient information block)
(other attributes)
(signature algorithms information block)
</Manifest>
<Value encoding 'encoding scheme'>
(encoded signature value)
<Value>
</Signature>the digital signature is not computed directly from the pieces of information to be authenticated. Instead, it's computed from a set of authenticated attributes (the Manifest), which include references to, and digests of, those pieces of information. 🧠
so the authentication is therefore "indirect". 🙈
3.2. Digest Element 💎
the Digest element consists of a unique and unambiguous reference to the XML resources being authenticated. It's built from a locator and the digest value data itself. The Digest algorithm is referred to indirectly via a DigestAlgorithmRef, so that Digest algorithms can be shared by multiple resources. 🍓
<Digest DigestAlgorithmRef='D.1'>
<Locator href='resource locator'/>
<Value>
(Digest value)
</Value>
</Digest>the resource locator is implemented as a simple XML Link [XLink]. This not only provides a unique addressing scheme for internal and external resources, but also facilitates authentication of composite documents. 🌈
3.3. Originator and Recipient Information Elements 🦋
the purpose of the Originator and Recipient information elements is to provide identification and keying material for these respective parties. 🫧
<OriginatorInfo>
(identification information block)
(keying material information block)
</OriginatorInfo>
<RecipientInfo>
(identification information block)
(keying material information block)
</RecipientInfo>the actual content of these two elements depends on the authentication scheme being used and whether a prior relationship exists between the parties. In some circumstances it can be quite hard to tell identification and keying material information apart. A unique reference to a digital certificate covers both. This may also be true for an account number when a prior relationship exists between the parties. 🤔
The Originator information element is mandatory. Depending on whether a prior relationship with the recipient exists, this block either refers to a public credential such as a digital certificate, or displays a unique identifier known by the recipient. 👑
The Recipient information element may be used when a document contains multiple signature information blocks, each intended for a particular recipient. A unique reference in the Recipient information block helps the recipients identify their respective Signature information block. 💌
The Recipient information element may also be used when determining the authentication key takes a combination of keying material provided by both parties. For example, this would be the case when establishing a key by means of the Diffie Hellman [Schneier] Key Exchange algorithm. 🔑
3.4. Algorithm Element ⚙️
the Algorithm element is a generalized place to put any type of algorithm used within the signed IOTP message. The Algorithm may be a Signature algorithm or a Digest algorithm. Each algorithm contains parameters specific to the algorithm used. 🍰
<Algorithm type='digest' ID='12'>
(algorithm information block)
</Algorithm>Algorithms are required to contain an ID, which allows for indirect reference to them from other places in the XML signature. 🆔
4. Detailed Signature Syntax 🎀
4.1. Uniform Resource Names 🌷
to prevent potential name conflicts in the definition of the numerous type qualifiers considered herein, this specification uses Uniform Resource Names [RFC 2141]. 🏷️
4.2. IotpSignatures 🧁
the IotpSignatures element is the top-level element in an IOTP signature block. It consists of a collection of Signature elements, and an optional set of Certificates. 🎂
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED >Content Description 📦
- Signature: A collection of Signature elements.
- Certificate: Zero or more certificates used for signing
Attributes Description 🏷️
- ID: Element identifier that may be used to reference the entire Signature element from a Resource element when implementing endorsement.
4.3. Signature Component 🌟
4.3.1 Signature ✨
Okay so the Signature element is literally the main event of this whole spec 💅 It has two sub-elements. The first is a set of attributes called the Manifest, which is the part that actually gets authenticated 🔐 The second is the signature value (or values).
The Value element inside Signature is the encoded signature of the Manifest, so it's what lets you verify the Manifest. 🫶
Making the signed value is a multi-step process that uses a canonicalization algorithm, a digest algorithm, and a signature algorithm. Let's go 🎀
First, the Manifest gets canonicalized using whatever algorithm is named in the Algorithm element of the Manifest. This clears up any whitespace inconsistencies that XML parsing engines add, so everyone's working with the same clean version ✨
Then that canonical form gets turned into a digest, which uniquely identifies the canonicalized document. Even a tiny change to the original gives you a totally different digest value 💀
Last, the digest gets signed with a public or symmetric key algorithm, which digitally stamps it (with the signer's certificate if it's available). That final signed digest is what gets stored in the Signature's Value element 👑
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED >Content Description
Manifest: A set of attributes that actually constitutes the authenticated part of the document.Value: One or more encodings of signature values. Multiple values allow for multiple algorithms to be supported within a single signature component. 🌈
Attributes Description
ID: Element identifier that may be used to reference the Signature element from a Resource element when implementing endorsement. 🦋
4.3.2 Manifest 🌸
The Manifest element is a collection of attributes that specify things like references to the resources being authenticated, plus the keying material and algorithms to be used. 🔑
<!ELEMENT Manifest
( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+,
)
<!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED
>Content Description
Algorithm: A list of algorithms used for signing, digest computation, and canonicalization.Digest: A list of digests of resources to be authenticated and signed.Attribute: Optional element that's a collection of complementary attributes to be authenticated.OriginatorInfo: Element that provides identification and keying material information related to the originator.RecipientInfo: Optional element that provides identification and keying material information related to the recipient.
Attributes Description
LocatorHrefBase: This provides a similar construct to the HTML HREFBASE attribute, and it implicitly sets all relative URL references within the Manifest to be relative to the HrefBase. For example, the IOTP Manifest may contain:
<Manifest LocatorHrefBase='iotp:<globally-unique-tid>'>And subsequent Locators may be:
<Locator href='C.9'>An implementation should concatenate the two locator references with "#" to create the entire URL. See the definition of the Locator attribute on the Digest element for more detail. 🧩
4.3.3 Algorithm 🧮
This specification uses an Algorithm data type that covers many different kinds of algorithms. The Algorithm element lets you specify sub-algorithms as parameters of the primary algorithm. You do that with a parameter that points to another Algorithm. There's an example of this in the Parameter section, so keep an eye out 👀
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED >Content Description
Parameter: The contents of an Algorithm element are an optional collection of Parameter elements, which are specified on a per-algorithm basis.
Attributes Description
ID: The ID of the algorithm is used by the Digest and RecipientInfo to refer to the signing or digest algorithm being used.type: The type of algorithm, either a digest or a signature. This is implied by the element it's referred to from. So if the DigestAlgorithmRef refers to an algorithm, it's implicit that the targeted algorithm is a digest. 🔍name: The type of the algorithm, expressed as a Uniform Resource Name.
4.3.4 Digest 🍓
The Digest element is the fingerprint of a given resource. It has two sub-elements. The first says which algorithm to use to compute the fingerprint, and the second is the fingerprint value itself 🫧
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>Content Description
Locator: Contains a "HREF" or URL Locator for the resources to be fingerprinted. For use within IOTP, a "scheme" with the value "iotp" may be used with the following structure:
'iotp:<globally-unique-tid>#<id-value>'.This should be interpreted as referring to an element with an ID attribute that matches <id-value> in any IOTP Message that has a TransRefBlk Block with an IotpTransId that matches <globally-unique-tid>. 🕵️♀️
If the LocatorHrefBase attribute is set on the Manifest element that this Digest element is a child of, then concatenate the value of the LocatorHrefBase attribute with the value of the Locator attribute before identifying the element being referred to.
If the LocatorHrefBase attribute is omitted, <globally-unique-tid> should be interpreted as the current IotpTransId, which is included in the IOTP message that contains the Manifest component.
Value: Encoding of the fingerprint value.
Attributes Description
DigestAlgorithmRef: ID Reference of the algorithm used for computing the digest.
4.3.5 Attribute 🎀
The Attribute element is a complementary piece of information that shall be included in the authenticated part of the document. It's mainly there so the signature element can be customized. This is the spot where a specific IOTP implementation can add custom attributes that must be authenticated directly. An Attribute element has a value, a type, and a criticality 💖
At this time, no IOTP specific attributes are specified. 🙃
<!ELEMENT Attribute ANY >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>Content Description
ANY: The actual value of an attribute depends solely on its type.
Attributes Description
type: The type of the attribute.critical: Boolean value indicating whether the attribute is critical (true) or not (false). A recipient shall reject a signature that contains a critical attribute that they don't recognize. However, an unrecognized non-critical attribute may be ignored. ⚠️
4.3.6 OriginatorInfo 🦋
The OriginatorInfo element provides identification and keying material information for the originator 🪪
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED
>Content Description
ANY: Identification and keying material information may consist of ANY construct. That flexibility lets people adopt application-specific schemes. 🌈
Attributes Description
OriginatorRef: A reference to the IOTP Org ID of the originating signer.
4.3.7 RecipientInfo 💜
The RecipientInfo element provides identification and keying material information for the recipient. It gets used either to help a given recipient recognize a Signature element, or when the authentication key is a combination of keying material from both the recipient and the originator 🤝
The RecipientInfo attributes give you one central place where the signatures, algorithms, and certificates meant for a particular recipient are specified 📦
The signature certificate reference ID MUST point to a certificate object. 🔐
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>Content Description
ANY: Identification and keying material information may consist of ANY construct.
Attributes Description
SignatureAlgorithmRef: A reference to the signature algorithm used to sign the SignatureValueRef intended for this recipient. The signature algorithm reference ID MUST point to a signature algorithm within the Manifest.SignatureValueRef: A reference to the signature value for this recipient. The signature value reference ID MUST point to a value structure directly included within a Manifest. This reference can be omitted if the application can specify the digest value. 🫶SignatureCertRef: A reference to the certificate used to sign the Value pointed to by the SignatureValueRef. This reference can be omitted if the application can identify the certificate.RecipientRefs: A list of references to the IOTP Org ID of the recipients this signature is intended for.
4.3.8 KeyIdentifier 🗝️
The key identifier element can identify the shared public or symmetric key between parties who already have a prior relationship. This element can be included in the ReceipientInfo Element 💫
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>4.3.9 Parameter 🧚
A Parameter element provides the value of a particular algorithm parameter, whose name and format have been specified for the algorithm in question 🌸
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>For IOTP 1.0, the following parameter type is standardized: "AlgorithmRef".
An AlgorithmRef contains an ID of a "sub-Algorithm" that's used when computing a sequence of algorithms. For example, a signature algorithm actually signs a digest algorithm. To specify a chain of algorithms used to compute a signature, AlgorithmRef parameter types are used like this:
<Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
<Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
</Algorithm>
<Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
<Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>Content Description
ANY: The contents of a Parameter element are ANY valid construct, specified on a per-algorithm, per-parameter basis.
Attributes Description
type: The type of the parameter, expressed as a free-form string whose value is specified on a per-algorithm basis. 💅
4.4 Certificate Component 🎀
4.4.1 Certificate 🎀
okay so the Certificate element can do one of two things: hold the actual value of a digital certificate, or point to where you can go grab it. 💌
<!ELEMENT Certificate
( IssuerAndSerialNumber,
( Value | Locator ) )
>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED >Content Description
IssuerAndSerialNumber: the unique identifier of this certificate. This element is mandatory in order to prevent unnecessary decoding during validation of a certificate chain. It also helps with certificate caching, especially when the value isn't directly provided. ✨Value: the encoding of the certificate value. What actually gets encoded depends on the type of the certificate. 🧁Locator: an XML link element that can be used to retrieve a copy of the digital certificate. What gets returned through this locator depends on the security protocol being used. 🔗
Attributes Description
ID: an element identifier that can be used to reference the Certificate element from a RecipientInfo element. 🦋type: the type of the digital certificate. This attribute is specified as a Universal Resource Name. Support for the X.509 version 3 certificate [X.509] is mandatory in this specification if the Certificate element is used. The URN for such certificates is "urn:X500:X509v3". 👑
4.4.2 IssuerAndSerialNumber 🌸
the IssuerAndSerialNumber element identifies a certificate, and through that, an entity and a public key. It does this using the name of the certificate issuer plus an issuer-specific certificate identification. the vibe is very "two-part ID that actually means something" 🙈
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED >Attributes Description
issuer: the name of the issuing certification authority. See [RFC 2253] for RECOMMENDED syntax. 🍓number: the issuer-specific certificate identification. 💜
4.5 Common Components 🧚
4.5.1 Value 💖
a Value holds the "raw" data of a signature or digest algorithm, usually in base-64 encoded form. See [RFC 2045] for the algorithm used to base-64 encode data. 🫶
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none) 'base64'
>Content Description
- PCDATA: the content value after adequate encoding. ✨
Attributes Description
encoding: this attribute says which decoding scheme to use to recover the original byte stream from the content of the element. This document recognizes the following two schemes: 🌈none: the content hasn't been subject to any particular encoding. This doesn't rule out native XML encoding, like a CDATA section or XML escaping. 🙃base64: the content has been encoded using the base64 encoding scheme. 🦋
4.5.2 Locator 🔗
the Locator element is made of a simple XML link [XLink]. It lets you reference a resource or a fragment of a resource without any ambiguity. 🎯
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED >Attributes Description
xml:link: a required XML link attribute that specifies the nature of the link (simple, in this case). 💅href: the locator value. It may contain a URI [RFC 2396], a fragment identifier, or both. 🌸
5. Supported Algorithms 👑
the IOTP specification 1.0 requires implementation of the DSA, DOM-HASH, SHA1, and HMAC algorithms. Implementation of RSA is also recommended. no cap, that's the core lineup 💅
5.1 Digest Algorithms 🍓
this specification covers two types of digest algorithms. Both give you a digest string as the result. ✨
Surface string digest algorithms
these algorithms don't know anything about the content being digested. They work on the raw content value, so any change to the surface string directly changes the digest that gets produced. 🙈
Canonical digest algorithms
these ones are tailored for a particular content type, and the digest depends on the core semantics of that content. Changes that are limited to the surface string don't affect the digest, unless they affect the core semantic. it's giving meaning over formatting 🧠💜
5.1.1 SHA1 🌊
a surface string digest algorithm designed by NIST and NSA for use with the Digital Signature Standard. It produces a 160-bit hash value. This algorithm is documented in NIST FIPS Publication 180-1 [SHA1]. 🔐
this algorithm doesn't require any parameter. ✨
The SHA1 URN used for this specification is urn:nist-gov:sha1. 🎀
5.1.2 DOM-HASH 🌳
an XML canonical digest algorithm proposed by IBM Tokyo Research Laboratory. It works on the DOM representation of the document and gives an unambiguous way to recursively compute the hash value of the nodes that make up the DOM tree [RFC 2803]. It has lots of uses, like computing digital signatures and synchronizing DOM trees. ngl, the catch is that an element's hash is computed from the hashes of its inner elements, so it's better suited to small documents that don't need one-pass processing. 🫣
as of today, this algorithm is limited to the contents of an XML document. So it does not provide authentication of the internal or external subset of the DTD. 🙅♀️
The DOM-HASH algorithm requires a single parameter, which shall include a surface string digest algorithm such as SHA1. 💖
The DOM-HASH URN used for this specification is urn:ibm-com:dom-hash. 🧚
The DOM-HASH uses a surface-string digest algorithm to compute a fingerprint. SHA1 is recommended in this specification. 🌈
Example
<Algorithm name='urn:fips:sha1' type='digest' ID='P.3'>
</Algorithm>
<Algorithm name='urn:ibm:dom-hash' type='digest' ID='P.5'>
<Parameter type='AlgorithmRef'>P.3</Parameter>
</Algorithm>5.2 Signature Algorithms 🦋
this specification uses "digital signature" as a catch-all, covering both digital signatures and message authentication codes. So the signature algorithms here include public key digital signature algorithms such as ECDSA, and message authentication codes such as HMAC [RFC 2104]. 🫶
5.2.1 DSA 💎
a public-key signature algorithm proposed by NIST for use with the Digital Signature Standard. It's documented in NIST FIPS Publication 186 [DSS] and ANSI X9.30 [X9.30]. 🔑
The DSA algorithm requires a single parameter, which includes the canonical digest algorithm used to compute the fingerprint of the signature Manifest. 🎯
The DSA URN used in this specification is urn:nist-gov:dsa. 💅
The DSA uses a canonical or surface-string digest algorithm to compute the Manifest fingerprint. DOM-HASH is recommended in this specification. 👑
Signature Value Encoding:
the output of this algorithm is a pair of integers, usually written as the pair (r, s). The signature value shall consist of the concatenation of two octet-streams, which come from octet-encoding the values r and s. Integer to octet-stream conversion shall be done according to the PKCS#1 [RFC 2437] specification, with a k parameter equal to 20. 🧮✨
Example
<Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>5.2.2 HMAC 🌷
a Message Authentication Code proposed by H. Krawczyk et al., documented in [RFC 2104]. 🔒
this spec does something a bit different from the usual HMAC. The MAC is computed over the hash of the contents being authenticated, instead of the actual contents. So the signature value that comes out of the algorithm can be shown like this: 🙌
SignatureValue = HMAC( SecretKey, H(Manifest))this specification also considered HMAC output truncation, as proposed by Preneel and van Oorschot. In their paper [PV], these two researchers showed some analytical advantages of truncating the output of hash-based MAC functions. Output truncation like this is also considered in the RFC document. 📄✨
HMAC requires three parameters. The first is a canonical digest algorithm. The second is a hash function. The last one is optional and specifies the length in bits of the truncated output. If this last parameter is absent, no truncation shall occur. 🧩
The HMAC URN used in this specification is urn:ietf-org:hmac. 🎀
Canonical digest algorithm: the canonical or surface-string digest algorithm used to compute the Manifest fingerprint. The type of this parameter is set to "AlgorithmRef". The recommended value of this Parameter should be the ID reference for the Algorithm element DOM-HASH. 🌸
Hash-function: the hash function used to compute the MAC value from the secret key and the fingerprint of the signature Manifest. The type of this parameter is set to "HashAlgorithmRef", and its value should be set to the ID reference for the Algorithm element of SHA1. 💜
Output-length: the length in bits of the truncated MAC value. The type of this parameter is set to "KeyLength", and its value is set to the length in bits of the truncated MAC value. 🍓
Signature Value Encoding:
the output of this algorithm can be assumed to be a large integer value. The signature value shall consist of the octet-encoded value of this integer. Integer to octet-stream conversion shall be done according to the PKCS#1 [RFC 2437] specification, with a k parameter equal to ((Hlen +7) mod8), where Mlen is the length in bits of the MAC value. 🧠
Example
<Algorithm name='urn:ietf-org:hmac' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
<Parameter type='HashAlgorithmRef'>P.5</Parameter>
<Parameter type='KeyLength'>128</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>5.2.3 RSA ✨
okay so RSA is a public-key signature algorithm from RSA Laboratories, and it's documented in PKCS#1 [RFC 2437]. 💅
this spec uses the RSA encryption algorithm with padding block type 01. to compute the signature value, the signer shall first digest the signature Manifest and then encrypt the resulting digest with his private key. 🔐
this signature algorithm needs exactly one parameter: the canonical digest algorithm used to compute the fingerprint of the signature Manifest. 🎀
Specifications
the RSA URN used here is "urn:rsasdi-com:rsa-encription" (spelling and all 🙈). RSA uses a canonical or surface-string digest algorithm to compute the Manifest fingerprint, and DOM-HASH is recommended in this specification. 🌸
Signature Value Encoding:
the output is a single octet-stream, and no further encoding is required. ✨
Example
<Algorithm name='urn:rsasdi-com:rsa-encription'
type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>5.2.4 ECDSA 🦋
ECDSA is a public-key signature algorithm proposed independently by Neil Koblitz and Victor Miller. it's being put forward as an ANSI standard and is documented in the ANSI X9.62 standard proposal [X9.62] and the IEEE/P1363 standard draft proposal [IEEE P1363]. main character energy, honestly. 👑
the ECDSA algorithm needs one parameter: the canonical digest algorithm used to compute the fingerprint of the signature Manifest. 💜
Specifications
the ECDSA URN used here is "urn:ansi-org:ecdsa". ECDSA uses a canonical or surface-string digest algorithm to compute the Manifest fingerprint, and the DOM-HASH [RFC 2803] is recommended in this specification. 🍓
Signature Value Encoding:
the output is a pair of integers, usually called the pair (r, s). the signature value shall be the concatenation of two octet-streams, which come from octet-encoding the values r and s. integer-to-octet-stream conversion shall be done according to the PKCS#1 [RFC 2437] specification with a k parameter equal to 20. it's giving precision 🫶
Example
<Algorithm name='urn:ansi-org:ecdsa' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>6. Examples 🧚
okay here's the example signed IOTP message, and it is serving 💅
<IotpMessage>
<TransRefBlk ID='M.1'>
<TransId
ID='M.2'
version='1.0'
IotpTransID='19990809215923@www.iotp.org'
IotpTransType='BaselinePurchase'
TransTimeStamp='1999-08-09T12:58:40.000Z+9'>
</TransId>
<MsgId xml:lang='en' SoftwareID='Iotp wallet version 1.0'>
</MsgId>
</TransRefBlk>
<IotpSignatures>
<Signature>
<Manifest>
<Algorithm name='urn:nist-gov:sha1'
type='digest' ID='P.3'>
</Algorithm>
<Algorithm name='urn:nist-gov:dsa'
type='signature' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash'
type='digest' ID='P.5'>
<Parameter type='AlgorithmRef'>P.3</Parameter>
</Algorithm>
<Digest DigestAlgorithmRef='P.6'>
<Locator href='P.1'/>
<Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ
</Value>
</Digest>
<OriginatorInfo
<IssuerAndSerialNumber
issuer='o=Iotp Ltd., c=US'
number='12345678987654'/>
</OriginatorInfo>
<RecipientInfo
SignatureAlgorithmRef='P.4'
</RecipientInfo>
</Manifest>
<Value>
9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0
</Value>
</Signature>
<Certificate type='urn:X500:X509v3'>
<IssuerAndSerialNumber
issuer='o=GlobeSet Inc., c=US'
number='123456789102356'/>
<Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</Value>
</Certificate>
</IotpSignatures>
<PayExchBlk ID='P.1'>
<PaySchemeData
ID='P.2'
PaymentRef='M.5'
ContentSoftwareId='abcdefg'>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
</PaySchemeData>
</PayExchBlk>
</IotpMessage>7. Signature DTD 💖
the DTD is next, and it's the blueprint for everything above 📐
<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED
>
<!--
******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED
>
<!ELEMENT Manifest
( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+
)
>
<!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED
>
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED
>
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
<!ELEMENT Attribute ANY >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED
>
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!--
******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Certificate
( IssuerAndSerialNumber, ( Value | Locator ) )
>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED
>
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED
>
<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none 'base64'
>
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED
>8. Security Considerations 🔥
this is the serious part, bestie, so read it properly 🙈 this entire document is about the IOTP v1 protocol signature element, and that element is used for authentication. the full security story lives in the Security Considerations section of [RFC 2801] "Internet Open Trading Protocol - IOTP, Version 1.0". no skipping it! 💀
References ✨
Okay bestie, this is the bibliography, aka the list of everything this spec leaned on 📚 Every source is here with all its details, so you can go check any of them 🫶
[DSA]Federal Information Processing Standards Publication FIPS PUB 186, "Digital Signature Standard(DSS)", 1994,<http://csrc.nist.gov>[IEEE P1363]IEEE P1363, "Standard Specifications for Public-Key Cryptography", Work in Progress, 1997,<http://stdsbbs.ieee.org/>[PV]Preneel, B. and P. van Oorschot, "Building fast MACs from hash functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14.[RFC 1321]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.[RFC 2045]Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.[RFC 2046]Freed N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.[RFC 2104]Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[RFC 2141]Moats, R., "URN Syntax", RFC 2141, May 1997.[RFC 2253]Wahl, W., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.[RFC 2396]Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.[RFC 2437]Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications, Version 2.0", RFC 2437, October 1998.[RFC 2801]Burdett, D., "Internet Open Trading Protocol - IOTP, Version 1.0", RFC 2801, April 2000.[RFC 2803]Maruyama, H., Tamura, K. and N. Uramot, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.[Schneier]Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons[SHA1]NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, April 1995.[X.509]ITU-T Recommendation X.509 (1997 E), "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", June 1997.[X9.30]ASC X9 Secretariat: American Bankers Association, "American National Standard for Financial Services - Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry - Part 1: The Digital Signature Algorithm(DSA)", 1995.[X9.62]ASC X9 Secretariat: American Bankers Association,"American National Standard for Financial Services - Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry - The Elliptic Curve Digital Signature Algorithm (ECDSA)", Work in Progress, 1997.[XLink]Eve Maler, Steve DeRose, "XML Linking Language (XLink)",<http://www.w3.org/TR/1998/WD-xlink-19980303>[XML]Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible Markup Language (XML) 1.0",<http://www.w3.org/TR/1998/REC-xml-19980210>
Authors' Addresses 💌
The authors of this document are, the brilliant humans behind it 🌸
Kent M. Davidson
Kent M. Davidson
Differential, Inc.
440 Clyde Ave.
Mountain View, CA 94043 USA
EMail: kent@differential.comYoshiaki Kawatsura
Hitachi, Ltd.
890-12 Kashimada Saiwai Kawasaki,
Kanagawa 2128567 Japan
EMail: kawatura@bisd.hitachi.co.jpFull Copyright Statement ⚖️
Now the legal bit 🙈 This notice is copied word for word, because the terms are the terms and nobody gets to freestyle a copyright notice 💜
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. So the people keeping the RFC library running are backed by the Internet Society, and that's the whole story, bestie ✨
📦 where this page comes from
- ietf: rfc2802 2000-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms