[Rats] Re: Structure of RATS Verifier Specifications

[Carl Wallace <[e-mail]>]

I don't follow how processing algorithm (Section 9) would move to an architecture document. Section 8 seems like a decent basis for a high level I-D but concrete processing rules need to live somewhere, and an architecture I-D doesn't seem like the right place.

As an aside, while skimming the CoRIM sections referenced below, I noticed the rules in 9.3.4.4 include a bespoke certificate validation algorithm. Is there any reason why this should not just reference Section 6 of RFC 5280?

On 10/23/25, 3:47 PM, "Steven Bellock" <sbellock=[e-mail] <mailto:[e-mail]>> wrote:


By plug-in model I mean the RATS Verifier Architecture will describe , at a high level, a processing flow that somewhat already exists in the CoRIM draft. Normative documents then specify a section of that flow such that, as time goes on, we can update or replace those documents without having to change the overarching abstract processing flow. As such, CoRIM can return to its original mission of


"This document specifies the information elements for representing Endorsements and Reference Values in CBOR format."


As for picture(s), the CoRIM folks already have started a nice one in https://ietf-rats-wg.github.io/draft-ietf-rats-corim/draft-ietf-rats-corim.html#name-reference-verifier-algorith <https://ietf-rats-wg.github.io/draft-ietf-rats-corim/draft-ietf-rats-corim.html#name-reference-verifier-algorith>
________________________________________
From: Michael Richardson
Sent: Thursday, October 23, 2025 12:22 PM
To: Steven Bellock; rats
Subject: Re: [Rats] Structure of RATS Verifier Specifications


Steven Bellock <sbellock=[e-mail] <mailto:[e-mail]>> wrote:
> From the perspective of correctness and cleanliness, starting from 9334
> we should dig down into the Verifier box through an informative
> architecture document that describes these seven (or more?) phases of
> the RATS Verifier processing pipeline. Using a plug-in model,
> subsequent normative documents then provide limited and concrete
> specifications for one or more phases of verification. As such, large
> swaths of the current CoRIM draft move to this document, thus
> increasing the probability that CoRIM actually becomes an RFC.


I complained a few months ago about the size of the CoRIM document.
~6800 lines of text, compared to ~2700 for 9334.


Your plan seems like a good one to deal with this.
I'm not sure what a plug-in model means for a document, but I'm listening!
Pictures. Diagrams. How would you organize this text?


--
Michael Richardson <[e-mail] <mailto:[e-mail]>> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide










_______________________________________________
RATS mailing list -- [e-mail] <mailto:[e-mail]>
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>