On 2/2/23, 12:00 PM, "Carsten Bormann" <[email protected] <mailto:[email protected]>> wrote:
On 2023-02-02, at 17:53, Carl Wallace <[email protected] <mailto:[email protected]>> wrote: > > Thanks. I did not know that trick and will try it out. I will be curious to > see if the result works relative to the "first rule defines the semantics of > the entire specification" requirement in Appendix C of RFC8610 (I am guessing > not given this spec has three top level structures). RFC 9052 has this right in 1.4: start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types ; This is defined to make the tool quieter: Internal_Types = Sig_structure / Enc_structure / MAC_structure [CW] OK, but the types I was referencing are C509Certificate, C509CertificateSigningRequest and C509CertificateRevocationList. I asked because I was curious how the authors were going to handle that (i.e., with three modules or a socket). > It was encountering that rule this morning that made me ask this question. > The CDDL validators I tried (including yours) enforce that rule. Indeed. My CDDL 2.0 implementation will also have a command line argument to choose the start rule. [CW] Perfect. > So validating a subcomponent, for example, is not possible without having a > CDDL file per validation target (vs having a validator that just walks the > rules in a CDDL file and reports if a match was found). That is an interesting idea for a tool feature. Might have a few too many false positives (such as any `foo = any` rule). [CW] Defining the start rule is much better. That had occurred to me as well (but I elected for the quick and easy walk the list in a mod to a validator this morning, no false positives in my case fortunately). By having a CDDL 2.0 export statement, the guessing could be reduced to the rules “exported”. Grüße, Carsten _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
