Re: Proposed changes for properties document

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) 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

> 
> - 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)?

> 
> - 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 Wednesday, 18 February 2009 18:03:54 UTC