Thanks Jeremy, I agree with everything you said. OS
On Thu, Jun 29, 2023 at 11:00 AM Jeremy O'Donoghue < [email protected]> wrote: > It’s taken a while to digest my thoughts on this discussion. I’m coming to > this as an implementer, often (but not always) in constrained devices which > need to be interoperable in complex multi-vendor deployments. > > > > The short version is that I **strongly** prefer a single “alg” integer to > further parameterise the key usage space. The use of a construction like > “hkc” is almost certain to complicate interoperability and testing. > Large-scale systems may be able to support many options, but constrained > systems rarely have that luxury. While configuration or profile documents > can help, there is generally a risk over time of there being a large enough > number of configurations that they no longer help very much as everyone > chooses his/her favourite. > > > > I would also like to note that I don’t recommend Carsten’s “combinatorial > bitmap” approach for the same reason – it won’t scale. I have experience in > this from the GlobalPlatform TEE Internal Core APIs where we attempted to > encode information in such a bitmap and ran out of bits over time. New > algorithms **will** be added, and reserved bitfields are never wide > enough. > > > > While crypto-agility is of definite and growing importance, it is not > unreasonable to restrict the space within which agility is permitted to a > subset of the large set of possible options in the name of > interoperability, providing options that provide meaningfully different > levels of security and/or differently constructed algorithms (hence, > presumably, resistant to different classes of attack) > > > > If the time to generate new informational RFCs to define new cipher-suites > for COSE “alg” is too long, we should address this rather than adopting > “hkc” as a workaround. > > > > Outlook really doesn’t manage threading well, so apologies for top-posting > responses to other specific points in the thread below. > > > > *Compliance with existing standards:* This is the COSE list, and I’m only > tangentially interested in JOSE, so answering for COSE. It has been stated, > and I agree that you need the key + alg to determine what to do. I believe > this remains unchanged with the single integer “alg” solution. The “hkc” > solution definitely represents a change, and does overload some concepts > that are described be existing COSE parameters – which implies even more > testing for consistency of all of the information in a COSE structure > before starting to use it. > > > > *Compatibility with design policy of other HPKE application standards:* I > am more interested in maintaining COSE as a reasonably clean, consistent > and comprehensible standard. Compatibility with standards developed > elsewhere falls into the “nice to have” category for me, and is definitely > secondary to the goal of a clean COSE. > > > > *Variety of supportable use-cases: *This is exactly the same with both > proposals, as far as I can tell. The difference is in the mechanism to > define new variations. I regard restricting the default set of operations > as a feature and not a bug. > > > > From my, possibly selfish, vendor and interoperability perspective, > HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM and > HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM do exactly the same > thing, with near-indistinguishable levels of security, so it is not really > clear why I would need both. > > > > HPKE also allows me, if I understand correctly, to select > HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA384-AES256GCM – while legal, I > doubt that this represents a sensible choice for most users. > > > > In short, this is exactly the area where I **like** to see expert review. > > > > *Ease of coding:* I don’t see this as a strong argument for “alg” over > “hkc”. It is probably true that “alg” is smaller and simpler for > constrained environments as it simplifies checking in cases (common) where > layering of operations is not as clean as might be possible in a larger > implementation, but this is not really a strong justification for the > approach. > > > > In the counter-direction, the argument in favour of “hkc” as simpler from > an ease of coding perspective only applies if there is a clean separation > between the COSE and HPKE layers. For me, the essential separation is > between the description of the encoding and cryptographic libraries – it is > not a given that there needs to be a separate HPKE layer, so I don’t see it > as proven that this approach is superior. > > > > In any case, for systems like these, the coding time for a new algorithm > is far exceeded by the time needed to complete validation to a satisfactory > level. > > > > *Facilitating Algorithm Choice:* I’ve worked for many years with people > who develop Trusted Applications on GlobalPlatform TEE where the > cryptographic APIs allow a great deal of flexibility. I have seen far more > security errors resulting from people choosing inappropriate cryptography > than I have seen benefit from that flexibility. There is a huge benefit in > having expert scrutiny to select a relatively small set of options that > cover common use-cases over letting people do bad things. > > > > This means that I strongly favour simplification of usage for the 99% of > users who just want to do something secure. The 1% who have special > use-cases must certainly not be prevented from doing so, but I don’t really > care if they must deal with a slightly more inconvenient representation. In > short, optimize and guide towards for the correct usage of the common > use-cases while not actively preventing other options. > > > > This also helps hugely with interoperability as it provides a tractable > combination of options to test (this is not a trivial factor for product > vendors). > > > > *Ease of Adding a new HPKE KEM: *I don’t agree on the assumption that > HPKE will be provided as a separate layer. This will doubtless often be the > case, but it will not always be true. We certainly don’t “need” to do it. > > > > Adding any new algorithm to a system implies change somewhere, and for the > same reason that I don’t regard “ease of coding” as an argument in favour > of “alg”, I don’t regard “ease of adding a new HPKE KEM” as an argument in > favour of “hkc”. > > > > In particular, I expect to see increasing numbers of systems for which the > layers defined in CBOR are at least partially auto-generated from CDDL, and > in this case I think the effort would be the same. > > > > Also important to consider that many embedded systems are essentially > statically linked and run from a single system image, so making any change > implies creating a complete new image. > > > > Incidentally, solutions like dependabot do not address the problem of > creating adequate validation suites for cryptographic systems, and more > algorithm combinations creates a combinational explosion in the testing > requirements. > > > > *Examples* > > > > Ø > AwesomeHPKEApp.new(suite={kem: DHKEM_X25519_HKDFSHA256(0x20), kdf: > > Ø > HKDF_SHA256(0x01), aead: AES128GCM(0x01)}) > > Ø > > Ø > AwesomeHPKEApp.new(suite="HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM") > > > > Assuming we had a value of 1762 for “alg” representing > “HPKEv1-Base-DKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM”, I offer you: > > > > AwesomeHPKEApp.new(alg=1762) > > > > …which seems shorter still. I’m aware this example is facetious, but in > reality libraries would pre-define constants that an IDE would likely > auto-complete for you (even emacs does such things these days). > > > > Best regards > > Jeremy > > > > On 11/06/2023, 03:26, "COSE" <[email protected]> wrote: > > > > *WARNING:* This email originated from outside of Qualcomm. Please be wary > of any links or attachments, and do not enable macros. > > I'm not attached to including aead information in "alg"... It's not in > ECDH-ES. > > > > Here is an example: > > > > https://github.com/transmute-industries/jose-hpke/blob/main/example.json > > > > My point is APIs expect to be able to rely on alg... To generate keys, and > to restrict what they can be used for... > > > > alg is optional, but when it's present it should be understood. > > > > Consider the format of ES256 signatures... > > > > Ever wonder how to convert DER signatures to that format?... how do you > know the difference between a DER format ecdsa signature and a JOSE one? > > > > > > ES256 isn't just pointing to raw crypto, it's defining what is necessary > to achieve interoperability. > > > > JOSE HPKE interoperability isn't created by embracing the implementation > cost of supporting the entire registry. > > > > It's created by telling implementers what is mandatory to implement. > > > > That starts with naming popular combinations that are worth supporting. > > > > Like ecdsa with sha256 and a signature encoding that doesn't rely asn1... > We call that ES256. > > > > What will we call the combination of HPKE parameters that is used 99% of > the time?... Naming is hard. > > > > > > OS > > > > > > On Sat, Jun 10, 2023, 8:50 PM AJITOMI Daisuke <[email protected]> wrote: > > Hi Laurence, > > First of all, I appreciate your efforts to separate your personal > preferences and base the discussion on objective facts. > > *Compatibility with COSE* > > COSE today centers around a single integer algorithm ID. This is the only > type of algorithm ID defined in 9052 and 9053. It is used in all the > message types and for COSE_key. > > > This is not true. > > > > As John Mattsson (and maybe Ilari) also pointed out, in COSE/JOSE, > a specific cryptographic algorithm is not determined by the algorithm ID > alone, but in combination with the key parameters. > > > > So it should be stated as "COSE today centers around *a combination of > key parameters and* a single integer algorithm ID* bound to the key > operation*." > > Please see the following examples: > > > - kty: OKP + crv: Ed25519 + alg: EdDSA > - kty: EC + crv: P-256 + alg: ES256 (ECDSA-SHA256) > - kty: EC + crv: P-256 + alg: ECDH-ES > > Does "EdDSA" alone specifically determine the cryptographic algorithm at > the granularity of the HPKE cipher suite (a combination of kem/kdf/aead)? > > "HPKE-v1-Base" (perhaps it would be better to append "-KEM") could be > considered closer to the above precedents (EdDSA, ES256, ECDH-ES) than > Orie's proposal, at least in the sense that it doesn't express the details > of the key. > > > > Moreover, all alg values are defined within the scope of the operation > where the key is directly used (cryptographic agility per key operation). > > Orie's proposal significantly deviates from this convention. > > I believe it's clearly against the COSE convention to include AEAD > information, which is originally unrelated to the key, in the alg value. > What are your thoughts? > > Can you confidently say that deviating from the principle of > "cryptographic agility per key operation" won't impact existing > implementations or systems? > > > It might be permissible to include up to KDF based on convention, as it > falls within the scope of the derive_key operation, but including AEAD is > clearly a deviation from COSE convention. > Following the structure of HPKE, I believe it is accurate and better to > keep the alg within the scope of KEM in COSE-HPKE. > > > > Any algorithm negotiation scheme built as suggested in 9052 section 10 is > going to support a single integer because most of COSE uses it. > > > Therefore, this is also not true. > As I mentioned above, the negotiation/determination of cryptographic > algorithms at the same granularity as the HPKE ciphersuites is done by > using not only alg but also the key parameters together. > > As an internal software process in COSE, alg is first used as a switch to > invoke a module per algorithm category (EdDSA, ECDSA, ECDH), and the > selection on a specific cryptographic algorithm is made primarily by the > key parameters (including the key itself). Of course, alg is also used in > the module, but mainly for deciding an additional hashing algorithm, etc. > > In addition, I couldn't find such a description you pointed out in > RFC9052, section 10... > Are you referring to the following part? I cannot interpret it the way you > do. > > * Applications may need to provide some type of negotiation or discovery > method if multiple algorithms or message structures are permitted. The > method can range from something as simple as requiring preconfiguration of > the set of algorithms to providing a discovery method built into the > protocol. S/MIME provided a number of different ways to approach the > problem that applications could follow: > > > > As COSE is used more widely, other protocols and facilities will need to > identify algorithms. For example, X.509-like certificates. We won’t just > see algorithm identification in the COSE RFCs. > > > Sorry. I did not understand this part. Could you please explain it in a > bit more detail? > > > *Ease of Coding *Is it easier to pass an integer around or a structure? > What about error conditions and code size? > > > This "ease of coding" is vague, and it tends to become a subjective > measure and doesn't contribute to a productive discussion, in my opinion. > > > > This point should be narrowed down to whether there is a need to > continuously maintain the implementation of the COSE layer. It is an > essential and straightforward criterion. > > In that regard, the existing draft doesn't require maintenance, while > Orie's proposal would require ongoing maintenance. > > With every addition of a new alg value, mapping rules would need to be > implemented, the invocation conditions for the COSE-HPKE extension would > need to be modified, tests would need to be added, and releases would be > necessary. > > > It is evident that the existing draft is superior. > > Furthermore, regarding COSE-HPKE, I believe it is necessary to consider > the separation of the COSE layer and the HPKE layer. > > It is desirable from a software design perspective for the COSE layer to > only have a pass-through mechanism to HPKE and delegate all matters related > to HPKE to the HPKE layer. > > *Facilitating Algorithm Choice* > What I bring up here is how implementors and deployers will choose what > algorithm(s) to use. How will the pick from the lists of available > algorithms? > > > With a single integer we’ll only define a subset of all the combo’s of > what’s possible. We can make the decision easier for many by providing > fewer choices (and if someone doesn’t like the combo we’ve defined, they > have to either go to the trouble to define a new one or use one in the > proprietary space). > > > I contemplated this issue using the example of MLS, which adopts the same > approach as Orie's proposal. > > (Note that it's not a popular approach! All of the other HPKE application > specs adopt the same approach as the current COSE-HPKE draft.) > > I would be glad if you could answer as a reply to "6. Ease of cipher suite > selection by application" in my earlier post in this thread if it really > facilitates the decision of the cryptographic algorithm. > > > > From my point of view, the benefits obtained as a trade-off for > sacrificing the significant advantage of flexibility are very small or > perhaps non-existent. > > Even apart from the fact that it goes against the conventions of COSE, the > design of forcefully squeezing HPKE into the alg field, resembling a > ciphersuite, not only fails to make the selection easier but may even have > the opposite effect. > > > > I think that making the decision to narrow down the alg values to just one > (or two) might work. However, in the context of the COSE-HPKE > specification, which should be generic, I consider it a clear mistake to do > so. > > > > *Ease of adding a new HPKE KEM (or other alg)* > > ... > There will still need to be a major SW update for anyone to know about the > new KEM. > > ... > but probably the SW update that needs to be done no matter what sort of ID > we use is a much bigger task. > > > > As I mentioned above, we need to separate the COSE layer from the HPKE > layer. > > > The HPKE layer is most likely to be provided by a near-platform layer such > as openssl. For example, iOS 17 recently added support for HPKE. > > https://developer.apple.com/documentation/cryptokit/hpke > > > I think it is more in line with reality to assume that most COSE libraries > will use HPKE functionality supplied as a dependent library/dependent > platform. > And keeping up with dependent library updates and dependent platform > updates is an essential part of maintaining all software. > > To compare, once this common update work is put aside, we should focus > only on the COSE layer. > Looking only at the COSE layer, the costs associated with adding a new KEM > are as follows. Note that none of these are necessary in the current > COSE-HPKE draft at all. > - Development of an RFC spec defining the algorithm IDs for the new KEMs, > and registration with the IANA Registry > - Is it really that easy to carefully select which ciphersuites to use > with the newly added KEMs? I don't think it is that easy a task as it > requires accountability for the rationale for the selection. > - Even if you consider it easy, this is not just a document, it is an > international standard. It will take more than 6 months to go through > numerous expert reviews and become an RFC. > - Updating the COSE layer implementation and documentation > > So are the additional costs above insignificant compared to keeping up > with updates to dependent libs/platforms? > > Fortunately, with the proliferation of solutions such as github > actions(dependabot, etc.) that make CI/CD effortless, this type of work has > become much easier these days. > (On average, I handle updates to dependent libraries as PRs from > dependabot about once a day. I just open the github app on my phone and > click the button a couple of times.) > > Thus, it's not a big task to begin with, and obviously a minor cost > compared to the additional costs mentioned above (RFC publishing and > updating the implementation and documentation). > This is not a level of difference that depends on how you think about it, > but rather, objectively speaking, there is a stark and significant > difference. > > In summary, you did not directly respond to the 6 advantages of the > existing draft that I listed in my earlier email in this thread, although > you did present his factually based thoughts on my points of (1), (3), (4), > and (6), > As stated above, I must say that there are factual errors and a > significant bias in the scoping and evaluation of the comparables. > > In addition to your responses to my points of (2) and (5), I would like to > see you provide objective factual reasons why Orie's proposal should be > taken. > > > I do not see any advantage at all other than a reduction in message size > by about a few bytes in COSE. Moreover, this advantage backfires in > JOSE/JWK. > > Finally, > > The iOS 17 HPKE library cited above does not adopt a ciphersuite approach, > but an a-la-carte approach. > Why doesn't Apple, which also values the developer experience, adopt the > ciphersuite approach? > In my opinion, the generality required for the iOS HPKE library, which is > limited to "apps that only run on iOS devices," is less than that required > for COSE. > I mean that there is a rationale for narrowing down the number of > ciphersuites more than COSE-HPKE. > > I think this is related to what I wrote in an earlier email in this thread > (6. Ease of cipher suite selection by application) and the following > opinion I appended at the end. > > > > Finally, about the article that Orie seems to be influenced by: > https://www.blockchaincommons.com/musings/musings-agility/ > This article cites TLS1.3 as a good example of a modern approach that > limits cipher suites. > This characteristic of TLS1.3 applies to HPKE as well. > The KEM/KDF/AEAD algorithms of HPKE are already carefully selected. (The > variety of cipher algorithm options in TLS1.3 is even greater than that in > HPKE) > There should be no problem with showing the raw choices of each step in > HPKE to the higher levels. > > > > and, > > I think he prefers ciphersuites over cryptographic agility, but then how > many cipher suites should we define in the COSE-HPKE spec? > As a precedent, let's bring up the cipher suites carefully selected by > experts for MLS. > > https://www.ietf.org/archive/id/draft-ietf-mls-protocol-20.html#section-17.1 > I tried to express them in JWK/JOSE 'alg' values, but just enumerating > them is exhausting due to the length of these names. It's likely to lead to > typing mistakes or incorrect autocomplete, resulting in poor usability. > > > - "HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM" > - "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" > - "HPKEv1-Base-DHKEM(P25519,HKDFSHA256)-HKDFSHA256-ChaCha20Poly1305" > - "HPKEv1-Base-DHKEM(X448,HKDFSHA512)-HKDFSHA512-AES256GCM" > - "HPKEv1-Base-DHKEM(P521,HKDFSHA512)-HKDFSHA512-AES256GCM" > - "HPKEv1-Base-DHKEM(X448,HKDFSHA512)-HKDFSHA512-ChaCha20Poly1305" > - "HPKEv1-Base-DHKEM(P384,HKDFSHA384)-HKDFSHA384-AES256GCM" > > > Let me point out in advance that adding post-quantum KEMs or KEMs for > compressed or compact points for NIST curves will further increase the > variation, and there's no rational reason why COSE should limit this list > to fewer numbers. > Now, how much difference is there in the knowledge required for an > application designer to choose one out of these seven options, compared to > choosing one each from 5 KEMs, 3 KDFs, and 3 AEADs? > > > As you can see from the list of values defined as JOSE 'alg' values above, > the names are long and the similarities between each choice are high. > To choose the desired one from this list, you need to understand HPKE to > some extent. Ultimately, isn't this task almost the same as choosing one > each from 5 KEMs, 3 KDFs, and 3 AEADs? > Should we choose this policy, ignoring the demerits of No.1-5 above? > Moreover, the visibility of the JWK 'alg' value is low, and it is not > developer-friendly. > > > Next, let's imagine a situation where an application developer has to > specify a cipher suite. Is there a difference between the two examples > below? > > > AwesomeHPKEApp.new(suite={kem: DHKEM_X25519_HKDFSHA256(0x20), kdf: > HKDF_SHA256(0x01), aead: AES128GCM(0x01)}) > > > AwesomeHPKEApp.new(suite="HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM") > > > The former still has to internally decompose the suite_id into kem_id, > kdf_id, and aead_id. > > > Best, > Daisuke > > > > 2023年6月10日(土) 2:09 lgl island-resort.com <[email protected]>: > > This is an attempt to structure this as an engineering trade-off decision > between pros and cons. I’m setting this up as a choice between 1) a single > integer alg ID like most of COSE today and 2) a data structure holding a > triple like we have in the latest COSE-HPKE draft. > > > > I’m trying to structure here with the facts and trade-offs separate from > my personal opinion. Hoping that we can agree on some of the facts, even if > we don’t have the same opinion. > > > > *Compatibility with COSE* > > COSE today centers around a single integer algorithm ID. This is the only > type of algorithm ID defined in 9052 and 9053. It is used in all the > message types and for COSE_key. > > > > Any algorithm negotiation scheme built as suggested in 9052 section 10 is > going to support a single integer because most of COSE uses it. > > > > As COSE is used more widely, other protocols and facilities will need to > identify algorithms. For example, X.509-like certificates. We won’t just > see algorithm identification in the COSE RFCs. > > > > My opinion: I prefer the single integer. The triple is something many > COSE-using projects and protocols won’t do by default where the integer is. > > > > > > *Ease of Coding* > > Is it easier to pass an integer around or a structure? What about error > conditions and code size? > > > > For the integer option, some code to map the integer to the three alg > inputs to HPKE is needed. but that is not too complex and similar already > exists in COSE for things like ECDH-ES (alg -29). > > > > For the 3-item structure code is also needed. It will have some error > conditions that decoding a single integer won’t. > > > > My opinion: It’s not a big deal either way, but I prefer the single > integer, based on work in t_cose. > > > > > > *Facilitating Algorithm Choice* > > What I bring up here is how implementors and deployers will choose what > algorithm(s) to use. How will the pick from the lists of available > algorithms? > > > > With a single integer we’ll only define a subset of all the combo’s of > what’s possible. We can make the decision easier for many by providing > fewer choices (and if someone doesn’t like the combo we’ve defined, they > have to either go to the trouble to define a new one or use one in the > proprietary space). > > > > On the other hand, with the triple, the full fanout of the choice is > theirs and there is full flexibility. > > > > My opinion: I lean to the single integer and limited choice because I > think too much choice is not helpful or necessary and many combos don’t > make sense. That said, I can see how some want the full mix-and-match. Note > that COSE ECDH-ES already has the exactly the same fan-out problem and > seems to manage without a triple. > > > > > > *Ease of adding a new HPKE KEM (or other alg)* > > This is about what happens when we need a new KEM, say for PQ. > > > > With the triple, the KEM just gets registered and everything is done as > far as alg IDs and documents. There will still need to be a major SW update > for anyone to know about the new KEM. > > > > With the integer ID, a new integer ID must be created, documented and > registered in addition to the addition to the HPKE registry. The document > only has to be informational though. So the integer ID means some extra > registrations and an informational document. > > > > My opinion: Some advantages for the triple, but probably the SW update > that needs to be done no matter what sort of ID we use is a much bigger > task. Also, the number of new algorithms registered should small, like two > or three. > > > > LL > > > > > > > > P.S. If of interest, here’s a few of the reasons I’ve changed my mind. At > first I was interested in just getting something workable agreed upon that > wasn’t too bad. Over the last months I’ve come think more about how COSE > works as a ecosystem including COSE_Key and algorithm negotiation and came > to see the single integer as a cleaner solution. Then Orie and Christopher > Wood chimed in supporting the single integer. > > > > > > > > > > > > > > On Jun 7, 2023, at 9:45 AM, Ilari Liusvaara <[email protected]> > wrote: > > > > On Wed, Jun 07, 2023 at 07:25:48AM -0500, Orie Steele wrote: > > > HPKE should work without creating new key types for dh kems, and > should work with existing APIs that currently generate keys and > envelopes based on alg. > > > The first part works, and I have written an implementation. > > The second part has _never_ worked in either JOSE nor COSE. I believe > the current record is 5 different key subtypes for one alg (for both > COSE and JOSE)! > > > > A single equality check should confirm if the suite is acceptable to > the recipient, if they have a restricted key. > > > And what about check if suite is acceptable for _sender_? > > I think that barring a major flaw in HPKE, there is no need for > recipient to ever have a restricted key. Interop is separate matter, > and there can be many different supported combinations. > > > > The size and expression of the alg value, should be debated, but > following the conventions and fully specifying HPKE with alg, should > be resolved first. > > > The convetion in COSE is to _not_ have ciphersuites. The some stuff > that looks a bit like ciphersuites is just size optimizations. > > > > COSE HPKE will need to update registries, so let's make the minimal > updates necessary to support what the industries wants to use. > > > I think the minimum number of registry changes possible is 3. > > - A new alg > - A new header parameter > - A new key type or a reserved crv range. > > > > We don't need to create new key types. > > > It is much cleaner to create a new key type than to reserve a crv > range. How is HPKE KEM 48 represented in _systematic_ manner? > > > > We don't need to expose a new way to parameterize alg. > > > Doing so saves a lot of work. > > > > If we don't know which alg values for COSE HPKE need to be registered, > we can wait till people show up who do. > > > What we do know is that it is either going to be a long list among time > or 1 up-front. > > > > A simple RFC that follows conventions doesn't take long to update the > registry. > > > It is still unnecressary work. > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
