[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] wd-42 errors - <dss:VerificationTime>
Ed,
Nick, All, I
forward my proposal por dss:VerificationTime and dss:ReturnSigningTime. In
my opinion, the final solution should take in consideration the following design
criteria
we should make some effort to inform
the user about what’s happening behind the scenes when validating a
signature, if we don’t want to have every different core-implementing server
to behave differently in an incomprehensible way for the clients. dss:VerificationTime For
me, although these definitions seem to be very obvious,
So,
in the context of a signature verification, WE ALWAYS
HAVE a “verification time”, that sometimes is a “signing
time” (and that’s good) and some times is not (depending of whether
the “signing time” is known or not). I
propose the following:
dss:ReturnSigningTime I
concur with Ed, the ReturnSigningTime
should work only when we have information about the “signing time”
(i.o.c. we should have a “signing time not
found”). I also think that the signature timestamp cannot be accepted as
a “signing time” (it’s an upper bound for it), BUT is very
useful to qualify the signing time (i.e. to set the maximum acceptable error
for the claimed signing time, i.e. via signature policy (signature timestamp
delay)). So I would never return the signature timestamp time in the response,
and use the ThirdPartyTimestamp
attribute of the dss:SigningTime
to signal when a timestamp is used to qualify the signing time (that is, when
we have both signing time information (i.e. SigningTime
attribute) and third-party signature time information (i.e. timestamp / timemark)). I
would refactor the ThirdPartyTimestamp attribute to ThirdPartyTimeInformation to cover the time-mark case,
changing it from boolean to
string and enumerating the possible cases (timestamp, timemark,
none). What
do you think? Kind
regards,
Carlos González-Cadenas De:
ed.shallow@rogers.com [mailto:ed.shallow@rogers.com] Hi Nick, Moving forward, this is good. Comments inter-mixed below. Ed Following from the issue raised by Ed on <dss:VerificationTime>
and its <ed> You need to cover the scenario when the incoming signature has neither
a SigningTime attribute nor a Timestamp of any kind. I would say the server
would have to return "SigningTime not present in signature". In fact
this is the scenario which represents the initial motive behind
having a VerificationTime optional input. The caller wants to know if the
signature (absent of any claimed SigningTime) is/was valid at this particular
point in time. Under the scenario where no signing time of any sort exists and
if the request does NOT contain a dss:VerificationTime, then the DSS
implementation has only 2 choices 1) use current time, or 2) reject request.
Take your pick. This I believe needs to be made clear in the spec, and again
for inter-operability reasons the core should describe default processing.
Again and as always, this can be qualified/overriden/constrainted by the
profiles. </ed> <ed> Forgive me, but I do not know what this is saying. If you are saying
something like "the VerificationTime element should have additional
REQUEST-side qualifiers something like ... - use the SigningTime if present to verify this signature - use the current time if no signing time of any sort exists - use the TimeStampTime in any 3rd party content TimeStampToken included
as a SIGNED ATTRIBUTE that might be present ... then I am all for it !!! In fact these qualifiers themselves could
be subject to extensibility in the spec. This is infinitely better that
hard-defining rules in the specification has to how to handle and report on
VerificationTime and also supports your "local policy applies"
suggestion. Implementations simply extend the above list and inter-operability
is preserved since implementations can simply return "Not Supported"
if they encounter something they can't handle. Lowest common denominator. N.B. Again please note that I totally discount SIGNATURE timestamps as
a legitimate source of SigningTime since they attest and represent the
time before which they know the signature existed and not when it was
created. We are discussing the original SigningTime here, not the
signature-timestamped-at time. I would suggest all references to
signature timestamp as it applies to this discource (i.e. ReturnSigningTime) be
dropped, or left to policy qualifiers (see below) Forgive the diatribe but I believe the ultimate
time-respecting signature tool would ... - pass the DATA/CONTENT to be signed to a trusted 3rd party
timestamping service (e.g. TSA) - include that data and the resultant content timestamp in the scope of
the new signature as Signed Attributes/Properties - produce the signature - send the signature to be verified to a DSS or equivalent service
and include an AddTimestamp option to get a signature timestamp as well Then you would have: - a reference to the time before which you know the data existed - a claimed signing time which would have to be after the 1st time - a time before which the data, the content timestamp, and the
signature existed and was verified, and lastly - a timestamp optionally attesting to this verification and its results P.S. If a non-DSS implementation created the signature e.g. OpenOffice,
Microsoft Office, or some software vendors signing tool, then a
SigningTime attribute may be present and might simply reflect the system
time taken from the desktop PC it runs on. In this case the SigningTime is
simply self-declared. </ed> <ed> That is fine and I agree you absolutely need to confirm the
"window set by policy" as you mentioned. But today's
TSA's provide a timestamp or a time mark applied to a digital signature
value which ONLY attests to the facat that the digital signature was
created before the date included in the time-stamp or time mark. This is
enormously helpful when assessing whether this time is within the certificate
validity period, but does NOTHING in attesting to the claimed SigningTime nor
the data existed before time. </ed>
<ed> I contend we should extend the VerificationTime to allow callers to
qualify what they want checked on the Request side of things. This is how we
stay clear of the policy quagmire and maintain flexibility and extensibility. </ed> <ed>
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]