Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)

From: Sarbari Gupta <[email-masked]>
Date: Thu, 20 May 1999 09:10:32 -0400

I would be willing to accept a two-layer scheme where the timestamp
token (without nonce and status) uses the SignedData structure, and the
other information (nonce, status, etc.) passes unsigned with the
assumption that (when necessary) there exists a secure transport
mechanism (such as SSL/TLS). 

This scheme does make the I-D a bit simpler. However, this still implies
the use of separate certificates (one for timestamp token signing and
the other for authentication,) unless the same certificate/key can be
used for authentication as well as timestamping.  

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
[email-masked]
=================================

-----Original Message-----
From: Michael Zolotarev [mailto:[email-masked]]
Sent: Wednesday, May 19, 1999 9:19 PM
To: 'Sarbari Gupta'; [email-masked]
Cc: 'Robert Zuccherato'; 'Denis Pinkas'; 'Peter Sylvester'; 'Stephen
Farrell'
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)

Sarbari wrote:
---------------------------------------------
4) The current definition of the TSTInfo data structure seems to be
trying to kill two birds with a single stone. It seems that the TSA
response can potentially contain:
	- the signed timestamp token
	- other information related to the response such as status,
nonce, etc.
As such, it would seem logical to use a nested SignedData structure to
signify the response from the TSA. The first level SignedData would
contain the status, nonce, and (when status = SUCCESS) the timestamp
token. The timestamp token itself would use another SignedData structure
to hold the relevant data of the timestamp token. The actual timestamp
token is for wider distribution - I don't think it is a good design
approach to overload it with transient information such as a nonce.

In fact, to be a purist, a failed timestamp request is not generating a
timestamp token, so the error message and the nonce should be signed by
a key that is different from the key used to sign a good timestamp
token. This is further reason to support nested SignedData structures
each of which can be signed by a different key.
-------------------------------------------------

This is yet another voice in support of the idea we have been tossing
around
for a few days (in both private and public mails). The reasons for
splitting
the message into data and status were the same as you have come up with.
In fact, a similar approach has been proposed by the AC draft.

For your reference:

> The whole structure turns into the following:
>   TSResponseMessage ::= SEQUENCE {
>        statusInfo   PKIStatusInfo -- from [CMP]
>        tsoken       SignedData  OPTIONAL -- TSTInfo with NO statusInfo
inside there
>   }

and another one

> >  TSResponseMessage ::= CHOICE {
> >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo
inside
there
> >       errorInfo [1]  ErrorMsgContent -- from [CMP]
> >  }

Sarbari actually went further, suggesting an extra signed layer around
the
whole lot. Well, this may answer the argument that sending a non-signed
status is a bad thing. Making it optional (leave it to the transport?,
using
ContentType? )...

Do you (the Group) think that the subject MAY deserve a broader
discussion?

MichaelZ

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 10:25:07 -0400

Michael;

As I stated in my previous message, I really don't see the advantage of
having a nested structure.  You suggest here that the outer layer
(containing the error information) be optionally unsigned and rely on other
mechanisms to provide security.  I am extremely uncomfortable with this.  If
we are developing security standards we should make them secure, and not
assume that people will do the right thing at the transport level.  We have
never made such an assumption, and doing so would be a major change of focus
for this document.

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> > >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo inside
> there
> Sarbari actually went further, suggesting an extra signed layer around the

---

From: Sarbari Gupta <[email-masked]>
Date: Thu, 20 May 1999 10:50:20 -0400

Robert,

The advantage is that you do not bundle up (just because it is
convenient at the programming level) transient information into a long
term entity such as the TST. When that TST is sent out to (let's say) a
1000 recipients, what utility is served these 1000 individuals by the
nonce and the status fields?

- Sarbari

-----Original Message-----
From: Robert Zuccherato [mailto:[email-masked]]
Sent: Thursday, May 20, 1999 10:25 AM
To: 'Sarbari Gupta'; [email-masked]; [email-masked]'
Cc: 'Denis Pinkas'; 'Peter Sylvester'; 'Stephen Farrell'
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)

Michael;

As I stated in my previous message, I really don't see the advantage of
having a nested structure.  You suggest here that the outer layer
(containing the error information) be optionally unsigned and rely on
other
mechanisms to provide security.  I am extremely uncomfortable with this.
If
we are developing security standards we should make them secure, and not
assume that people will do the right thing at the transport level.  We
have
never made such an assumption, and doing so would be a major change of
focus
for this document.

	Robert.

inside
the

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 12:54:37 -0400

Okay, you do get that advantage.  But at the cost of increased complexity.
I don't see the trade off as being worth it.

> ----------
> From: 	Sarbari Gupta[SMTP:[email-masked]]
> Sent: 	Thursday, May 20, 1999 10:50 AM
> To: 	'Robert Zuccherato'; Sarbari Gupta; [email-masked];
> [email-masked]'