Re: Proposed changes for properties document

Agree

regards, Frederick

Frederick Hirsch
Nokia



On Feb 19, 2009, at 7:14 PM, ext Thomas Roessler wrote:

> I'd propose that, additionally, we simply call the properties document
> "XML Signature Properties" -- it's beyond just requirements and design
> at this point.
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>
> On 19 Feb 2009, at 01:11, Thomas Roessler wrote:
>
>> I've tried to merge most of this into the current draft, plus some
>> minor editorial wordsmithing.
>>
>> Some additional questions and remarks:
>>
>> - I see a remark in there that calls out the namespace URI as
>> subject to change.  Is it?
>>
>> - I've changed the reference to XML Signature to the dated first
>> edition.  We have a separate reference for the second edition.  This
>> probably needs clean-up across all the specs, but isn't critical for
>> the first draft.
>>
>> Specifically....
>>
>>> Looks good - a couple of minor comments below but probably don't
>>> need to be addressed for FPWD if not enough time.
>>>
>>> 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.
>>>
>>> s/Validtion/Validation
>>>>> Profiles MUST specify what application behavior is expected in
>>>>> case an unknown profile URI is encountered.
>>>
>>> ... and if more than one Profile element URI is recognized. This is
>>> probably not a good idea (it may be better to define a new URI)
>>
>> Well, I could see a number of uses for having multiple, orthogonal
>> profiles.  I've added the following: "Profiles MUST specify whether
>> profile URIs defined by them can coexist with other instances of the
>> profile property element."
>>
>>> but maybe in some cases it makes sense to support more than one
>>> profile URI if the behavior is independent of each other. In any
>>> case it should be specified as to if this is legal or not.
>>>
>>>> - 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.
>>>
>>> same comment as above.
>>>
>>>> - 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.
>>>
>>> - this property should probably have two times: a notBefore and
>>> notAfter time
>>> (ex: signing a check with a date in the future).
>>>
>>> - profile should also state if duplicate instances are ignored or
>>> cause validation failure
>>>
>>
>> Propose:
>>
>>> An expiry property with an <emph>untimezoned</emph> time value MUST
>>> NOT be considered valid.  If multiple instances of this property
>>> are found on a single signature, then applications MUST NOT deem
>>> any of these properties valid.
>>
>>
>>>> - 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.
>>>
>>> - shouldn't the timestamp be optional? Are there any use cases
>>> where nonces must be retained indefinitely (or some really long
>>> time)?
>>
>> I have no strong view on this point; I hope we can take this up
>> after the FPWD is published.
>>
>>>> - 5.4.2 Validation (for ReplayProtect property)
>>>
>>> - profile should also state if duplicate instances are ignored or
>>> cause validation failure
>>>
>>>> *Add* the following:
>>>>> Behavior of applications when an invalid property is encountered
>>>>> is application-specific.
>>>
>>> Shouldn't the above sentence be for all properties and not just the
>>> ReplayProtect property? To cover my comments above about duplicate
>>> properties, you could change this to:
>>>
>>> Behavior of applications when an invalid property or more than one
>>> recognized property is encountered is application-specific.
>>>
>>>> I wonder whether we want to say anything about the amount of time
>>>> for which nonces are kept.
>>>
>>> Seems to be something the profiles should specify.
>>>
>>>> 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.
>>>
>>> Hmm, not sure would have to think about it some more.
>>>
>>> --Sean
>>>
>>
>

Received on Friday, 20 February 2009 13:48:18 UTC