+1 to the commentary on keeping payloads opaque until after security checks.
One interesting difference between jose and cose, is that jose has: typ: the content type of the token. cty: the content type of the payload. For most JWT use cases the cty value is sorta redundant, since we expect the payload to be of type application/json. For COSE, there is no registered tag for typ, and we might expect many different cty values, since COSE is friendlier as an envelope format to wrapping different content types. I am not sure about CWTs, are they also expected to produce cbor or can they be used to produce json after verify? I am intrigued by the difference between: jwt+json (doesn't make sense) json+jwt (alternative name for JWT?) And cwt+cbor (kinda makes sense) cbor+cwt (alternative name for CWT?) According to the JWT BCP, the specific typing is used to distinguish different types of tokens, and so: typ: subtype+jwt Just to highlight the draft / todos related to this thread: 1. Multiple suffixes draft 2. +cwt suffix registration 3. typ tag for COSE (if parity with JWT BCP is desired) OS On Tue, Apr 4, 2023, 3:35 PM Smith, Ned <[email protected]> wrote: > +1 to: > > > The security & safety aspect is definitely important here – I was > assuming that a receiver that cannot understand/parse the full media type > may just render some informative details about the > > > data object to the user, or log these details in a nice way (so that a > user reading the logs can understand), without necessarily continuing to > process: > > > the receiver should not take any risky / critical actions like > authorizing something, based on a partially parsed data item. Whatever the > media type composition it remains the responsibility of the > > > receiver to not be vulnerable to attacks done by an attacker e.g. > sending half-correct data items to that receiver. > > > > It seems the intent of having a security envelope is that what is inside > the envelope remains off limits (opaque) until the security checks are > satisfied. > > The content-type-name conventions could model the intent that envelope > payloads remain opaque by excluding them from a content-type-name structure > that includes a crypto envelope (e.g., cose, jose, cwt, jwt, eat). When the > cryptographic processing is complete, what remains is the payload and that > payload should/could have a different content-type-name. RATS found it > helpful to define uccs to represent unsigned cwt. For example, if an ar4si > structure was placed in a cose envelope, the content-type-name might be > “application/cose+cbor”. Following the processing of the envelope, the > resulting content might have a content-type-name of > “application/ar4si+cbor”. Alternatively, if the envelope was > “application/cwt+cbor”, the resulting verified output might be > “application/ar4si+uccs”. > > > > Any of the token types (jwt, cwt, eat) are interesting because they have > both an envelope and a content (that is intended to be opaque until after > the security checks are finalized). > > > > In the case of cwt, uccs [I-D.ietf.rats.uccs] would be the expected > emergent content type. But even if cose was used instead of cwt, uccs could > still be a reasonable emergent content type. > > > > Keeping crypto enveloped payloads opaque also implies content-type > nesting. > > > > *From: *RATS <[email protected]> on behalf of Esko Dijk < > [email protected]> > *Date: *Tuesday, April 4, 2023 at 9:16 AM > *To: *Orie Steele <[email protected]> > *Cc: *"Smith, Ned" <[email protected]>, Laurence Lundblade < > [email protected]>, Michael Richardson <[email protected]>, Thomas > Fossati <[email protected]>, Thomas Fossati <[email protected]>, > cose <[email protected]>, rats <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *Re: [Rats] [COSE] [Anima] cose+cbor vs cwt in MIME types > > > > The security & safety aspect is definitely important here – I was assuming > that a receiver that cannot understand/parse the full media type may just > render some informative details about the data object to the user, or log > these details in a nice way (so that a user reading the logs can > understand), without necessarily continuing to process: > > the receiver should not take any risky / critical actions like authorizing > something, based on a partially parsed data item. Whatever the media type > composition it remains the responsibility of the receiver to not be > vulnerable to attacks done by an attacker e.g. sending half-correct data > items to that receiver. > > > > For example, if a receiver logs every failed request carrying a > ‘eat+cwt+cbor’ item where the CWT is incorrect in a CBOR diagnostic > notation in the log file; then the attacker has a nice way to try to > overflow the logs. But the same problem is there if it would be an > ‘eat+cwt’ media type, although slightly different perhaps. (The version of > ‘eat+cwt+cbor’ may give a slightly larger attack surface in > implementations. E.g. a developer may be more tempted to let the receiver > treat the data item as CBOR as a fallback option and do something with it, > thus wasting system resources.) > > > > In ANIMA WG we just had a call to discuss we could have a ‘+cose’ subtype > registered, so that our Voucher format could be “voucher+cose” or > “voucher-cbor+cose” or so. (The latter ‘-cbor’ is appended to distinguish > from the archetypical Voucher data format which is JSON. The fact that the > COSE wrapper is itself CBOR, is independent from that.) > > Input from COSE WG members would be useful for this! > > > > Esko > > > > > > *From:* Orie Steele <[email protected]> > *Sent:* Tuesday, April 4, 2023 17:27 > *To:* Esko Dijk <[email protected]> > *Cc:* Smith, Ned <[email protected]>; Laurence Lundblade < > [email protected]>; Michael Richardson <[email protected]>; Thomas > Fossati <[email protected]>; Thomas Fossati <[email protected]>; > cose <[email protected]>; rats <[email protected]>; [email protected] > *Subject:* Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types > > > > Inline > > > > On Tue, Apr 4, 2023 at 2:55 AM Esko Dijk <[email protected]> > wrote: > > > So you can read the subtype "eat" and then consider it as +cwt, +cose, > +cbor, for an example media type of "application/eat+cbor+cose+cwt" > > > > It looks like in your example the order is reversed; given the existing > examples defined in draft-ietf-mediaman-suffixes-03 Section 2.1? > > > > Let’s assume it is the reverse, namely “application/eat+cwt+cose+cbor”. > Then following the Section 2.1 examples a parser would go through these > steps for example: > > > > - Do I know “application/eat+cwt+cose+cbor” ? No. > - Do I know “+cbor” ? Yes, decode it as CBOR – ok it’s valid, proceed > to next stage of the processing pipeline. > - Do I know “+cose” ? No. Processing stops here. > > > > Is it safe to end here? > > > > > - > - End result: I’ll render it in CBOR diagnostic notation. > > > > Is this safe for a token format? > > > > > - > > > > Another parser might do these steps: > > > > - Do I know “application/eat+cwt+cose+cbor” ? No. > - Do I know “+cbor” ? Yes, decode it as CBOR – it’s valid, proceed to > next stage of the processing pipeline. > - Do I know “+cose” ? Yes, that’s COSE semantics – decode it – it’s > valid, and although I can’t verify the signature, go to next stage of the > processing pipeline. > - Do I know “+cwt” ? No, stop here. > > > > Again is this safe place to end? > > > > > - > - End result: display it as a COSE object. Do not trust it as I can’t > verify the signature. > > > Exactly... This could be desirable, but it makes me a bit nervous... see > "alg=none". > > > > - > > > > Yet another parser: > > > > - Do I know “application/eat+cwt+cose+cbor” ? No. > - Do I know “+cbor” ? Yes, decode it as CBOR – it’s valid, proceed to > next stage of the processing pipeline. > - Do I know “+cose” ? Yes, that’s COSE – decode it – it’s valid, go to > next stage of the processing pipeline. > - Do I know “+cwt” ? Yes, that’s a CWT – now checking that the COSE > payload is correct CBOR with CWT structure inside – okay. > - End result: display it as a CWT. > > > > > > For security oriented APIs this feels like where you want to end... > Perhaps what we are seeing here is an interaction between "safe api design" > and "trying to process stuff that might not be verified, or has been > tampered with"... > > > > > > Using the reverse way "application/eat+cbor+cose+cwt" seems not compatible > with what’s currently written in draft-ietf-mediaman-suffixes-03 about > “pipelines”. > > For example, suppose a “CWT decoder” gets this media type first, and it > then sends “eat+cbor+cose” to the next pipeline stage, that wouldn’t make > sense since the ‘+cbor’ and ‘+cose’ parts were already decoded as part of > ‘+cwt’. > > > > > > I agree, but the JWT BCP uses at+jwt... so you either handle JWT or you > fail... that seems desirable in most security cases. > > > > For completeness here the example from the draft "image/svg+xml+gzip": > > - Do I know "image/svg+xml+gzip" ? No. > - Do I know “+gzip” ? Yes, I can unzip the data – that works. Send the > data to the next pipeline stage. > - Do I know “+xml” ? Yes, that’s just XML – can display it. > > > It is not "just XML".. it is "+xml" vs "application/xml"... this is > discussed in the IETF 116 meeting (and there is no consensus on how the > current draft should be interpreted). > > - https://www.iana.org/assignments/media-types/application/xml > > vs > > - > https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml > - https://www.rfc-editor.org/rfc/rfc7303.html#page-12 > > > > - > - Do I know “svg” ? No. > - End result: display the object in my XML viewer. > > > > (Using here "image/svg+gzip+xml" would lead to incorrect results clearly.) > > > > Yes, this makes me wonder what happens to protected and unprotected > headers, when processing anything with +cwt or +cose in the middle of > multiple suffixes... to me this suggests that they cannot go "in the > middle', unless everything to the left expects them. > > I suppose this concern also applies to +jwt, except in those cases the > intention is very clearly to produce a specific subtype that is also a JWT. > > Arguing against myself: > > “application/eat+cwt+cose+cbor” seems ok if the goal is to end at COSE > without verifying (a tamper friendly media type). > > “application/eat+cwt” seems ok if the goal is to end at an eat token or > fail (tamper unfriendly) > > I am nervous about specifying "verifiable media types" that in practice > processing of verifying can be skipped, and it seems like multiple suffixes > is a gateway to seeing more of these in the future. > > I think it would be nice if the suffixes draft commented on cases where > digital signatures might interact with suffixes, including commenting > on +jwt and +cose. > > > > > > Esko > > > > *From:* Orie Steele <[email protected]> > *Sent:* Tuesday, April 4, 2023 02:09 > *To:* Smith, Ned <[email protected]> > *Cc:* Laurence Lundblade <[email protected]>; Esko Dijk < > [email protected]>; Michael Richardson <[email protected]>; > Thomas Fossati <[email protected]>; Thomas Fossati < > [email protected]>; cose <[email protected]>; rats <[email protected]>; > [email protected] > *Subject:* Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types > > > > Per the JWT BCP, regarding typ. > > > > https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing > > > > The +jwt suffix goes on the end. > > > > You would need to register +eat as a structured suffix otherwise. > > > > My understanding is that you currently intend to register application/eat > as a subtype, not a structured suffix (you can do both, see json). > > > > The 116 meeting mentions that while it is the case today that most > structured suffix are also registered subtypes, this might not be a > reliable assumption in the future. > > > > The current multiple suffixes draft makes it clear that processing of > suffixes is right to left (confusing / surprising perhaps). > > > > So you can read the subtype "eat" and then consider it as +cwt, +cose, > +cbor, for an example media type of "application/eat+cbor+cose+cwt" > > > > As I mentioned before, the multiple suffixes draft might not land... So it > would be better to avoid multiple plus and follow the conventions from the > JWT BCP, and avoid registering new or interesting suffixes, given the > current confusion regarding them. > > > > I'm not saying any of this is correct, just noting what the suffixes draft > says today, and how it is related to the several +jwt media types that have > already been registered. > > > > Another interesting case to consider... Data URI of type "eat+jwt+gzip"... > Since base64 URL encoding can quickly max out QR Codes / NFC or URL limits. > > > > Decompress, verify, parse / validate. > > > > OS > > > > > > On Mon, Apr 3, 2023, 6:36 PM Smith, Ned <[email protected]> wrote: > > > application/eat+cbor+cose+cwt > > > > EAT is a specialization of a CWT or a JWT. What in eat is encoded before > the cbor (which encodes the token)? > > > > If the conceptual message is identified by a message wrapper > draft-ftbs-rats-msg-wrap-02 > - RATS Conceptual Messages Wrapper (ietf.org) > <https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/>, then the > cbor bytes could be encoded in an cmw array. As in: > > `[ “application/cbor+cose+cwt+eat”, bstr ]` > > > > The discussion around cmw hasn’t concluded, but in theory, the array > structure could be embedded in a conveyance protocol or message that would > have some way to identify it as a cmw. The cmw I-D doesn’t try to define a > media type name for `cmw-array`. Hopefully, that isn’t needed. But it is > the outer most onion skin before talking about conveyance protocol / > message framing. > > > > -Ned > > > > *From: *Orie Steele <[email protected]> > *Date: *Monday, April 3, 2023 at 3:21 PM > *To: *"Smith, Ned" <[email protected]> > *Cc: *Laurence Lundblade <[email protected]>, Esko Dijk < > [email protected]>, Michael Richardson <[email protected]>, > Thomas Fossati <[email protected]>, Thomas Fossati < > [email protected]>, "[email protected]" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types > > > > Inline: > > > > On Mon, Apr 3, 2023 at 3:10 PM Smith, Ned <[email protected]> wrote: > > > there’s no standard for the key material and key identification > > The observation is that the COSE block contains a key-id that can be used > to locate the key material (e.g., I assume key material refers to the > public key needed to verify the COSE signature given asymmetric crypto). > The COSE parser (layer) would normally be equipped to handle this sort of > thing. If the media type was ‘cwt’ the parser would have to support > everything in the COSE layer as well as what’s in the token part as well. > EAT adds additional parsing requirements on top of CWT. Hence, the > expression “application/cbor+cose+cwt+eat” isn’t unreasonable. > > > > I would expect something more like this (according the current suffixes > draft): > > application/eat+cbor+cose+cwt > > or simply: > > application/eat+cwt (since cwt implies cbor + cose) > > Closest JWT analogy currently in the registry: > > - https://www.iana.org/assignments/media-types/application/at+jwt > - https://www.rfc-editor.org/rfc/rfc9068.html > > keep in mind the multiple suffixes is not yet an RFC... if you can avoid > multiple suffixes, I think it is very wise to do so. > > The reason to use multiple suffixes is to signal that there is meaningful > processing that can be done... for token formats, I feel this is less true > than json flavors, such as "application/vc+ld+json". > > I had a discussion with friends at IETF 116 about "sd+jwt" vs "sd-jwt", > related to > https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-03.html#name-iana-considerations-24 > > For example, sd-jwt implies normal jwt processing is not meaningful, > whereas sd+jwt implies jwt processing is meaningful... There were good > arguments on both sides. > > Given the current state of consensus on multiple suffixes, I would > potentially avoid taking a dependency on it if possible, sticking to just 1 > plus. > > > > Someone could argue that “…+cose+cwt…” doesn’t add anything, as “+cwt” > alone could infer both. The same is true for “…cbor+eat…”. > > But I think there is value in being able to describe a fully qualified > representation that is the primitive representation after the various > inferred representations have been computed. > > > > > but that’s about the library, not dispatching some content arriving to a > particular application > > I think the value is it doesn’t assume monolithic applications. A library > or processor that is specific to the encoding between the pluses, e.g., > “+cose+”, can be used in some sort of highly optimized pipeline, rather > than presumed to be a monolith. > > > > *From: *Laurence Lundblade <[email protected]> > *Date: *Monday, April 3, 2023 at 12:44 PM > *To: *Orie Steele <[email protected]> > *Cc: *"Smith, Ned" <[email protected]>, Esko Dijk < > [email protected]>, Michael Richardson <[email protected]>, > Thomas Fossati <[email protected]>, Thomas Fossati < > [email protected]>, "[email protected]" <[email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types > > > > I’m not sure identifying something as COSE, or even CWT is that useful > because there’s no standard for the key material and key identification > that cuts across all uses of COSE or CWT. > > > > For example with EAT the receiver probably will need an endorsement (a > very specific thing with very specific semantics) with a public key to be > able to process the CWT/COSE. If COSE is used for encrypted email (a future > S/MIME), the key material identification will probably be really different. > It’s hard for me to see what a generic COSE/CWT handler is going to do > here. It’s good and well if an EAT processor uses the same COSE library as > an S/MIME processor, but that’s about the library, not dispatching some > content arriving to a particular application. > > > > No objection to the work here. Just some observations. > > > > LL > > > > > > > > On Apr 3, 2023, at 11:14 AM, Orie Steele <[email protected]> > wrote: > > > > Yes! That seems to have been one proposal, related to cleaning up the > registry and clarifying interpretation. > > If you have strong opinions on this, please help contribute to the dialog > on this media types list: > > > https://mailarchive.ietf.org/arch/msg/media-types/qO72m31whV5QZmV6kj55KDqS8n8/ > > Regards, > > OS > > > > On Mon, Apr 3, 2023 at 1:12 PM Smith, Ned <[email protected]> wrote: > > Interesting! > > It would be nice if I-D.ietf-mediaman-suffixes could define a backward > compatibility convention that shows how existing / registered > media-type-names can co-exist with I-D.ietf-mediaman-suffixes. > > > > > > *From: *Orie Steele <[email protected]> > *Date: *Monday, April 3, 2023 at 10:47 AM > *To: *"Smith, Ned" <[email protected]> > *Cc: *Esko Dijk <[email protected]>, Michael Richardson < > [email protected]>, Thomas Fossati <[email protected]>, Thomas > Fossati <[email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [COSE] [Rats] [Anima] cose+cbor vs cwt in MIME types > > > > At IETF 116 this draft was discussed: > > - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes > - https://youtu.be/BrP1upACJ0c?t=1744 > > TLDR; there is work in progress to define multiple suffixes, and how they > are interpreted. > > This would be relevant to potential future +cwt media types, it is already > causing us some concern with respect to special cases of +jwt. > > Regards, > > OS > > > > On Mon, Apr 3, 2023 at 12:28 PM Smith, Ned <[email protected]> wrote: > > It seems the early registrations focused on encoding formats for content > to the right of the "+" like '+xml', '+json', '+cbor', '+der', while later > registrations seem to include schema formats like '+jwt', '+sqlite3', and > '+tlv'. > > It would have been nice if the registry defined the right side for > encoding formats and let the left side contain content / schema formats > IMHO. That way, the parsers could scan for the "+" to identify if it > supports the encoding format as a first pass operation. If it can't decode > the first byte, then there's no point in going further. > > If it can decode, then the first byte/bytes may provide insight into what > content is there. For example, a CBOR tagged structure. But additionally, > the left hand side identifies schemas. Given many data structures can be > integrity protected, signed, and encrypted. Supplying a value that > describes a cryptographic enveloping schema / format seems like a > reasonable requirement for the '-label' to the immediate left of the plus, > e.g., "-cose+cbor". > The data within the cryptographic envelope may follow a well-defined > schema such as the RATS ar4si. E.g., "ar4si-cose+cbor". I don't see a > problem with omitting the cryptographic envelope label if no envelope is > provided. E.g., "ar4si-+cbor". > > JWT and CWT are both an envelope and a data model schema, so the > cryptographic envelope could be inferred. But it wouldn't be incorrect to > restate the obvious for the benefit of the parsers who only care about > cryptographic wrapper processing. E.g., "jwt-jose+json" is still a > reasonable way to encode 'jwt'. > > If there are content schemas that are to the left of some other content > schema, then that can be accommodate easily by prepending another 'label-'. > E.g., "ar4si-jwt-jose+json". > > This approach allows an initial parser / message router to get a view of > all the parsers needed to fully inspect the message in advance of making an > initial message routing decision which would enable efficient parser > offload architectures. There could be different registries for the > different types of structure "+label" for encoding formats only, "-label" > to the immediate left of "+" for cryptographic enveloping, and application > formats for the next left most content. > > To make processing even more efficient, the content-type-name should > reverse the order based on outer-most format. E.g., "json+jose-jwt-ar4si". > This way buffer only needs to contain the first bytes up to the '+' and so > forth. > > I realize this goes beyond the initial focus of the discussion thread. But > IETF is also concerned about the long-term future of the Internet and in > optimizing wherever it makes sense. Content typing is just a form of deep > packet inspection that goes beyond network framing. > > Cheers, > Ned > > On 4/3/23, 12:33 AM, "RATS on behalf of Esko Dijk" <[email protected] > <mailto:[email protected]> on behalf [email protected] > <mailto:[email protected]>> wrote: > > > Hi, > > > As for the questions mentioned on these slides: > > > 1. "Is is '-cose+cbor' or '-cbor+cose' > > > The registry > https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml > < > https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml> > lists the subtypes that one have after the '+' sign. > 'cbor' is there but 'cose' is not. 'cwt' is also not there. > > > So for the moment, registering a 'mytype+cose' or 'voucher+cose' or > 'voucher-cbor+cose' is not possible now unless you would also register the > '+cose' as a subtype. RFC 9052 did not choose to register the subtype > '+cose', for whatever reason. > > > Luckily because COSE is just "plain CBOR" itself , we can use the subtype > '+cbor'. So having "voucher-cose+cbor" would be fine. Also "voucher+cbor" > would be equally ok albeit a little bit less informative that it contains > COSE. > > > > > 2. "are they sufficiently different" (this is about > application/voucher-cose+cbor and application/eat+cwt formats) > > > The voucher is not a CWT format, e.g. it does not use the standardized CWT > claims at all. It defines an own format within the constraints of YANG > CBOR, while CWT does not use any YANG semantics. > > > (Now converting the constrained Voucher format into a CWT based format > would certainly be possible; but that's probably not the discussion > intended by these slides.) > > > Regards > Esko > > > PS more detailed info at > https://github.com/anima-wg/constrained-voucher/issues/264 < > https://github.com/anima-wg/constrained-voucher/issues/264> > https://github.com/anima-wg/constrained-voucher/issues/263 < > https://github.com/anima-wg/constrained-voucher/issues/263> > > > -----Original Message----- > From: Anima <[email protected] <mailto:[email protected]>> On > Behalf Of Michael Richardson > Sent: Monday, March 27, 2023 01:19 > To: Thomas Fossati <[email protected] <mailto:[email protected]>>; > Thomas Fossati <[email protected]<mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; [email protected] <mailto:[email protected] > >; [email protected]<mailto:[email protected]> > Subject: Re: [Anima] [Rats] cose+cbor vs cwt in MIME types > > > Michael Richardson <[email protected] <mailto:[email protected]>> > wrote: > > COSE CHAIRS: can we have 5 minutes for this discussion? > > I guess I can make two slides tomorrow and get Thomas to co-author them. > > > I guess we didn't get any time at COSE. > > > > https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf > < > https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf > > > > > _______________________________________________ > Anima mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/anima < > https://www.ietf.org/mailman/listinfo/anima> > > > _______________________________________________ > RATS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/rats < > https://www.ietf.org/mailman/listinfo/rats> > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > > > > *Error! Filename not specified.* <https://www.transmute.industries/> > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > > > > *Error! Filename not specified.* <https://www.transmute.industries/> > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > > > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > > > > [image: Image removed by sender.] <https://www.transmute.industries/> >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
