[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] FW: [dss-comment] Public Comment
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)
<ed>
Possible with conventional CMS/PKCS7, but the SigningTime attribute is mandated by ETSI 101 733 (and RFC3126).
See 6.1 ... " - SigningTime; This must always be present (see clause 3.7.3) ..."
Thus, this is only a problem for the core. See below.
</ed>
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)
<ed>
Yes, I think you are correct. What you seem to be saying here is "If nothing is present to use when comparing against certificate validfrom and validto, then the DSS implementation would use the dss:VerificationTime passed in on the request.
Agreed. Furthermore, if all of the above is true, but the request does NOT contain a dss:VerificationTime, then the DSS implementation has only 2 choices 1) use current time, or 2) reject request. This I believe needs to be made more clear.
</ed>
*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).
<ed>
Agreed. I would make one minor change to the above assertion. If both SigningTime and a standard signature timestamp (i.e. 1.2.840.113549.1.9.16.14) are present, then use the time in the token to assess validity against the certificate, not both the SigningTime and the timestamp time. Clearly the signature timestamp represents a more authoritative time, and the application of the signature timestamp in the first place would have caught any abnormalities in the SigningTime then. That is what TSAs do. You bring up another interesting point re: server policy. You are stating, or more accurately implying, that a DSS core implementation ought to have a policy covering timestamp creation. This also should be mentioned in the text of the core.
</ed>
*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).
<ed>
A few issues here. Let me repeat your premise. SigningTime present but signature timestamp not. A DSS implementation will only update the signature being verified if it is asked to do so. This is the purpose of the AddTimestamp OptionalInput on Verify. So if the requester has not asked for a timestamp, what should the server do. I would wager that the SigningTime present is unauthoritative and may have been generated outside of DSS. Therefore I believe allowing a dss:VerificationTime seems appropriate here. However we cannot unilaterally give legitimacy to a SigningTime which is present by adding a timestamp when the user has provided a dss:VerificationTime. I would reject in this case the request to AddTimestamp when a dss:VerificationTime is present and a SigningTime is present. I think this is what you are getting at.
</ed>
*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).
<ed>
This one is more legitimate as we can assume that the DSS implementation has performed the appropriate edits when it first embedded the signature timestamp. So seeing it there makes things easier. Use its claims and validate as described in the core. I would again ignore dss:VerificationTime when a signature timestamp is present (or we could reject ???).
</ed>
*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.
<ed>
I think this is a simpler case of the timestamp present scenario. I believe we cannot legitimize anything more than what is already represented in the elementary timestamp which all the ingredients to allow verification. I would say dss:VerificationTime is not acceptable here.
</ed>
For me it does make sense to add some clarifications to the optional input text,
What do you think,
<ed>Good stuff.</ed>
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]