rfc2802.txt

中、英文RFC文档大全打包下载完全版 .

   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='[e-mail]'
              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>