Thanks for unpacking this for me.
On Tue, Oct 4, 2022 at 12:08 PM Maik Riechert <[email protected]>
wrote:
> > Is it not possible to put the merkle root in the Countersign_structure
> (protected header) ?
>
>
>
> The way how COSE countersignatures work is that their TBS covers both the
> countersigned COSE_Sign1 envelope (protected header, payload, signature)
> plus the protected header of the countersigner. This is in conflict of
> wanting to countersign multiple envelopes in a single signature (ledgers
> sign many leaves by signing the Merkle tree root).
>
This is the crux of the issue that I did not understand... I'm not sure I
do now, but here goes:
I am hearing this is possible, but not wanted:
[opaque_1, opaque_2, ..] => [CoseSign1, CoseSign2, ...] => { root }
=> [CounterSign1, CounterSign2, ...]
This is wanted, but unsure how to achieve:
[CoseSign1, CoseSign2, ..] => { root } => CounterSign1 =>
[CoseSign1 + CounterSign1, CoseSign2 + CounterSign1, ...]
It seems like maybe not a "countersignature" use case... unless the second
signature is truly over the first one...
I'm now understanding why the need to register a new algorithm if the
"standard countersignature" is not usable... to expand the definition of
"countersignature" to "over merkle roots" OR "over original signatures".
Is there concern about "removing the counter signature" from the "receipt"
?
Because if not, you can possibly just inject a normal CoseSign1 (with crit)
in the unprotected header (of the original CoseSign1) maybe... and nothing
new would be needed?
^ If this is not acceptable, I guess we really do need a new form of
counter signature, that is not over a signature, but is over a merkle root
instead.
Hence, to get around this, you can create a new format that allows this
> (the current SCITT receipt I-D is an example of that), or you can be a
> little creative with what a signature means and use standard COSE plus new
> signature algorithms (that deal with the binding of individual envelopes to
> the tree root signature using Merkle tree inclusion proofs under the hood).
>
>
>
> > For all signature algorithms, and all merkle proof encoding algorithms
> (only SCITT-CCF proposed today) , let a new registry entry be:
> MERKLE_PROOF_FORMAT + - + SIGNATURE_ALG.
>
> > ^ Is this the proposal?
>
>
>
> As mentioned earlier, an alternative is to use MERKLE_PROOF_FORMAT alone
> and move the inner SIGNATURE_ALG inside the signature structure itself.
>
^ This approach was also suggested when JWP was proposed at IET114...
Essentially, register a single new `alg` value, and then prepend the merkle
root, signature alg, and receipts to the signature....
I'm not a huge fan of "overloading the signature"... especially in JOSE /
base64url encoded JSON... for CBOR, it seems more reasonable.
I would love to hear from others on this.
>
> *From:* Orie Steele <[email protected]>
> *Sent:* Dienstag, 4. Oktober 2022 16:46
> *To:* Maik Riechert <[email protected]>
> *Cc:* Mike Prorock <[email protected]>; Russ Housley <[email protected]>;
> [email protected]; cose <[email protected]>
> *Subject:* Re: [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2
> countersignatures
>
>
>
> Inline:
>
>
>
> On Tue, Oct 4, 2022 at 10:17 AM Maik Riechert <[email protected]>
> wrote:
>
> The repo you linked to uses JWP, which is a new proposed envelope format.
> That’s exactly what we’re discussing here: use a new custom format, or
> represent it as signature algorithm.
>
>
>
>
>
> I don't understand why either is needed.
>
> Your CDDL proposal below doesn’t work. The TBS of the signature value
> below is over Countersign_structure. But what we need is the TBS to be the
> Merkle tree root.
>
>
> Is it not possible to put the merkle root in the Countersign_structure
> (protected header) ?
>
>
> And that can be achieved by nesting the actual signature within an outer
> “meta”-signature through a custom signature algorithm that would know how
> to verify that structure using additional information like the Merkle tree
> path.
>
>
>
>
>
> Where does the "Merkle tree path" go?
>
>
>
> This sounds like a hint to a verifier about how to interpret the
> "Countersign_structure" header claims... which I assume would be signalled
> in the protected section of the Countersign_structure.
>
> It reminds me of "crit"..
> https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.11
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7515.html%23section-4.1.11&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953841997670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=59vBqnUImaTAi48aWv0p7CGk9rG8eklwpYJOz0uO6z8%3D&reserved=0>
>
> > The "crit" (critical) Header Parameter indicates that extensions to
> > this specification and/or [JWA] are being used that MUST be
> > understood and processed.
>
> See it in use: https://www.rfc-editor.org/rfc/rfc7797#section-6
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7797%23section-6&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ww7fBCP38CVcYbnhEP79qx%2FviysXMtu1YIUr%2BFNdNdk%3D&reserved=0>
>
>
>
> I’d like to call attention again to Russ’ message just so we don’t loose
> sight of it:
>
> > If I understand this proposal correctly, a value for SCITT-CCF-ES256
> would be added to the IANA-maintained COSE Algorithms registry. Right now,
> all of the entries are for cryptographic algorithms. I'd like to hear what
> the Designated Experts think about using the registry to identify an
> application-specific structure in addition to the cryptographic algorithm.
>
>
> Certainly we could create new registry entries for this, mapping from:
> https://www.iana.org/assignments/cose/cose.xhtml
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcose%2Fcose.xhtml&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=gFH8FSVA5PG9ToXgn3h90NnGKd6UZowxo5nGkSSORek%3D&reserved=0>
>
>
> For all signature algorithms, and all merkle proof encoding algorithms
> (only SCITT-CCF proposed today) , let a new registry entry be:
> MERKLE_PROOF_FORMAT + - + SIGNATURE_ALG.
>
>
> ^ Is this the proposal?
>
>
>
>
>
>
> *From:* Orie Steele <[email protected]>
> *Sent:* Dienstag, 4. Oktober 2022 16:06
> *To:* Maik Riechert <[email protected]>
> *Cc:* Mike Prorock <[email protected]>; Russ Housley <[email protected]>;
> [email protected]; cose <[email protected]>
> *Subject:* Re: [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2
> countersignatures
>
>
>
>
>
> [
> / protected h'A201260300' / << {
> / alg / 1:-7, / ECDSA 256 /
> / ctyp / 3:0 *<--* ... for example "application/spdx-sbom" (not
> currently a real ctyp)
> } >>,
> / unprotected / {
> / kid / 4: "11",
> / countersign / 11: [
> / protected h'A1013823' / << {
> / alg / 1:-36 / ECDSA 512 / <--- counter signature alg...
> already reserved.
>
> ... we could inject the merkle proof here as well.
> *"merkle_alg" : SCITT-CCF,*
> *"merkle_root": "merkle_root".*
> } >>,
> / unprotected / {
> / kid / 4: "[email protected]"
>
> *"merkle_receipt": "path from the original leaf (original
> COSE Sign1) to the merkle root... encoded in CBOR".*
> },
> / signature / h'01B1291B...'
> ]
> },
> / payload / 'This is the content.', <-- For example SPDX SBOM.
> / signature / h'BB...'
> ]
>
> I've tested this and it works with JOSE, for example:
>
>
> https://github.com/w3c-ccg/Merkle-Disclosure-2021/tree/main/packages/json-web-proof/ref-impl
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c-ccg%2FMerkle-Disclosure-2021%2Ftree%2Fmain%2Fpackages%2Fjson-web-proof%2Fref-impl&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=GCoJOpypBfxTAkB%2Fs%2BvpeHhMPO9nO0upZaAJvmxYrjE%3D&reserved=0>
>
> ^ This package uses a "signed merkel root" + "merkle receipts" to create a
> selective disclosure scheme, where a prover can prove a message is in a
> merkle root that was signed by an issuer.
>
> In your construction, I don't think we care to support selective
> disclosure, and the counter sign issuer is the one who signs over the root,
> the original issuer is part of the COSE Sign1 that becomes the leaf.
>
> Maybe I am not understanding the objective.
>
> I don't understand what a "ledger transaction" looks like... is that a
> "merkle receipt" (a proof of leaf inclusion in a merkle root) ?
>
> Regards,
>
> OS
>
>
>
> On Tue, Oct 4, 2022 at 9:54 AM Maik Riechert <[email protected]>
> wrote:
>
> No, this wouldn’t work, as this would assume that each ledger transaction
> is signed individually. The signature is over the Merkle tree root. And
> only the extra information binds it to the actual leaf we care about (the
> original COSE envelope plus the countersigner protected header).
>
>
>
> *From:* Orie Steele <[email protected]>
> *Sent:* Dienstag, 4. Oktober 2022 15:21
> *To:* Maik Riechert <[email protected]>
> *Cc:* Mike Prorock <[email protected]>; Russ Housley <[email protected]>;
> [email protected]; cose <[email protected]>
> *Subject:* Re: [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2
> countersignatures
>
>
>
> Looking at the examples:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign#appendix-A.2.1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign%23appendix-A.2.1&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Xc7JqGE2zS5Dw3oIztcyfnzEc4H%2Fk6ydOmx%2F977xWZ0%3D&reserved=0>
>
> [
> / protected h'A201260300' / << {
> / alg / 1:-7, / ECDSA 256 /
> / ctyp / 3:0 *<-- ... for example "application/spdx-sbom" *(not
> currently a real ctyp)
> } >>,
> / unprotected / {
> / kid / 4: "11",
> / countersign / 11: [
> / protected h'A1013823' / << {
> / alg / 1:-36 / ECDSA 512 /* <--- counter signature alg...
> already reserved.*
>
> ...
> *we could inject the merkle proof here as well. *
> *"receipt_alg" : SCITT-CCF, * *"receipt": {}*
> } >>,
> / unprotected / {
> / kid / 4: "[email protected]"
> },
> / signature / h'01B1291B...'
> ]
> },
> / payload / 'This is the content.',* <-- For example SPDX SBOM.*
> / signature / h'BB...'
> ]
>
> Does this match what you were saying above?
>
> Regards,
>
> OS
>
>
>
> On Tue, Oct 4, 2022 at 8:56 AM Maik Riechert <[email protected]>
> wrote:
>
> Orie, sure, that can be done by moving the base alg in the signature
> structure, similar to the referenced RFC. Then alg would be “SCITT-CCF”,
> and for non-CCF implementations it may be another custom alg or an existing
> alg (e.g., “ES256” if every COSE envelope is countersigned individually,
> rather than signing a Merkle tree root periodically).
>
>
>
> Note that “cty” doesn’t exist for COSE countersignatures, since there is
> no payload of the countersigner. Instead, any metadata from the
> countersigner would be part of the protected header. See also
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=a73rWP1ZcEwtWKWWYqvJcXabAUMDeA3%2FFoZSJwAzlVk%3D&reserved=0>
> .
>
>
>
> *From:* Mike Prorock <[email protected]>
> *Sent:* Dienstag, 4. Oktober 2022 14:48
> *To:* Orie Steele <[email protected]>
> *Cc:* Russ Housley <[email protected]>; Maik Riechert <
> [email protected]>; [email protected]; cose <[email protected]>
> *Subject:* [EXTERNAL] Re: [COSE] SCITT receipts as COSE V2
> countersignatures
>
>
>
> Likewise I am with Orie on this one
>
>
>
> cty or similar would make things a whole lot cleaner for Interop reasons
> and prevents a lot of potential confusion and complexity
>
> Mike Prorock
> mesur.io
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmesur.io%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=yLVmFtZ80OnTCz%2FuHOjmsSe5U7XyttcrYr%2BQgzCB6Ng%3D&reserved=0>
>
>
>
> On Tue, Oct 4, 2022, 07:01 Orie Steele <[email protected]> wrote:
>
> I'm a -1 to needing to register a new alg for every existing registered
> alg when used with counter signatures... specifically:
>
> - SCITT-CCF-ES256
> - SCITT-CCF-EdDSA
> - SCITT-CCF-ES384
> - SCITT-CCF-FANCY_NEW_PQC_1
> - SCITT-CCF-FANCY_NEW_PQC_2
> - SCITT-CCF-FANCY_NEW_PQC_3
>
> Can we move the "application specific" component of the "alg" value to a
> separate field?
>
> Example:
>
> alg: ES256 // support existing alg values with no
> changes
> cty: 'application/scitt-ccf' // signal the content type
>
> ?
>
> Regards,
>
> OS
>
>
>
> On Tue, Oct 4, 2022 at 7:44 AM Russ Housley <[email protected]> wrote:
>
> If I understand this proposal correctly, a value for SCITT-CCF-ES256 would
> be added to the IANA-maintained COSE Algorithms registry. Right now, all
> of the entries are for cryptographic algorithms. I'd like to hear what the
> Designated Experts think about using the registry to identify an
> application-specific structure in addition to the cryptographic algorithm.
>
>
>
> Russ
>
>
>
>
>
> On Oct 4, 2022, at 8:00 AM, Maik Riechert <
> [email protected]> wrote:
>
>
>
> Hi all,
>
>
>
> In the SCITT community call yesterday we had a discussion on receipts (
> https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-receipts-01
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-birkholz-scitt-receipts-01&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Of6IHJ0VmBbgWlQb9upWd%2Ft3qoQTTVcsWAEFXCisxew%3D&reserved=0>)
> and whether they should be represented as standard COSE V2
> countersignatures (
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=a73rWP1ZcEwtWKWWYqvJcXabAUMDeA3%2FFoZSJwAzlVk%3D&reserved=0>
> ).
>
>
>
> The current receipt format’s CDDL is as follows:
>
>
>
> [
>
> service_id: tstr
>
> contents: any
>
> ]
>
>
>
> where `contents` depends on the “tree” algorithm (with the requirement
> that it has to contain a protected header somewhere in it) identified via
> parameters associated to the service_id. Currently there is only a single
> tree algorithm (based on a CCF ledger implementation) where the CDDL is as
> follows:
>
>
>
> [
>
> signature: bstr
>
> node_certificate: bstr
>
> inclusion_proof: [+ ProofElement]
>
> leaf_info: [
>
> internal_hash: bstr
>
> internal_data: bstr
>
> protected: bstr .cbor {
>
> issuedAt: uint
>
> }
>
> ]
>
> ]
>
>
>
> In order to support more schemes around key discovery (e.g., DID), it
> makes sense to move the protected header to the front and make it part of
> the common top-level structure:
>
>
>
> [
>
> protected: bstr .cbor {
> service_id: tstr
>
> issuedAt: uint
>
> },
>
> contents: any
>
> ]
>
>
>
> The new `contents` would then look like this:
>
>
>
> [
>
> signature: bstr
>
> node_certificate: bstr
>
> inclusion_proof: [+ ProofElement]
>
> leaf_info: [
>
> internal_hash: bstr
>
> internal_data: bstr
>
> ]
>
> ]
>
>
>
> If you then squint a bit more, you can re-imagine this as a COSE V2
> countersignature:
>
>
>
> [
>
> protected: bstr .cbor {
> alg: tstr
> service_id: tstr
>
> issuedAt: uint
>
> },
>
> unprotected: { * label => values }
>
> signature: bstr
>
> ]
>
>
>
> For the CCF tree algorithm, this would equate to `alg` being a new
> identifier (e.g., “SCITT-CCF-ES256”) and the signature being the `contents`
> structure wrapped as bstr.
>
>
>
> Russ raised concerns that carrying all of the additional bits in the
> signature bytes may be hard to justify when it comes to registration of the
> new signature algorithm in COSE’s IANA registry. There seems to be
> precedent though, for example
> https://datatracker.ietf.org/doc/html/rfc8778
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8778&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=98SNXmYoA3Cr4yj2f8kBi8Q5dUscuLlmjdAoUPiQYxk%3D&reserved=0>
> where
> for Leighton-Micali the signature value (see 2.2) is a structure containing
> a leaf number, an LM-OTS signature, a type code indicating a subalgorithm,
> and a tree path from leaf to root.
>
>
>
> We discussed two alternatives: 1. Keeping it a separate format specific to
> SCITT. 2. Establishing receipts as new COSE message type, though this may
> be more challenging.
>
>
>
> Any discussions and opinions on this topic are highly appreciated.
>
>
>
> Maik
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=wHrfmS5l8XuWSc7HhCNEiZiYZ4A8xer2xJhQFrupskU%3D&reserved=0>
>
>
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842153889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=wHrfmS5l8XuWSc7HhCNEiZiYZ4A8xer2xJhQFrupskU%3D&reserved=0>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Jasru3654WCCLHgx4RFtmDaFxQdzvCL1nNNRmkOmNfE%3D&reserved=0>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ITlCV8dq%2FOtrxRdNYfkme20yVTecsA0ftwWkQmDo%2BHQ%3D&reserved=0>
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=JLQoiBCJDGb9fQM1QSxpgmnSxEBGXCJd76wDRPcTaek%3D&reserved=0>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Jasru3654WCCLHgx4RFtmDaFxQdzvCL1nNNRmkOmNfE%3D&reserved=0>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ITlCV8dq%2FOtrxRdNYfkme20yVTecsA0ftwWkQmDo%2BHQ%3D&reserved=0>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Jasru3654WCCLHgx4RFtmDaFxQdzvCL1nNNRmkOmNfE%3D&reserved=0>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ITlCV8dq%2FOtrxRdNYfkme20yVTecsA0ftwWkQmDo%2BHQ%3D&reserved=0>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7Cd769b8a2a1b34bddedec08daa61f9c9c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638004953842310116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ITlCV8dq%2FOtrxRdNYfkme20yVTecsA0ftwWkQmDo%2BHQ%3D&reserved=0>
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
