W3C home > Mailing lists > Public > public-xmlsec@w3.org > February 2009

Re: Proposed changes for properties document

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Tue, 17 Feb 2009 18:27:44 -0500
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Message-Id: <8CB8B38B-DD34-4495-B15C-034FFCBA7B63@nokia.com>
To: ext Thomas Roessler <tlr@w3.org>
Thanks for these suggested changes. By timezoned I assume you mean  
times must be expressed in UTC, if so would it be more obvious to  
state that times must be expressed as UTC (although timezoned is clear  
in conjunction with schema reference).

Perhaps we can defer changes to the details of nonces after additional  
review, or do others have concrete suggestions?

regards, Frederick

Frederick Hirsch
Nokia



On Feb 17, 2009, at 5:48 PM, ext Thomas Roessler wrote:

> I'd suggest that we change the properties document as follows
> (probably some more fine tuning makes sense):
>
> - 5. Rename "Design" -> "Signature Properties"
>
> - Add the following text:
>
>> This section defines a number of signature properties that are
>> expected to be commonly used in profiles.  For each property, an
>> intended processing model is suggested.  However, the details of
>> processing each of these properties will depend upon individual
>> application scenarios, and MUST be specified in any profile that
>> makes use of the properties defined in this document.
>
> - 5.1.2 Validation (for profile property)
>
> Replace with:
>
>> Applications are expected to use this property to verify an
>> assertion that a signature is meant to fulfill a specific profile.
>> Validtion behavior is application-specific.
>
>> Profiles MUST specify what application behavior is expected in case
>> an unknown profile URI is encountered.
>
>
> - 5.2.2 Validation (for usage property)
>
> Replace with:
>
>> Applications are expected to use this property to identify a
>> specific usage for a document (e.g., document signing vs code
>> signing).  An unexpected usage URI will frequently be reason for
>> applications to deem a signature invalid for the intended usage.
>
>> Profiles MUST specify what application behavior is expected in case
>> an unknown usage URI is encountered.
>
> - 5.3 (Expires property)
>
> Insert the following after the schema:
>
>> Expiration times MUST be given as timezoned values. (See section
>> 3.2.7 of [XML Schema part 2].)
>
> http://www.w3.org/TR/xmlschema-2/#dateTime
>
> - 5.3.2 Validation (for expires property)
>
> Replace with:
>
>> Applications are expected to use this property to identify the
>> expiry date of a signature.  Evaluation of this property is with
>> respect to an application defined reference time (possibly wall
>> clock time, possibly a time that is determined otherwise).  A
>> property value that is later than the reference time will frequently
>> be reason for applications to deem a signature invalid with respect
>> to the reference time.
>
>> Profiles MUST specify what reference time should be used when
>> interpreting this property.
>
> - 5.4 ReplayProtect property
>
> Add after the XML schema snippet:
>
>> Timestamp values MUST be timezoned. A ReplayProtect property with an
>> untimezoned time stamp MUST be treated as invalid.
>
>
> - 5.4.2 Validation (for ReplayProtect property)
>
> *Add* the following:
>
>> Behavior of applications when an invalid property is encountered is
>> application-specific.
>
> I wonder whether we want to say anything about the amount of time for
> which nonces are kept.  I also wonder whether it makes sense to drop
> the nonce encoding (the value is an opaque string, after all), and
> simply make it a base64 encoded octet-stream, with a (specified)
> minimum supported length.  I'd suggest something outrageous like 512
> bits for that.
>
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
Received on Tuesday, 17 February 2009 23:28:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:57 GMT