Subject: Re: [pkix] timestamp signature validation

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Mar 2013 01:21:05 +0000

Erwann Abalea <[email-masked]> writes:

>At least one TSP in Czechoslovakia. With Qualified Certificates. The
>attribute certificates is additional to the signer. Other than that, I have
>never encountered attribute certificates in the wild.

Has anyone considered contacting the TSP (do you mean TSA?) to let them know
that they're doing this?  Given some of the totally broken behaviour of both
TSAs and TSP clients, they may not even be aware that they're doing this.  It
seems we're having a complex debate over something that may just be yet
another TSA implementation bug.

Peter.

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Mar 2013 02:52:32 +0100 (CET)

> another TSA implementation bug.

I still don't understand how the presence of attribute certificates
could interfere (rather then enabling an otherwise failing) timestamp
verification.

A TSA client that is not explicitly instructed to look for
attribute certificates and to require specific authorization data
ought to be completely ignorant of any certs besides the TSA
signature cert.

Or is there anything in rfc3161 that suggests looking at other certs?

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 13 Mar 2013 11:04:29 +0100

2013/3/13 Martin Rex <[email-masked]>

> > >At least one TSP in Czechoslovakia. With Qualified Certificates. The
[read "Czech Republic" instead, as it was notified in private]

> > another TSA implementation bug.

They're aware they're doing this. It's on purpose.

> could interfere (rather then enabling an otherwise failing) timestamp

A dark corner from RFC2634. SigningCertificate attribute contains a
sequence of ESSCertID, and usually this sequence is composed of only one
certificate.

[...]
   If more than one certificate is present in the sequence of
   ESSCertIDs, the certificates after the first one limit the set of
   authorization certificates that are used during signature validation.
   Authorization certificates can be either attribute certificates or
   normal certificates.
[...]

Everywhere "certificate" is mentioned, it can either be a public-key
certificate (here named "normal certificate") or an attribute certificate.
(Deciding what to do facing several public-key certificates in such a
situation isn't clear, even after reading that paragraph).

> Or is there anything in rfc3161 that suggests looking at other certs?

Other than following RFC2634, performing a correct chain validation, and
verify authorizations? No.

-- 
Erwann.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 13 Mar 2013 11:30:34 +0100

On 03/13/2013 11:04 AM, Erwann Abalea wrote:
>
> 2013/3/13 Martin Rex <[email-masked] <mailto:[email-masked]>>
>
>     Peter Gutmann wrote:
>     > Erwann Abalea <[email-masked] <mailto:[email-masked]>> writes:
>     > >
> A dark corner from RFC2634. SigningCertificate attribute contains a sequence of ESSCertID, and 
> usually this sequence is composed of only one certificate.
>
> [...]
> Everywhere "certificate" is mentioned, it can either be a public-key certificate (here named 
> "normal certificate") or an attribute certificate.
> (Deciding what to do facing several public-key certificates in such a situation isn't clear, even 
> after reading that paragraph).
>
> Other than following RFC2634, performing a correct chain validation, and verify authorizations? No.
>

I have a different opinuion.

RFC 3161 mentions that a server must add
an esscertid of the signing certficate.
One uses thus a particular profile of esscertid.
Whilst one can dedate the reason for that (i.e. to be conformant
to the EU directive of signatures), this does obviuously not
stop tsas to add other certs.

But; For the security (whatever that means) of the time stamp any additional
data are not relevant.

A  tsa client can just limit itself to just check the first occurence in the EssCertId
sequence to match with the TSA's public key cert (and treat everything else
similar as a non critical extension.

If TSAs add other things and if some specialized client want to check this
(with some hardcoded values of attribut certs) that outside the scope
of RFC 3161.

RFC 2634 does not require that ALL applications MUST verify all features
as soon as they appear. at least as far as I understand it.
this would be a devive task, how can an application learn
the meaning of an attribute certificate?

Peter

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Mar 2013 17:57:16 +0100 (CET)

Peter Sylvester wrote:
> Erwann Abalea wrote:
>> Martin Rex wrote:

The way rfc3161 is specified, it is only the ASN.1 type ESSCertID
with respect to the TSA Signature certificate that is imported from
rfc2634, not any of the semantics associated with attribute certificates.

That doesn't preclude that specific TSA servers&clients could define
clear semantics in which fashion such data could be come relevant
for the verification of the timestamp.

But absent such out-of-band preconfigured semantics, an rfc3161 TSA
client ought to entirely ignore unsolicited ESSCertID entries
and unsolicited certs in the TimeStampToken for the purpose of
robustness and adherence to he "principle of least surprise".

> 
> A  tsa client can just limit itself to just check the first occurence
> in the EssCertId sequence to match with the TSA's public key cert
> (and treat everything else similar as a non critical extension.

A TSA client may have a preconfigured list of valid TSA signers
consisting of ToBeSigned structures, where an ESSCertID containing
a certificate hash would have to be ignored anyway.

Simply always using the SignerInfo->SignerIdentifier element (which
is mandary at the ASN.1 level) rather than digging through the
signed attributes for an awkward ESSCertID (which is optional
at the ASN.1 level) saves a significant amount of complex and
brittle code.

And if the document itself already lists 8 patents that might
be applicable, an implementor may want to scope his implementation
to the exact functionality that is necessary for interop in order
to limit the "IP trolls attack surface"...

> (with some hardcoded values of attribut certs) that outside the scope

Correct.

   http://tools.ietf.org/html/rfc2634#section-5.3

   5.3 Related Signature Verification Context

   Some applications require that additional information be used as part
   of the signature validation process. In particular, authorization
   information from attribute certificates and other public key
   certificates or policy identifiers provide additional information
   about the abilities and intent of the signer. The signing certificate
   attribute described in Section 5.4 provides the ability to bind this
   context information as part of the signature.

While specific applications can "require that additional information
be used as part of the signature validation process", rfc3161 _by_itself_
is clearly no such application that does.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 16 Mar 2013 05:27:48 +0100 (CET)

> sequence of ESSCertID, and usually this sequence is composed of only one

There seem to be more dark areas that just "corners" in rfc2634
and its alleged update rfc5035.

The first thing that puzzles me: why does ESSCertID use such
an extremely awkward "ESSCertID"?

http://tools.ietf.org/html/rfc2634#page-48

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

   When creating an ESSCertID, the certHash is computed over the entire
   DER encoded certificate including the signature. The issuerSerial
   would normally be present unless the value can be inferred from other
   information.

   When encoding IssuerSerial, serialNumber is the serial number that
   uniquely identifies the certificate. For non-attribute certificates,
   the issuer MUST contain only the issuer name from the certificate
   encoded in the directoryName choice of GeneralNames. For attribute
   certificates, the issuer MUST contain the issuer name field from the
   attribute certificate.

It says:

"... the isser MUST contain only the issuer name from the certificate
encoded in the directoryName choice of GeneralNames"

But that seems non sensical.

The definition of GeneralNames from rfc5280 looks like this:

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

so GeneralNames does _not_ contain a CHOICE.
There may be a (close to) inifinite number of GeneralName types
contained in that GeneralNames sequence, but that seems awkward.

Looking at what values issuer can have in certs (from 5280 again):

  TBSCertificate  ::=  SEQUENCE  {
       version         [0]  Version DEFAULT v1,
       serialNumber         CertificateSerialNumber,
       signature            AlgorithmIdentifier,
*>     issuer               Name,
       validity             Validity,
       subject              Name,
       subjectPublicKeyInfo SubjectPublicKeyInfo,
       issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                            -- If present, version MUST be v2 or v3
       subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                            -- If present, version MUST be v2 or v3
       extensions      [3]  Extensions OPTIONAL
                            -- If present, version MUST be v3 --  }

or in CRLs:

  TBSCertList  ::=  SEQUENCE  {
       version                 Version OPTIONAL,
                                   -- if present, MUST be v2
       signature               AlgorithmIdentifier,
*>     issuer                  Name,
       thisUpdate              Time,
       nextUpdate              Time OPTIONAL,
       revokedCertificates     SEQUENCE OF SEQUENCE  {
            userCertificate         CertificateSerialNumber,
            revocationDate          Time,
            crlEntryExtensions      Extensions OPTIONAL
                                     -- if present, version MUST be v2
                                 }  OPTIONAL,
       crlExtensions           [0] Extensions OPTIONAL }
                                     -- if present, version MUST be v2

And looking at how CMS (rfc2630) defined IssuerAndSerial

      IssuerAndSerialNumber ::= SEQUENCE {
*>      issuer Name,
        serialNumber CertificateSerialNumber }

      CertificateSerialNumber ::= INTEGER

I fall to understand why ESSCertID uses something so extremely complicated
as a "SEQUENCE of GeneralName", where everyone else has been using "Name"?

It gets even weirder in rfc5035:

        ESSCertIDv2 ::=  SEQUENCE {
            hashAlgorithm           AlgorithmIdentifier
                   DEFAULT {algorithm id-sha256},
            certHash                 Hash,
            issuerSerial             IssuerSerial OPTIONAL
        }

I'm puzzled why rfc5035 defines ESSCertIDv2 in a fashion that it is
thoroughly binary incompatible with ESSCertID from rfc2634?

Had it used "DEFAULT {algorithm id-sha1}," instead, then it would
share the same ASN.1 DER encoding with ESSCertID from rfc2634 when
SHA-1 is used for the hash, vaguely similar how the Validity in
X.509v3 certificates is being slowly migrated from UTCTime to a subset
of GeneralizedTime.

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Sat, 16 Mar 2013 15:51:37 +0100

> so GeneralNames does _not_ contain a CHOICE.

GeneralNames is a SEQUENCE of GeneralName, and GeneralName is a CHOICE
(among them, directoryName, of type Name).

> as a "SEQUENCE of GeneralName", where everyone else has been using "Name"?

True. But after all, when you encode the AuthorityKeyIdentifier
extension, the authorityCertIssuer is also of GeneralNames type.

> X.509v3 certificates is being slowly migrated from UTCTime to a subset

True again.

-- 
Erwann.

---

From: [email-masked] (Martin Rex)
Date: Mon, 18 Mar 2013 18:49:27 +0100 (CET)

Erwann Abalea wrote:
> Martin Rex <[email-masked]>:
> >

Did you notice the MUST requirements in the second paragraph,
that I quoted from rfc2634 (setences 2+3)?

rfc2634 does not allow anything else than the "issuer  Name,"
from TBSCertificate to appear in issuerSerial of ESSCertID.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 18 Mar 2013 19:26:45 +0000

If you want to be less complex (restrict issuer names to directory name only) it's easy to profile the ESS syntax to do so.

If the ESS syntax said "Name", it would be impossible to use anything else (such as rfc822Name) if issuer SANs later became fashionable.

Usage should be determined by policy; syntax strives to be policy-neutral.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, March 18, 2013 1:49 PM
To: Erwann Abalea
Cc: [email-masked]
Subject: Re: [pkix] timestamp signature validation

Erwann Abalea wrote:
> > I fall to understand why ESSCertID uses something so extremely 
> > complicated as a "SEQUENCE of GeneralName", where everyone else has been using "Name"?
> 

Did you notice the MUST requirements in the second paragraph, that I quoted from rfc2634 (setences 2+3)?

-Martin
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Tue, 19 Mar 2013 06:19:37 +0100 (CET)

Kemp, David P. wrote:
>
> If you want to be less complex (restrict issuer names to directory
> name only) it's easy to profile the ESS syntax to do so.

rfc2634 _already_ contains a MUST requirement that restricts the issuer
name to directoryName only.

> 
> If the ESS syntax said "Name", it would be impossible to use anything
> else (such as rfc822Name) if issuer SANs later became fashionable.

As far as rfc2634 is concerned, that is _de_facto_ impossible.

It has to be expected that conforming implementations will properly
enforce the rfc2634 "MUST contain only the issuer name from the
certificate encoded in the directoryName choice" and reject ESSCertIDs
that contains anything else than directroyName.

> Usage should be determined by policy; syntax strives to be policy-neutral.

That is only possible when the semantics are well-defined from the
beginning, i.e. what is allowed to be present, and what to do with
it when an implementation does not recognize/support that data.

For rfc2634 the situation is brief and clear: only directoryName is
permitted, this is a MUST requirement, so any other content MUST
result in the complete rejection of the ESSCertID.

-Martin