> On Jun 23, 2021, at 8:32 PM, Carsten Bormann wrote:
>
> On 23. Jun 2021, at 18:42, Mike Jones
> wrote:
>>
>> I believe that we should create a policy requiring that all future algorithm
>> registrations should be non-polymorphic. Furthermore, I believe we should
>> consider defining and
On 2021-06-24 5:32, Carsten Bormann wrote:
On 23. Jun 2021, at 18:42, Mike Jones
wrote:
I believe that we should create a policy requiring that all future algorithm
registrations should be non-polymorphic. Furthermore, I believe we should
consider defining and registering new
On 23. Jun 2021, at 18:42, Mike Jones
wrote:
>
> I believe that we should create a policy requiring that all future algorithm
> registrations should be non-polymorphic. Furthermore, I believe we should
> consider defining and registering new non-polymorphic algorithm identifiers
> so that
On 2021-06-23 22:59, John Mattsson wrote:
Except helping FIDO/WebAuthn, what concrete benefits do you want to achieve by
duplicating the public key parameters in the signature algorithm?
One very obvious problem is that cryptographic APIs do not understand what
"EdDSA" is.
If you look into
Some of you may have seen this from the secdir email I sent out a few weeks
ago. I think I may have sent it to the wrong place in order to keep things
moving forward, so I'm going to try this list instead. If it's the wrong place
as well, would someone mind pointing me in the right direction
Except helping FIDO/WebAuthn, what concrete benefits do you want to achieve by
duplicating the public key parameters in the signature algorithm?
> Furthermore, I
> believe we should consider defining and registering new non-polymorphic
> algorithm identifiers so that use of the existing
Mike Jones wrote:
> The WebAuthn and FIDO2 working group members had thought that the COSE
> algorithm semantics were the same as those for JOSE, where algorithm
> identifiers are not polymorphic. They were wrong, but that's water
> under the bridge now. The FIDO/WebAuthn usage
> On Jun 23, 2021, at 9:42 AM, Mike Jones
> wrote:
>
> The WebAuthn and FIDO2 working group members had thought that the COSE
> algorithm semantics were the same as those for JOSE, where algorithm
> identifiers are not polymorphic. They were wrong, but that's water under the
> bridge now.
[Writing as an individual - not a chair]
The WebAuthn and FIDO2 working group members had thought that the COSE
algorithm semantics were the same as those for JOSE, where algorithm
identifiers are not polymorphic. They were wrong, but that's water under the
bridge now. The FIDO/WebAuthn
> On Jun 23, 2021, at 11:21 AM, Carsten Bormann wrote:
>
>
>
>> On 2021-06-23, at 17:19, Russ Housley wrote:
>>
>> In order to always regenerate the same byte string for the "to be
>> signed" value, the core deterministic encoding rules defined in
>> Section 4.2.1 of [RFC8949].
>
>
This provides a tighter reference regarding deterministic encoding. The issue
was raised by John Mattsson, and the resolution was proposed by Carsten Bormann.
In addition, I updated the Acknowledgments to include John and Carsten.
Russ
> On Jun 23, 2021, at 11:45 AM, internet-dra...@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the CBOR Object Signing and Encryption WG of the
IETF.
Title : CBOR Object Signing and Encryption (COSE):
Countersignatures
Authors : Jim Schaad
> On Jun 23, 2021, at 10:52 AM, John Mattsson
> wrote:
>
>
> - The order of COSE_Countersignature0 processing at the receiver seems
> undefined. The order should either be mandated or it should be stated that
> the receiving part can process things in any order.
>
> I think that Jim
> On 2021-06-23, at 17:19, Russ Housley wrote:
>
> In order to always regenerate the same byte string for the "to be
> signed" value, the core deterministic encoding rules defined in
> Section 4.2.1 of [RFC8949].
This sentence no verb.
> These rules match the ones laid out in
>
> On Jun 23, 2021, at 11:09 AM, Carsten Bormann wrote:
>
> On 2021-06-23, at 16:52, John Mattsson
> wrote:
>>
>> John: Ok, I think the current text is fine. Section 4.2 of RFC8949 specifies
>> two different orders for maps but that is probably not important for COSE.
>
> If you do need to
On 2021-06-23, at 16:52, John Mattsson
wrote:
>
> John: Ok, I think the current text is fine. Section 4.2 of RFC8949 specifies
> two different orders for maps but that is probably not important for COSE.
If you do need to provide deterministic encoding for maps, please choose the
"Core
Hi Russ,
See inline
From: Russ Housley
Date: Wednesday, 2 June 2021 at 21:54
To: John Mattsson
Cc: cose@ietf.org
Subject: Re: [COSE] Some comments on draft-ietf-cose-countersign-04
Thanks John.
Some comments on draft-ietf-cose-countersign-04
- References:
OLD: [I-D.ietf-cbor-7049bis]
NEW:
17 matches
Mail list logo
