[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] FW: [dss-comment] Public Comment
Dear all,
Just some intermixed comments to Carlos' statements....
gonzalezcarlos@netfocus.es wrote:
>*CMS / XML Signatures without (claimed) signing time indication (ESS (for CMS)
>or XAdES(for XML) signed attribute) and without signature timestamp (the
>unsigned attribute in RFC3161) or signature time mark (secure record in the
>server): In this case, as we don't have any information that points out neither
>when the signature was created nor when the signature does exist, I think the
>processing semantics for the DSS request using verification time would be
>"verify this signature as if it were created on the time passed in the
>verification time optional input". (that will imply verifying the certificate at
>that point)
>
>
>
I do not like very much the sentence "verify this signature as if it
were created on the time passed in the verification time optional
input". Instead, I think that the semantics is better expressed by:
"verify if the signature, ***whenever it was created*** WAS STILL VALID
at the indicated time".
This, as Carlos says, will imply verifying the certificate at the
indicated time, BUT also all the rest of validation material
(certification path and CRLs/OCSP responses), and check their
relationship with the dss:VerificationTime.
But one thing is the fact that the steps for verification are the same
and a deffinetively different story is the semantics associated to the
request.
>*CMS / XML Signatures with signing time indication and with signature timestamp
>or signature time mark: After checking that the delay between the signing time
>and the signature timestamp is acceptable under the server policy /
>configuration (we can assume this delta between the two as an "acceptable"
>error), we should verify the certificate at the signature creation time (in this
>case i think VerificationTime is not acceptable).
>
>
I disagree with the last sentence. Why the dss:VerificationTime is not
acceptable? IMHO this would mean that arbitration is not possible with
this protocol. I mean, imagine that the signature is created in t0, and
time-stamped in t0+delta and first verified in t1. Then time passes and
in t2 verifier and signer have a dispute... The verifier claims that he
verified the signature in t1 and it was unvalid. Signer says that this
was not possible. A potential arbitrator **must** be able to request (in
t2) the server to perform a validation as if everything happenned in
t1.... and how far is t1 from t0 and t0+delta would depend on the
environment.... But the issue here is that the arbitrator MUST be able
to include a dss:VerificationTime.
>*CMS / XML Signatures with signing time indication and without signature
>timestamp or signature time mark: In this case, we can update the signature with
>a timestamp or add a time mark, and after that, we can fall back to the second
>case (in this case i think VerificationTime is not acceptable).
>
>
>
I would say that the sentence "we can update the signature with a
timestamp or add a time mark" is made thinking in a certain use case. I
envisage this protocol as something giving service to very different
scenarios. But even if we update the signature, for me it does make
sense to request verification with dss:VerificationTime. Again, this is
the time instant when we want to check if the signature (no matter
whether it has a signature time-stamp or not) was valid.
>*CMS / XML Signatures without signing time indication and with signature
>timestamp or signature time mark: In this case, we don't know the signing time
>(at most, if we have luck, we have a time reference near the signing time). In
>my interpretation, that case is similar to the first, but using an upper bound
>(we know for sure that the signing time can't be after the time reference
>stamped / marked).
>
>
>
I agree in the fact that we do know the upper bound of signing time. As
for the conclusion, I still think that dss:VerificationTime could be a
time completely different to the one indicated in the time-stamp token
or the time-mark.
> <> *CMS / XML Timestamps: In this case, the validity interval for a
> timestamp is
> the period between the time included in the timestamp token plus the
> accuracy /
> error (also included in the TST) and the time when the TSA certificate
> expires (given that we have no revocation of the TSA keys). We can use
> the verification time to instruct the server when to validate, and the
> server should validate the
> TSA certificate using VerificationTime when that time is inside the
> interval
> described above.
> For me it does make sense to add some clarifications to the optional
> input text,
> <>
> What do you think,
>
> Kind regards,
>
> Carlos
>
>
> *On Mon Apr 24 17:02 , "Hal Lockhart" sent:
>
> *
>
> Forwarded from Comment List.
>
> -----Original Message-----
> From: comment-form@oasis-open.org
> <javascript:top.opencompose('comment-form@oasis-open.org','','','')>
> [comment-form@oasis-open.org <javascript:top.opencompose('<a
> href=>','','','')">comment-form@oasis-open.org
> <javascript:top.opencompose('comment-form@oasis-open.org','','','')>]
> Sent: Friday, April 21, 2006 8:40 AM
> To: dss-comment@lists.oasis-open.org
> <javascript:top.opencompose('dss-comment@lists.oasis-open.org','','','')>
> Subject: [dss-comment] Public Comment
>
> Comment from: inma@dif.um.es
> <javascript:top.opencompose('inma@dif.um.es','','','')>
>
> Name: Inma Marín
> Title: IT Consultant
> Organization: University of Murcia
> Regarding Specification: DSS Core Committee Draft 3 (DSS Core Elements)
>
> I have a question regarding element. In the specification it is said that
> this element "instructs the server to determine the signature's
> validity at
> the specified time, instead of the current time". How is this
> verification,
> taking into account the verification time, accomplished?
>
> I suppose that, once the server has checked that the signature is
> valid, he
> checks the signing certificate validation by considering the verification
> time. But, what happens if the signature has a timestamp token? should
> that
> timestamp token be checked taking into account the verification time, too?
>
> Could you be so kind as to clarify the process of verifying a signature by
> checking the verification time, please?
>
> I also noticed that includes a date time but, it is possible to indicate a
> period of time, that is, re-define this element to include before and/or
> after date time? Have you considered this possibility?
>
> Thank you very much in advance.
>
> Regards,
> Inma.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dss-comment-unsubscribe@lists.oasis-open.org
> <javascript:top.opencompose('dss-comment-unsubscribe@lists.oasis-open.org','','','')>
> For additional commands, e-mail: dss-comment-help@lists.oasis-open.org
> <javascript:top.opencompose('dss-comment-help@lists.oasis-open.org','','','')>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> <../parse.pl?redirect=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php>
>
>
>
>
> --------------------------------------------------------------------------------
> Msg sent via @Mail - http://atmail.com/
> --------------------------------------------------------------------- To
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this
> mail. You may a link to this group and all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]