Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

From: Denis Pinkas <[email-masked]>
Date: Mon, 14 Feb 2000 14:38:51 +0100

Keeping the flames from Mr Manuel Heras-Gilsanz out of the debate,
let us see how we can modify the draft for "the benefit of
interoperability with alien civilisations !! ".    :-)

My role, as the lead editor, is to try to obtain a working group
consensus. Thanks to Tom Gindin for his proposal leading the way to
a consensus.

We need to solve three issues if we want to guarantee a smooth
co-existence of the two standards.

1. the form of the request,
2. the error codes attached with the response,
3. the form of the response.

1. The form of the request

Tom's proposal, agreed by Roland, is for ISO to add an optional
mechanism parameter that will be defaulted to the IETF mechanism,
i.e. digital signature.

This allows the same server to listen to the same port and respond
to IETF conformant requests or ISO conformant requests, provided
that ISO adopts the same parameters of the request that the IETF
defines.

In practice we will have the ISO protocol as a superset from the
IETF protocol. If someone wants to speak of one protocol but not the
other how should we name it ? Since everything is very simple with
our WG (think about SCVP), why don't we rename it: "Simple Time
Stamping Protocol (STSP)" ?

ISO could then call their version something like "eXtended Time
Stamping Protocol (XTSP)"or, whatever they like, provided that the
name is different.

2. The error code attached with the request or the response

It is anticipated that ISO will need a few error codes that are not
all yet defined. These error codes must not collide. The best way I
see to deal with this issue is that we reserve some error codes in
our specification and let them know that they are exclusively to be
allocated by ISO SC 27. We do not even need to say in the
specification that they are for ISO. The IETF WG (and chairs) will
remember not to use them for IETF purposes. However we need to know
how many they anticipate. Five, ten ?

3. The form of the response

The response may be quite different, so there is no need for
alignment. However, it will be certainly useful to be able to
reference the two data structures from the response so that they can
be used in other data structures. We have done this for our data
structure in the annex A where we define a Signature Timestamp
attribute using the following object identifier:

id-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) 
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa (2)
id-aa-timeStampToken (14)}

ISO might wish to define another OID for their data structure which
will have to bear a name different from "SignatureTimeStampToken ".
I would suggest that they use someting like
"SignatureExtendedTimeStampToken" or anything else they wish,
provided that it is different.

Other matters: Response to Tom's questions

I answered to Tom's first question (should the mechanismNotSupported
bit be added to PKIFailureInfo in the PKIX draft?) by proposing to
reserve a few error codes (to ISO).

The second question raised by Tom, was: "Should the ISO ASN.1 format
for TimeStampReq and TSTInfo be documented in an appendix to the
PKIX draft, pointing out that these are fully compatible with the
PKIX definitions within the existing draft?

The answer to that question is fairly simple. No, because we can't !
We do not know yet what they will be, be since the ISO process is
still long and no one can predict what will be the final result. We
cannot wait until the completion of the ISO work to publish our
standard.

Conclusion

Besides the other minor fixes around the ASN1 syntax, I believe that
we are now close to a consensus. I would like to hear about the WG
to see if this opinion is shared and then I will post to the mailing
list the changes that I propose as a result of the last call.

Please, leave flames out of the debate.  :-)

Regards,

Denis

---

From: Roland Mueller <[email-masked]>
Date: Sun, 20 Feb 2000 15:42:12 -0600

Hello Denis,

The ISO working group would like to thank the members of the IETF
working group for their efforts toward producing an interoperable
timestamping standard.  We are pleased to incorporate aspects of the
recent IETF proposal into our work in the interests of developing a
truly interoperable standard.

1. Request message

We concur with the IETF proposal for making the 'mechanism' field of
the interoperable request message an optional field, placed in the
structure at a position selected by the authors of the IETF draft
document.  We feel the selection of a default value for the field is a
matter of local policy and hence should be determined by the local
policy statement of the TSA.

2. Error codes

We concur with the IETF proposal for setting aside a range of error
codes for future use by the SC 27 group.  At this time only one
additional code is anticipated, however setting aside a quantity of
error codes for use by SC 27 is a quite reasonable approach.

3. Reply message

The latest IETF proposal suggests that replies generated by the
systems are quite different, and hence cannot be aligned.  The ISO
working group would respectfully disagree here, as the replies are
actually quite similar, and we believe they can be aligned with a
minimum of effort.

The timestamp information returned by both proposals is actually
identical, as the ISO proposal has chosen to adopt the IETF TSTInfo
structure, with an optional mechanism field corresponding to the one
agreed to above.  Since both proposals use the same TSTInfo structure,
time values are interoperable, hash codes and algorithms are
interoperable, policy and mechanism identifiers are interoperable.
Both proposals encapsulate the TSTInfo structure in the TimeStampToken
datatype; the only remaining difference is in syntax of that datatype.

The IETF draft defines the TimeStampToken datatype as a CMS SignedData
construct, where the TSTInfo structure is wrapped inside the CMS
structure.  CMS SignedData constructs can be used in two different
ways, however; as an encapsulation and as an external signature.  The
encapsulation mode means the data upon which the signature is computed
is wrapped inside the CMS structure, whereas the external signature
mode leaves the data external to the CMS structure.  Both modes provide
equivalent security, both are directly supported and specified within
the CMS specification [RFC 2630, page 9].

The ISO proposal is to simply use the CMS construct as an external
signature rather than as an encapsulation.  The ISO proposal thus
defines the 'TimeStampToken' data type as follows:

TimeStampToken ::= SEQUENCE {
        tspData         TSTInfo,
        tspSignature    OCTET STRING }

The CMS SignedData construct used as an external signature is
DER-encoded in the tspSignature field.  In effect both proposals
accomplish the same thing; the TSTInfo structure is signed, and the
signature information is encapsulated in a CMS SignedData construct.

Defining the TimeStampToken type as proposed above allows both IETF
and ISO mechanisms to generate fully interoperable tokens, while in
addition allows the ISO to develop those additional mechanisms it
has identified for support.

On a final note, aligning the standards as proposed above has the
added benefit of making the token embedding technique detailed in
Annex A of the IETF draft also completely interoperable.  No changes
to that Annex are required.