Movatterモバイル変換

[0]ホーム
URL:

W3CREC-DSig-label-20091124


PICS Signed Labels
(DSig)
1.0 Specification

W3C Recommendation 27-May-1998 (revised 24-Nov-2009)

Latest Version:
http://www.w3.org/TR/REC-DSig-label
This version:
http://www.w3.org/TR/2009/REC-DSig-label-20091124
Previous version:
http://www.w3.org/TR/1998/REC-DSig-label-19980527/

Note:This paragraph is informative. This document iscurrently not maintained. PICS has been superseded by the Protocol for Web Description Resources (POWDER). W3C encourages authors andimplementors to refer to POWDER (or its successor) rather than PICS when developing systems to describe Web content or agents toact on those descriptions. A brief document outlining the advantages offered by POWDER compared with PICS isavailableseparately.

EditorAuthors:

Copyright  ©  1998W3C(MIT,INRIA,Keio ), All Rights Reserved. W3Cliability,trademark,documentuseandsoftwarelicensingrules apply.

Status of this document

Last updated: 1998-06-01T14:03:02Z

This document has been reviewed by W3C Members and other interestedparties and has been endorsed by the Director as a W3CRecommendation. It is a stable document and may be used as referencematerial or cited as a normative reference from anotherdocument. W3C's role in making the Recommendation is to draw attentionto the specification and to promote its widespread deployment. Thisenhances the functionality and interoperability of the Web.

As a result of comments supplied during the balloting period, thesyntax of quoted ISO dates has been changed from strictly PICS 1.1 conformantto permit either PICS 1.1 or ISO conformant forms.At the same time we have added optional seconds and decimalfractions of seconds fields to support those cryptographic algorithmsthat require sub-minute precision in timestamps.

A confusing reference to sigblocks in equivalent standalone labelsis fixed. The title is changed to indicate that this is a signaturespecification specifically for PICS labels.

At the time this Recommendation was published a possiblerevision to PICS 1.1 was being discussed. That revision to PICS 1.1 wasexpected to be called PICS 1.2 and was expected to have no significantimpact on this specification. Allreferences herein to "PICS 1.1" should be interpreted to mean "PICS 1.1and PICS 1.2".

Comments on this Recommendation maybe sent tow3c-dsig-ask@w3.org.

This document is part of theW3CDigital Signature Project.

A list of current W3C Recommendations, Proposed Recommendations andWorking Drafts can be found at:http://www.w3.org/TR

Abstract

The W3C Digital Signature Working Group ("DSig") proposes a standard formatfor making digitally-signed, machine-readable assertions about a particularinformation resource.PICS 1.1 labels arean example of such machine-readable assertions. This document describesa method of adding extensions to PICS 1.1 labels for purposes of signingthem. More generally, it is the goal of the DSig projectto provide a mechanism to make the statement:signer believesstatementaboutinformation resource. In DSig 1.0statement is anystatement that can be expressed with PICS 1.1.

Contents

DSig 1.0 Overview

The W3C Digital Signature Working Group ("DSig") proposes a standard formatfor making digitally-signed, machine-readable assertions about a particularinformation resource.PICS 1.1 labels arean example of such machine-readable assertions. This document describesa method of adding extensions to PICS 1.1 labels for purposes of signingthem. More generally, it is the goal of the DSig projectto provide a mechanism to make the statement:

signer believesstatement aboutinformationresource

In this specificationstatement is anystatement that can be expressed with PICS 1.1.This document also provides detailed usage guidelines for creatingPICS 1.1 labels that are valid DSig 1.0 Signature labels.

DSig 1.0 signature labels inherit both a means of transporting a signatureblock data and a simple framework for making the machine-readable assertionsfrom the underlying PICS framework. PICS compliant applications can syntacticallyparse DSig 1.0 signature labels; only cryptographic functions need to beadded to PICS-aware applications in order to make use of the semantic contentof a DSig signature.

In its simplest form, a DSig 1.0 signature label is a signed statementabout an information resource. This document describes two DSig-specificextensions to standard PICS 1.1 labels:resinfo andsigblock.Theresinfo extension is used to create cryptographic linksbetween the signature label and the information resource described by thelabel. Typically this linkage is created through the use of one or morecryptographic hash functions. Thesigblock extension containsone 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 is described 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 reviewingthe PICS 1.1 architecture and illustrating how DSig 1.0 signature labelsare built on top of PICS 1.1 labels.

PICS Architecture

At the core of the PICS infrastructure is the rating service. Theratingservice either chooses an existing, or develops a newrating systemto use in labeling content. The rating system, which is described in ahuman readable form at therating system URL, specifies the rangeof statements that can be made. The rating service establishes criteriafor determining who can label content using their name and how the labelsmust be applied. This combination of criteria and rating service are uniquelyidentified by the particularservice URL. This service URL becomesthe brand, if you will, of the rating service. At a minimum, the serviceURL will return a human readable form of the rating criteria and a linkto the description of the rating system. The rating service is also responsiblefor delivering aservice description file. This is a machine-readableversion of the rating system with pointers to the rating system URL andthe rating service URL. While not required, it is recommended that thisbe available automatically at the service URL.
Elements of PICS infrastructure

A labeler, given authority by the rating service, uses the criteriaestablished by them along with the rating system to label content. Thesecontent labels contain a statement about the content of the resource beinglabeled and contain a link back to the service URL. Content labels cancome in the content itself, with the content or from a trusted third partysuch as a label bureau. Policies determine what actions are taken basedon the specific statements in the content label. If a content label isbased on an unknown service URL, it is a simple (and potentially automatable)task to retrieve the appropriate service description file to understandwhat statements are being made in the label.

DSig 1.0 utilizes the PICS infrastructure as described above with afew differences:

PICS 1.1 labels and label lists

PICS labels are always transmitted as lists of one or more individual PICSlabels ("label lists"); in common PICS practice PICS label lists usuallycontain exactly one label. Full details of PICS labels and label listsare available in "PICSLabel Distribution Label Syntax and Communication Protocols Version 1.1"document:In DSig 1.0, each assertion about an information resource is given in alabel. A label consists of aservice identifier,options,extensions and anassertion (in PICS 1.1 the assertion iscalled a rating). The service identifier is the URL chosen by the ratingservice (seeRatingServices and Rating Systems) as its unique identifier. Options andextensions give additional properties of the label, the document beinglabeled and properties of the assertion itself. The assertion itself isa set of attribute-value pairs that describe a document along one or moredimensions. One or more labels may be distributed together as a list whichallows for some data aggregation.

A PICS labels 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 notshowing error status codes) is:
   (PICS-1.1     <service 1 url>[service 1option...]       labels [label 1option...] 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 serviceoptions which are inherited by each label within the scope of the service;service options may be overridden by individual label options. When a newservice is identified in the label list, the options from the previousservice no longer apply. Thus, in the above example label 4 could be equivalentlyrepresented 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 thereof; the detailsof signing labels are presented below.

PICS defines two distinct types of labels,specific andgeneric:

PICS Options and DSig

Semantics of Embedded Signature Blocks

By convention, a DSig signature block itself has the weakest possible semantics,namely "the entity possessing the key that created this signature had accessto the secret key used to generate the signature and the signed data atthe same time." For DSig 1.0 signature labels, we want somewhat strongersemantics that also includes the semantics of the ratings contained withinthe label. Thus, by definition a PICS label which includes a DSigsigblockextension has the following semantics:
"The entity possessing the secret key that digitally signedthis PICS 1.1 label had access to the secret key and the label at the sametimeand asserts that the statements made within the label are valid"

Applying PICS to DSig

Following the format given inPICSLabel Distribution Label Syntax and Communication Protocols Version 1.1we now review each of the PICS 1.1 options; giving appropriate usage rulesfor applying them within the context of DSig 1.0 Signature Labels.

PICS label options can be divided into three groups. Options from thefirst 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.

  1. Information about the document that is labeled.
    atquoted-PICS-ISO-date
    The last modification date of the information resource to which this assertionapplies, at the time the assertion was made . This can serve as a lessexpensive, but less reliable, alternative to the DSig 1.0resinfoextension.
    MIC-md5 "Base64-string"
    -or- md5 "Base64-string"
    If this option is present in a DSig 1.0 label, it should be ignored. Further,it should be removed from the label for the purposes of signing. This optionhas been superceded by the DSig 1.0resinfoextension.
  2. Information about the label itself.
    byquotedname
    An identifier for the person or entity who was responsible for creatingthis particular label. The contents of the by field are not restrictedby the DSig 1.0 specification; it is common practice in PICS usage to includea name or e-mail address in the string value of theby field. WithinDSig 1.0, theby field is considered informational only; thebyoption name need not be the same as that of the signer(s). Thesigblockextension includes fields for the identity of the signer (in thesignature section) and certificates (or references to them) identifyingthe signer(s) (within theattribution information section).
    forquotedURL
    The URL (or prefix string of a URL) of the information resource to whichthis assertion applies. This option is required for generic labels andin certain other cases (see "Requesting Labels Separately," PICS LabelDistribution Label Syntax and Communication Protocols Version 1.1); itis optional in other cases. Thefor option is valid as both a serviceand label option in a label list.
    genericboolean
    -or- genboolean
    If this option is set to true, the label can be applied to any URL startingwith the prefix given in thefor option. By default, this optionis false. Set to true, it is used to supply ratings for entire sites orsubparts of sites. All generic labels must also include theforoption. A generic label should not be created unless it can be legitimatelyapplied toall documents whose URL begins with the prefix specifiedin thefor option (even if a more specific label exists). If thegeneric option is used with a true value, the DSig 1.0resinfoextensioncan not be used because there will not be a specific information resourceto hash.
    onquoted-PICS-ISO-date
    The date on which this label was created. This may be different than thedate the label was signed (which may be included within the DSig 1.0sigblockextension).
    signature-RSA-MD5 "Base64-string"
    If this option is present in a DSig 1.0 label it should be ignored andremoved from the label for the purposes of signing. This option has beenreplaced with the DSig 1.0sigblock extension.
    untilquoted-PICS-ISO-date
    -or- expquoted-PICS-ISO-date
    The date on which the label expires (how long the label is good for).
  3. Other information.
    commentquotedname
    Information for humans who may see the label; no associated semantics.
    complete-labelquotedURL
    -or- fullquotedURL
    De-referencing this URL returns a complete label that can be used in placeof the current one. The complete label has values for as many attributesas possible. This option is used when a short label is transmitted forperformance purposes but additional information is also available. Whenthe URL is de-referenced it returns an item of type application/pics-labelsthat contains a label list with exactly one label. In DSig 1.0 this optionmight be used if the initial label transmitted was an abbreviated versionof the full label. The abbreviated version might contain minimal optionsand no signature. The client application could then de-reference this URLto get the full, signed version of the label.
    extension (optionalquotedURL data*)
    -or- extension (mandatoryquotedURL data*)
    Future extension mechanism. To avoid duplication of extension names, eachextension is identified by aquotedURL. The URL is de-referencable,yielding a human-readable description of the extension. If the extensionisoptional then software which does not understand the extensioncan simply ignore it; if the extension ismandatory then softwarewhich does not understand the extension should act as though no label hadbeen supplied. Each item ofdata must be one of a fixed set of simple-to-parsedata types as specified in the detailed syntax below. Seehttp://www.w3.org/PICS/extensions/ for a partiallisting of extension URIs previously defined.The DSig 1.0resinfoandsigblock extensions uses this mechanism (See "DSigExtensions," below for details.)

DSig Extensions

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 resourceby including one or more hashes of the information resource within thesignature label. Similar, albeit limited, functionality was accomplishedin the PICS 1.1 specification via theMIC-md5 (ormd5) option.DSig 1.0 replaces this option with theresinfoextension,which permits a single label to include multiple hashes using multiplehash algorithms.

PICS 1.1 also specified a signature option,signature-RSA-MD5,but its functionality was similarly limited. DSig replacessignature-RSA-MD5with thesigblock extension. Thesigblock extensionmay contain one or more signatures using any cryptographic algorithm; inaddition, asigblock may optionally include information inthe form of certificates or links to certificates.

A DSig 1.0 Signature Label is a standard PICS 1.1 label. The DSig extensionsresinfo andsigblock are both optional andcan be used as needed. A PICS 1.1 label is only considered a DSig 1.0 SignatureLabel when it contains asigblock extension.

The syntax of the extensions presented below is written in modifiedBNF. By convention,

a?
a or nothing; optional a.
a+
one or more occurrences of a.
a*
zero or more occurrences of a.
Quoted strings are case sensitive but other literal elements are case insensitive.Multiple contiguous space characters are be treated as though they werea single space character except in quoted strings.

URLs as identifiers

Within the DSig 1.0sigblock andresinfo extensions,URLs are used as identifiers to indicate a particular hashing algorithm,certificate type or signature type. Specifically, they are used as:To ensure the uniqueness of identifiers, the identifier must be a validURL. This in effect creates a distributed registry of unique names whichcan be created and shared by any community of interest.

Since the identifier is a URL, it must, when resolved, yield a a document.We recommend the returned document:

We require that such identifier description documents always be provided.

Any incompatible change in an identifier should be accomplished by creatingan entirely new identifier URL.

URL identifiersfor some common, popular signature suites are available. Of course,DSig 1.0 implementations are not restricted to using these or only these.To provide a base level of interoperability, all DSig 1.0 implementationsare required to implement the signature suites listed in Appendix 3.

Resource Reference Information Extension

The goal of the resource reference information (resinfo)extension is to provide a cryptographic link between the signature labeland an information resource. DSig 1.0'sresinfo extensionbuilds upon the PICS 1.1for,at andMIC-md5optionsto provide this cryptographic link. Specifically, theresinfoextension provides a mechanism for including cryptographic checksums (hashes),in any named cryptographic algorithm, to the label. These hashes providea means for the receiver of the label to determine if the information resourcethey have is the same as the one about which the assertion was made.

Theresinfo extension is associated with a specific resource.This resource may be identified by thefor option or may be impliedby the context of the label (in the resource, delivered in the HTTP headerwith the resource, returned by a label bureau based on a request, etc.).

In the structure of a PICS label, theresinfo extensioncan be aservice option and/or alabel option. It functionsidentically to any other option with respect to inheritance within a servicesection from service option to label option. A single document can havemany URLs; the URL used to retrieve a document may differ from the URLin thefor option of a label that accompanies the document, butthe document retrieved must be the same document or the hash(s) containedin theresinfo extension will not be valid.

Structurally,resinfo contains one or more hashes of theinformation resource; each hash includes a hash algorithm identifier, theactual 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 quotedURL identifieras defined above. It identifies thespecific hashing algorithm by which the following hash was computed. Theactual hash is given as a quoted base64 encoded string.

Usage notes:

Detailed Syntax of theresinfo Extension in a PICS 1.1 Label

resinfo-extension ::='extension ( optional '     '"http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"' resinfo-data+ ')'resinfo-data   ::='('HashAlgoID resource-hash hash-date?')'HashAlgoID     ::=quotedURLquotedURL      ::= '"'URL '"'resource-hash  ::= '"base64-string"'hash-date       ::= quoted-ISO-datequoted-ISO-date ::= '"' YYYYsep MMsep DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'     based on the PICS-defined ISO 8601:1988 date and time format, restricted     to the specific form described here:    sep  ::= '.' | '-'    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 59)    ss    ::= two digits of second (00 through 59), optional    f     ::= digit(s) of fractions of second, optional    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 validquoted-ISO-date     denoting November 5, 1994, 8:15 am, US Eastern Standard Time    Notes:      1. The ISO 8601:1988 date and time format standard allows considerably      greater flexibility than that described here.  DSig requiresprecisely     the syntax described here -- neither the time nor the time zone may     be omitted, none of the alternate ISO formats are permitted, and     the punctuation must be as specified here, Except:     2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988      date and time format. PICS 1.1 uses '.' as separators while the ISO     standard calls for '-'.  DSig supports both syntaxes.  PICS 1.1 also     does not support the optional seconds and fractions of seconds fields     and permits minutes to range from 0 to 60.base64-string ::= as defined in RFC-1521.URL           ::= as defined in RFC-1738.
The following example shows a valid DSig 1.0resinfo extensionwith two hashes of the referenced information resource.
   extension     ( optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"            ( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "base64 hash" )            ( "http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "base64 hash"               "1997-02-05T08:15-0500" ) )
In this example, we begin with theextension ( optional tokenswhich identify this extension as an optional extension to the PICS labelwithin which it is contained. This declaration is followed by aURL,http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0, which provides a unique namefor the extension. De-referencing the URL provides human readable informationon the extension. Finally we have two repeating subsections of the extension,each of which contain hash information. Here again, de-referencing thehash algorithm identifier URL returns a human readable description, thistime of the hash algorithm. In our specific example above, the first hashis of type SHA1. This is followed by the actual hash data and followedby the date the hash was computed. The second clause uses the MD5 hashalgorithm.

The Signature Block Extension

The DSig 1.0 Signature Block Extension (sigblock) providescryptographic protection of the DSig 1.0 label by using digital signaturetechniques. It identifiesThesigblock extension can also contain certificates thatcan be used by a trust management system (TMS) to decide if the signatureis trustworthy.

Format Specification

A Signature Block consists ofUsage notes:Here is a structural representation of thesigblock extension:
   extension      ( optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"         <attribution info> <signature>* ) )

Attribution Information

The Attribution Information section contains self-verifiable informationrelated to the creation of the digital signature on the label. In particular,cryptographic certificates asserting identity, authorization or other capabilitiesmay be included here. Certificates may be directly embedded within theAttribution Information section of thesigblock extension,or URLs pointing to certificates may be included. Attribution Informationis not required (i.e. this section of the extension may be empty), in whichcase trust management systems must depend on other information sourceswhen interpreting the label. Furthermore, the information provided hereinmay or may not be used by the trust management system in processing thelabel.

Attribution Information supports any certificate format; the types ofcertificates included will depend on the public key infrastructure usedby the application. Certificate format is indicated by the certificatefamily identifier, a quoted URL identifieras definedabove. This certificate family identifier, when dereferenced, providesinformation on the format of the data to follow.

None of the information contained within the Attribution Informationsection is signed by the label's signature because certificates themselvesare expected to be self-verifying. (More precisely, none of the informationwithin the entiresigblock extension, including the AttributionInformation section, contributes to the hash of the label that is signedas part of the signature option.) Thus, applications may augment the contentsof the Attribution Information section without invalidating the signatureon the label (e.g. newly-discovered certificates may be included in theAttribution Information section as they are found, or an expired certificatemay be replaced).

Here is a structural representation of the Attribution Information section:

   ( "AttribInfo"      ( "CertificateFamilyIdentifierURL" "Certificate Data")      ( "CertificateFamilyIdentifierURL" "Certificate Data")                      ...)
Here is an example Attribution Information section:
   ( "AttribInfo"       ( "http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")      ( "http://www.w3.org/PICS/DSig/X509-1_0"         "http://ice-tel-ca/certs/DN/CN=Lipp,O=TU-Graz,OU=IAIK")      ( "http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")      ( "http://www.w3.org/PICS/DSig/pgpcert-1_0"         "http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at" ) )

Signatures

The Signature section of thesigblockextension containsthe actual digital signature data. Each Signature section contains exactlyone signature; multiple Signature sections may be included in thesigblockextension when multiple, parallel signatures are desired. The syntax ofthe Signature section is:
   ( "Signature" SignatureSuite SigData+)
Being crypto-neutral, DSig 1.0 does not prescribe the use of particularalgorithms for generating hashes or digital signatures. DSig 1.0 also doesnot define any particular format for representing cryptographic informationin thesigblock. Instead, we introduce the concept of "signaturesuites," which bundle together certain hashing algorithms, signature algorithmsand representation format. Each digital signature includes a signaturesuite identifier (a quoted URL identifieras defined above)that tells applications how the signature was generated and how it shouldbe parsed.

Each signature suite:

Signature suites have complete control over the contents of the SigDataimmediately following the signature suite URL. The format of this datamust satisfy the SigData portion of the BNF; beyond that requirement, theformat of the data is governed by the definition given in the signaturesuite.DSig 1.0 does define two hash algorithms and two signature suites forinteroperability; see Appendix 3.Implementations must implement these four algorithms in addition to any othersthey may wish to define.

Common SigData fields

Although each signature suite is free to specify its own format for signaturedata (SigData) fields, there are some types of information that are likelyto be used by most signature suites. For example, signature suites needto include the actual cryptographic data that constitutes a digital signature.Signature suites will probably also wish to include information about thecryptographic keys used to generate and verify the signature. We now definesome common SigData fields and their identifying string tokens ("SigTokenString"in the BNF below). These string tokens arereserved wordsin thesense that any signature suite that uses SigData field identified by thesetokens must do so in a manner consistent with this specification.
Keyholder tokens: information about keys relatedto the signature
Mathematically, a digital signature only cryptographically guarantees thatat a particular point in time some process had access to both the signing(secret) key and the text of the signed document. The "Keyholder"-typeSigData fields of a signature provides information about the key that wasused to create the corresponding signature. The key may be bound to someentity (such as a person, server, or organization) by various certificates.There are four common ways to uniquely specify a particular key; each hasits own identifying token:
  1. Provide the public key directly ("ByKey");
  2. Provide a hash (or fingerprint) of the public key ("ByHash");
  3. Provide somename that is associated with the public key, such asan X.509 "distinguished name" or the UserID string of a PGP key ("ByName");or
  4. Provide the name of a certifying authority (CA) and information, whichidentifies the desired key to the CA ("ByCert").
To be useful, the information identifying the signing key will lead theapplication to corresponding certificates in the Attribution Informationsection (if any) or provide the starting point for fetching certificatesfrom remote sources.

The following subsections specify the content of the SigInfo fieldsassociated with each of these tokens.

"ByKey"
The token "ByKey" identifies the value that follows as the key that shouldbe used to validate the signature (or sufficient information to generatethat key locally).
   ( "ByKey" <Key-Value, SignatureSuite dependent> )
The format of the included key necessarily depends on the particular signaturesuite used and must be specified in the signature suite document. Hereis an example use of "ByKey" within the Digital Signature Algorithm (DSA)signature suite:
   ( "ByKey"      ( "P" "base64-encoded-modulus" )      ( "Q" "base64-encoded-divisor" )      ( "G" "base64-encoded-number" )      ( "Y" "base64-encoded-public-key" ) )
"ByHash"
The token "ByHash"identifies the value that follows as the hashof the key that should be used to validate the signature.
   ("ByHash" "base-64-encoded-hash-of-key" )
Details on how the hash for a key is generated is a property of individualsignature suites.
"ByName"
The token "ByName" identifies the value that follows as a name (or otherreference) that may be used to identify the corresponding public key. Thename that should be provided depends on the relevant public key infrastructure.
   ( "ByName" "Name-as-string-value" )
"ByCert"
The token "ByCert" identifies the value that follows as containing thename of a certifying authority (CA) and the serial number a relevant certificateissued by that CA. The name given for the CA depends on the naming conventionsof the relevant public key or certification infrastructure.
   ( "ByCert" ( "CA-Name-as-string-value" <CA-Serial-No.> ) )
The "On" token: Time of Signature generation
The token "On" identifies the value that follows as the time the label'ssignature was generated. (This option is distinct from the PICS 1.1 labeloption "on" which indicates the time at which the label itself was created.)We recommend using this standard element in all signature suites.

The time that the signature was created is encoded as aquoted-ISO-Date.The format of a quoted-ISO-Date is defined below.

   ("on" quoted-ISO-Date)
Notice that the "on" time is advisory only to applications verifying thedigital signature; as this section is part of the entiresigblockextension it is not cryptographically protected by the signature itself.(The contents of thesigblock do not contribute to the hashof the label that is signed by the signature.) If a cryptographically-protecteddate is desired, the correct way to implement it is to include the datewithin another PICS label extension; that extension may then contributeto the hash of the canonicalized label.
The "include" and "exclude" tokens: modifying thecanonicalized form of the label
If an application wishes to transmit both signed and unsigned informationin a label the suggested method for doing so is to generate two labels(one signed, one unsigned) and send both labels as a PICS label list. However,some PICS 1.1 protocols, including the protocol for requesting labels froma PICS label bureau, require that exactly one PICS label be returned inresponse to a request, and thus it may be necessary for a signing applicationto sign only a subset of a PICS label. If the signature suite permits signaturesover partial contents of labels, the "include" and "exclude" tokens providethat functionality:
   ( "exclude" field-list )    ( "include" field-list )
The "include" and "exclude" SigData fields modify the default behaviorof the label canonicalizer. "include" indicates that only the fields listedare included in the signature, "exclude" indicates that all fields areincluded in the signature except those listed. Before a label is signed,it is put into canonical form; the section "Creatingan equivalent standalone label" below describes in detail the canonicalizationprocess. PICS labels have many semantically-equivalent forms yet theseforms yield distinct hashes, so it is important that signing and verifyingapplications canonicalize labels in the same way. After the equivalentstandalone label has been generated following the default canonicalizationrules, individual label options may be dropped if an "include" or "exclude"option is present. If an "include" option is present, any field not listedin the field-list is removed from the canonicalized label. If an "exclude"option is present, all fields listed in the field-list are removed fromthe canonicalized label. At most one "include" or "exclude"; field mayappear; it is an error to have both an "include" and an "exclude" option.

The value associated with an "include" or "exclude" option (the "field-list")is a list of label fields to be included or excluded in the canonicalizedform. There are three types of fields in PICS 1.1 labels: options, ratingstransmit/value pairs, and extensions. The format of a field-list is asfollows:

field-list      ::= '(' option-list? ratings-list? extension-list? ')'option-list     ::= '(' "options" <options>* ')'ratings-list    ::= '(' "ratings" <ratings>* ')'extension-list  ::= '(' "extensions" <quoted-URL>* ')'
A field-list is simply at most, one each of: option-list, ratings-listand extension-list, with their associated data. An option-list is a listof PICS 1.1 label option names (e.g. "for" or "by"). A ratings-list isa list of PICS 1.1 ratings service transmit-names (e.g. "suds" in the example"Good Clean Fun" rating service). An extension-list is a list of quoted-URLswhere each quoted-URL uniquely identifies a particular PICS 1.1 label extension.

Note: The "include" and "exclude" SigData types exist in this specificationstrictly to overcome limitations in PICS 1.1 protocols. W3C's new metadatainfrastructure,Resource DescriptionFramework (RDF) should not have these limitations and it is the intentof the DSig working group that "include" and "exclude" not be present inthe DSig 2.0 specification, which will build on RDF.

The "SigCrypto" token: signature cryptographic data
The "SigCrypto" token identifies the SigData field that contains the cryptographicdata that is the signature itself. The format and contents of this fieldare entirely specified by particular signature suites.

Hashing

Correct hashing is the key to successful signing. DSig 1.0 therefore specifieshow a PICS 1.1 label is converted into a unique, canonicalized form whichdoes not include thesigblock extension (this process isexplained in theSigningsection below). This canonicalizedlabel is the input to the signature suite's signature algorithm. The signaturealgorithm may require or accept other inputs in addition to the contentsof the equivalent standalone label. For example, the signature suite maypad the data in a particular way, or mix into the hash of the data informationconcerning the algorithms used to generate the hash and signature.

Parallel and cascaded signatures

Multiple parallel signatures on the same PICS 1.1 label may be createdsimply by including several "Signature" fields within thesigblockextension. Cascaded signatures (signatures on signatures) are not supportedwithin a single DSig signature label. To create a cascaded signature, aDSig signature label may be signed using another DSig signature label.

An examplesigblock extension:

   extension (optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"      ("AttribInfo"          ("http://www.w3.org/PICS/DSig/X509-1_0" "base64-x.509-cert")         ("http://www.w3.org/PICS/DSig/X509-1_0"             "http://SomeCa/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")         ("http://www.w3.org/PICS/DSig/pgpcert-1_0" "base64-pgp-signed-key")         ("http://www.w3.org/PICS/DSig/pgpcert-1_0"          "http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))      ("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"          ("byKey" (("N" "aba21241241=")                    ("E" "abcdefghijklmnop=")))         ("on" "1996-12-02T22:20-0000")         ("exclude" (("extensions" "http://foo/badextension")))         ("SigCrypto" "aba1241241=="))      ("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/DSS-1_0"         ("ByName" "plipp@iaik.tu-graz.ac.at")         ("on" "1996-12-02T22:20-0000")         ("SigCrypto" (("R" "aba124124156")                        ("S" "casdfkl3r489")))))

Detailed Syntax of thesigblock Extension in a PICS 1.1 Label

Note: This extension is not a valid PICS 1.1 extension because Base64 encodinguses a '/' which cannot be represented as a PICS 1.1 datum. Nonetheless,since quotedURL (whichdoes allow the use of '/') and quotedname(which does not) are indistinguishable at a lexical level (and both arelegitimate for use as a PICS 1.1. datum), we believe that all existingPICS parsers will support the grammar presented below.
SignatureExtension  ::= 'extension ( optional'                                      SigBlockURL AttributionInfo Signature* ')'SigBlockURL         ::= '"http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"'AttributionInfo     ::= '(' '"AttribInfo"' Certificate* ')'Certificate         ::= '(' CertificateFamilyID CertificateData ')'CertificateFamilyID ::= quotedUrlCertificateData     ::= quotedBase64String | quotedUrlSignature           ::= '( "Signature"' SignatureSuiteID SigData+ ')'SigData             ::= '(' SigTokenString SigInfo ')'SigTokenString      ::= quotedNameSigInfo             ::= SigData | quotedURL | quoted-ISO-date | quotedBase64String                        | quotedName | number | '(' SigInfo+ ')'SignatureSuiteID    ::= quotedUrlquotedURL           ::= '"' URL '"'URL                 ::= as defined by RFC-1738.quotedBase64String  ::= '"' base64String '"'base64String        ::=as defined in RFC-1521.alpha               ::= 'A' | .. | 'Z' | 'a' | .. | 'z'digit               ::= '0' | .. | '9'quotedName          ::= '"' ( urlChar | ' ')+ '"'urlChar             ::=alphaNumPM | '.' | '$' | ',' | ';' | ':'                           | '&' | '=' | '?' | '!' | '*' | '~' | '@'                           | '#' | '_' | '(' | ')' | '/' | '%' hex hex                     ; Note: Use the "%" escape technique to insert                     ; single or double quotation marks within a URLalphaNumPM          ::= alpha | digit | signhex                ::= digit | 'A' | .. | 'F' | 'a' | .. | 'f'sign                ::= '+' / '-'number              ::=[sign]unsignedInt['.' [unsignedInt]]unsignedInt         ::= digit+quoted-ISO-date ::= '"' YYYYsep MMsep DD 'T' hh ':' mm[':' ss['.' f+]] Stz '"'     based on the PICS-defined ISO 8601:1988 date and time format, restricted     to the specific form described here:    sep  ::= '.' | '-'    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 59)    ss    ::= two digits of second (00 through 59), optional    f     ::= digit(s) of fractions of second, optional    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 validquoted-ISO-date     denoting November 5, 1994, 8:15 am, US Eastern Standard Time    Notes:      1. The ISO 8601:1988 date and time format standard allows considerably      greater flexibility than that described here.  DSig requiresprecisely     the syntax described here -- neither the time nor the time zone may     be omitted, none of the alternate ISO formats are permitted, and     the punctuation must be as specified here, Except:     2. ISO date described here differs from the PICS 1.1 and ISO 8601:1988      date and time format. PICS 1.1 uses '.' as separators while the ISO     standard calls for '-'.  DSig supports both syntaxes.  PICS 1.1 also     does not support the optional seconds and fractions of seconds fields     and permits minutes to range from 0 to 60.

Signing

Since even a single DSig 1.0 signature label must be represented as a PICS1.1 label list, it is important to understand the structure of such a list.This is explained above in the sectionPICS1.1 labels and label lists. Here again is a structural representationof a PICS 1.1 label 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> ...)             ...      ...   )

Signing a label

The process for signing a label is fairly straightforward whether the labellist containing the label is made up of a single label or a series of labels.First we create anequivalent standalone label for the label to be signed.Then the equivalent standalone label is canonicalized (similar to canonicalizinga PICS label for transmission). Finally, a digital signature is generated,inserted into asigblock extension, and that extension isplaced in the label as a label extension. An equivalent standalone labelcan have at most oneresinfo extension (which it may inheritfrom the service options).

Creating an equivalent standalone label

An equivalent standalone label is a PICS 1.1 label list containing a singlelabel. The single label must be normalized to a form where all optionsare label options (this includes extension options) and thesigblockextension (if present) has been removed.Fromthe example label list above, label 4 could be reduced to the single label:
   (PICS-1.1      <service 2 url>       labels [service 2 option...] OVERRIDDEN BY [label 4 option...]           ratings ([label 4 ratings ...]))
This is not yet an equivalent standalone label. We still need to take intoaccount any modifications denoted by "include" or "exclude" specifiersin thesigblock extension. (If the signature is being createdthe application knows which fields it wants to include in or exclude fromthe equivalent standalone label. The "include" and "exclude" options conveythis information to applications trying to verify the signature.) The resultinglabel list is the equivalent standalone label.

Canonicalization of the equivalent standalonelabel for signing

An Example

The following example illustrates a step-by-step process to sign a PICS1.1 label.

Step 1: creates a PICS 1.1 label

  (PICS-1.1 "http://www.gcf.org/v2.5"     by "John Doe"     labels         for "http://www.w3.org/PICS/DSig/Overview"        on "1994.11.05T08:15-0500"        ratings (suds 0.5 density 0 color 1))
Step 2: compute the hashes of the document, create theresinfoextension, and insert it in the label
  (PICS-1.1 "http://www.gcf.org/v2.5"     by "John Doe"     labels         for "http://www.w3.org/PICS/DSig/Overview"        extension           (optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"             ("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")             ("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="               "1997-02-05T08:15-0500"))        on "1994.11.05T08:15-0500"        ratings (suds 0.5 density 0 color 1))
Step 3: canonicalize the label
( PICS-1.1 "http://www.gcf.org/v2.5" l by "John Doe"  extension ( optional   "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0" (   "http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="    "1997-02-05T08:15-0500" ) ( "http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0"  "aba21241241=" ) ) for "http://www.w3.org/PICS/DSig/Overview"   on "1994.11.05T08:15-0500" r ( color 1 density 0 suds 0.5 ) )
Step 4: sign the canonicalized form of the label and insert it in the label
  (PICS-1.1 "http://www.gcf.org/v2.5"     by "John Doe"     labels         for "http://www.w3.org/PICS/DSig/Overview"        extension           (optional "http://www.w3.org/TR/1998/REC-DSig-label/resinfo-1_0"             ("http://www.w3.org/TR/1998/REC-DSig-label/SHA1-1_0" "aba21241241=")             ("http://www.w3.org/TR/1998/REC-DSig-label/MD5-1_0" "cdc43463463="               "1997-02-05T08:15-0500"))        extension           (optional "http://www.w3.org/TR/1998/REC-DSig-label/sigblock-1_0"              ("AttribInfo"                 ("http://www.w3.org/PICS/DSig/X509-1_0" "efe64685685=")                ("http://www.w3.org/PICS/DSig/X509-1_0"                  "http://SomeCA/Certs/ByDN/CN=PeterLipp,O=TU-Graz,OU=IAIK")                ("http://www.w3.org/PICS/DSig/pgpcert-1_0" "ghg86807807=")                ("http://www.w3.org/PICS/DSig/pgpcert-1_0"                  "http://pgp.com/certstore/plipp@iaik.tu-graz.ac.at"))             ("Signature" "http://www.w3.org/TR/1998/REC-DSig-label/RSA-MD5-1_0"                 ("byKey" (("N" "aba212412412=")                           ("E" "3jdg93fj")))                ("on" "1996-12-02T22:20-0000")                 ("SigCrypto" "3j9fsaJ30SD=")))        on "1994.11.05T08:15-0500"        ratings (suds 0.5 density 0 color 1))
And now we have a valid DSig-1.0 label.

Signing Notes

While PICS allows labels to be truncated to reduce their size, if thisis done in DSig 1.0 after signing, the signature will no longer be valid.An alternative is to distribute an unsigned label with thecompleteoption pointing to a full, signed label. Client software in need of a signedlabel can de-reference thecomplete option's URL to retrieve a complete,signed label.

Appendix 1: Service Resource Information

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 theonly information about the rating service contained within the label itselfis the service's URL. Since the human-readable description pointed to bythat URL is what defines the rating semantics, it is possible under thecurrent scheme for the semantics of the rating service to changeafterthe label has been created without invalidating the label.

If this is a concern, a simple policy in the trust engine that evaluatessignatures could be established to require a separate signature label onthe service description file.

Appendix 2: Transporting DSig 1.0 Labels

DSig 1.0 labels are PICS 1.1 compliant and thus may be transported in thesame way as PICS 1.1 labels. PICS Label Distribution Label Syntax and CommunicationProtocols 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 usesRFC-822 headers, or Separately from the document.

Labels may also exist on their own, referenced via a URL. When the URLis de-referenced it returns an item of type application/pics-labels thatcontains a label list.

The specifications for embedding a PICS label in an HTML document arewell defined. It is possible to use DSig labels in document other thanHTML. To do this, a specification for how the label is embedded in thatdocument type and how the document is normalized for hashing into the labelmust be created.

Appendix 3: Conforming Implementations

In order to conform with this Recommendation, an implementation must support:

Acknowledgments

Reference Materials

Authors Addresses

Yang-hua Chu
Carnegie Mellon University
Department of Computer Science
Wean Hall 5123
5000 Forbes Avenue
Pittsburgh, PA 15213
Email:yhchu@cs.cmu.edu

Philip DesAutels
Formerly: Project Manager, Technology and Society Domain, W3 Consortium
Current Address:
Senior Principal Architect
MatchLogic, Inc.
400 S. McCaslin Blvd.
Louisville, Colorado 80027
Email:philipd@matchlogic.com

Brian LaMacchia
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email:bal@microsoft.com

Peter Lipp
IAIK, University of Technology, Graz
Institute for Applied Information Processing and Communications
Klosterwiesgasse 32/I, A-8010 Graz, Austria
Email:plipp@iaik.tu-graz.ac.at

Change History

1998-06-01 Make the document fullyvalid HTML 4.0
1998-05-27 First version published onhttp://www.w3.org/TR
[8]ページ先頭
©2009-2025 Movatter.jp