> I understood that some people think that we can encode the map key for
'kty'
> as both 'kty' and also 1.
Perhaps my description has been misleading but, at least for me, it was
very clear that we could NOT encode the map key as 'kty' and also 1 because
the CDDL says that (as Jeremy mentioned).
On 09/08/2021, 21:21, "Laurence Lundblade" wrote:
On Aug 9, 2021, at 12:43 PM, Michael Richardson
mailto:mcr+i...@sandelman.ca>> wrote:
Carsten Bormann mailto:c...@tzi.org>> wrote:
This discussion is all a bit short sighted to me. Sure, we can advise
against registering text labels now. But
> On Aug 9, 2021, at 12:43 PM, Michael Richardson wrote:
>
>
> Carsten Bormann wrote:
>> This discussion is all a bit short sighted to me. Sure, we can advise
>> against registering text labels now. But COSE has a long life with many
>> applications before it, some of which may be outside
Carsten Bormann wrote:
> This discussion is all a bit short sighted to me. Sure, we can advise
> against registering text labels now. But COSE has a long life with many
> applications before it, some of which may be outside what you are
> thinking about now. What’s the rush on
> What’s the rush on disabling these?
You may indeed be right.
At least, I think there may be no need to rush to apply the change
to 8152bis (Maybe that's impossible in the first place though).
Maybe we should discuss this more. I would be happy if you would consider
this matter as the next step
This discussion is all a bit short sighted to me. Sure, we can advise against
registering text labels now. But COSE has a long life with many applications
before it, some of which may be outside what you are thinking about now. What’s
the rush on disabling these?
Sent from mobile, sorry for
> We can deprecate tstr as key.
> We can say that no signer MUST NEVER emit this again.
> We can say that a verifier MAY accept tstr as a key.
This sounds reasonable to me.
Since any tstr labels are not registered in the IANA registry for now and
there are no implementations that support the
Laurence Lundblade wrote:
> I don’t think tstr can be removed from the standard. That would break
> backwards compatibility. Maybe a strong recommendation could be added
> with the comment that many implementations don’t support tstr.
Any system built upon COSE that does not support
Sent from mobile, sorry for terse
> On 6. Aug 2021, at 06:57, Laurence Lundblade wrote:
>
> There is a revision of 8152 in process right now called 8152bis. That seems
> like the place to do it.
Well, rfc 9052/9053 are almost published. But I think we already diagnosed that
it would be
I don’t think tstr can be removed from the standard. That would break backwards
compatibility. Maybe a strong recommendation could be added with the comment
that many implementations don’t support tstr.
There is a revision of 8152 in process right now called 8152bis. That seems
like the place
Hi folks,
> I prefer to see the option of `tstr` labels removed if possible.
I'm glad to see that there are several people who agree with me.
To remove the option of tstr labels from the spec, would a revised RFC be
needed? Or would an errata enough for that?
Anyway, I would like to hear from
Hi list,
I agree with Laurence on this. I work on platform-related security standards at
GlobalPlatform where we are using COSE quite extensively. A major use-case is
highly constrained embedded targets where the benefits from eliminating string
handling are considerable – many such platforms
Yes, I much prefer int labels for a small C implementation. Adding support for
tstr labels would noticeably increase code size. I hope no one registers a tstr
label. It seems unlikely because algorithms are relatively hard to invent and
vet.
LL
> On Jul 28, 2021, at 5:47 AM, Carsten Bormann
Hi Carsten,
Thanks for your quick reply.
> Strings of length 1 Standards Action With Expert Review
> Strings of length 2 Specification Required
> Strings of length greater than 2 Expert Review
I overlooked the above part of the IANA registry.
As for alg, my question was solved and I understood
Hi Daisuke,
> On 2021-07-28, at 13:45, AJITOMI Daisuke wrote:
>
> In my opinion, the tstr type for 'kty', 'alg', 'crv' or 'key_ops' is not
> necessary because I think the major advantage of COSE is its compactness,but
> I would like to know what you are assuming as the value of tstr.
The
Hi folks,
I am an open source CWT/COSE library (Python CWT:
https://github.com/dajiaji/python-cwt) implementer.
I've already implemented most of the functionality of COSE and CWT, but
there are a few things I would like to clarify.
One of the questions I have is the 'tstr' values for 'kty',
16 matches
Mail list logo
