Re: Proposed changes for properties document

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 Thursday, 19 February 2009 00:11:12 UTC