Propose text to close #63 #171
Conversation
draft-ietf-cbor-7049bis.md
Outdated
| duplicate keys. This requires the application to handle (check | ||
| against) duplicate keys, even if the application rules are identical | ||
| to the generic data model rules. | ||
| * lose some entries with duplicate keys, e.g. by only delivering the |
There was a problem hiding this comment.
Clearly it is right for generic decoders to error out on the first duplicate.
Is it OK for a generic decoder to silently ignore duplicates? If this is considered OK designers and implementors will rely on this behavior. I think it is not OK because we probably can't write a rule about which ones (first, last, middle, random) will be ignored and have it widely and reliably implemented. So I think this third option should be removed.
draft-ietf-cbor-7049bis.md
Outdated
| they do need to validate key uniqueness. These generic decoders can | ||
| only be used in situations where the encoder can be relied upon to | ||
| always provide valid maps; this is not possible if the encoder can | ||
| be under control of an attacker. |
There was a problem hiding this comment.
The encoder should always be considered under control of the attacker. There should be no discussion of a situation where an encoder can be relied upon to provide valid maps.
draft-ietf-cbor-7049bis.md
Outdated
| duplicate keys. This requires the application to handle (check | ||
| against) duplicate keys, even if the application rules are identical | ||
| to the generic data model rules. | ||
| * lose some entries with duplicate keys, e.g. by only delivering the |
There was a problem hiding this comment.
Do we really want to exclude decoders that can neither detect duplicates nor pass duplicates on? That will force encoder implementors in some environments to not use the common map / list constructs in those environments.
|
Just an FYI, fxamacker/cbor provides a generic decoder with two choices (so far) for duplicate map keys. I'm hoping changes to 7049bis doesn't turn these options into non-compliance, the fxamacker/cbor provides options for fast detection and rejection of duplicate map keys based on applying a Go-specific data model to CBOR's extended generic data model in order to determine duplicate vs distinct map keys. Detection relies on whether the CBOR map key would be a duplicate "key" when decoded and applied to the user-provided Go map or struct.
APF suffix means "Allow Partial Fill" so the destination map or struct can contain some decoded values at the time of error. It is the caller's responsibility to respond to the |
|
@x448 You are in compliance with the most recent text. DupMapKeyEnforcedAPF corresponds to the first bullet and DupMapKeyQuiet to the last. The text implies that use of the last option should only be in attacker-free environments. |
|
@laurencelundblade Thanks! I appreciate you taking time to let me know. BTW, we thanked you in the release notes for fxamacker/cbor v2.1.0 (Feb 17) -- it added CBOR tags support resulting in lots of questions (e.g. time tags) that week. |
Co-Authored-By: Laurence Lundblade <laurencelundblade@users.noreply.github.com>
There was a problem hiding this comment.
I actually would prefer "or" over "and".
This text tries to summarize the mailing list discussion, stating facts about what approaches can be used under which circumstances.