W3C DSS Signature Suite - Version 1.0


The Digital Signature Algorithm is a Federal Information Processing Standard (FIPS) issued on May 19,1994. It specifies a combination of algorithms: DSA for generating the signature on a hash of the data, calculated using the Secure Hash Algorithm (SHA-1). This signature suite specifies how it is used to sign a PICS  label per the DSig 1.0 Specification.

Status of this Document

This document is part of the DSig 1.0 Recommendation. It has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document.

Last updated: 1998-05-27T18:31:48Z

Overview

This signature suite is identified by the URL

http://www.w3.org/TR/1998/REC-DSig-label/DSS-1_0

This signature suite uses for hashing

The Secure Hash Algorithm (SHA-1), National Institute of Standards and Technology, NIST FIPS PUB 180-1, "Secure Hash Standard,", U.S. Department of Commerce, April 1995

and for encryption

The DSA Encryption Algorithm, National Institute of Standards and Technology, NIST FIPS PUB 186, "Digital Signature Standard,", U.S. Department of Commerce, May 1994.

DSS Overview

The Digital Signature Algorithm (DSA) was published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS). DSS was selected by NIST, in cooperation with the NSA  to be the digital authentication standard of the U.S. government. The standard was issued on May 19, 1994. DSA is based on the discrete logarithm problem  and is a variant of the Schnorr and ElGamal signature algorithms. It is for authentication only.  

One or more certificates may accompany a digital signature. A certificate is a signed document that binds the public key to the identity of a party. Its purpose is to prevent someone from impersonating someone else. If a certificate is present, the recipient (or a third party) can check that the public key belongs to a named party, assuming the certifier's public key is itself trusted. These certificates can be held in the Attribution Information section of the DSig 1.0 Signature Block Extension and thus passed along with the signature to aid in validating it. (See section Attribution Information section in the DSig 1.0 Specification.)

The signature section of the DSig 1.0 Signature Block Extension is defined in the DSig 1.0 Specification. For the DSS signature suite, the signature section has the following required and optional fields.

Encoding

All values are encoded using the standard base-64 representation of a byte-array containing the two's-complement representation of the value to encode. The first byte in this array is the high-order byte. The minimal number of bytes necessary is used to represent a certain value, so no leading zero-bytes are allowed.

Required Fields

The general specification allows for four variants on how to specify what key has been used for signing, or rather what key is to be used for verifying the signature: ByKey, ByHash, ByName and ByCert. The signature suite specs are to specify what forms are mandatory or optional. For this signature suite, exactly one of ByKey, ByHash, ByName and ByCert have to be present. It is assumed, that in all cases where one or more certificates are stored in the attribution information section, a reference to one of these certificates is appropriate, and the ByHash method can be used. If no certificates are available, either the ByKey method is appropriate, or ByName/ByCert may be used, if online search or retrieval is reasonably available.

"ByKey"- key value for validating a signature

The token "ByKey" identifies the value that follows as the key that should be used to validate the signature (or sufficient information to generate that key locally).

   ( "ByKey" <Key-Value, Signature-Suite dependent> )

Within the DSS signature suite, the key values are (refer to FIPS 186, Section 4 DSA Parameters, for futher details):

   ( "ByKey"
      ( "P" "base64-encoded-modulus" )
      ( "Q" "base64-encoded-divisor" )
      ( "G" "base64-encoded-number" )
      ( "Y" "base64-encoded-public-key" ) )

   

"ByHash" - key value for validating a signature

The token "ByHash" identifies the value that follows as the SHA-1 hash of the key that should be used to validate the signature.

   ( "ByHash" "base-64-encoded-hash-of-key" )

The hash-value is calculated from the concatenation of the following information:

  • L(Y),V(Y),L(P),V(P),L(Q),V(Q) and L(G),V(G) where 
  • L(x) is the length of x in bits and
  • V(x) is the value of x as an array of bytes, high byte first

If the length of one element is less than or equal to 127, the length-value L(x)   is exactly one byte with the length as value. If the length is larger than 127, but less than  32767, the length-value consists of 3 bytes, the first with the value 82 hexadecimal, the other two contain the length as a 16-bit integer, high byte first. A length > 32767 is not supported.

ByName - referencing the key value for validating a signature by name

The token "ByName" identifies the value that follows as the name of the entity that has generated the signature. It should be used to identify the public key necessary to validate the signature.

( "ByName" "Name-as-string-value" )

It can be used as a pointer to one of the certificates in the attribution information section, or be used to fetch a certificate from a local certificate-repository or an online-retrieval service. The format of the value depends on the certificate-system used, and can be a distinguished name from an X.509-field, an email-address or some other string value. ByName should be avoided, if searching the certificates given is likely to result in ambiguity.

ByCert  - referencing the key value for validating a signature by certificate

The token "ByCert" identifies the value that follows as a pointer to a certificate. It should be used to identify the public key necessary to validate the signature.

   ( "ByCert" ( "CA-Name-as-string-value" <CA-Serial-No.> ) )

It can be used as a pointer to one of the certificates in the attribution information section, or be used to fetch a certificate from a local certificate-repository or an online-retrieval service. The format of the value depends on the certificate-system used, and has to be specified in the Certificate Family Identifiers- Documents. 

"SigCrypto" - signature cryptographic data

The "SigCrypto" token identifies the SigData field that contains the cryptographic data that is the signature itself. The format and contents of this field are (refer to FIPS 186, Section 5, Signature Generation, for details):

      ("SigCrypto" 
		( ( "R" "base64-encoded-R" )
		  ( "S" "base64-encoded-S" ) ) )

Optional Fields

All common SigData fields in the DSig Label spec are applicable in this Signature Suite specification.

Example

( "Signature" "http://www.w3.org/TR/1998/REC-DSig-label/DSS-1_0" 
	( "SigCrypto" 
		( ( "S" "bXLm1G2RunA7xR2EHwSMDSI27DE=" ) 
		  ( "R" "CTU9+g0KL3TBsvxEtBQzrTu5NmM=" ) ) ) 
	( "ByKey" ( 
		( "Y" "APyKJ4o3...." ) 
		( "Q" "AJdgUI8VIwvMspK5gqLrhAvwWBz1" ) 
		( "P" "AP1/U4Ed..." ) 
		( "G" "APfhoIXW..." )
	 ) ) 
) 

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Feedback
Peter Lipp Feb. 1998