Subject: Comments on time-stamp-01: Identification of TSA

From: [email-masked] (Terry Hayes)
Date: Mon, 24 May 1999 13:53:32 -0700

The current time-stamp draft contains several places that define fields
or recommend use of previously defined fields to identify the TSA
creating the token.  I believe that the draft provides too many ways to
do this, which will work against creation of interoperable
implementations.  In addition, I believe that some of the current
options are motivated by concerns that are better addressed in other
ways.

First, the protocol uses a CMS SignedData object as the basic form of
the time-stamp token.  This object allows identification of the signer
in the SignerInfo section.  This data is sufficient to locate the
correct certificate, build the chain and validate TSA's identity.  This
should be the primary (and possibly only) method of identifying the TSA
that generated the token.  However, the current draft goes on to mention
several other identification fields.

The draft contains the following text:

     The purpose of the tsa field is to identify 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.  This field MAY be omitted if the Signing
     Certificate Attribute has been included as a signed
     attribute.  (See Section 5 of [ESS].) It MUST be present if
     the ESSCertID Attribute is not used to identify the TSA.

'tsa' is an optional GeneralName field defined within the TSTInfo
sequence.  Because it is optional, it cannot be relied upon to locate
the proper certificate needed to verify the token.  It may be useful to
locate the certificate if a verifier files certificates using values
other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
TSA would need to know what other types of GeneralName might be useful
to a client.  The 'tsa' field does have one difference from the
SignerInfo fields - it is signed with the message.  This has some
significance for some attacks on the protocol, which I'll discuss later.

The 'substitution attack' ([ESS]) is prevented for TSA signatures in two
ways.  First, the key used for signing time-stamp tokens is required to
be used only for that purpose.  This means that existence of a second
certificate (with different capabilities) for the same key is already
prohibited by the draft.  Second, the token also contains a
PolicyIdentifier that is effect for the signature.  The verifier must
check that the certificate chain allows this policy to be used.  This
requirement prevents a second certificate (with different
PolicyIdentifier values) from being used to check the signature.  In
fact, the policy identifiers in the SigningCertificate sequence of [ESS]
duplicate the value already found in the token.

Finally, the time-stamping draft expresses concern for attacks that may
occur when the CA does not perform proof-of-possession checks on the TSA
key.  To counter these, the draft encourages use of the fields mentioned
above (including the tsa field, and the SigningCertificate attribute)
which are included within the token signature.  This prevents a
substitution attack where the substitute certificate is for an entirely
different subject name.  However, since other drafts will address these
attacks during the certificate enrollment process (the CMC draft
contains proof-of-possession protocol), I think the time-stamp protocol
should not define its own mechanisms for dealing with the problem.

In summary, there are too many ways to identify the TSA certificate.  We
should use the basic CMS SignerInfo for this data.  Attacks (as listed
in [ESS]) Concerns about proof-of-possession flaws should be addressed
elsewhere, specifically in the certificate request process.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 26 May 1999 18:58:37 +0200

> several other identification fields.
No: The data are NOT sufficient to locate the correct certificate.

You just define a NEW protocol that requires POP to be done elsewhere
than during signature validation of the document.

The ESS signing cert is a possibility to avoid that 
thus to respond to the problem mentioned in rfc2510: 

   policy issue).  However, it is REQUIRED that CAs/RAs MUST enforce POP
   by some means because there are currently many non-PKIX operational
   protocols in use (various electronic mail protocols are one example)
   that do not explicitly check the binding between the end entity and
   the private key.  Until operational protocols that do verify the
   binding (for signature, encryption, and key agreement key pairs)
   exist, and are ubiquitous, this binding can only be assumed to have
   been verified by the CA/RA. Therefore, if the binding is not verified
   by the CA/RA, certificates in the Internet Public-Key Infrastructure
   end up being somewhat less meaningful.
> significance for some attacks on the protocol, which I'll discuss later.
The text clearly indicates that ONE of the optional possibilities MUST
be used for identification. A tsa that does not fill in neither the 'tsa'
neither the signing cert attribute would not be conformant.  
Policy in the TSTInfo should also be optional, since it can also be
filled in using the signing cert attribute. 

Whether it would be required to fill in a policy in at least one of
the fields, I don't care. 

> should not define its own mechanisms for dealing with the problem.
If you can avoid the requirement for proof of possession in
an operational protocol, then you don't have to address that problem. 

> elsewhere, specifically in the certificate request process.

Refering to use the ESS signing cert, concerns about 
proof of possession ARE refered elsewhere. 

The TSA and policy indicator in the text seem to me leftovers from
the time where the ESS signing cert attribute wasn't known. 

The only point that the tsa name inside the TSTinfo can handle is that
you immediately have a name of the TSA. But this seems a rather
weak argument, since in order to verify the integrity of the cert
you probably have access to the cert anyway. 

if one does not want to create another new special way for identification
etc. one might suggest to completely remove the tsa and policy from
the TSTinfo. The current text is a compromise so far.

Peter