RE: [dss] Time-stamping issue closed?

["Edward Shallow" <ed.shallow@rogers.com>]

Hi Nick,

  As requested in your summary to Stephan today, here are my comments on the
CMS Timestamping-related sections:

(Note: I'll send the XML Timestamping feedback in a separate post as this
one is getting long and it is late on Friday here)

General
*******

Here is the exhaustive list of permutations and combinations of PROTOCOL
(Sign or Verify), timestamp signature TYPE (CMS or PKCS7), timestamp
signature SCOPE (content timestamp or signature timestamp), and finally
timestamp LOCATION (embedded or standalone). I have traced them back into
the document and illustrated which sections address them or where they are
not addressed.

Here you go:

PROTOCOL/TYPE/SCOPE/LOCATION Combinations
*****************************************

Combination 1 - Sign/CMS/Content/Standalone

--> covered by the Timestamp Profile but inadequately/poorly explained. The
basic requirement to simply create a standalone timestamp (as covered by the
Timestamp profile) should be referenced in the core. I would this reference
to section 3.4. For example: Users wishing to create a signature whose
SignatureType is a timestamp SignatureType as per section 7.1, should refer
to the Timestamp Profile of this spectification.   


Combination 2 - Sign/CMS/Content/Embedded

--> MISSING FROM THE CORE. Should be added to section 3.5.2.1. This has been
done. See below. This option represents a timestamp as an AUTHENTICATED
attribute created BEFORE the act of signing. In essence it is a
SignedProperty of the resultant signature being created as part of this
SignRequest. We could force the user to treat this case by using
<SignedProperties>, but this would be inconsistent treatment given support
for AddTimestamp, would force 2 calls, and would be orthogonal. 


Combination 3 - Sign/CMS/Signature/Standalone

--> covered by the Timestamp Profile but inadequately/poorly explained. If
the user is passing in a DocumentHash whose content was derived from the
signature value of some signature, then they would essentially be creating a
Combination 3. Again this is not adequately explained in the Timestamp
Profile.


Combination 4 - Sign/CMS/Signature/Embedded   --> covered in section 3.5.2.1
entitled <AddTimestamp>. Small textual errors require fixing. See below.


Combination 5 - Verify/CMS/Content/Standalone

--> should be covered by the Timestamp Profile but it is inadequately/poorly
explained. Section 4.1.3 of the Timestamp Profile states that only
DocumentHash should be sent in on a Verify timestamp request. This is
inconsistent and different than what is advocated for timestamp verification
as explained in Section 4.3.2.1 See Lines 1440-1441 where it is advocated
that the orginal data that was timestamped be passed in NOT just the hash.
This is a question of integrity and what the practice of timestamp
verification should or should not entail. I believe what is stated in
Section 4.3.2 is closer to industry expectations.    


Combination 6 - Verify/CMS/Content/Embedded   --> partially covered in
Section 4.3.2.1 By definition this timestamp is an authenticated attribute
and some integrity would be achieved by simply verifying the enclosing
signature. However the need for the MessageImprint in the timestamp to be
cryptographically bound to the signature hash value should be better
explained in this section. (see my Suggestion in Point 6 and 7 below).  


Combination 7 - Verify/CMS/Signature/Standalone   --> should be covered by
the Timestamp Profile but it is inadequately/poorly explained.


Combination 8 - Verify/CMS/Signature/Embedded   --> covered in section
4.3.2.1

(Note: There is an equivalent 8 Combinations for XML. I'll send the feedback
separately but the feedback is similar.)

In general all CMS standalone timestamps (as reflected above) are/must be
addressed by the Timestamp Profile. All CMS embedded timestamps must be
addressed by the core due their close tie with the enclosing signature.


Specific
********

Point 1) Add level 4 Headings (e.g. 4.3.2.1) to the Table of Contents. It
presently only shows Headings down to 3 levels (e.g. 4.3.2)

Point 2) Section placement is incorrect. Non-sequitor as follows:

4.3 Basic Processing for XML Signatures
    4.3.1 Multi-Signature Verification
    4.3.2 Timestamp Verification procedure
          4.3.2.1 Processing for CMS RFC 3161 timestamp tokens
          4.3.2.2 Processing for XML timestamp tokens

4.3.2.1 deals with CMS yet it is in a section reserved for XML

Point 3) Add a comment after Line 977 "The optional Type attribute of
AddTimestamp may be omitted if it is the same as the SignatureType.

Point 4) As it pertains to Line 985 starting with "... , the client should
..." the <AddTimestamp> OptionalInput of the Verify protocol section is
missing from the core document.

Point 5) Line 980 remove "passed in on the request" and replace with "just
created"

Point 6) On Line 1458 remove "If the timestamp is a standalone content
timestamp, then simply verify it." replace with "Similarly if the timestamp
is embedded as an authenticated attribute and represents a content
timestamp, extract the timestamp token and verify it."

Point 7) Line 1439-1441 remove "additional data passed ... Right up until
the end of the paragraph" and replace with "content that was used to derive
the MessageImprint hash value. The content timestamp which is embedded as an
authenticated attribute has a MessageImprint value that was derived from the
eContent of the signature itself."

Point 8) Line 1434 change "CMS RFC 3161 timestamp tokens" to "CMS RFC 3161
embedded timestamp tokens" The reason for this change is the assumption that
all treatment of standalone timestamps is dealt with in the Timestamp
profile.

Point 9) Line 1468 remove "For a content timestamp, this data must be passed
in as a separate InputDocument." and replace with "For a content timestamp
which is embedded as an authenticated attribute, this data is the eContent
of the enclosing signature. The special case where the enclosing signature
is detached is not directly supported by the core. It is felt that it would
be unlikely that a signature would contain an embedded content timestamp yet
leave the signature content detached from the signature itself. This
scenario could be addressed by a profile.
  
Cheers,
Ed

P.S. I guess I should volunteer to fix up the Timestamp Profile, but I'll
wait for the next call to discuss this.


-----Original Message-----
From: Nick Pope [mailto:pope@secstan.com] 
Sent: January 23, 2006 1:04 PM
To: Nick Pope; Ed Shallow; Juan Carlos Cruellas; Konrad Lanz
Cc: Stefan Drees; OASIS DSS TC
Subject: RE: [dss] Time-stamping issue closed?

Major apologies to Stefan - I mean to say:

 Stefan has NOW updated the Core with the restucturing of the Core as
discussed at the last meeting.  Can you confirm that this now closes the the
Time-stamp issue.


Nick

> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: 23 January 2006 17:56
> To: Ed Shallow; Juan Carlos Cruellas; Konrad Lanz
> Cc: Stefan Drees; OASIS DSS TC
> Subject: [dss] Time-stamping issue closed?
>
>
> Dear All,
>
> Stefan has not updated the Core with the restucturing of the Core as 
> discussed at the last meeting.  Can yu confirm that this now closes 
> the the Time-stamp issue.
>
> Nick Pope
> Mob: +44 (0) 777 567 2590
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>




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