Subject: [lamps] Need clarification on ESS (RFC 2634)

From: Midnight Wonderer <[email-masked]>
Date: Tue, 2 Mar 2021 18:54:22 +0700

Hello there,

I submitted a patch for OpenSSL, which is related to RFC 2634; the
current implementation seems to verify ESSCertID against root
certificates, which contradicts the ESS response from public timestamp
authorities and marks the response invalid.

The issue stemmed from the lack of definition of "authorization
certificates that are used during signature validation" mentioned in
the RFC. I also checked RFC 5035; no clarification there either.

I need clarification on "authorization certificates".
Does it include a trust anchor?
Having the definition of the term would be nice.

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Mar 2021 13:33:38 -0500

ESSCertID is intended to prevent the simple substitution and re-issue attacks.  The trust anchor itself is not subject to such attacks.

Russ

> On Mar 2, 2021, at 6:54 AM, Midnight Wonderer <[email-masked]> wrote:
> 
> Hello there,
>

---

From: David von Oheimb <[email-masked]>
Date: Wed, 10 Mar 2021 09:01:44 +0100

I have follow-up question on this because the ambiguity in RFC 2634 (and
5035)

SigningCertificate ::=  SEQUENCE {
       certs        SEQUENCE OF ESSCertID,
       policies     SEQUENCE OF PolicyInformation OPTIONAL
   }

on the interpretation of the 'certs' sequence of cert IDs is much
greater than
just whether the trust anchor (TA) is meant to be constrained in there
or not.

In the requirements updated by 5035, the sentences in question are the
following:

|certs contains the list of certificates that are to be used in
validating the message. The first certificate identified in the sequence
of certificate identifiers MUST be the certificate used to verify the
signature. [...] If more than one certificate is present, subsequent
certificates limit the set of certificates that are used during
validation. [...]. If only the signing certificate is present in the
sequence, there are no restrictions on the set of certificates used in
validating the signature.|

The case that only one cert ID is given is sufficiently clear.
Yet what exactly should it mean for the case that further cert IDs are
given?

I've been discussing this reviewing "Midnight Wonderer"'s OpenSSL PR
https://github.com/openssl/openssl/pull/14214

One could interpret the above as:
If there is more than one such cert ID given,
then all the referenced certs must be part of the validating chain
(where the leaf cert must match the first cert ID)
AND other certs (apart from the root/TA) must not be in that chain.

Yet the latter conjunct is not stated there.

My interpretation is more general and less strict, namely:
If there is more than one such cert ID given,
then all the referenced certs must be part of the validating chain
(where the leaf cert must match the first cert ID).

In other words, this allows extra certs anywhere in the chain.
This still prevents substitution and re-issue attacks,
but does not preclude, for instance, that the validating chain
is an extension of the list given by the cert IDs.

Consider the following chains as an example:
signer cert - intermediate cert - TA1
signer cert - intermediate cert - bridge cert - TA2
and suppose the signer includes in the SigningCertificate structure
only the fingerprints of the signer cert of the intermediate cert.

The question then boils down to:
Is it correct/intended that the validator can accept the second (longer)
chain?

Rejecting such a chain prolongation may appear more "secure", but
I have the impression that this would needlessly rule out
cross-certification scenarios.

A related unclarity is whether the order of the given cert IDs is meant
to play a role
(except for the first such ID, which clearly plays a role), but that
looks rather irrelevant to me
because any correctly built validation chain will have its intrinsic
order of certs anyway.

    David

On 03.03.21 19:33, Russ Housley wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Midnight Wonderer <[email-masked]>
Date: Thu, 11 Mar 2021 16:18:29 +0700

Since most people don't have a context about the situation, let me
give a short explanation.

The question boiled down to:
Whether the verifier should ensure all authorized certificates
availability in the set of ESSCertID or ensure all ESSCertID
availability in the set of (chain of) authorized certificates.

The implication is that the former will allow extra ESSCertIDs in the
signer info, while the latter would allow extra authorized
certificates in the validating chain.

The details are as David gave, also the reason why he believes the
latter is the way to go.

On Wed, 10 Mar 2021 at 15:01, David von Oheimb <[email-masked]> wrote:
>
> I have follow-up question on this because the ambiguity in RFC 2634 (and 5035)
>
> on the interpretation of the 'certs' sequence of cert IDs is much greater than
> just whether the trust anchor (TA) is meant to be constrained in there or not.
>
> In the requirements updated by 5035, the sentences in question are the following:
>
>    certs
>       contains the list of certificates that are to be used in
>       validating the message.  The first certificate identified in the
>       sequence of certificate identifiers MUST be the certificate used
>       to verify the signature. [...]
>
>       If more than one certificate is present, subsequent certificates
>       limit the set of certificates that are used during validation.
>       [...].  If only
>       the signing certificate is present in the sequence, there are no
>       restrictions on the set of certificates used in validating the
>       signature.
>
> Yet what exactly should it mean for the case that further cert IDs are given?
>
> Is it correct/intended that the validator can accept the second (longer) chain?
>
> I have the impression that this would needlessly rule out cross-certification scenarios.
>
> A related unclarity is whether the order of the given cert IDs is meant to play a role
> (except for the first such ID, which clearly plays a role), but that looks rather irrelevant to me
> because any correctly built validation chain will have its intrinsic order of certs anyway.
>
>     David

---

From: David von Oheimb <[email-masked]>
Date: Thu, 11 Mar 2021 13:56:18 +0100

Midnight Wonderer (BTW, why don't you give your real name?),
thanks for your further explanation.

Good that you pointed out that the way certificates are looked up is
critical here,
namely whether it is based on the list of ESSCertIDs or based on the
validation chain.

Unfortunately the way you phrased it is somewhat confusing, due to the
term"authorized certificates"
and because the order of the quantifiers in your formulation is unclear.
We need to be more precise.
According to RFC 2634 there are "authorization certificates" motivated
in section 5.3.1:

>
>         5.3.1 <https://tools.ietf.org/html/rfc2634#section-5.3.1>
>         Authorization Information
>
>    Some applications require that authorization information found in
>    attribute certificates and/or other public key certificates be
>    validated. This validation requires that the application be able to
>    find the correct certificates to perform the verification process;
>    however there is no list of the certificates to used in a SignerInfo
>    object. The sender has the ability to include a set of attribute
>    certificates and public key certificates in a SignedData object. The
>    receiver has the ability to retrieve attribute certificates and
>    public key certificates from a directory service. There are some
>    circumstances where the signer may wish to limit the set of
>    certificates that may be used in verifying a signature. It is useful
>    to be able to list the set of certificates the signer wants the
>    recipient to use in validating the signature.
So these are certificates containing authorization information that may
be regarded crucial.
The signer is given the possibility to pin down these certs
by listing their ESSCertIDs in a SigningCertificate attribute of the
SignerInfo structure
and thus to require the verifier to make use of exactly these certs.
This should disallow the verifier to use potentially other certs
that the local validation chain building brought up and that also
validate the signature
but that might not bear the wanted authorization information.

Using this clarification, let me re-phrase the below remarks as follows:

There actually two questions.

 1. Whether the verifier is required to ensure that

      * all certs referenced by the given ESSCertIDs are part of the
        validation chain,
        which requires that all ESSCertIDs given by the signer must be
        respected
        while potentially allowing for further certs in the validation chain

    or to ensure that

      * all members of the validation chain are referenced in the
        ESSCertIDs,
        which allows ESSCertIDs to be neglected if no corresponding cert
        is in the chain.

        Therefore in my view this interpretation is wrong.

 2. In case more than one cert is referenced in the list of ESSCertIDs,
    shall this mean that
    /only/ those certs (apart from the trust anchor) may appear in the
    validation chain,
    or are /additional/ certs acceptable as part of the validation chain?

    I believe there should be freedom for the latter,
    in particular in order to allow for cross-certification.

    David

---

From: Midnight Wonderer <[email-masked]>
Date: Thu, 11 Mar 2021 22:02:25 +0700

This may sound funny to you, but my nickname IRL is "Midnight".
Anyway, my real name is hardly a secret; it is also in the git
commits. It's Sarun Rattanasiri. Either name is okay to me, but I
guess calling me Midnight here would be weird.

The objective of the previous message is to provide an abstracted
overview, omitting some details. So more people can understand the
topic. I also suggested reading your message for details.

The one who controls the set of ESSCertID is the signer, while the one
who controls the chain is the certificate authorities.

In another interpretation apart from the one you are suggesting:
- The signers can grant complete freedom to CAs simply by sending a
single ESSCertID as part of the signer info.
- The signers who want a single valid path can send ESSCertIDs of that
specific chain.
- The signers who want multiple valid paths can send the union of
ESSCertIDs of all chains known to the signer. Hence, the validator
should allow unused ESSCertIDs; the unused ones probably came from
other chains.

This means that the signers have every choice, including the
cross-signing scenario you are describing. Also, being able to limit
the know certificates or granting complete controls to CAs.

In the interpretation you suggested, the signer would have less choice
of controls, while certificate authorities always possess some
freedom.
If you are the one who writes the standard yourself, is this what you intended?

On Thu, 11 Mar 2021 at 19:56, David von Oheimb <[email-masked]> wrote:
> Good that you pointed out that the way certificates are looked up is critical here,
> namely whether it is based on the list of ESSCertIDs or based on the validation chain.
>
> Unfortunately the way you phrased it is somewhat confusing, due to the term"authorized certificates"
> and because the order of the quantifiers in your formulation is unclear. We need to be more precise.
> According to RFC 2634 there are "authorization certificates" motivated in section 5.3.1:
>
> 5.3.1 Authorization Information
>
> So these are certificates containing authorization information that may be regarded crucial.
> by listing their ESSCertIDs in a SigningCertificate attribute of the SignerInfo structure
> that the local validation chain building brought up and that also validate the signature
> Whether the verifier is required to ensure that
>
> all certs referenced by the given ESSCertIDs are part of the validation chain,
> which requires that all ESSCertIDs given by the signer must be respected
> all members of the validation chain are referenced in the ESSCertIDs,
> which allows ESSCertIDs to be neglected if no corresponding cert is in the chain.
>
> In case more than one cert is referenced in the list of ESSCertIDs,
> shall this mean that
> only those certs (apart from the trust anchor) may appear in the validation chain,
> or are additional certs acceptable as part of the validation chain?
>

---

From: David von Oheimb <[email-masked]>
Date: Fri, 12 Mar 2021 09:50:01 +0100

Hi Sarun et al.,

> guess calling me Midnight here would be weird.
nice to see your real name. I also like your nickname/pseudonym.

> topic. I also suggested reading your message for details.

Fine.

> who controls the chain is the certificate authorities.
Yeah, and the verifier controls the trust anchor(s), by which it may gain
confidence in the CAs and ultimately in the signer and the signed data.

> single ESSCertID as part of the signer info.
This is the simple case everyone appears to agree on,
because it has been specified very clearly and its usefulness is rather
clear.

> should allow unused ESSCertIDs; the unused ones probably came from
This interprets the list (or actually: set) of certs referenced by the
ESSCertIDs
as an upper bound of the certs that are allowed in the validation chain.
(You do not mention here that you do not want to see the TA(s) constrained,
but this becomes clear in https://github.com/openssl/openssl/pull/14214.
This can be seen as to be somewhat contradicting, but can be acceptable.)

> the known certificates or granting complete controls to CAs.
Well, this comes at a price:
If it gives more than one ESSCertID, the signer /must/ provide the cert
IDs of
/all/ interpretation it allows because any other CA cert is implicitly
forbidden.
I do not see this as realistic because the signer usually does not have
an overview
of which chains all potential verifiers may want use and which TAs they
trust.
In particular, the signer must be aware of all cross-certification
chains it wants to allow.

> of controls, while certificate authorities always possess some freedom.
I did not write that standard, and if I had,
I would have made sure that it is not that unclear/ambiguous.
I would not even have introduced the "feature" of giving more than one
ESSCertID
because I doubt the value of them and the relevance of of the "CA
re-issue attacks"
that they aim to thwart, but discussing that would be a story of its own.

If I was forced to provide that feature,
I'd clearly separate this from the  (optional) constraint given as the
first ESSCertID
and would give the explicit choice whether the referenced set of CA
certificates
(referred to as "authorization certificates" in RFC 2634) shall be used
as a lower
or upper bound of the intermediate CA certs in the validation chain.

I meanwhile did an online search trying to find out how other users and
implementors
of RFC 2634/5035 interpret the feature in question, but could not find much.

BouncyCastle silently ignores further ESSCertIDs
<https://github.com/bcgit/bc-java/blob/master/pkix/src/main/java/org/bouncycastle/tsp/TimeStampToken.java#L186>,
also the IAIK CMSSignedData demo
<https://github.com/alhopper/iaik-cms/blob/master/iaikcms/src/demo/cms/pkcs7cms/PKCS7CMSSignedDataDemo.java#L682>,
which is correct for TSP [RFC 3161/5816] use, but supposedly not for
other uses.
The EU-funded DSS - Digital Signature Services at least complain about
extra ESSCertIDs
<ojects/ESIG/repos/dss/browse/dss-document/src/main/java/eu/europa/ec/markt/dss/validation102853/cades/CAdESSignature.java?at=f53b73317a3e58582a23f6d96b68b7c2d86539f2#435>.

Apart  from those I only know of OpenSSL. The implementation there is
for TS and S/MIME.
It has been done originally by Zoltan Glozik in 2002 and was contributed
in 2006
<https://github.com/openssl/openssl/commit/c7235be6e36c4bef84594aa3b2f0561db84b63d8>.
Multiple ESSCertIDs did not gain much attention, but occasionally people
reported trouble with them.

The only normative document I found to give an interpretation of further
ESSCertIDs is
BSI TR-03125 Anlage TR-ESOR-ERS
<https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03125/BSI_TR_03125_Anlage_ERS_V1_2_1.html>
by the German Federal Office for Information Security (BSI).
In its section 3.6. on verifying an "Evidence Record" it says:

> (A3.6-3) Wenn das SigningCertificateV2 – Attribut Angaben zum
> Zertifikatspfad enthält,
> müssen diese Zertifikate für die Signatur- bzw. Siegelprüfung
> verwendet werden
>
which translates to:
In case the SigningCertificateV2 attribute includes details on the
certificate path,
these certificates must be used for validating the signature or seal,
respectively.

This happens to be the "lower bound" interpretation that I believe is
the one to go for.

    David

---

From: Russ Housley <[email-masked]>
Date: Sat, 13 Mar 2021 15:48:50 -0500

The introduction to Section 5 of RFC 2634 says:

   Concerns have been raised over the fact that the certificate which
   the signer of a CMS SignedData object desired to be bound into the
   verification process of the SignedData object is not
   cryptographically bound into the signature itself. This section
   addresses this issue by creating a new attribute to be placed in the
   signed attributes section of a SignerInfo object.

Then, that section goes on to describe three attacks that are addressed by including the SigningCertificate attribute:

   - Substitution Attack
   - Reissue of Certificate
   - Rogue Duplicate CA

The result in all of these situations is that signer's public key being included in another certificate.

In some PKI environments, there may be no risk for any of these attacks.  In other PKI environments, the protection offered by the SigningCertificate attribute is needed.  The signing certificate attribute prevents the simple substitution and re-issue attacks by restricting the set of certificates to be used in building the certification path for the signer.

The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature.

If more than one certificate is present in the sequence of ESSCertIDs, the certificates after the first one limit the set of certificates that are used in building the certification path for the signer.

If only the signing certificate is present in the sequence, there are no restrictions on the set of certificates that are used in building the certification path for the signer.

I have no insights of offer about the BouncyCastle or the OpenSSL implementations of the  SigningCertificate attribute.

I hope this helps,
  Russ

---

From: David von Oheimb <[email-masked]>
Date: Sat, 13 Mar 2021 23:43:17 +0100

Russ,

thanks for your response. As mentioned the role of the first cert in the
ESSCertID sequence is pretty clear, but how to interpret

"the certificates after the first one limit the set of certificates that
are used in building the certification path for the signer" ?

Should this mean that all certs referenced by the ESSCertIDs must appear
in the validation chain
or that all certs in the validation chain (excluding maybe the trust
anchor) must be referenced by the given ESSCertIDs?

    David

---

From: Russ Housley <[email-masked]>
Date: Sat, 13 Mar 2021 17:47:24 -0500

David:

I interpret it the first way.  Each certificate in the sequence of ESSCertIDs must appear in the certification path used by the replying party.

Russ

> On Mar 13, 2021, at 5:43 PM, David von Oheimb <[email-masked]> wrote:
> 
> Russ,
> 
> thanks for your response. As mentioned the role of the first cert in the ESSCertID sequence is pretty clear, but how to interpret
> 
> "the certificates after the first one limit the set of certificates that are used in building the certification path for the signer" ?
> 
> Should this mean that all certs referenced by the ESSCertIDs must appear in the validation chain
> or that all certs in the validation chain (excluding maybe the trust anchor) must be referenced by the given ESSCertIDs?
> 
>     David
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
>>

---

From: Midnight Wonderer <[email-masked]>
Date: Sun, 14 Mar 2021 09:09:01 +0700

> I interpret it the first way.  Each certificate in the sequence of ESSCertIDs must appear in the certification path used by the replying party.

Fine by me, but as an outsider, the one who doesn't participate in PKI
development or discussing standard, if that is the case, I wonder why
the spec can't simply say:
"The sequence of ESSCertIDs must appear in the certification path in order."?

And not mention about one id or many ids at all; they are simply the same case.
Trying to explain it the way it is, is confusing and unnecessarily
complicated the spec.
As David said, the list of ESSCertIDs is presumed to be the "lower
bound" to be useful, anyway.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 13 Mar 2021 19:23:27 -0800

> "The sequence of ESSCertIDs must appear in the certification path in order."?

If we were writing it again now, we might say such a thing, but this
particular spec was written more than 20 years ago and at that time we
didn't have as much experience as we do now with the different ways in
which confusion can arise during path building.  (Well, I assume we didn't
-- I wasn't working with this stuff back then.)

Simply re-issuing the specification with revised text is not a trivial
matter, given the procedures of the RFC Series, though it can be done if
strongly needed.

-Ben

---

From: David von Oheimb <[email-masked]>
Date: Sun, 14 Mar 2021 13:21:50 +0100

Thanks Russ and Ben for your helpful clarifying responses.

>>> I interpret it the first way.  Each certificate in the sequence of ESSCertIDs must appear in the certification path used by the replying party.

Glad to hear that you confirmed the interpretation that I also found
most reasonable
and which is also the one implied in section 3.6 of BSI TR-03125 annex
TR-ESOR-ERS.

So the implementation in OpenSSL dating back to 2002 has been
interpreting further ESSCertIDs in the wrong way;
this is being corrected in https://github.com/openssl/openssl/pull/14503.
I meanwhile realized that both Java implementations I mentioned
yesterday are wrong for a different reason:
they simply ignore any further ESSCertIDs, and this is not acceptable
for TSP use, either.

> -- I wasn't working with this stuff back then.)

I also presume that the inaccuracy was simply a mistake.

> matter, given the procedures of the RFC Series, though it can be done if

I agree that doing an update of RFC 5035 would be quite some effort.
Yet why not place an erratum as a pragmatic solution?

Although those needlessly vague formulations in RFCs 2634 and 5035 are
not strictly wrong,
they provably constitute a meta-level specification bug: they have been
interpreted wrongly
in major implementations, including OpenSSL and Bouncy Castle.

    David

---

From: Midnight Wonderer <[email-masked]>
Date: Mon, 15 Mar 2021 00:20:25 +0700

Just a heads up, as mentioned by David in his pull request, the new
interpretation also implies that verifiers should accept a blank set
of ESSCertID; and skip verifying certificates if that is the case.
If this looks fine to people on this mailing list, who am I to say otherwise.

However, Bouncy Castle folks seem to assume there will always be at
least 1 ESSCertID available in the sequence.
https://github.com/bcgit/bc-java/blob/2c0804/pkix/src/main/java/org/bouncycastle/tsp/TimeStampToken.java#L110
Which suggested that they probably interpret it the other way.

I don't know how things are done here, but should we continue
immediately after the chairperson announce his interpretation? It
seems to break all major implementations.
Should we wait a bit? Or probably notify Bouncy Castle folks first?

I mean, it weird to me. It seems that the spec was interpreted wrongly
for a decade. And then some dude has an issue, so he sends a pull
request to one of the implementations. And the reviewers connect with
a group that discussing the standard. The group provides the correct
interpretation within a few days, which contradicts all existing major
implementations.

Should we correct the implementation in OpenSSL right away? Or if
there should be some procedure to handle such a case?

---

From: Russ Housley <[email-masked]>
Date: Sun, 14 Mar 2021 13:24:10 -0400

No.  RFC 2634 says that the signer's certificate MUST be included.  The attribute should be omitted if the sequence is empty.

Russ

> On Mar 14, 2021, at 1:20 PM, Midnight Wonderer <[email-masked]> wrote:
>

---

From: Midnight Wonderer <[email-masked]>
Date: Mon, 15 Mar 2021 00:46:47 +0700

> No.  RFC 2634 says that the signer's certificate MUST be included.  The attribute should be omitted if the sequence is empty.

I will let David do the talk this time. He probably read the document
more thoroughly than I do. However, I skimmed through and confirmed
once that he is right on that part.
The message may hide somewhere? Probably away from section 5.

---

From: David von Oheimb <[email-masked]>
Date: Sun, 14 Mar 2021 19:13:00 +0100

On 14.03.21 18:24, Russ Housley wrote:
> No.  RFC 2634 says that the signer's certificate MUST be included.

Russ, where does it say so?

I did not find any requirement in RFCs 2634 and 5035 that the 'certs'
sequence in ...

SigningCertificate ::=  SEQUENCE {
       certs        SEQUENCE OF ESSCertID{,v2}
       policies     SEQUENCE OF PolicyInformation OPTIONAL
   }

... MUST be non-empty.

> The attribute should be omitted if the sequence is empty.
As I gave as an argument to Sarun in the discussion of the pull request
<https://github.com/openssl/openssl/pull/14503>, IMO it makes sense to
allow an empty list of ESSCertIDs,
in order to cover the case that the signer does not want/need to
restrict the certs used for validation but wants to give policy
constraints only.

> The message may hide somewhere? Probably away from section 5.

I'd say: the requirement is AFAICS not present for ESS, but it hides in
other RFCs ;-)
For the specific use with TSP according to RFC 3116 (and  5816), its
section 2.4.2 says:

>       The time-stamp token MUST NOT contain any signatures other than
>       the signature of the TSA.  The certificate identifier (ESSCertID)
>       of the TSA certificate MUST be included as a signerInfo attribute
>       inside a SigningCertificate attribute.
which does require at least one cert ID in time-stamp tokens (referring
to the signer cert).
Also CAdES-BES according to the informational RFC 5126 requires it.

So my conclusions is that generally ESS does not require the signer cert
ID to be included,
but of course applications of ESS can have tighter requirements, and
some of them do.

BTW, just to prevent some potential confusion due to what Sarun wrote below:
BouncyCastle etc. are not wrong in expecting an ESSCertID for the TSP
signer cert,
but, as stated in my last message, they do wrong in ignoring any further
cert ID given.

    David

---

From: Russ Housley <[email-masked]>
Date: Sun, 14 Mar 2021 16:31:08 -0400

In Section 5.4 of RFC 2634:

   The first certificate identified in the sequence of certificate
   identifiers MUST be the certificate used to verify the signature.

Russ

> On Mar 14, 2021, at 2:13 PM, David von Oheimb <[email-masked]> wrote:
> 
> I did not find any requirement in RFCs 2634 and 5035 that the 'certs' sequence in ...
> 
> As I gave as an argument to Sarun in the discussion of the pull request <https://github.com/openssl/openssl/pull/14503>, IMO it makes sense to allow an empty list of ESSCertIDs,
> in order to cover the case that the signer does not want/need to restrict the certs used for validation but wants to give policy constraints only.
> 
> I'd say: the requirement is AFAICS not present for ESS, but it hides in other RFCs ;-)
> For the specific use with TSP according to RFC 3116 (and  5816), its section 2.4.2 says:
> 
> 
> which does require at least one cert ID in time-stamp tokens (referring to the signer cert).
> So my conclusions is that generally ESS does not require the signer cert ID to be included, 
> but of course applications of ESS can have tighter requirements, and some of them do.
> 
> BouncyCastle etc. are not wrong in expecting an ESSCertID for the TSP signer cert,
> but, as stated in my last message, they do wrong in ignoring any further cert ID given.
> 
>     David
> 
> 
> 
>>> On Mar 14, 2021, at 1:20 PM, Midnight Wonderer <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> https://github.com/bcgit/bc-java/blob/2c0804/pkix/src/main/java/org/bouncycastle/tsp/TimeStampToken.java#L110 <https://github.com/bcgit/bc-java/blob/2c0804/pkix/src/main/java/org/bouncycastle/tsp/TimeStampToken.java#L110>

---

From: David von Oheimb <[email-masked]>
Date: Sun, 14 Mar 2021 22:42:58 +0100

>    identifiers MUST be the certificate used to verify the signature.

Hmm, it can well be that the idea was/is that if the SigningCertificate
attribute is present, at least one cert ID must be given.
OTOH, this understanding could also be due to sloppiness in the above
quoted sentence on the use of the definite article "The",
which strictly speaking, from a grammar point of view, would a priori
need an object to refer to.

In my reading the included "MUST" just governs the properties of the
first entry /if present/, and
if the presence of first entry is really required, I'd say the sentence
should have been preceded, e.g., by:

    At least one certificate identifier MUST be present.

Of course one still can simply forbid that the list of cert IDs is
empty. This implies that the corner case I gave below,
namely that signer does not want to restrict any certs used for
validation but wants to give policy constraints (only),
is ruled out - is there no value for that case?

Anyway, if your verdict is not retracted, of course it is no problem at
all to implement an unconditional check
that, also in the general ESS case, any given SigningCertificate
attribute MUST contain a non-empty list of cert IDs.

What do you think about the pragmatic idea to provide the clarifications
we reached here
in the form of errata on RFC 2634 and/or RFC 5035?

    David

>
> On Mar 14, 2021, at 2:13 PM, David von Oheimb <[email-masked]
> <mailto:[email-masked]>> wrote:
>> ... MUST be non-empty

---

From: Russ Housley <[email-masked]>
Date: Sun, 14 Mar 2021 18:17:30 -0400

David:

Sure, it might have been better for the ASN.1 to mandate at lease one item in the SEQUENCE:

  SigningCertificate ::=  SEQUENCE {
       certs        SEQUENCE SIZE (1..MAX) OF ESSCertID,
       policies     SEQUENCE SIZE (1..MAX) OF PolicyInformation OPTIONAL}

  SigningCertificate ::=  SEQUENCE {
       certs        SEQUENCE SIZE (1..MAX) OF ESSCertIDv2,
       policies     SEQUENCE SIZE (1..MAX) OF PolicyInformation OPTIONAL}

However, the author chose to say it in accompanying text.

(More below ...)

> On Mar 14, 2021, at 5:42 PM, David von Oheimb <[email-masked]> wrote:
> 
> Hmm, it can well be that the idea was/is that if the SigningCertificate attribute is present, at least one cert ID must be given.
> OTOH, this understanding could also be due to sloppiness in the above quoted sentence on the use of the definite article "The",
> which strictly speaking, from a grammar point of view, would a priori need an object to refer to.
> 
> In my reading the included "MUST" just governs the properties of the first entry if present, and
> if the presence of first entry is really required, I'd say the sentence should have been preceded, e.g., by:
> 
> Of course one still can simply forbid that the list of cert IDs is empty. This implies that the corner case I gave below, 
> namely that signer does not want to restrict any certs used for validation but wants to give policy constraints (only),

By my reading of the text, that is not supported.

> Anyway, if your verdict is not retracted, of course it is no problem at all to implement an unconditional check
> that, also in the general ESS case, any given SigningCertificate attribute MUST contain a non-empty list of cert IDs.
> 
> What do you think about the pragmatic idea to provide the clarifications we reached here

I do not find the existing text as confusing as you do.  That said, I would suggest getting review of proposed replacement text on the mail list before posting an errata.

Russ

---

From: David von Oheimb <[email-masked]>
Date: Wed, 17 Mar 2021 09:09:08 +0100

On 14.03.21 23:17, Russ Housley wrote:

> I do not find the existing text as confusing as you do.  
I agree in the sense that I see the topic of the 2nd clarification less
confusing and critical than the 1st one
because the question whether a ESSCertID{,v2} list shall contain at
least one entry only influences
the corner case whether signingCertificate{,V2} attributes can be used
to express policy constraints only.

Yet the 1st vagueness, whether the ESSCertID{,v2} list is supposed to
mean a lower or upper bound of the allowed certs in the validation
chain, is major.
As mentioned, several implementations including Bouncy Castle simply
ignore the case that that ESSCertID{,v2} contains more than one element, and
the only implementation that is known to take care of them, in OpenSSL,
has been confused and thus wrong from its beginning nearly two decades ago!

> That said, I would suggest getting review of proposed replacement text
> on the mail list before posting an errata.

1. Here is my proposal for an erratum to RFC 2634:
[

In section 5.4 some aspects of the 'certs' field of a SigningCertificate
attribute:

described in the following sentences are very vague:

    The first certificate identified in the sequence of certificate
    identifiers MUST be the certificate used to verify the signature.
    [....]
    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.

This lead to major confusion and wrong implementations.
As meanwhile has been clarified, this should read as:

    The sequence of certificate identifiers MUST contain at least one
element.
    The first certificate identified MUST be the certificate used to
verify the signature.
    [....]
    If more than one certificate identifier is present in the sequence
of ESSCertIDs,
    all certificates referenced there MUST be part of the signature
validation chain.

]

2. Here is my analogous proposal for an erratum to RFC 5035:
[

In the added section 5.4.1 some aspects of the 'certs' field of a
SigningCertificateV2 attribute:

   SigningCertificateV2 ::=  SEQUENCE {
       certs        SEQUENCE OF ESSCertIDv2,
       policies     SEQUENCE OF PolicyInformation OPTIONAL
   }

described in the following sentences are rather vague:

 certs
      validating the message.
      [...]

This lead to major confusion and wrong implementations.
As meanwhile has been clarified, this should read as:

 certs
    contains the list of certificates that are to be used in
    validating the message. It MUST contain at least one element.
    [...]
    If more than one certificate identifier is present in the sequence
of ESSCertIDv2s,
    all certificates referenced there MUST be part of the signature
validation chain.

]

(One may further mandate/clarify that the certificate identifiers must
be given in the same order
as they are expected in the validation chain, but as mentioned before I
think this is not important
because the order should not play a semantic role and will be determined
by the validation chain anyway.)

>        policies     SEQUENCE SIZE (1..MAX) OF PolicyInformation OPTIONAL}
Concerning the alternative ASN.1 syntax of the /policies/ field included
above:
 
   SEQUENCE SIZE (1..MAX) OF PolicyInformation OPTIONAL

there was no request for clarification, and I do not see the need for a
change there.
(Although it would have been equivalent and IMO more adequate to use simply

    SEQUENCE OF PolicyInformation

for backward compatibility reasons I do not propose to touch anything
here.)

    David

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Mar 2021 22:57:17 -0700

Hi David,

[...]

While your formulations are useful for the mailing-list discussion, when it
comes time to actually submit errata reports they will need to be
formulated a little differently.

The form just has (in addition to some other metadata) the section fo teh
document, "original text", "corrected text", and "notes".  So all the
commentary will need to be in one place, and after the OLD/NEW text.  So,
with this digression over, we should continue to review the OLD/NEW text
and get support for the specific NEW texts. :)

Thanks,

Ben

---

From: David von Oheimb <[email-masked]>
Date: Tue, 23 Mar 2021 08:57:20 +0100

Hi Ben et al.,

according to your feedback on how to (re-)structure the errata texts to
be discussed here before they get submitted,
here is an update of my proposal, which essentially is the same as
before but in the required format.

    David

    Proposal for erratum to RFC 2634

      Section:

5.4

      Original text:

      Corrected text:

    [... (unchanged)]

      Notes:

Some aspects of the 'certs' field of a SigningCertificate attribute:

described in the sentences quoted above are very vague.
This lead to major confusion and wrong implementations.
As meanwhile has been clarified, they should be re-phrased;
see suggested new version above.

(One may further mandate/clarify that the certificate identifiers must
be given in the same order
as they are expected in the validation chain, but I think this is not
important because
the order should not play a critical role and will be determined by the
validation chain anyway.)

    Proposal for erratum to RFC 5035

      Section:

3, which inserts new section 5.4.1

      Original text:

 certs

      Corrected text:

 certs
    [... (unchanged)]

      Notes:

Some aspects of the 'certs' field of a SigningCertificateV2 attribute:

described in the sentences quoted above are rather vague.
This lead to major confusion and wrong implementations.
As meanwhile has been clarified, they should be re-phrased;
see suggested new version above.

(One may further mandate/clarify that the certificate identifiers must
be given in the same order
as they are expected in the validation chain, but I think this is not
important because
the order should not play a critical role and will be determined by the
validation chain anyway.)

On 18.03.21 06:57, Benjamin Kaduk wrote:
> The form just has (in addition to some other metadata) the section of the