if there is no need for the Created property in the Widgets Signature
spec I suggest we remove it, though keep what we have in the Signature
Properties specification.
regards, Frederick
Frederick Hirsch
Nokia
On Apr 15, 2009, at 5:45 AM, ext Priestley, Mark, VF-Group wrote:
Dear All,
I have a number of comments against the Created property.
As previously communicated on conference calls (although I can't
find the relevant minutes) Vodafone objects to the mandatory use of
the Created property. The main objection is that on mobile devices
the user often does not set the correct time (or more usually the
correct year) which means the device defaults to the time/year of
manufacture. As a result many signatures will contain Created
property values that, as far as the device is concerned, happen in
the future. Without a requirement on a reliable and accurate
timesource, which we are not proposing to introduce, the Created
property cannot be relied on. This combined with the fact that the
use of the Created property is down to the signer, or the signing
scheme within which the signer is operating, mean we think its use
should be optional.
This general comment translates to the specific comments below.
-----
5.1
"Each signature file MUST contain a dsp:Created signature properties
element compliant with XML Signature Properties [XMLDSIG-Properties]
and this specification."
We would like to see the above changed to a MAY.
-----
5.6
"As an example of use, assume a distributor's signing process is
found to have been compromised. Thus, it is not practical to
exchange the signature key. Being able to invalidate all signatures
made before a particular date would be important in such a scenario."
I'm not sure the above is a good example? If the signing process has
been compromised then I may want to invalidate signatures before
this date, but wouldn't I also change my key at this time to stop
creating new compromised signatures? In this case the end-entity
cert should be revoked. My understanding of timestamps was that
their main reason for being is to confirm that a signature was
created at a particular instance in time. This information can then
be used for non-repudiation and/or proof of existence of the signed
object at a particular time in the past. The above use case seems to
be suggesting something else which I do not fully understand.
As previously communicated I think there is a case for an Expires
property, which could be used to state a point in time after which a
Signature is no longer valid (to allow for Signature with shorter
lives than the keys used to create them), but this is different from
the Created property.
My suggestion is to rework the example.
-----
7.2
The sentence:
"A wall clock timestamp SHOULD be placed"
is inconsistent with the text in 5.1 which states the element as a
MUST. If the text in 5.1 is changed to a MAY then the text in 7.2
would be OK but we would prefer to make this a MAY as well.
-----
7.3
"The Created Signature Property value SHOULD represent a wall clock
timestamp earlier than the current time, to the nearest minute. "
It's not clear what the user agent should do to respect this
requirement? We think that this should be left to the signer or
signing scheme to reflect use of the Created property through the
UA's security policy. The text on the Created property could then be
deleted from this section.
-----
9.2.1
"Upon signature generation, if this property is used, the time value
is set to a reference time, as defined by the application. "
Again, this is inconsistent with the text in 5.1 in which the
Created property is mandatory, unless the intention of the text is
to be if the property is used by the UA?
-----
9.2.2
We think it should be made clear that Validation of the Created
property is optional.
Thanks,
Mark
Mark Priestley
Mobile: +44 (0)7717512838
E-mail: mark.priest...@vodafone.com
Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury,
Berkshire RG14 2FN Registered in England No 3802001
