OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] Proposal for verification time and signing time issues found in DSS Core


Vey good.
 
A few minor suggestions:
 
-----Original Message-----
From: Carlos González-Cadenas [mailto:gonzalezcarlos@netfocus.es]
Sent: 21 May 2006 13:54
To: dss@lists.oasis-open.org
Subject: [dss] 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
Chief Security Officer

netfocus
Diagonal 188-198 Planta 2
08018 Barcelona
tel: 902 303 393
fax: 902 303 394
gonzalezcarlos@netfocus.es
www.netfocus.es

 

 

------------------

 

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.

 

Suggest re-word to clarify english and align with wording used in (1)
 
"This element instructs the server to attempt to determine the signature's validity at the specified time, instead of a time determined by the 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.

 
To follow convention for notes reword as:
 
"Note: In order to ..."
 
Also delete " data" to read "obtain the information necessary to carry out ....."
 

 

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

 

I suggest that this sentence "This elemenet ...arbitration ..." is deleted as arbitration is a whole new issue which mainly involves factors outside our scope (e.g. independence).

 

 

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.

 

 

Given it is allowable for a client to choose the verification time for a multi-signature scenario, I see not reason for this to be dissallowed for the server.  I suggest:
 
"In the case of multi-signature verification it is a matter of server policy as to whether this element is supported."

 

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.

 

Suggest reword:
 "Note: The signing time may be derived, for example, from a claimed signing time signed signature attribute."

 

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

 

This could be a client policy issue.  Replace

 

 is dependent from server policy,  

 and therefore not included in this core specification.

"is outside the scope of this specification."

 

 

 

When there's no way for the server to determine the signing time, the server MUST omit the <SigningTimeInfo> output. 

 

I would prefer an explicit response "Could not determine signing time." rather than a non reponse which looks like a protocol error.

 

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

 

Suggest omit this sentence "The core ... does not specify..." as this is in slight contradiction to the earlier statement about claimed 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]