The Security Considerations section should address conveyance of trust anchors, which have very different security considerations than conveying secure statements like Endorsements.

[thomas-fossati]

[paulhowardarm]

Hi @carl-wallace - could you help me to understand this point that we captured from your review of CoSERV last year?

Is there a threat scenario that you had in mind with this comment?

At the moment, CoSERV is just a mechanism for querying and carrying artifacts, and we've tried to keep it quite generic in the sense that we don't differentiate between the different types of artifact (trust anchors, refvals, endorsed vals).

Can you spell out the "very different" security considerations with trust anchors? I get that they are foundational to any trust model, but I'm unclear on why this means they need to be conveyed differently.

[carl-wallace]

I was not suggesting they need to be conveyed differently but that a CoSERV instance responsible for delivering trust anchors may be operated with more rigor than one that distributes artifacts that are otherwise secured. There're lots of words about trust anchor management requirements in the PKIX document archive, including the draft you referenced and RFCs 5914 and 5934. To some extent, you could argue the security considerations from RFC 5934 apply to a CoSERV instance doing TA management.

As a simple example, it may be perfectly fine to operate a CoSERV instance that mirrors endorsements (which are "secure statements") using a key secured by a software crypto module but you may want to use a hardware crypto module for an instance handling TA management.

[paulhowardarm]

As far as possible, we're trying to limit the scope of CoSERV to describe just the query language and the API, while remaining agnostic about specific deployment considerations (such as how to secure signing keys). It's partly because such considerations apply across the various RATS roles anyway, whether CoSERV is used or not. But it's also because the scope of the document could creep into quite unwieldy spaces if we start making a lot of very specific recommendations. At worst, it could transform into some kind of practical deployment guide for RFC9334. Maybe such a document would be valuable, but I don't think draft-coserv wants to become that document.

That said, we do recognise that the aggregation model and the shallow/deep trust models have some specific deployment considerations. The latest version of the draft is trying to do a better job of addressing that. See in particular the latest security considerations subsection on aggregation, which hopefully addresses the "secure statements" concern.

[paulhowardarm]

Pending review of latest §8.3