Subject: R: R: TSP: Response to the comments raised by Russ Housley

From: Santoni Adriano <[email-masked]>
Date: Tue, 10 Oct 2000 08:57:08 +0200

The response is actually *not* just a CMS message, as Sylvester rightly
pointed out. I just made a trivial mistake in my previous comment. So the
issue of  file extensions is worth discussing (not for long, though). The
issue about MIME type instead is not, because application/timestamp has been
already defined. Perhaps we can think of adding subtypes and arguments to
the MIME content-type (eg to distinguish requests from responses), but
that's probably not so critical an issue. What I strongly believe is that
the draft should now brought on to RFC status asap. Too much time has
passed, and the community needs a stable standard (especially in Europe,
where digital signatures are supposed to be strengthened and prolonged in
time with timestamps); maybe we do not have the most perfect standard of all
time, but perfection is unreachable and unnecessary; let's work with this
one and see what happens.

Adriano

SIA S.p.A.
Milano, IT/EU
https://ca.sia.it

-----Messaggio originale-----
Da: Russ Housley [mailto:[email-masked]]
Inviato: lunedì 9 ottobre 2000 23.07
A: Santoni Adriano
Cc: Denis Pinkas; IETF-PXIX
Oggetto: Re: R: TSP: Response to the comments raised by Russ Housley

If the response is just a CMS SignedData message, then do not assign a new 
MIME type.  Use the ones already defined in RFC 2633.

Russ

At 09:16 AM 10/09/2000 +0200, Santoni Adriano wrote:
>Is it really useful to tell apart requests vs. responses? From the TSP
>server viewpoint, an incoming message is supposed to be a request and it
>will be processed based on that obvious assumption. So the single
>content-type "application/timestamp" should suffice, IMO. As to file
>extensions, I think it's pretty irrilevant; however, as the response is a
>CMS SignedData message, I presume ".P7M" would be a proper file extension
>for it. As to the request...I do not know; why not ".TSR" ?
>
>Adriano Santoni
>
>SIA S.p.A.
>Milano, IT
>https://ca.sia.it <https://ca.sia.it>
>
>
>-----Messaggio originale-----
>Da: Russ Housley [mailto:[email-masked]]
>Inviato: venerdì 6 ottobre 2000 20.11
>A: Denis Pinkas
>Cc: IETF-PXIX
>Oggetto: Re: TSP: Response to the comments raised by Russ Housley
>
>
>Denis:
>
>I am happy with your response to number 3.  Now, for number 10.  How about
>something like the following:
>
>
>For the <list your types here> MIME types, implementations SHOULD include
>the optional "name" and "filename" parameters.  Including a file name
serves
>helps preserve type information when timestamps are saved as files.  When
>these parameters are included, a file name with the appropriate extension
>SHOULD be selected:
>
>
>
>   MIME Type                     File Extension
>
>
>
>     <your request type>           .<your request extension>
>
>
>
>     <your response type>          .<your response extension>
>
>
>
>     ...
>
>
>
>In addition, the file name SHOULD be limited to eight characters followed
by
>a three letter extension. The eight character filename base can be any
>distinct name.
>
>
>
>Russ
>
>
>At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:
>
>
>Russ,
>
>Thank you for your response.
>
>The only remaining issues are numbered 3 and 10. See my comments embedded
>below.
>
> > Denis:
> >
> > Thank you for addressing my concerns.  I address each of your proposed
> > resolutions below.
> >
> > TECHNICAL
> >
> > 1 and 2. Your proposed resolution resolves my concern.
> >
> > 3. I am not satisfied.  I accept that this is not the place to define
TSP
> > policy or practice statements.  However, I do not think that the RFC
2459
> > syntax is appropriate for use in the TSP context.  Also, you ignored my
> > concern regarding qualifiers.  RFC 2459 contains:
> >
> >     PolicyInformation ::= SEQUENCE {
> >          policyIdentifier   CertPolicyId,
> >          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
> >                                  PolicyQualifierInfo OPTIONAL }
> >
> > I would prefer a structure that said "TSAPolicyId" instead of
> > "CertPolicyId." Using "CertPolicyId" in this context will, in my
opinion,
> > confuse matters.  Also, I would like to omit policy qualifiers
> > altogether.  I do not like them in certificate policies, and I would
like
> > to avoid them in TSA policies.
>
>I had corrected the text but I did not understood your were also requesting
>an ASN.1 change.
>Sorry about that misunderstanding. I agree with your request and I have
done
>the changes, i.e:
>
>  TSAPolicyId ::= OBJECT IDENTIFIER
>
>and in the request:
>
>  reqPolicy       TSAPolicyId    OPTIONAL,
>
>while in the response:
>
>  policy          TSAPolicyId,
>
> > 4 through 9. Your proposed resolution resolves my concern.
> >
> > 10. This comment is related to comment number 9, but it has absolutely
> > nothing to do with flow.  It has to do with the specification of file
> > naming conventions.  I would like to see a section that is parallel to
RFC
> > 2633, Section 3.2.1.  Further, I think that that file naming conventions
> > should be labeled SHOULD, not MUST.
>
>I understand the last sentence of your request, but I'm not sure what you
>are requesting for the remaining of it-- all the text in Section 3.2.1 of
>2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
>would like to see something similar to the paragraph regarding base name
>(i.e., 8 characters, can be any distinct name, ..) although many systems
>today are no more limited to 8 characters. :-) If you want some specific
>addition, would you be able to propose it ?
>
>Regards,
>
>Denis
>
> > 11. Fair enough; CMP should include a state machine too.  I believe that
> > many interoperability issues can be avoided by specifying the state
> > machine.  I am not going to hold things up over this issue.
> >
> > 12 and 13. Your proposed resolution resolves my concern.
> >
> > EDITORIAL
> >
> > 14 and 15. Your proposed resolution resolves my concern.
> >
> > 16. Okay.  As I said, this is an editorial comment, so I can live with
the
> > current text.
> >
> > 17 through 24. Your proposed resolution resolves my concern.
> >
> > Russ