Subject: draft-ietf-pkix-rfc3161bis-01.txt

From: Peter Sylvester <[email-masked]>
Date: Wed, 04 Mar 2009 18:22:25 +0100

I had the impression that thegoal of that texwt was an update
concerning hash algorithms.

One could expecte it would only contain an update to the ESScertid using
ESSCertidV2 etc.

The actual texts corresponds roughly to an expired draft some
years ago.

        - the document has been aligned with RFC 3628 to make the
          difference between a time-stamping unit (TSU) and a TSA.

Thus, the text is not a small update of 3161 but introduces several
new items, some of them seems questionable to me. Some problems
which had been mentioned with RFC 3161 in the past, have not been
addressed.

In 3161, a TSA is merely a technical service similar to what is
said in 3161bis for a TSU. A TSA in 3161bis does not really
have a defined technical role.

On the other hand the field tsa in a response refers to a TSA,
and to a certficate that validates it. But a TSA does no longer
have a certificate, only TSUs.

As a consequence, the following paragraph cannot mention TSA
but at best a TSU.
Besides that it should also mentiion ESSCertIDv2.)

    The purpose of the tsa field is to give a hint in identifying the
    name of the TSA.  If present, it MUST correspond to one of the
    subject names included in the certificate that is to be used to
    verify the token.  However, the actual identification of the entity
    that signed the response will always occur through the use of the
    certificate identifier (ESSCertID Attribute) inside a
    SigningCertificate attribute which is part of the signerInfo
    (See Section 5 of [ESS]).

Chapter 3.3 does not use the 2119 terminology in the first phrase but
rather the ISO terminoilogy. 3.3 is not relevant for the function of
a time stamp service. (Although it is likely that TSA actually
have filled all the REQUIRED 'shall) attributes in the DN)

The following text is extremely fuzzy:

    The name of the issuing TSU shall contain an appropriate subset of
    the following attributes (defined in ISO 9594-6 [ISO9594-6] and
    ITU-T Recommendation X.520 [X.520]):

        - countryName;
        - stateOrProvinceName;
        - organizationName;
        - commonName.

What means "appropriate subset". The text does not exclude
other attributs. So in fact, it says: The TSU MUST have a subjectDN?

It is not defined what name identifies a TSA? for example, everything except
the common name?

4.3 :

As it had been mentioned before the socket protocol as it is defined
has some problems: Since it was taken texto from CMP, there are some features
that are may require some complexity in clients:
Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
a response within a few milliseconds with a TCP connection kept open,
I wouldn't call this a service.
For HTTP, a server cannot return a poll indication as a comparison.

If a client does not send a pollReq, what will happen with a pending
response?

The protocol does not specify who terminates the connection. Is it the
server that closes after one exchange?

If multiple requests and responses can be exchanged over the same connection,
what is the dialogue model? request/response, pipelining, etc?

What is a TSU message? I think it should be TSP message. Old text was
TSA, which was also somewhat wrong.

Security section point 1 seems not quite correct:

Instead of :
it SHALL be set either to unspecified (0), affiliationChanged (3),
       superseded (4) or cessationOfOperation (5).  In that case,

it should say

In the case when the reasonCode is set to either
       affiliationChanged (3),
       superseded (4) or cessationOfOperation (5)

Unspecified means that ther can be a key compromise IMO?

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 11 Mar 2009 10:23:54 +0100

I would like to line up and express my concerns regarding the direction of
this document.

In principle I'm worried about the fundamental changes of concept and
terminology made in the update of an existing IETF standard.

While 3161 used TSA (Time Stamping Authority) as a collective term, 3161bis
uses three different terms:

TSA - TS Authority
TSU - TS Unit
TSS - TS Service

This is extremely confusing to me and appears unnecessary distinctions for
the sake of defining a protocol.

The change is motivated by RFC 3628 which has been upgraded as Normative.
But RFC 3628 is an Informational policy document and should never be
normative over the protocol standard.

I see several mixes of these new terms that appears confusing to me. For
example TSU is mentioned as being responsible for things where I would
suspect that any responsibility must reside with a TSA.

In section 4.3 the body text talk about TSU Messages, but the protocol
definitions define TSA Messages.

And it goes on like that throughout the document.

A more thorough discussion is needed here. My current view is that we
probably should revert completely back to the text of RFC 3161 and then just
do a minimum of technically well motivated changes. At this time I oppose
terminology alignment to RFC 3628.

/Stefan

---

From: Alfredo Esposito <[email-masked]>
Date: Thu, 12 Mar 2009 14:03:43 +0100

The meaning of TSU seems to me pretty clear: it is the entity signing 
the time stamp token. For example, my company runs several Time stamp 
services, each based on more than one different signing unit, for 
performance and availability. An organization (i.e. an Authorithy) can 
offer different time stamp services with different policies, so that TST 
are signed with different keys. At the same time, defining different 
roles does not forbid to collapse all in one. I don't see the problem.
Some suggestions for the draft
I would remove the first part of section 3.3 (identification of the TSU) 
related to the TSU name since it seems outside the scope of the document 
(named Time stamp PROTOCOL) and more suitable for a profile document 
(strictly speaking also the prescription of the EKU would be out of 
scope, but it was already there in the RFC 3161).
--Introduction
-replace
The TSA can  also be used to indicate the time of submission when a 
deadline is critical, or to indicate the time of transaction for entries 
in a  log.  An exhaustive list of possible uses of a TSU is beyond the 
scope of this document.
-with
A time-stamp can also be used to indicate the time of submission when a 
deadline is critical, or to indicate the time of transaction for entries 
in a  log.  An exhaustive list of possible uses of a time-stamps scope 
of this document.
--Definitions
-replace
time-stamping authority: authority which issues time-stamp tokens.
-with
time-stamping authority: authority responsible of issuing time-stamp tokens.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Mar 2009 15:23:56 +0100

> roles does not forbid to collapse all in one. I don't see the problem.

A small paragraph allowing a reader to better distinguish the technical
term from some organisational usage may be sufficient. This is similar
as for the definition of an RA and CA. When used as technical terms,
a CA is simply a signing device, and a TSA is simply a 'signing device that
adds some time.'

... some text removed

> Stefan Santesson wrote:

... some text removed

>> terminology alignment to RFC 3628.

I fully agree with this.

The text should be just have an update for the ESSSigningCertV2.

I mentioned also some unclear text concerning the socket protocol.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 12 Mar 2009 15:14:02 +0100

Alfred,

> the time stamp token.

You see, already here you loose me.

How can a "Unit" be an Entity? If so, how do you define entity?

/Stefan

---

From: Alfredo Esposito <[email-masked]>
Date: Thu, 12 Mar 2009 17:27:53 +0100

I love joking with the words in my own language, but my English is not 
smart enough
TSU is the subject of a X.509 public key certificate and the 
corresponding private key is used to sign time-stamp-token compliant 
with IETF RFC 3161
Is it better?

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 12 Mar 2009 17:49:08 +0100

Alfredo,

It may seem that I'm kidding around with words, but to me it is larger than
that.

No your definition does not help convince me why I need three separate terms
to describe one entity of a protocol, unless they are distinguished in the
protocol bits on the wire.

If the protocol could be defined for a TSA, and the bits on the wire are the
same today, except for the CertID, then why do I have to split the entity
into three separate terms. It's just confusing.

Where is the benefit?

/Stefan

---

From: Alfredo Esposito <[email-masked]>
Date: Thu, 12 Mar 2009 18:23:37 +0100

Stefan
Sure, for the mere description of the protocol we just need a 
"time-stamp" responder (may be the best term), unaware of the technical 
implementation and of any way the responder is organized.
Nevertheless, IMHO, distinguishing among the physical responder and the 
organization ("the authority") liable for the service was a plus.

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 12 Mar 2009 18:27:20 +0100

Stefan,

When you use the TSP (P = Protocol), you talk to a service (in this case,  a Time Stamping Service).

You will get a response from one of the TSUs behind that service.

If the request is sucessful, the TST is signed by a TSU.

Every TSU is managed by a TSA.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : Alfredo Esposito 
Date : 2009-03-12, 17:49:08
Sujet : Re: draft-ietf-pkix-rfc3161bis-01.txt

Alfredo,

Where is the benefit?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 12 Mar 2009 19:00:04 +0100

I can understand that it is a plus for a policy document, but not for the
protocol standard, especially not when we are "updating" an existing
standard.

I could argue the same for PKI. When describing a certificate issuing
service from a policy perspective I may want to distinguish between the
legal entity responsible for the service, the RA, the cryptographic modules
and the keys. But for the sake of defining the certificate standard, we only
have one entity (the certificate issuer a.k.a. The CA).

/Stefan

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 13 Mar 2009 09:56:24 +0100

so, if a "time stamp Responder" uses several signature creation devices in order to increase performance, but the
corresponding certificates are issued for the same subject names, these signature creation devices represent the same
TSU? This seems counterintuitive to me.
And I am not sure whether this (quite typical) scenario is reflected by the new draft. At least the last sentence in
section 3.3 indicates a different scenario:
   A TSS MAY have distinct TSUs, e.g., to accommodate different
   policies, different algorithms, different private key sizes or to
   increase the performance.

Johannes

-- 
Viele Grüße,
Johannes Merkle

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 15 Mar 2009 10:42:42 +0100

> If the request is sucessful, the TST is signed by a TSU.
No, not in rfc 3161. The term used is TSA. The way how the
service is implemented, is out of scope NOIMO.

> Every TSU is managed by a TSA.
Since I don't know your interpretation of "managed", it
is not clear whether you think about the TS Service Provider
the TS Service Operator, or some legal entity that assumes
the correct usage of a date and the protection of a key, or
else.

Nothing of that matters for the protocol.

Peter

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 16 Mar 2009 12:27:29 +0100

Sorry for the delay to respond.

Responses are in-line.

Denis
----- Message reçu ----- 
De : owner-ietf-pkix 
À : ietf-pkix 
Date : 2009-03-04, 18:22:25
Sujet : draft-ietf-pkix-rfc3161bis-01.txt

[Denis]  The key point is that the certificate belongs to one TSU, not to one TSA.

A TSU certificate may be revoked. A TSA has no certificate and thus is not revoked if one of its TSUs is compromised.
A TSA is the administrative entity responsible for managing one or more TSUs.

[Denis]  In the proposal, I kept the same names for the fields. 
Maybe this is not the best choice, and "tsa" should be changed into "tsu" to reflect better the difference.

Chapter 3.3 does not use the 2119 terminology in the first phrase but
rather the ISO terminoilogy. 

[Denis]  Do you mean "shall" should be changed into" SHALL" ?

3.3 is not relevant for the function of
a time stamp service. (Although it is likely that TSA actually
have filled all the REQUIRED 'shall) attributes in the DN)

        - countryName;
        - stateOrProvinceName;
        - organizationName;
        - commonName.

[Denis]  The text is very explicit: "organizationName shall be present". Other fields are optional.

4.3 :

[Denis]  I care for backwards compatibility first. 
If some cases may not exist, then we can suppress them. 
If they may exist, then we should keep them. 

[Denis]  If you have a proposal , please post it to the list.

[Denis]  A TSU Message is simply a message from a TSU.

Instead of :

it should say

[Denis]. Good catch. Let us delete "unspecified (0)"

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 19 Mar 2009 14:16:54 +0100

>     [Denis]  The key point is that the certificate belongs to one TSU,
No. in RFC3161 a certficate belongs to a TSA. This is a technical entity
that has the authority to create time stamps.

all organisational aspects are not part of 3161.
>
>      
>     A TSU certificate may be revoked. A TSA has no certificate and
>     thus is not revoked if one of its TSUs is compromised.
not in RFC 3161. Besides that to me the words

  "administrative entity responsible for managing"

are ambiguous.

>     Maybe this is not the best choice, and "tsa" should be changed
>     into "tsu" to reflect better the difference.
>
Some people use ASN.1 compilers that generate variable names
based on asn.1 types. Changing a name is  a problem even
if the bits on the wire are the same.  Furthermore, user interfaces
may also more or less directly use the names. Think
also about a XER representation which would be used as
an intermediate format.

The disaster of contentCommitment vs nonRepudiation MUST
not be repeated.

>     [Denis]  Do you mean "shall" should be changed into" SHALL" ?
As far as I remember a 'shall' in
iso terms is the same as MUST. 

But I do not know what you intend? Do you want to
prohibit organisationalUnit for example, or not?
>     present". Other fields are optional.

Right, organisation 'shall' == MUST be present. So, if nothing else, then
you would only have one TSU of this TSA?

  "It is not defined what name identifies a TSA".

>     If they may exist, then we should keep them.
You should think at conformance. If a client implementation
claims conformance and support of the socket protocol, does it
need to implement all these polling features?

>     [Denis]  If you have a proposal , please post it to the list.*
>
I care for backward compatibility. I don't know what implementations
do. A proposal existed, you may want to recover the text from
an update to cmp.

-connection usage: Typically, a client establises a connection.
Since it is not specified who terminates it, the following
cases can occur:

- a client assumes that the connection is closed by the server.
- a client closes a connection after having received a response.
- a client may maintain a connection in order to send other
  requests.

When a client uses the third variant, it should be prepared
for the connection being closed by the server.

>     [Denis]  A TSU Message is simply a message from a TSU.
I wonder whether you got the point.
>     [Denis]. Good catch. Let us delete "unspecified (0)"
The question was: "do we need all that?"

I don't think thar

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Mar 2009 16:52:09 -0400

>The disaster of contentCommitment vs nonRepudiation MUST

I agree!  The PKIX specification continue to use the older name 
(nonRepudiation instead on contentCommitment) , and I strongly 
believe that is the right thing to do as Peter argues.  Gratuitous 
name changes really need to be avoided.

Russ