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

From: Russ Housley <[email-masked]>
Date: Thu, 05 Oct 2000 13:49:20 -0400

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.

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.

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: Denis Pinkas <[email-masked]>
Date: Fri, 06 Oct 2000 16:26:56 +0200

Russ,

Thank you for your response.

The only remaining issues are numbered 3 and 10. See my comments embedded
below.
 
> 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,

> 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

---

From: Russ Housley <[email-masked]>
Date: Fri, 06 Oct 2000 14:11:18 -0400

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,

The only remaining issues are numbered 3 and 10. See my comments
embedded

below.

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

and in the request:

reqPolicy
TSAPolicyId    OPTIONAL,

while in the response:

policy
TSAPolicyId,

> 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

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 10 Oct 2000 13:25:48 +0200

Russ,

> 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

I did not realized first why you were leaving the types empty, :-)
... until I found the acronym collision between
application/timestamp-request (TSR) and application/timestamp-response
(TSR).

Here is a proposal to solve this acronym collision:

For the application/timestamp-query and application/timestamp-reply 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

  application/timestamp-query            .TSQ
  application/timestamp-reply            .TSR

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.

Would that text be OK with you ?

Regards,

Denis

>      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>
> 
>          ...
> 
>      followed by a three letter extension. The eight character filename
>      base can be any distinct name.
> 
> Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Oct 2000 14:28:26 -0400

Denis:

This is fine with me.

Russ