jiebi/CodeConvo huggingface dataset:
Change:
Capture the discussion in the 2022-06-08 interim and .
Comment by NAME : I have a hard time motivating why this can be unadorned CBOR text string, given that these two fields are always human-readable text. Maybe we need to add a default, i.e. that when text used, that is to be interpreted as English language is used.
(w/ TF:) making "foo" a shorthand for 38(["en", "foo", false]) makes sense in the Anglo-American dominated world we live in. Details (en? en-US?) need to be discussed though.
I wouldn't go down the rabbit hole of also picking the locale. Too much stress I'm happy with the minimum required to satisfy the rule, i.e., "en".
In we decided to go with the following: use context if available fall back to english Now, similar to , should we have a (and ) keys for when the CPD is stored/forwarded and therefore the context is lost?
LGTM

Discussion:
2. A Concise Problem Details data item is a CBOR data item with the <del> following structure: </del> <ins> following structure (rules named starting with "tag38" are defined in tag38): </ins> A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered,

Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38 <del> for the definition of the latter. </del> <ins> for the definition of the latter.  Language tag and writing direction information for unadorned text strings are intended to be obtained from context; if that context needs to be saved or forwarded with a Concise Problem Details data item, "base-lang" and "base-rtl" can be used for that.  If no such (explicitly saved or implicit) context information is available, unadorned text is interpreted with language-tag "en" and writing-direction "false" (ltr). </ins> The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered.
Change:
The sign encoding function should deal with other types of curves as well. Make the text refer to the SEC1 encoding function.

Discussion:
private curves can be used as well. contains the x coordinate for the EC point.  The integer is <del> converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string. </del> <ins> converted to an octet string as defined in SEC1.  Leading zero octets MUST be preserved. </ins> contains either the sign bit or the value of y coordinate for the EC point.  When encoding the value y, the integer is converted to an octet string (as defined in SEC1) and encoded as a CBOR bstr. <del> Leading zero octets MUST be preserved.  When encoding the sign of y, the expression 'y > 0' is evaluated and encoded a CBOR boolean. </del> <ins> Leading zero octets MUST be preserved.  The compressed point encoding is also supported.  Compute the sign bit as laid out in the Elliptic-Curve-Point-to-Octet-String Conversion function of SEC1.  If the sign bit is zero, then encode y as a CBOR false value, otherwise encode y as a CBOR true value.  The encoding of the infinity point is not supported. </ins> contains the private key.
Change:
Everybody but me wants a MAC w/o recipients.
There also needs to be an equivalent no-recipient signature version. Thanks.
That string does not even parse.
Should the kid attribute be a binary value rather than a string value?
No arguments that binary should not be the only type for this, some questions that binary is useful based on Jose experience. Definite arguement that binary is required. Doing two types is probably a bad idea.

Discussion:
6. <ins> COSE supports two different MAC structures.  COSE_MAC is used when the key needs to be explicitly identified.  The structure supports the use of recipient structures to allow for random content encryption keys to be used.  COSE_MAC0 is used when the a recipient structure is not needed because the key to be used is implicitly known. 6.1. </ins> In this section we describe the structure and methods to be used when doing MAC authentication in COSE.  This document allows for the use of all of the same classes of recipient algorithms as are allowed for

The CDDL fragment which represents the above text for COSE_Mac follows. <del> 6.1. </del> <ins> 6.2. In this section we describe the structure and methods to be used when doing MAC authentication for those cases where the recipient is implicitly known. The MAC message uses the COSE_Mac0 structure defined in this section for carrying the body. The MAC structure can be encoded either withor without a tag depending on the context it will be used in.  The MAC structure is identified by the CBOR tag TBD6.  The CDDL fragment that represents this is: The COSE_Mac0 structure is a CBOR array.  The fields of the array in order are: is described in header-parameters. is described in header-parameters. contains the serialized content to be MACed.  If the payload is not present in the message, the application is required to supply the payload separately.  The payload is wrapped in a bstr to ensure that it is transported without changes.  If the payload is transported separately, then a null CBOR object is placed in this location and it is the responsibility of the application to ensure that it will be transported without changes. contains the MAC value. The CDDL fragment which corresponds to the above text is: 6.3. </ins> In order to get a consistent encoding of the data to be authenticated, the MAC_structure is used to have a canonical form.

in order are: A text string that identifies the structure that is being encoded. <del> This string is "MAC" for the COSE_Mac struture. </del> <ins> This string is "MAC" for the COSE_Mac structure.  This string is "MAC0" for the COSE_Mac0 structure. </ins> The protected attributes from the COSE_MAC structure.  If there are no protected attributes, a zero length binary string is to be
Change:
Response to note from Göran Selander 1) we need to say where the secret is derived from 2) how it is formatted, and 3) why we are not using KA and KB in the KDF step.

Discussion:
Since the only the math is changed by changing the curve, the curve is not fixed for any of the algorithm identifiers we define. <ins> Shared Secret to Byte String: Once the shared secret is computed using the correct mathematics, the resulting value needs to be converted to a byte string to run the KDF function.  The X coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly as it is a byte string of a known length.  For the P-256, P-384 and P-521 curves, the X coordinate is run through the I2OSP function defined in RFC3447 using the same computation for n as is defined in ECDSA. </ins> Ephemeral-static or static-static: The key agreement process may be done using either a static or an ephemeral key for the sender's side.  When using ephemeral keys, the sender MUST generate a new

If the 'key_ops' field is present, it MUST be empty for the public key. <ins> 12.4.2. Some method of checking that points provided from external entities are valid.  For the 'EC2' key format, this can be done by checking that the x and y values form a point on the curve.  For the 'OKP' format, there is no simple way to do point validation. Consideration was given to requiring that the public keys of both entities be provided as part of the key derivation process.  (As recommended in section 6.1 of RFC7748.)  This was not done as COSE is used in a store and forward format rather than in on line key exchange.  In order for this to be a problem, either the receiver public key has to be chosen maliciously or the sender has to be malicious.  In either case, all security evaporates anyway. A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted. (Either by the end user or by the entity that is responsible for making trust statements on keys.) </ins> 12.5. Key Agreement with Key Wrapping uses a randomly generated CEK.  The

applications to document how content padding is to be done in order to prevent or discourage such analysis.  (For example the strings could be defined as 'YES' and 'NO '.) <del> Timing Issues - TBD </del>
Change:
This is basically the text that Ludwig agreed to. Will seek second confirmation for issue
In Section 13.2. there is the following text: "This key structure contains only private key information, care must be taken that it is never transmitted accidentally. For public keys, there are no required fields. For private keys, it is REQUIRED that 'k' be present in the structure." This should probably read something like this: "This key structure only contains secret (or symmetric) key information, care must be taken that it is never transmitted accidentally. For symmetric keys, it is REQUIRED that 'k' be present in the structure."
What if we change it to be This key structure does not have a form that contains only public members. For symmetric keys, it is REQUIRED that 'k' be present in the structure.
I really have nothing against the "care must be taken ..." part. I'd actually tend to leave it in, but feel free to rephrase that as you see fit.

Discussion:
contains the value of the key. <del> This key structure contains only private key information; care must be taken that it is never transmitted accidentally.  For public keys, there are no required fields.  For private keys, it is REQUIRED that </del> <ins> This key structure does not have a form which contains only public members.  As it is expected that this key structure is going to be transmitted, care must be taking that it is never transmitted accidentally or insecurely.  For symmetric keys, it is REQUIRED that </ins> 'k' be present in the structure. 14.
Change:
We change the title of the document Implement the suggested change from Carsten that we put nils in to unused elements in the ParytInfo structure. I was a bit more complete than the original suggestion but it is probably simpler to get right that way.
It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field. The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later. It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode, modify and re-encode any of the top level information. I don't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one.
Did not correctly read the spec.

Discussion:
<del> CBOR Encoded Message Syntax </del> <ins> COSE: A Message Based Security Solution for CBOR </ins> draft-ietf-cose-msg-latest Abstract

Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size.  There is a need for the ability to have the basic security services defined for this data <del> format.  This document specifies processing for signatures, message authentication codes, and encryption using CBOR.  This document also specifies a representation for cryptographic keys using CBOR. </del> <ins> format.  This document defines the CBOR Object Signing and Encyption (COSE) specification.  This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization.  This specifiction additionally specifies how to representat cryptographic keys using CBOR. </ins> Contributing to this document

can thus be inferred rather than made explicit.  If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information.  The <del> identity information does not need to be specified and can be left as absent. </del> <ins> identity information does not need to be specified and is set to nil in that case. </ins> This contains a nonce value.  The nonce can either be implicit from the protocol or carried as a value in the unprotected

used to carry this value in the message However, the nonce value could be determined by the application and the value determined from elsewhere. <del> This item is optional and can be absent. </del> <ins> This option does not need to be specified and is set to nil in that case </ins> This contains other information that is defined by the protocol. <del> This item is optional and can be absent. </del> <ins> This option does not need to be specified and is set to nil in that case </ins> This field holds information about party V.  The content of the structure are the same as for the PartyUInfo but for partyV.
Change:
Started a birthday attack consideration, but it is not valid as far as I can tell so remove it.

Discussion:
Have any security considerations that are part of the message been enforced (as specified by the application or crit parameter)? <del> This document defines several algorithms where the computed authentication tag can be truncated to a shorter value than the default value.  Doing this truncation affects the authentication service provided by this value.  In general, [CREF3] </del> There are a large number of algorithms presented in this document that use nonce values.  For all of the nonces defined in this document, there is some type of restriction on the nonce being a

appropriate table when we defined what a 'kty' is so they have had a chance to find out what 'OKP' is.  If we did this we would need to do it for all of the different values that show up here. <del> [CREF3] GS: Include a birthday attack note on tag size? </del>
Change:
The majority of changes prior to the examples section are to address typos or what I saw as inconsistencies. I will admit I wasn't as diligent as I should have been on those, but I need to take another pass on the document. The examples were reformatted to minimize side scrolling -- and likely fit within the TXT representation.

Discussion:
view. Switch from using a map to using an array at the message level. <del> While this change means that it is no longer possible to new named parameters to the top level message, it also means that there is not a need to define how older implementations are defined to behave when new fields are present.  Most of the reasons that a new field would need to be defined are adequately addressed by defining a new parameter instead. </del> <ins> While this change means that it is no longer possible to add new named parameters to the top level message, it also means that there is not a need to define how older implementations are defined to behave when new fields are present.  Most of the reasons that a new field would need to be defined are adequately addressed by defining a new parameter instead. </ins> Signed messages separate the concept of protected and unprotected attributes that are for the content and the signature.

structures are used for the plain text and for the different key management techniques. <del> One of the by products of using the same technique for encrypting and </del> <ins> One of the byproducts of using the same technique for encrypting and </ins> encoding both the content and the keys using the various key management techniques, is a requirement that all of the key management techniques use an Authenticated Encryption (AE) algorithm.

and place in the protected field of the Enc_structure and the COSE_Encrypt structure. <del> Copy the add field from the COSE_Encrypt structure to the </del> <ins> Copy the 'aad' field from the COSE_Encrypt structure to the </ins> Enc_Structure. Encode the Enc_structure using a CBOR Canonical encoding CBOR- Canonical to get the AAD value. <del> Encrypt the plain text and place it in the ciphertext field.  The AAD value is passed in as part of the encryption process. </del> <ins> Encrypt the plain text and place it in the 'ciphertext' field. The AAD value is passed in as part of the encryption process. </ins> For recipient of the message, recursively perform the encryption algorithm for that recipient using the encryption key as the plain

4.3. <del> Verify that the protected field is empty. </del> <ins> Verify that the 'protected' field is empty. </ins> <del> Verify that the aad field is empty. </del> <ins> Verify that the 'aad' field is empty. </ins> <del> Encrypt the plain text and place in the ciphertext field. </del> <ins> Encrypt the plain text and place in the 'ciphertext' field. </ins> 5.
Change:
Fix some additional errors found in the CDDL descriptions. It is still not completely correct so automatic testing is not turned on yet. Also some of the examples were out of date to the expected syntax so they got some updates.

Discussion:
this structure does not preclude a protocol to use one of the individual structures as a stand alone component. <del> This structure is encoded as an array by CBOR.  Descriptions of the fields: indicates which of the security structures is in this block. contains the top level fields for the security service provided. The type in this field is based on the value of the field msg_type. msg_type 1 is used for COSE_sign msg_type 2 is used for COSE_encrypt msg_type 3 is used for COSE_mac </del> <ins> The top level of each of the COSE message structures are encoded as arrays. We use an integer to distingish bettwen the different security message types.  By looking at the integer in the first element, one can determine which security message is being used and thus what the syntax is for the rest of the elements in the array. Implementations SHOULD be prepared to find an integer in the location which does not correspond to the values 0 to 2.  If this is found then the client MUST stop attempting to parse the structure and fail. Clients need to recognize that the set of values could be extended at a later date, but should not provide a security service based on guesses of what is there. NOTE: Alternative syntax with tags would be Where we would need to define the latter two as tagged arrays like is currently done for COSE_SignedMessage. There is no space savings in CBOR, this is strictly about using CBOR paradymes.  It is not clear what would happen if a JOSE serialization appeared, but that is probably not interesting.  If this path is used, then there is no extensibility for new messages types.  They would need to be defined on their own. </ins> 3.
Change:
Following discussions on the mailing list. Removing the ability to have flattened encoding for signers and recipients.
Closes issue
JOSE now allows for a single recipient to be encoded at the same level as the content. While COSE does not allow for quite the same way of encoding this it would be possible to do something similar. Current syntax is "recipients : COSEencrypta null;" Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub-encodings in CBOR. This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it. Not really that hard to do from a programmers point of view.
Open for group discussion
Based on the messages, there seems to be no support for combining the two maps together into a single map. I have therefore removed that from my working copy of the draft. There was one request for allowing option b (where a single recipient can be represented as a single map entry rather than as an array of a single map). I have looked at code size, and there does not seem to be a lot of code associated with this option, but as there was no outcry for this option I have not included it. Unless others have opinions that they believe need to be expressed, I am closing this issue.

Discussion:
Remove the authentiction tag for encryption algorithms as a separate item. <ins> Remove the flattened mode of encoding.  Forcing the use of an array of recipients at all times forces the message size to be two bytes larger, but one gets a corresponding decrease in the implementation size that should compenstate for this. </ins> 1.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

the responsibility of the application to ensure that it will be transported without changes. <del> is either a single signature or an array of signature values. A single signature value can be represented using either data type.  Implementations MUST be able to parse both data types. </del> <ins> is an array of signature items.  Each of these items uses the COSE_signature structure for its representation. </ins> The CDDL grammar structure for a signature is:

encryption process (i.e. detached content) then the value 'nil' is encoded here. <del> contains the recipient information.  The field can have one of three data types: </del> <ins> contains the recipient information.  The field can have one of two data types: </ins> An array of COSE_encrypt elements, one for each recipient. <del> A single COSE_encrypt element, encoded as an extension to the containing COSE_encrypt element, for a single recipient.  Single recipients can be encoded either this way or as a single array element. </del> A 'nil' value if there are no recipients. 4.1.
Change:
Fix install instructions in the README for kramdown-xml2rfc Update COSE spec for tagging discussion Update Issues document for closed and newly opened discussion issues.
Carsten has suggested that we could eliminate the need for the COSE_MSG structure if we were to get tags assigned from CBOR for these structures. Should this be done?
a) CBOR Tag - either general or specific to each type b) Required Identifier c) Use the same techniques as JOSE There was no support for option C. There was support for Option B There was some support for Option A, but only if it was optional. Mike Jones suggested that we should use the header parameter 'typ', I responded to this message saying that it was not clear that this was a correct use of the field based on the description in the JWS document. At this point I will keep the field as mandatory and outside of the headers field. I am planning on doing the IANA request for a CBOR Tag and to keep the tag as being optional in the grammar and text.
Closed in Pull request

Discussion:
a later date, but should not provide a security service based on guesses of what is there. <del> NOTE: Alternative syntax with tags would be Where we would need to define the latter two as tagged arrays like is currently done for COSE_SignedMessage. There is no space savings in CBOR, this is strictly about using CBOR paradymes.  It is not clear what would happen if a JOSE serialization appeared, but that is probably not interesting.  If this path is used, then there is no extensibility for new messages types.  They would need to be defined on their own. </del> 3. The signature structure allows for one or more signatures to be

8. <del> There are IANA considerations to be filled in. </del> <ins> 8.1. It is requested that IANA assign a new tag from the "Concise Binary Object Represetion (CBOR) Tags" registry.  It is requested that the tag be assigned in the 0 to 23 value range. Tag Value: TBD1 Data Item: CBOR map Semantics: COSE security message. </ins> 9.
Change:
Create IANA considerations for: 1) key and keyset CBOR tags 2) COAP Content Format registrations

Discussion:
This section registers the "application/cose" and "application/ cose+cbor" media types in the "Media Types" registry.  [CREF11] These media types are used to indicate that the content is a COSE_MSG. <ins> [CREF12] </ins> Type name: application

Provisional registration?  No <ins> 15.9. This section registers a set of content formats for CoAP.  ID assignment in the 24-255 range requested. </ins> 16. There are security considerations:

explicitly allow for integers encoded with leading zeros. [CREF11] JLS: Should we register both or just the cose+cbor one? <ins> [CREF12] JLS: Should we create the equivalent of the smime-type parameter to identify the inner content type? </ins>