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

From: Santoni Adriano <[email-masked]>
Date: Mon, 9 Oct 2000 09:16:09 +0200

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 09 Oct 2000 17:06:46 -0400

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