[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for verification time and signing time issues found in DSS Core
Dear All, Please find attached a
proposal for the verification time and signing time issues found in DSS core,
in the context of Nick's reference email sent after the last conference call. Comments? Kind regards, Carlos Carlos González-Cadenas ------------------ 1) 4.3 item 3 (line 1481): Add "The server shall
verify the validity of the signature at a particular time (i.e. current time,
assumed signing time or other time), depending on the server policy. This
behaviour MAY be altered by using the optional input <UseVerificationTime>
(see section 4.6.2)" 2) 4.6.2 Optional Input <UseVerificationTime> This element instructs the
server to attempt to determine the signature’s validity at the specified
time, instead of any other time that could be determined there based on any
specific implementation or server policy. Note that in order to perform
the verification of the signature at a certain time, the server MUST obtain the
information necessary data to carry out this verification (e.g. CA
certificates, CRLs) applicable at that time. <CurrentTime>
[Optional] Instructs the server to use its current time
(normally the time associated with the server-side request processing). <SpecificTime>
[Optional] Allows the client to manage manually the time instant used in the verification
process. It
SHOULD be expressed as UTC time (Coordinated Universal Time) to reduce
confusion with the local time zone use. This element enables effectively the possibility of carrying arbitration
processes between a signer and a verifier in the event of a dispute. Profiles MAY define new child
elements associated to other different behaviours. <xs:element
name="UseVerificationTime"/> <xs:complexType
name="UseVerificationTimeType"> <xs:choice> <xs:element
name="CurrentTime"/> <xs:element
name="SpecificTime" type="xs:dateTime"/> <xs:any
namespace="##other"/> </xs:choice> </xs:complexType> If the verification time is a
significant period in the past the server MAY need to take specific steps for
this, and MAY need to ensure that any cryptographic weaknesses over
the period do not affect the validation. This optional input is allowed
in multi-signature verification. 3) New optional input/output
<ReturnVerificationTimeInfo> / <VerificationTimeInfo> This element allows the client
to obtain the time instant used by the server to validate the signature. <xs:element
name="ReturnVerificationTimeInfo"/> Optionally, in addition to the
verification time, the server MAY include in the <VerificationTimeInfo>
response any other relevant time instants that may have been used when
determining the verification time or that may be useful for its qualification. <VerificationTime>
[Required] The time instant used by the server when verifying the signature. It SHOULD be expressed as UTC time (Coordinated Universal
Time) to reduce confusion with the local time zone use. <AdditionalTimeInfo>
[Optional] Any other time instant(s) relevant in the
context of the verification time determination. The Type attribute qualifies the kind of time information included in the
response. The Ref attribute allows to establish
references to the source of the time information, and SHOULD be used when there
is a need to disambiguate several <AdditionalTimeInfo>
elements with the same Type attribute. This specification defines the following base types, whose
values MUST be of type xs:dateTime and SHOULD be
expressed as UTC time (Coordinated
Universal Time). Profiles MAY include and
define new values for the Type attribute. urn:oasis:names:tc:dss:1.0:additionaltimeinfo:signatureTimestamp The time carried inside a timestamp applied over the signature
value. urn:oasis:names:tc:dss:1.0:additionaltimeinfo:signatureTimemark The time instant associated to the signature stored in a secure
record in the server. urn:oasis:names:tc:dss:1.0:additionaltimeinfo:signedObjectTimestamp The time carried inside a timestamp applied over a signed
object. Note that XML Signatures can be produced over multiple objects (via multiple ds:Reference elements), and therefore it's possible to have
multiple timestamps, each one applied
over each object. In this case, the Ref attribute MUST include the value of the
Id attribute of the ds:Reference
element. urn:oasis:names:tc:dss:1.0:additionaltimeinfo:claimedSigningTime The time claimed by the signer to be the signature creation
time. <xs:element
name="VerificationTimeInfo" type="VerificationTimeInfoType"/> <xs:complexType
name="VerificationTimeInfoType"> <xs:sequence> <xs:element
name="VerificationTime" type="xs:dateTime"/> <xs:element
name="AdditionalTimeInfo" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="dss:AnyType"> <xs:attribute name="Type" type="xs:anyURI" use="required"/> <xs:attribute name="Ref" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> This optional input is not
allowed in multi-signature verification. 4) 4.6.5 Optional Input <ReturnSigningTimeInfo> and Output <SigningTimeInfo> This element allows the client
to obtain the time instant associated to the signature creation. Normally a claimed time value
very close to the signing time (included as a signed signature attribute) is
considered as the signing time. <xs:element
name="ReturnSigningTimeInfo"/> Sometimes, depending on the
applicable server policy, this signing time needs to be qualified, in order to
avoid unacceptable measurement errors or false claims, using time boundaries
associated to trustworthy time values (based on timestamps or time-marks
created using trusted time sources). In this case, the server MAY include these
values in the <LowerBoundary> and <UpperBoundary> elements, respectively. Criteria for determining when
a time instant can be considered trustworthy and for determining the maximum
acceptable delays between the signing time and their boundaries (if any) is
dependent from server policy, and therefore not included in this core specification. When there's no way for the
server to determine the signing time, the server MUST omit the <SigningTimeInfo> output. <SigningTime>
[Required] The time value considered by the server to be
the signature creation time. <SigningTimeBoundaries>
[Optional] The trusted time values considered as lower and upper limits for
the signing time. If this element is present, at least one of the <LowerBoundary>
and <UpperBoundary> elements MUST be present. <xs:element
name="SigningTimeInfo" type="SigningTimeInfoType"/> <xs:complexType
name="SigningTimeInfoType"> <xs:sequence> <xs:element
name="SigningTime" type="xs:dateTime"/> <xs:element
name="SigningTimeBoundaries" minOccurs="0"> <xs:complexType> <xs:sequence> <xs:element name="LowerBoundary"
minOccurs="0" type="xs:dateTime"/> <xs:element name="UpperBoundary"
minOccurs="0" type="xs:dateTime"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> This core specification does
not specify the means for obtaining the signing time. This optional input is not
allowed in multi-signature verification. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]