Re: Proposed changes for properties document

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 00:14:45 UTC