Re: [dss] FW: [dss-comment] Public Comment

[<gonzalezcarlos@netfocus.es>]

Hi All,

I have introduced this point in the XSS profile I have sent to the group. I will try to summarize the different cases that make sense for me

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

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

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

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

 *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 [comment-form@oasis-open.org] 
> Sent: Friday, April 21, 2006 8:40 AM
> To: dss-comment@lists.oasis-open.org
> Subject: [dss-comment] Public Comment
>
> Comment from: 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
> For additional commands, e-mail: 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

 

---

Msg sent via @Mail - http://atmail.com/