Editor
Authors:
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR
Note: Since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
The W3C Digital Signature Working Group ("DSig") proposes a standard format for making digitally-signed machine-readable assertions about a particular information resource. More generally, it is the goal of the DSig project to provide a mechanism to make the statement:
signer believes statement about information resource
This document describes a method of utilizing PICS 1.1 labels with extensions to meet this goal. It also provides detailed usage guidelines for creating PICS 1.1 labels which are valid DSig 1.0 Signature labels.
DSig 1.0 signature labels inherit both a means of transporting signature block data and a simple framework for making the machine-readable assertions from the underlying PICS framework. PICS-compliant applications can syntactically parse DSig 1.0 signature labels; only cryptographic functions need to be added to PICS-aware applications in order to make use of the semantic content of a DSig signature.
In its simplest form, a DSig 1.0 signature label is a signed statement about an information resource. This document described two DSig-specific extensions to standard PICS 1.1 labels: resinfo and sigblock. The resinfo extension is used to create cryptographic links between the signature label and the information resource described by the label. Typically this linkage is created through the use of one or more cryptographic hash functions. The sigblock extension contains one or more digital signatures of the other contents of the label.
In DSig 1.0, it is important to note that:
The basic structure of a PICS 1.1 label isdescribed below.
W3C recommendations and working drafts related to this document include:
We assume familiarity with these documents.
At the core of DSig 1.0 is the PICS 1.1 label, so we begin by reviewing the PICS 1.1 architecture and illustrating how DSig 1.0 signature labels are buitl on top of PICS 1.1 labels.
At the core of the PICS infrastructure is the rating service. The rating service either chooses an existing, or develops a new, rating system to use in labeling content. The rating system, described in a human readable form at the rating system URL is the range of statements that can be made. The rating service establishes criteria for determining who can label content using their name and how the labels must be applied. This combination of criteria and rating system makes up a coterie which is uniquely identified by a service URL. This service URL becomes the brand, if you will, of the rating service. At a minimum, the service URL will return a human readable form of the rating criteria and a link to the description of the rating system. The rating service is also responsible for delivering a service description file. This is a machine readable version of the rating system with pointers to the rating system URL and the rating service. While not required, it is recommended that this be available automatically at the service URL.
A labeler, given authority by the rating service, uses the criteria established by them along with the rating system to label content. These content labels contain a statement about the content of the resource being labeled and contain a link back to the service URL. Content labels can come in the content itself, with the content or from a trusted third party such as a label bureau. Policies determine what actions are taken based on the specific statements in the content label. If a content label is based on an unknown service URL, it is a simple (and automatable) task to retrieve the appropriate service description file to understand what statements are being made in the label.
DSig 1.0 utilizes the PICS infrastructure as described above with a few exceptions:
PICS labels are always transmitted as lists of one or more individual PICS labels ("labellists"); in common PICS practice PICS label lists usually contain exactly one label. Full details of PICS labels and label lists are available in "PICS Label Distribution Label Syntax and Communication Protocols Version 1.1" document:
In DSig 1.0, each assertion about an information resource is given in a label. A label consists of a service identifier, options, extensions and an assertion (in PICS 1.1 the assertion is called a rating). The service identifier is the URL chosen by the rating service (see Rating Services and Rating Systems) as its unique identifier. Options and extensions give additional properties of the label, the document being labeled and properties of the assertion itself. The assertion itself is a set of attribute-value pairs that describe a document along one or more dimensions. One or more labels may be distributed together as a list which allows for some data aggregation.
A PICS labellist contains one or more service sections:
(PICS-1.1 <Service 1 section> <Service 2 section> <Service 3 section>)
Where each service section contains options and labels:
<Service URL> <Service options for all labels in this section> labels <options for this label> ratings <rating for this label> <options for this label> ratings <rating for this label> ...
The general form for a label list (formatted for presentation, and not showing error status codes) is:
(PICS-1.1
<service 1 url> [service 1 option...]
labels [label 1 option...] ratings (<category> <value> ...)
[label 2 option...] ratings (<category> <value> ...)
...
<service 2 url> [service 2 option...]
labels [label 3 option...] ratings (<category> <value> ...)
[label 4 option...] ratings (<category> <value> ...)
...
...)
Labels in a label list are grouped by service. Each service may have service options which are inherited by each label within the scope of the service; service options may be overridden by individual label options. When a new service is identified in the label list, the options from the previous service no longer apply. Thus, in the above example label 4 could be equivalently represented as:
(PICS-1.1
<service 2 url>
labels [ service 2 options + label 4 option...] ratings (<category> <value> ...))
In DSig 1.0, we sign individual labels or portions therof; the details of signing labels are presented below.
PICS defines two distinct types of labels, specific and generic:
By convention, a DSig signature block itself has the weakest possible semantics, namely "the entity possessing the key that created this signature had access to the secret key used to generate the signature and the signed data at the same time." For DSig 1.0 signature labels, we want somewhat stronger semantics that also includes the semantics of the ratings contained within the label. Thus, by definition a PICS label which includes a DSig sigblock extension has the following semantics:
"The entity possessing the secret key that digitally signed this PICS 1.1 label had access to the secret key and the label at the same time and asserts that the statements made within the label are valid"
Following the format given in PICS Label Distribution Label Syntax and Communication Protocols Version 1.1 we now review each of the PICS 1.1 options; giving appropriate usage rules for applying them within the context of DSig 1.0 Signature Labels.
PICS label options can be divided into three groups. Options from the first group supply information about the document to which the label applies. Options from the second group supply information about the label itself. Options in the last group provides miscellaneous information.
A DSig label 'signs' an information resource. To do this in a secure fashion, the signed label must have a cryptographic connection to that resource. We create cryptographic links between a label and the labeled resource by including one or more hashes of the information resource within the signature label. Similar, albeit limited, functionality was accomplished in the PICS 1.1 specification via the MIC-md5 (or md5) option. DSig 1.0 replaces this option with the resinfo extension, which permits a single label to include multiple hashes using multiple hash algorithms.
PICS 1.1 also specified a signature option, signature-RSA-MD5, but its functionalits was similarly limited. DSig replaces signature-RSA-MD5 with the sigblock extension. The sigblock extension may contain one or more signatures using any cryptographic algorithm; in addition, sigblocks may optionally include information in the form of certificates or links to certificates.
A DSig 1.0 Signature Label is a standard PICS 1.1 label. The DSig extensions resinfo and sigblock are both optional and can be used as needed. A PICS 1.1 label is only considered a DSig 1.0 Signature Label when it contains a sigblock extension,
The goal of the resource reference information (resinfo) extension is to provide a cryptographic link between the signature label and an information resource. DSig 1.0's resinfo extension builds upon the PICS 1.1 for, at and MIC-md5 options to provide this cryptographic link. Specifically, the resinfo extension provides a mechanism for including cryptographic checksums (hashes), in any named cryptographic algorithm, to the label. These hashes provide a means for the receiver of the label to determine if the information resource they have is the same as the one about which the assertion was made.
The resinfo extension is associated with a specific resource. This resource may be identified by the for option or may be implied by the context of the label (in the resource, delivered in the HTTP headder with the resource, returned by a label bureau based on a request, etc.).
In the structure of a PICS label, the resinfo extension can be a service option and/or a label option. It functions identically to any other option with respect to inheritance within a service section from service option to label option. A single document can have many URLs; the URL used to retrieve a document may differ from the URL in the for option of a label that accompanies the document, but the document retrieved must be the same document or the hash(s) contained in the resinfo extension will not be valid.
Structurally, resinfo contains one or more hashes of the information resource; each hash includes a hash algorithm identifier, the actual hash of the resource and (optionally) the date the hash was computed.
("hash algorithm identifier" "base64-string of hash" "hash date")*
The hash algorithm identifier is a quoted URL, it identifies the specific hashing algorithm by which the following hash was computed. The DSig 1.0 compliance document identifies several hash algorithms currently in common use and defines standard URLs for each. To ensure that no two hash algorithm uses the same identifier, the identifier must be a valid URL. This in effect creates a distributed registry of unique names which can be created and shared by any community of interest.
Since the hash algorithm identifier is a URL, it can be resolved to retrieve a document (although it is not required that any document be accessible at a given URL). A document so referenced may be in any format, but we recommend that it:
Any incompatible change in a hash algorithm should be accomplished by creating an entirely new hash algorithm identifier URL.
Usage notes:
http://www.w3.org/PICS/DSig/resinfo-1_0.html
or the entire label should be disregarded.The following grammar, in modified BNF, describes the syntax of the resinfo extension in a PICS 1.1 label. This extension is a valid extension per the PICS 1.1 specifications.
resinfo-extension ::
'extension (' mand/opt '"http://www.w3.org/PICS/DSig/resinfo-1_0.html"' resinfo-data+ ')'
mand/opt :: 'optional' | 'mandatory'
resinfo-data :: '(' HashAlgoURL resource-hash hash-date*1 ')'
HashAlgoURL :: quotedURL
quotedURL :: '"' URL '"'
resource-hash :: '"base64-string"'
hash-date :: quoted-ISO-date
quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"'
based on the ISO 8601:1988 date and time standard, restricted
to the specific form described here:
YYYY :: four-digit year
MM :: two-digit month (01=January, etc.)
DD :: two-digit day of month (01 through 31)
hh :: two digits of hour (00 through 23) (am/pm NOT allowed)
mm :: two digits of minute (00 through 60)
S :: sign of time zone offset from UTC ('+' or '-')
tz :: four digit amount of offset from UTC
(e.g., 1512 means 15 hours and 12 minutes)
For example, "1994.11.05T08:15-0500" is a valid quoted-ISO-date
denoting November 5, 1994, 8:15 am, US Eastern Standard Time
Note: The ISO standard allows considerably greater
flexibility than that described here. PICS requires precisely
the syntax described here -- neither the time nor the time zone may
be omitted, none of the alternate formats are permitted, and
the punctuation must be as specified here.
base64-string :: as defined in RFC-1521.
Notes:
The following example shows a valid DSig 1.0 resinfo extension with two hashes of the referenced information resource.
extension (optional"http://www.w3.org/PICS/DSig/resinfo-1_0.html"("http://www.w3.org/PICS/DSig/SHA1.html""base64-string of hash") ("http://www.w3.org/PICS/DSig/MD5.html""base64-string of hash" "1997.02.05T08:15-0500"))
In this example, we begin with the extension (optional token which identifies this extension as an optional extension to the PICS label within which it iscontained. This declaration is followed by a URL, http://www.w3.org/PICS/DSig/resinfo-1_0.html which provides a unique name for the extension. De-referencing the URL should provide human readable information on the extension. Finally we have two repeating subsections of the extension, each of which contain hash information.Here again, de-referencing the hash algorithm identifier URL would return a human readable description, this time of the hash algorithm. In our specific example above, the first hash is of type SHA1. This is followed by the actual hash data and followed by the date the hash was computed. The second clause uses the MD5 hash algorithm.
The DSig 1.0 Signature Block Extension (sigblock) provides cryptographic protection of the label by using digital signature techniques. It identifies
and also provides the signature data itself. The sigblock extension can also contain certificates, that can be used by a trust management system (TMS) to decide if the signature is trustworthy.
A Signature Block consists of
The Signature Block is an optional extension. There is no need to make this extension mandatory, it allows the end-user to accept the label even if the software has no possibilitiy to verify the signature. If an unverifiable signature in a label can be used for trust-decisions has to be decided by the Trust-Manager.
(extension optional http://www.w3.org/PICS/DSig/sigblock.html ("DSigBlock-1.0" <attribution info> *<signature>))
The Attribution-Info section contains information that can be used by a TMS to establish trust into the signatures. Typically, it would be a set of certificates or pointers to certificates in the form of URL's. The Attribution Info can also be empty, in which case the TMS needs to determine the trust level independently (i.e. the TMS would retrieve the necessary certificates from elsewhere).
The Attribution-information can contain certificates in different forms, depending on the PK-Infrastructure used. DSig supports X.509-V3 Certs and PGP-Style certificates, but also is open to new, emerging "standards" like SDSI or SPKI. Each Certificate in this section therefore needs to be identified by a type expressed via an URI. Here are two examples:
| Certificate Family | URI |
| X.509v3 | http://www.w3.org/PICS/DSig/X509.html |
| PGP | http://www.w3.org/PICS/DSig/pgpcert.html |
These URI's are in some sense similar to MIME-types: they are a unique string specifying the type of the Certificate. Such URI's do not necessarily point to something. If they do, dereferencing them should result in a description of the format of the relevant Certificates or pointers to other locations where such descriptions can be found. We strongly recommend, that a description of the format is made available that way, unless the format is proprietary and not considered of public interest.
In the future, the URI's could also point to active elements that can be downloaded, and which understand that certificate format. Such code would follow an API the TMS can use to access the information in certificates of that type.
The Attribution Information-section is not signed, because certificates itself is expected to be self-verifying. Furthermore it is useful to be able to process the Attribution-block independently, thus allowing changes to this information without invalidating the signature (e.g. replacing an expired certificate with a renewed certificate, same key, newer validity period).
Here is an example
("AttribInfo"
("http://www.w3.org/PICS/DSig/X509.html" "=base64-x.509-cert=")
("http://www.w3.org/PICS/DSig/X509.html" "http://ice-tel-tlca/certs/DN/CN=Lipp,O=TU-Graz,OU=IAIK")
("http://www.w3.org/PICS/DSig/pgpcert.html" "=base64-pgp-signed-key=")
("http://www.w3.org/PICS/DSig/pgpcert.html" "http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at")
)
The Signature-Section contains the actual signatures. It can be repeated, in case there are multiple parallel signatures. This can be the result of multiple signatures by one person, using different public keys for different crypto-systems, PKI-infrastructures or roles, or different persons have signed the information resource. The Syntax of the Signature-Section is defined as:
("Signature" <Signature-suite> <KeyHolder> <SigInfo> <SigCrypto>)
Being crypto-neutral, DSig does not prescribe the use of certain algorithms for hashing the data or signing the hash. DSig also does not define a particular format for representing the cryptographic information in the Signature-Block. It uses the concept of signature-suites. This concepts bundles certain hashing-algorithms and signature-algorithms together, if the combination is considered safe.
<Signature-Suite> is an URL, that uniquely identifies the signature-suite used for generating the Signature Block. The specification of the properties of the signature-suite have to be retrievable using the given URL. If the signature-suite is a proprietary one, the URL need not point to that specification and serves only identifying purposes.
For the Signature-Block, we specify the format for some chosen, popular signature-suites in separate documents. This does not preclude the use of other combinations. The signature-suites a DSig-compliant implementation is required to support are specified in the DSig-Compatibility Document.
Each signature-suite
Mathematically, a digital signature only expresses that at some point, some process had access to both a secret and the unmodified message text. The Key-Holder section gives information about the key that has been used for creating the signature. The key can then be used to bind the signature to a principal, e.g. using the certificates given in the attribution-info section. This principal, also called the keyholder, need not necessarily be a person; the keyholder may also be a server or an organization.
The easiest way to do this is to include one of the following things into the Signature-section:
The information should point to the corresponding certificate in the Attribution Information Section, if any, or provide the starting point for fetching (other) certificates for the TM, which should end in linking the key to some other known (and trusted) key.
If the UI wants to display name information, the attribution information, if available, can be used to bind this key to such a name or it might need to consult a local key-store (like PGP's public key-ring).
The key-holder information is common to all signature-suites, and must be present in the Signature-Block, even if the information could also be retrieved from the SigCrypto, e.g. in the PKCS#7-case. This facilitates a limited handling of the Signature-Block, in case an implementation is unable to verify the signature, because the Signature-Suite used is not available in a particular implementation. Then, the application can at least display who claims to having made the signature.
The general syntax for the KeyHolder is:
(<KeyHolderType> <KeyholderInfo>)
where KeyHolderInfo depends on KeyholderType. The following subsections specify the content of KeyHolderInfo in the different cases.
The token Key identifies, that the keyholders public key is used to identify the keyholder.
("ByKey" <Key-Value, Signature Suite dependent> )
The format is obviously depending on the signature-suite used, and has to be specified in the signature-suite document. Here is an example for the Digital Signature Algorithm:
("ByKey"
("P" "=base64-encoded-modulus=" )
("Q" "=base64-encoded-divisor=" )
("G" "=base64-encoded-number==" )
("Y" "=base64-encoded-public-key=" )
)
The token Hash identifies, that the hash of the keyholders public key is used to identify the keyholder.
("ByHash" "=base-64-encoded-hash-of-key=" )
Details on how the hash for a key for a certain Algorithm is calculated must be defined in the Signature-Suite specification.
The token Name identifies, that the name of the keyholder is used to identify himself. The name given depends on the names used in the certification-infrastructure used to retrieve the key; it can be a DN for X.509-certs, an email-address for PGP-certificates or for X.509-certs, if email-addresses are stored in alternate-name-extensions.
( "ByName" "Name-as-string-value" )
The token Cert identifies, that the name of the CA and the serial number of the certificate should be used to identify the keyholder. The CA-name given depends on the CA-name-style used in the certification-infrastructure; it would be a DN for X.509-certs e.g.
( "ByCert" ("CA-Name-as-string-value" <CA-Serial-No.>))
The Signature-Information-Section is totally Signature-suite dependent. The specification of its content must be defined in their specs. There are some standard elements however, that will be useable in several Signature Suites. These standard elements are defined here, and we recommend their use for all signature suites that need that properties. In particular, all Signature-Suites defined for DSig-1.0 will use these standard elements.
In addition to the time the label was generated, the time the label was signed can be valuable information. We recommend using this standard element in all Signature Suites.
The date is coded as quoted-ISO-Date; for hashing, the bytes which form that string, in UTF-7, are used for hashing. E.g. when the signatures on-field is: "1996.12.02T22:20-0000", the string 1996.12.02T22:20-0000 is hashed, and consists of the UTF-7-values (hex) 31 39 39 36 2E 31 32 2E 30 32 54 32 32 3A 32 30 2D 30 30 30 30.
For other signature-suites, the date of the signature may be missing or not included in the hash. If another signature-suite includes this information in the SigInfo, it is required to follow this format.
("on" quoted-ISO-Date)
If a user wants to exclude parts of the label from being signed, these parts can be named in this element of the SigInfo-section. <Philip to add examples on why somebody wants to use that besides testing the scheme :-> There are two types of information that can be excluded from being signed: options and ratings. To exclude an option, the name of the option is put into the list of the elements to be excluded. To exclude a rating, the category-name is put into the list of elements to be excluded.
("exclude" ("options" <list of names of options to be excluded from signing>)
("ratings" < list of names of ratings to be excluded>))
The Signature-Crypto-Section is totally Signature-suite dependent. The specification of its content can be found in their specs.
For all Signature-Suites, the binary data included in encoded in base-64.
Correct hashing is the key of successful signing. DSig 1.0 therefore specifies how a PICS-1.1-label is converted into a unique, canonicalized form which does not include the Signature Block extension. This canonicalized label is then fed to the hashing algorithm and signed. The specification of the Signature-Suites must contain a section that specifies how the signature is generated and which information in addition to the label is hashed-in. The DSig-Signature-Suites can be used as an example.
To generate the signature, the hash generated above is protected by encrypting using the private key of the signer. We also recommend including the algorithm-identifier of the hash-algorithm used; the identifier is the token given in the following table. For signing, the string without the quotes, in the Unicode character set , UTF-7 encoding, is used.
| Hash-function | Token |
| SHA-1 | SHA1 |
| MD5 | MD5 |
The signature-suite-specifications must specify, whether the hash-token is included in the private key operation or not. We strongly recommend doing this, as it improves the overall security of the DSig-Scheme: the signature does not depend on the security of hash-functions except the one used for hashing the data. Assume, one of the hash-functions is broken (e.g. MD5). An attacker can then generate a document which produces a hash used in some Signature Block (possibly with some other, still secure hash function, e.g. MD15). Then he can easily produce a Signature Block claiming to use the broken hash-function (MD5) and using the SigCryptoBytes of the original signature. If the string "MD15" is included into the generation of these SigCryptoBytes, this attack is no longer possible.
are allowed, by including several Signatures. This is necessary if one wants to use multiple algorithms or more than one person wants to sign the information resource. The signatures are independent.
("DSigBlock-1.0"
("AttribInfo"
("http://www.w3.org/PICS/DSig/X509.html" "=base64-x.509-cert=")
("http://www.w3.org/PICS/DSig/X509.html"
"http://SomeCa/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")
("http://www.w3.org/PICS/DSig/pgpcert.html" "=base64-pgp-signed-key=")
("http://www.w3.org/PICS/DSig/pgpcert.html"
"http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at")
)
("Signature"
"http://www.w3.org/PICS/DSig/RSA-MD5.html"
("byKey" ("N" "=aba212412412=") ("E" "=abcdefghijklmnop="))
("on" "1996.12.02T22:20-0000")
("exclude" ("extensions" "SomeWeirdExtensionRequired") )
("SigCrypto" "=aba1241241=")
)
("Signature"
"http://www.w3.org/PICS/DSig/DSS.html"
("ByName" "plipp@iaik.tu-graz.ac.at")
("on" "1996.12.02T22:20-0000")
("SigCrypto" ( "R" "=aba1241241=" ) ( "S" "=casdfkl3r4=" ))
)
)
The syntax is given in the Augmented BNF Form following DRAFT-DRUMS-ABNF-01.(txt,ps)
signatureBlock ::= '("DSigBlock-1.0"' AttributionInfo 1*Signature ')'
AttributionInfo ::= '(' '"AttribInfo"' *Certificate ')'
Certificate ::= '(' CertificateType CertificateData ')'
CertificateType ::= QuotedUrl
CertificateData ::= QuotedBase64-string | QuotedUrl
Signature ::= '(' '"Signature"' Signature-suite Keyholder SigInfo SigCrypto ')'
Signature-suite ::= QuotedUrl
Keyholder ::= '(' KeyHolderType ')'
KeyholderType ::= ByKey | ByHash | ByName | ByCert
ByKey ::= '"ByKey"' '(' Algorithm AlgParameters ')'
Algorithm ::= quoted-string ; as sepcified in the Signature-suite
AlgParameters ::= 1*QuotedBase64-string ; as sepcified in the Signature-suite
ByHash ::= '"ByHash"' quotedBase64-string
ByName ::= '"ByName"' quoted-string
ByCert ::= '"ByCert"' quoted-string number
Siginfo ::= *SigInfoElement
SigInfoElement ::= SigTime | Exclude | OtherSigInfo
SigTime ::= '(' '"on"' quoted-ISO-date ')'
Exclude ::= '(' '"exclude"' 1*ExcludeInfo ')'
ExcludeInfo ::= '(' ExcludeType 1*QuotedString ')'
ExcludeType ::= '"options"' | '"extensions"'
OtherSigInfo ::= '(' SigInfoType SigInfoValues ')' ; as specified in the Suite
SigInfoType ::= Quoted-String
SigInfoValue ::= Quoted-URL | quoted-string | quotedBase64-string | number
SigCrypto ::= ( '"SigCrypto"' SigCryptoData )
SigCryptoData ::= 1*QuotedBase64-string | 1*SigCryptoValues ; as defined in the signature-suite
SigCryptoValues ::= '(' Quoted-string QuotedBase64-string ')' ; as specified in the Suite
QuotedMimeType ::= quoted-string
quoted-string ::= '"' UTF-7 '"'
UTF-7 ::= ;Characters encoded using UTF-7, with direct
;coding of UTF-7 set O except for the double-quote
;(decimal 34) which must be encoded to allow for its use
;as the string delimiter character. See note above.
quoted-URL ::= '"' URL '"'
;URL is as defined in RFC-1738 for URLs.
urlchar ::= alphanumpm / '.' / '$' / ',' / ';' / ':'
/ '&' / '=' / '?' / '!' / '*' / '~' / '@'
/ '#' / '_' / '(' / ')' / '%' hex hex
;Note: Use the "%" escape technique to insert
single or double quotation marks into a URL
alphanumpm ::= ALPHA / DIGIT / sign
number ::= [sign]unsignedint['.' [unsignedint]]
sign ::= '+' / '-'
unsignedint ::= 1#DIGIT
quotedname ::= '"' urlchar-or-space+ '"'
alphanumpm ::= 'A' / .. / 'Z' / 'a' / .. / 'z' / '0' / .. / '9' / sign
hex ::= DIGIT / 'A' / .. b/ 'F' / 'a' / .. / 'f'
urlchar-or-space ::= urlchar / ' '
quotedBase64-string ::= '"' base64-string '"'
base64-string ::= *(ALPHA / DIGIT / "+" / "/") ;as defined in RFC-1521.
quoted-ISO-date ::= YYY "." MM "." DD "T" hh ":" mm sign tz mm
YYYY ::= 0000.9999 ;four-digit year
MM ::= 01.12 ;two-digit month (01=January, etc.)
DD ::= 00.31 ;two-digit day of month (01 through 31)
hh ::= 00.23 ;two digits of hour (00 through 23) (am/pm NOT allowed)
mm ::= 00.59 ;two digits of minute (00 through 60)
tz ::= 00.11 ;tz + mm = four digit amount of offset from UTC
;(e.g., 1512 means 15 hours and 12 minutes)
;For example, "1994.11.05T08:15-0500" is a valid quoted-ISO-date
;denoting November 5, 1994, 8:15 am, US Eastern Standard Time
;Note: The ISO standard allows considerably greater
;flexibility than that described here. DSig requires precisely
;the syntax described here -- neither the time nor the time zone may
;be omitted, none of the alternate formats are permitted, and
;the punctuation must be as specified here.
DSig 1.0 signature labels are PICS 1.1 labels with extensions. The resinfo extension provides a cryptographic tie between the label and the information resource. The sigblock extension is the 'signature'. It identifies who has signed the information resource, when this signature has been generated, which algorithms were used to generate the signature, and of course, the signature data itself. Signatures can only be applied to individual labels not to a label list. (Label signatures are given as label options for the label to which they apply.)
Since even a single DSig 1.0 signature label must be represented as a PICS 1.1 label list, let's begin by looking at the structure of such a list.
(PICS-1.1
<service 1 url> [service 1 option...]
labels [label 1 options...] [label 1 signature] ratings (<category> <value> ...)
[label 2 options...] [label 2 signature] ratings (<category> <value> ...)
...
<service 2 url> [service 2 option...]
labels [label 3 options...] [label 3 signature] ratings (<category> <value> ...)
[label 4 options...] [label 4 signature] ratings (<category> <value> ...)
...
...)
The process for signing a label is fairly straight forward whether the labellist containing the label is made up of a single label or a series of labels. First, we create an equivalent standalone label. Then we canonicalize the equivalent standalone label. Finally, we sign the result and place the sigblock extension that is created back into the label as a label option. An equivalent standalone label can have at most one resinfo extension (which it may inherit from the service options) and one sigblock extension.
An equivalent standalone label is a PICS 1.1 labellist containing a single label, where the label has been normalized to a form where all options are label options (this includes extension options) and the sigblock extension (if present) has been removed. From the example labellist above, label 4 could be reduced to the single label:
(PICS-1.1
<service 2 url>
labels [service 2 option...] + [label 4 option...]
ratings (label 4 ratings <category> <value> ...))
This is not yet an equivalent standalone label. We still need to take into account any options or ratings named by the Exclude standard signature suite option of the sigblock extension. As explained in the Embedding the DSig Signature Block section, the Exclude option allows the signer to specify options and rating categories which they want to exclude from their signature.
The resulting labellist (below) is the equivalent standalone label.
(PICS-1.1
<service 2 url>
labels (Total Label 4 Options) ratings (Total Label 4 Ratings))
Where:
Total Label 4 Options = [service 2 option...] + [label 4 option...] - excluded options Total Label 4 Ratings = label 4 ratings (<category> <value> ...) - excluded category/value pairs
(The following example is incorrect and will be updated!!)
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels for "http://w3.org/PICS/Overview.html"
extension (optional "http://www.w3.org/pub/DSIG/v1.0/resinfo"
(resinfo (ResHashes (MD5 =aba212412412=))))
extension (optional "http://www.w3.org/pub/DSIG/v1.0/cryptinfo"
(sigblock
(signature
(SigInfo (on 1996.11.05T08:15-0500")
(CryptoSuite RSA/MD5))))))
on "1994.11.05T08:15-0500"
ratings (suds 0.5 density 0 color 1))
The normalized form remove excessive white-space and linefeed,
( PICS-1.1 "http://www.gcf.org/v2.5" by "John Doe" labels for
"http://w3.org/PICS/Overview.html" extension ( optional
"http://www.w3.org/pub/DSIG/v1.0/resinfo" ( resinfo ( ResHashes ( MD5
=aba212412412= ) ) ) ) extension ( optional "http://www.w3.org/pub/DSIG/v1.0/cr
yptinfo" ( sigblock ( signature ( SigInfo ( on 1994.11.05T08:15-0500" ) (
CryptoSuite RSA/MD5 ) ) ) ) ) )
on "1996.11.05T08:15-0500" r ( suds 0.5 density 0 color 1 ) )
After the signature is computed, the SigData is inserted as well as other
'unprotected' information to sigblock. Now this PICS label ready for FedEx
delivery.
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels for "http://w3.org/PICS/Overview.html"
extension (optional "http://www.w3.org/pub/DSIG/v1.0/resinfo"
(resinfo (ResHashes (MD5 =aba212412412=))))
extension (optional "http://www.w3.org/pub/DSIG/v1.0/cryptinfo"
(sigblock
(Attrib-Info
("http://iso.org/X/509/v3" =cdc323323223=)
("http://pgp.com/pgcert" =ded565566556=))
(signature
(KeyHolder (RSA =gfg787788787= =1100))
(SigInfo (on 1996.11.05T08:15-0500")
(CryptoSuite RSA/MD5))
(SigData =jkj89998394=))))
on "1994.11.05T08:15-0500"
ratings (suds 0.5 density 0 color 1))
While PICS allows labels to be truncated to reduce their size, if this is done in DSig 1.0 after signing, the signature will no longer be valid. An alternative is to distribute an unsigned label with the complete option pointing to a full, signed label. Client software in need of a signed label can dereference the complete option's URL to retrieve a complete, signed label.
There is a security hole in the above proposal. The semantics of the assertions (ratings) in a PICS 1.1 label are defined by the rating service, and the only information about the rating service contained within the label itself is the service's URL. Since the human-readable description pointed to by that URL is what defines the rating semantics, it is possible under the current scheme for the semantics of the rating service to change after the label has been created without invalidating the label.
If this is a concern, a simple policy in the trust engine that evaluates signatures could be established to require a separate signature label on the service description file.
DSig 1.0 labels are PICS 1.1 compliant and thus may be transported in the same way as PICS 1.1 labels. PICS Label Distribution Label Syntax and Communication Protocols Version 1.1 identifies three ways that a PICS label can be transported: In an HTML document, With a document transported via a protocol that uses RFC-822 headers, or Separately from the document.
Labels may also exist on their own, referenced via a URL. When the URL is dereferenced it returns an item of type application/pics-labels that contains a labellist.
The specifications for embedding a PICS label in an HTML document are well defined. It is possible to use DSig labels in document other than HTML. To do this, a specification for how the label is embedded in that document type and how the document is normalized for hashing into the label must be created.
Philip DesAutels
Project Manager, Technology and Society Domain, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1.617.258.5714
Fax: +1.617.258.5999
Email: philipd@w3.org
Peter Lipp
Technical University, Graz
Email: plipp@iaik.tu-graz.ac.at
Brian LaMacchia
AT&T Research Labs
Email: bal@research.att.com
Yang-hua Chu
Technical Staff, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1.617.253.5884
Fax: +1.617.258.5999
Email: yhchu@w3.org