[Rats] Re: Last Call comments on draft-ietf-rats-endorsements-09 (Section 4)

[Serhii Nikolaichuk <[e-mail]>]

Thomas,

PR #80 addresses both comments, and I have read the review discussion on it.
No further concerns from me; please consider both resolved.

On the second one in particular: "and therefore the signature-checking keys
endorsed for them" is the part I had not managed to state clearly myself. It
names the mechanism rather than just the property, which is what an
implementer choosing a lookup key actually needs.

Thanks for turning the review around so quickly.

Serhii Nikolaichuk
Austin, Texas

On Fri, Aug 28, 2026 07:36 AM, Thomas Fossati <[e-mail]> wrote:

> Hi Serhii,
>
> Thanks very much for your review.
>
> See https://github.com/ietf-rats-wg/rats-endorsements/pull/80 for an
> attempt at addressing your two concerns.
>
> cheers!
>
> On Wed, Aug 26, 2026 at 9:32 PM Serhii Nikolaichuk
> <[e-mail]> wrote:
> >
> > Hello,
> >
> > Two comments on draft-ietf-rats-endorsements-09, both on Section 4. I
> > implemented a verifier across three TEE families recently, and these are
> > the two places where the draft's abstraction and what I hit in practice
> > diverged. Neither is a blocking concern.
> >
> >
> > 1. Retrievability of an Endorsement is a distinct property, and it
> >    determines whether an unreachable Endorser is a delay or a dead end.
> >
> > Section 4 says:
> >
> >    "Such a certificate might be stored in the Verifier, or might be
> >     resolved on demand via some protocol, or might be passed to the
> >     Verifier along with the Evidence to appraise, depending on the
> >     protocol or general remote attestation procedure.  Details are out
> >     of scope of this document and left to protocol or procedure
> >     specifications."
> >
> > I agree those details belong elsewhere. The property I did not find
> > stated anywhere in the document is this: when the "resolved on demand"
> > mode is used and the Endorser is unreachable, whether appraisal is
> > merely *deferred* or *permanently impossible* depends on something the
> > draft does not name -- whether the Endorsement remains retrievable later
> > and still applies to the Evidence already in hand.
> >
> > For a per-part certificate over an immutable signed report, it does.
> > Retrieval can happen an arbitrary time later and the result is
> > cryptographically identical, because neither input has changed. For an
> > Endorsement with a short validity window, or one covering a part that
> > has since been decommissioned or re-keyed, it may not. Same failure at
> > appraisal time; entirely different consequence for the Evidence.
> >
> > Section 5 does not cover this, correctly, since it concerns the
> > timeliness of claims rather than the durability of the retrieval path.
> >
> > Suggested change: a sentence at the end of that paragraph in Section 4:
> >
> >    "Where a verification key is resolved on demand, specifications
> >     should state whether an Endorsement remains retrievable and
> >     applicable to previously collected Evidence.  This determines
> >     whether an unavailable Endorser defers an appraisal or prevents it."
> >
> > What prompted the comment: during a capture I ran, one vendor's key
> > distribution service was unreachable for a sustained period -- the TLS
> > handshake hung at server-hello from three independent networks, so not a
> > local egress problem. One machine's Evidence was collected intact and
> > its chain validation is still outstanding. In that specific case the
> > completion is genuinely deferrable and I expect to close it. I only
> > realised while writing this that I had no principled reason to expect
> > that, and that the draft gave me none.
> >
> >
> > 2. Identity claims used for key lookup differ in granularity, which
> >    bears on Section 6.
> >
> > Section 4 says:
> >
> >    "Evidence can contain an identifier for the Attester (e.g., [RFC9711]
> >     ueid) in a dedicated "identity claim" that can be used by the
> >     Verifier to look up its verification key for the Attester."
> >
> > Across the three families I worked with, the field that plays this role
> > identifies things at different levels: in one case a security-module
> > instance, in another the physical package. In my data one physical part
> > appears behind several separate Attester instances captured in different
> > runs.
> >
> > Where the verification key is endorsed per physical part rather than per
> > Attester instance, one Endorsement covers many Attesters at once. That
> > seems relevant to Section 6, and possibly to the scalability discussion
> > in Section 7.2, and I did not find it addressed. It may be deliberate
> > scoping -- if so, a sentence noting that identity-claim granularity is
> > out of scope would still help an implementer choosing a lookup key.
> >
> >
> > If the working group would find the underlying artifacts useful, I am
> > glad to share them: signed attestation documents from real hardware
> > across three TEE families, including the failed retrieval above kept as
> > a diagnostic. They check offline with a stock Python interpreter and no
> > third-party packages. I would rather not post a link unprompted; ask on
> > the list and I will, or I can send it off-list.
> >
> > Thanks for the document. Section 3 clarified something I had been
> > modelling incorrectly.
> >
> > Serhii Nikolaichuk
> > Austin, Texas
> >
> >
> >
> >
> >
> >
> >
> >
> > ______________
> >
> > _______________________________________________
> > RATS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>
>
> --
> Thomas
>