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

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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