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

[Santoni Adriano <santoni@xxxxxx>]

That could be simply fixed by declaring the tsaName field OPTIONAL...and
stating in the text that it's intended purpose is just that of a "hint" or
as an alternative name, carrying however no definite value in itself (only
the subject of the accompanying certificate in the outer SigneData structure
counts, of course).

Adriano

-----Messaggio originale-----
Da: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
Inviato: giovedì 27 maggio 1999 13.47
A: Robert Zuccherato
Cc: ietf-pkix@imc.org
Oggetto: Re: Comments on time-stamp-01: Identification of TSA


Robert,

I have been away during (only) 6 days and the number of ER-mails about the
TSP
draft is quite important. I will need to answer some other related E-mails
but
let us start by this one where you explicitly mention my name.

> The tsa field within the token is present to allow end users to obtain the
> identity of the supposed TSA without requiring them to obtain the TSAs
> certificate.  Considering that the tokens created by a TSA will be used
for
> non-repudiation in situations very removed (in time and space) from those
in
> which they were created, it may be useful to be able to refer to the token
> with serial number XXXXX from TSA YYYYY, without the only method of
> identifying the TSA being their subjectKeyIdentifier (or
> issuerAndSerialNumber).
>
> The ESSCertiID Attribute was added, as an option, upon the specific
request
> of Denis Pinkas.  I don't recall the arguments for it, so I will allow him
> to respond directly.

Hum! Since you raised the question, to tell the truth I was/am only
advocating
the use of ESSCertiID and the current document is the reflect of a (good/bad
?)
compromise.

Robert, you said : "The tsa field within the token is present to allow end
users
to obtain the identity of the supposed TSA without requiring them to obtain
the
TSAs certificate." A TSP caller will have anyway to verify the signature of
the
TSA, so it will always need the TSAs certificate (i.e. the
issuerAndSerialNumber
field). The name in the token itself is both insecure and useless. It is
insecure because it does not handle TSA name collission properly, so it can
only
be used as an hint. The hint is not very useful anyhow since it does not
allow
to point to all the TSA homonyms (if any). It is useless because it does not
allow to point unambigoulsly to the right certificate. So supporting the
identification of the TSA in the signer info is not really an option but a
need.
So I agree that there are too many ways to identify the TSA.

Denis


>
>         Robert.
>
> > ----------
> > From:         thayes@netscape.com[SMTP:thayes@netscape.com]
> > Reply To:     thayes@netscape.com
> > Sent:         Monday, May 24, 1999 4:53 PM
> > To:   ietf-pkix@imc.org
> > Subject:      Comments on time-stamp-01: Identification of TSA
> >
> > <<File: thayes.vcf>>
> > 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.
> >