diff options
Diffstat (limited to 'doc/rfc/rfc2802.txt')
| -rw-r--r-- | doc/rfc/rfc2802.txt | 1627 |
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc2802.txt b/doc/rfc/rfc2802.txt new file mode 100644 index 0000000..efabec3 --- /dev/null +++ b/doc/rfc/rfc2802.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group K. Davidson +Request for Comments: 2802 Differential +Category: Informational Y. Kawatsura + Hitachi + April 2000 + + + Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) + +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 + + A syntax and procedures are described for the computation and + verification of digital signatures for use within Version 1.0 of the + Internet Open Trading Protocol (IOTP). + +Acknowledgment + + This document 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. + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 1] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +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..................................29 + + + + + + + + +Davidson & Kawatsura Informational [Page 2] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +1. Introduction + + The Internet Open Trading Protocol (IOTP) provides 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 specification consists primarily of the definition of an XML + element known as the Signature element. This element consists of two + sub-elements. The first one is a set of authenticated attributes, + known as the signature Manifest, which comprises such things as a + + + +Davidson & Kawatsura Informational [Page 3] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + unique reference to the resources being authenticated and an + indication of the keying material and algorithms being used. The + second sub-element consists of 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, the digital signature is + computed from a set of authenticated attributes (the Manifest), which + include references to, and a digests of, those pieces of information. + + 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 is constructed of a locator + and the digest value data itself. The Digest algorithm is referred to + indirectly via a DigestAlgorithmRef, so that Digest algorithms may 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. + + + + + + + + +Davidson & Kawatsura Informational [Page 4] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +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 the existence or non-existence + of a prior relationship between the parties. In some circumstances, + it may be quite difficult to distinguish between identification and + keying material information. A unique reference to a digital + certificate provides for both. This may also stand true for an + account number when a prior relationship exists between the parties. + + The Originator information element is mandatory. Depending on the + existence or non-existence of a prior relationship with the + recipient, 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 being 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 determination + of the authentication key consists of a combination of keying + material provided by both parties. This would be the case, for + example, when establishing a key by means of 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. + + + +Davidson & Kawatsura Informational [Page 5] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + <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 + + The Signature element constitutes the majority of this specification. + It is comprised of two sub-elements. The first one is a set of + attributes, known as the Manifest, which actually constitutes the + authenticated part of the document. The second sub-element consists + of the signature value or values. + + + + + +Davidson & Kawatsura Informational [Page 6] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + The Value element contained within the Signature element is the + encoded form of the signature of the Manifest element, and thus + provides the verification of the Manifest. + + The process for generating the signed value is a multi-step process, + involving a canonicalization algorithm, a digest algorithm, and a + signature algorithm. + + First, the Manifest is canonicalized with an algorithm specified + within the Algorithm element of the Manifest. The canonicalized form + removes any inconsistencies in white space introduced by XML parsing + engines. + + This canonicalized form is then converted into a digest form which + uniquely identifies the canonicalized document. Any slight + modification in the original document will result in a very different + digest value. + + Finally, the digest is then signed using a public/symmetric key + algorithm which digitally stamps the digest (with the certificate of + the signer if available). The final signed digest is the value which + is stored within 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 a 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 consists of a collection of attributes that + specify such things as references to the resources being + authenticated and an indication of the keying material and algorithms + to be used. + + + + +Davidson & Kawatsura Informational [Page 7] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + <!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 authentication and + signed. + + Attribute: Optional element that consists of 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: The LocatorHrefBase provides a similar construct to + the HTML HREFBASE attribute and 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 definition of the Locator attribute + on the Digest element for more detail. + + + + + + + +Davidson & Kawatsura Informational [Page 8] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +4.3.3 Algorithm + + This specification uses an Algorithm data type which indicates many + different types of algoirithms. The Algorithm element allows for + specification of sub-algorithms as parameters of the primary + algorithm. This is performed via a parameter within the algorithm + that provides a reference to another Algorithm. An example of this is + shown in the Parameter section. + + <!ELEMENT Algorithm (Parameter*) > + <!ATTLIST Algorithm + ID ID #REQUIRED + type (digest|signature) #IMPLIED + name NMTOKEN #REQUIRED > + + Content Description + + Parameter: The contents of an Algorithm element consists of 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 used. + + type: The type of algorithm, either a digest or signature. This is + implied by the element to which the algorithm is referred. That is, + if the DigestAlgorithmRef refers to an algorithm, it is implicit by + reference 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 consists of the fingerprint of a given resource. + This element is constructed of two sub-elements. This first one + indicates the algorithm to be used for computation of the + fingerprint. The second element consists of the fingerprint value. + + <!ELEMENT Digest (Locator, Value) > + <!ATTLIST Digest + DigestAlgorithmRef IDREF #REQUIRED + > + + + + + + +Davidson & Kawatsura Informational [Page 9] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + 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 of + which this Digest element is a child, then concatenate the value of + the LocatorHrefBase attribute with the value of the Locator attribute + before identifying the element that is 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 which contains the Manifest component. + + Value: Encoding of the fingerprint value. + + Attributes Description + + DigestAlgorithmRef: ID Reference of algorithm used for computation of + the digest. + +4.3.5 Attribute + + The Attribute element consists of a complementary piece of + information, which shall be included in the authenticated part of the + document. This element has been defined primarily for enabling some + level of customization in the signature element. This is the area + where a specific IOTP implementation may include custom attributes + which must be authenticated directly. An Attribute element consists + of 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 + > + + + + + +Davidson & Kawatsura Informational [Page 10] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + Content Description + + ANY: The actual value of an attribute depends solely upon its type. + + Attributes Description + + type: Type of the attribute. + + critical: Boolean value that indicates if the attribute is critical + (true) or not (false). A recipient shall reject a signature that + contains a critical attribute that he does not recognize. However, an + unrecognized non-critical attribute may be ignored. + +4.3.6 OriginatorInfo + + The OriginatorInfo element is used for providing 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. Such a definition allows the adoption of + application-specific schemes. + + Attributes Description + + OriginatorRef: A reference to the IOTP Org ID of the originating + signer. + +4.3.7 RecipientInfo + + The RecipientInfo element is used for providing identification and + keying material information for the recipient. This element is used + either for enabling recognition of a Signature element by a given + recipient or when determination of the authentication key consists of + the combination of keying material provided by both the recipient and + the originator. + + The RecipientInfo attributes provide a centralized location where + signatures, algorithms, and certificates intended for a particular + recipient are specified. + + + + + +Davidson & Kawatsura Informational [Page 11] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + 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/symmetric + key identification between parties that benefit from a prior + relationship. This element can be included in the ReceipientInfo + Element. + + <!ELEMENT KeyIdentifier EMPTY> + <!ATTLIST KeyIdentifier + value CDATA #REQUIRED + > + + + + + +Davidson & Kawatsura Informational [Page 12] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +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 considered. + + <!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" 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 in the following manner: + +<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 consists of ANY valid + construct, which is 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 + + The Certificate element may be used for either providing the value of + a digital certificate or specifying a location from where it may be + retrieved. + + + + + +Davidson & Kawatsura Informational [Page 13] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + <!ELEMENT Certificate + ( IssuerAndSerialNumber, + ( Value | Locator ) ) + > + <!ATTLIST Certificate + ID ID #IMPLIED + type NMTOKEN #REQUIRED > + + Content Description + + IssuerAndSerialNumber: Unique identifier of this certificate. This + element has been made mandatory is order to prevent unnecessary + decoding during validation of a certificate chain. This feature also + helps certificates caching, especially when the value is not directly + provided. + + Value: Encoding of the certificate value. The actual value to be + encoded depends upon the type of the certificate. + + Locator: XML link element that could be used for retrieving a copy of + the digital certificate. The actual value being returned by means of + this locator depends upon the security protocol being used. + + Attributes Description + + ID: Element identifier that may be used to reference the Certificate + element from a RecipientInfo element. + + type: 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 + thereby an entity and a public key, by the name of the certificate + issuer and an issuer-specific certificate identification. + + <!ELEMENT IssuerAndSerialNumber EMPTY > + <!ATTLIST IssuerAndSerialNumber + issuer CDATA #REQUIRED + number CDATA #REQUIRED > + + + + + + + +Davidson & Kawatsura Informational [Page 14] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + Attributes Description + + issuer: Name of the issuing certification authority. See [RFC 2253] + for RECOMMENDED syntax. + + number: Issuer-specific certificate identification. + +4.5 Common Components + +4.5.1 Value + + A value contains the "raw" data of a signature or digest algorithm, + usually in a base-64 encoded form. See [RFC 2045] for algorithm used + to base-64 encode data. + + <!ELEMENT Value ( #PCDATA ) > + <!ATTLIST Value + ID ID #IMPLIED + encoding (base64|none) 'base64' + > + + Content Description + + PCDATA: Content value after adequate encoding. + + Attributes Description + + encoding: This attribute specifies the decoding scheme to be + employed for recovering the original byte stream from the content of + the element. This document recognizes the following two schemes: + + none: the content has not been subject to any particular encoding. + This does not preclude however the use of native XML encoding such as + CDATA section or XML escaping. + + base64: The content has been encoded by means of the base64 encoding + scheme. + +4.5.2 Locator + + The Locator element consists of simple XML link [XLink]. This + element allows unambiguous reference to a resource or fragment of a + resource. + + <!ELEMENT Locator EMPTY> + <!ATTLIST Locator + xml:link CDATA #FIXED 'simple' + href CDATA #REQUIRED > + + + +Davidson & Kawatsura Informational [Page 15] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + Attributes Description + + xml:link: Required XML link attribute that specifies the nature of + the link (simple in this case). + + href: Locator value that may contains either a URI [RFC 2396], a + fragment identifier, or both. + +5. Supported Algorithms + + The IOTP specification 1.0 requires the implementation of the DSA, + DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also + recommended. + +5.1 Digest Algorithms + + This specification contemplates two types of digest algorithms, both + of which provide a digest string as a result: + + Surface string digest algorithms + + These algorithms do not have any particular knowledge about the + content being digested and operate on the raw content value. Any + changes in the surface string of a given content affect directly the + value of the digest being produced. + + Canonical digest algorithms + + These algorithms have been tailored for a particular content type and + produce a digest value that depends upon the core semantics of such + content. Changes limited to the surface string of a given content do + not affect the value of the digest being produced unless they affect + the core semantic. + +5.1.1 SHA1 + + Surface string digest algorithm designed by NIST and NSA for use with + the Digital Signature Standard. This algorithm produces a 160-bit + hash value. This algorithm is documented in NIST FIPS Publication + 180-1 [SHA1]. + + This algorithm does not require any parameter. + + The SHA1 URN used for this specification is "urn:nist-gov:sha1". + + + + + + + +Davidson & Kawatsura Informational [Page 16] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +5.1.2 DOM-HASH + + XML canonical digest algorithm proposed by IBM Tokyo Research + Laboratory. This algorithm operates on the DOM representation of the + document and provides an unambiguous means for recursive computation + of the hash value of the nodes that constitute the DOM tree [RFC + 2803]. This algorithm has many applications such as computation of + digital signature and synchronization of DOM trees. However, because + the hash value of an element is computed from the hash values of the + inner elements, this algorithm is better adapted to small documents + that do not require one-pass processing. + + As of today, this algorithm is limited to the contents of an XML + document and, therefore, does not provide for 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 for computation + of a fingerprint. The 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 the terminology of 'digital signature' for + qualifying indifferently digital signature and message authentication + codes. Thus, the signature algorithms contemplated herein include + public key digital signature algorithms such as ECDSA and message + authentication codes such as HMAC [RFC 2104]. + +5.2.1 DSA + + Public-key signature algorithm proposed by NIST for use with the + Digital Signature Standard. This standard is documented in NIST FIPS + Publication 186 [DSS] and ANSI X9.30 [X9.30]. + + + + + +Davidson & Kawatsura Informational [Page 17] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + The DSA algorithm requires a single parameter, which includes the + canonical digest algorithm to be used for computing 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 for + computation of the Manifest fingerprint. The DOM-HASH is recommended + in this specification. + + Signature Value Encoding: + + The output of this algorithm consists of a pair of integers usually + referred by the pair (r, s). The signature value shall consist of the + concatenation of two octet-streams that respectively result from the + octet-encoding of the values r and s. Integer to octet-stream + conversion shall be done according to PKCS#1 [RFC 2437] specification + with a k parameter equals 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 + + Message Authentication Code proposed by H. Krawczyk et al., and + documented in [RFC 2104]. + + This specification adopts a scheme that differs a bit from the common + usage of this algorithm -- computation of the MAC is performed on the + hash of the contents being authenticated instead of the actual + contents. Thence, the actual signature value output by the algorithm + might be depicted as follows: + + SignatureValue = HMAC( SecretKey, H(Manifest)) + + This specification also considered HMAC output truncation such as + proposed by Preneel and van Oorschot. In their paper [PV] these two + researchers have shown some analytical advantages of truncating the + output of hash-based MAC functions. Such output truncation is also + considered in the RFC document. + + + + +Davidson & Kawatsura Informational [Page 18] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + HMAC requires three parameters. The first one consists of a canonical + digest algorithm. The second one consists of a hash function. The + last one is optional and specifies the length in bit 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: Canonical or surface-string digest + algorithm is to be used for computation of 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: Hash function is to be 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 the value + of this parameter should be set to the ID reference for the Algorithm + element of SHA1. + + Output-length: Length in bits of the truncated MAC value. The type of + this parameter is set to "KeyLength" and the value of this parameter + is set the length in bits of the truncated MAC value. + + Signature Value Encoding: + + The output of this algorithm can be assumed as 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 PKCS#1 [RFC 2437] specification with a k parameter equals to + ((Hlen +7) mod8), Mlen being 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> + + + + + + + + + +Davidson & Kawatsura Informational [Page 19] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +5.2.3 RSA + + Public-key signature algorithm proposed by RSA Laboratories and + documented in PKCS#1 [RFC 2437]. + + This specification adopts the RSA encryption algorithm with padding + block type 01. For computing the signature value, the signer shall + first digest the signature Manifest and then encrypt the resulting + digest with his private key. + + This signature algorithm requires a single parameter, which consists + of the canonical digest algorithm to be used for computing the + fingerprint of the signature Manifest. + + Specifications + + The RSA URN used in this specification is "urn:rsasdi-com:rsa- + encription". + + The RSA uses a canonical or surface-string digest algorithm for + computation of the Manifest fingerprint. The DOM-HASH is recommended + in this specification. + + Signature Value Encoding: + + The output of this algorithm consists of single octet-stream. 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 + + Public-key signature algorithm proposed independently by Neil Koblitz + and Victor Miller. This algorithm is being proposed as an ANSI + standard and is documented in ANSI X9.62 standard proposal [X9.62] + and IEEE/P1363 standard draft proposal [IEEE P1363]. + + + + + + +Davidson & Kawatsura Informational [Page 20] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + The ECDSA algorithm requires a single parameter, which consists of + the canonical digest algorithm to be used for computing the + fingerprint of the signature Manifest. + + Specifications + + The ECDSA URN used in this specification is "urn:ansi-org:ecdsa". + + The ECDSA uses a canonical or surface-string digest algorithm for + computation of the Manifest fingerprint. The DOM-HASH [RFC 2803] is + recommended in this specification. + + Signature Value Encoding: + + The output of this algorithm consists of a pair of integers usually + referred by the pair (r, s). The signature value shall consist of the + concatenation of two octet-streams that respectively result from the + octet-encoding of the values r and s. Integer to octet-stream + conversion shall be done according to PKCS#1 [RFC 2437] specification + with a k parameter equals to 20. + + 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 + + The following is an example signed IOTP message: + + <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> + + + +Davidson & Kawatsura Informational [Page 21] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + <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 + + + +Davidson & Kawatsura Informational [Page 22] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + </PackagedContent> + </PaySchemeData> + </PayExchBlk> + </IotpMessage> + +7. Signature DTD + + <!-- + ****************************************************** + * 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 + > + + + +Davidson & Kawatsura Informational [Page 23] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + <!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 + > + + + +Davidson & Kawatsura Informational [Page 24] + +RFC 2802 Digital Signatures for IOTP April 2000 + + + <!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 entire document concerns the IOTP v1 protocol signature element + which is used for authentication. See the Security Considerations + section of [RFC 2801] "Internet Open Trading Protocol - IOTP, Version + 1.0". + + + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 25] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +References + + [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. + + + +Davidson & Kawatsura Informational [Page 26] + +RFC 2802 Digital Signatures for IOTP 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> + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 27] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +Authors' Addresses + + The authors of this document are: + + Kent M. Davidson + Differential, Inc. + 440 Clyde Ave. + Mountain View, CA 94043 USA + + EMail: kent@differential.com + + + Yoshiaki Kawatsura + Hitachi, Ltd. + 890-12 Kashimada Saiwai Kawasaki, + Kanagawa 2128567 Japan + + EMail: kawatura@bisd.hitachi.co.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 28] + +RFC 2802 Digital Signatures for IOTP April 2000 + + +Full Copyright Statement + + 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. + + + + + + + + + + + + + + + + + + + +Davidson & Kawatsura Informational [Page 29] + |