Subject: [sacm] FW: [Cbor] 🔔 WGLC on draft-ietf-cbor-tags-oid-02

From: Francesca Palombini <[email-masked]>
Date: Thu, 29 Oct 2020 10:44:38 +0000

Hi SACM and RATS wg,

FYI, CBOR has just started a 2 weeks WGLC on the CBOR Tags for OIDs, which might be of interest to you.

Any feedback and review is welcome!
Francesca (CBOR chair)

On 29/10/2020, 10:57, "CBOR on behalf of Francesca Palombini" <[email-masked] on behalf of francesca.palombini=[email-masked]> wrote:

    CBOR wg,

    This starts a two weeks WG last call on https://tools.ietf.org/html/draft-ietf-cbor-tags-oid-02 , ending on *Thursday, 12th November*. 

    Please send inputs to the mailing list that you have read the document and do or do not feel it is ready to progress, along with any issues that you believe need to be dealt with.

    We will discuss any open issues we’ve gotten during our WG meeting at IETF109 scheduled for Thursday, 19 November.

    CBOR Chair
    Francesca

    On 28/10/2020, 18:44, "CBOR on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

        A New Internet-Draft is available from the on-line Internet-Drafts directories.
        This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF.

                Title           : Concise Binary Object Representation (CBOR) Tags for Object Identifiers
                Authors         : Carsten Bormann
                                  Sean Leonard
        	Filename        : draft-ietf-cbor-tags-oid-02.txt
        	Pages           : 14
        	Date            : 2020-10-28

        Abstract:
           The Concise Binary Object Representation (CBOR, draft-ietf-cbor-
           7049bis) is a data format whose design goals include the possibility
           of extremely small code size, fairly small message size, and
           extensibility without the need for version negotiation.

           The present document defines CBOR tags for object identifiers (OIDs).
           It is intended as the reference document for the IANA registration of
           the CBOR tags so defined.

        The IETF datatracker status page for this draft is:
        https://datatracker.ietf.org/doc/draft-ietf-cbor-tags-oid/

        There is also an HTML version available at:
        https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-02.html

        A diff from the previous version is available at:
        https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-tags-oid-02

        Please note that it may take a couple of minutes from the time of submission
        until the htmlized version and diff are available at tools.ietf.org.

        Internet-Drafts are also available by anonymous FTP at:
        ftp://ftp.ietf.org/internet-drafts/

        _______________________________________________
        CBOR mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/cbor

    _______________________________________________
    CBOR mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/cbor

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 29 Oct 2020 12:44:17 -0700

The question I have is whether there is any intent for these OIDs to be keys or labels in CBOR maps. In X.509/PKIX extensions are labeled by OIDs. Would there be similar use in CBOR?

Typically, CBOR map labels are integers and sometimes text strings. Having to pay attention to tags in map keys might be very inconvenient for some CBOR decoders, though that could be avoided in a given protocol by saying the map keys are byte strings that borrow tag 111 content eliminating the need for the tag.

LL

> On Oct 29, 2020, at 3:44 AM, Francesca Palombini <francesca.palombini=[email-masked]> wrote:
> 
> Hi SACM and RATS wg,
> 
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Oct 2020 21:25:45 +0100

Hi Laurence,

On 2020-10-29, at 20:44, Laurence Lundblade <[email-masked]> wrote:
> 
> The question I have is whether there is any intent for these OIDs to be keys or labels in CBOR maps.

The way tag factoring (Section 5 [1]) works for maps was specifically meant to support this.

> In X.509/PKIX extensions are labeled by OIDs. Would there be similar use in CBOR?

Please see the example on page 8 [2] for such usage.

> Typically, CBOR map labels are integers and sometimes text strings. Having to pay attention to tags in map keys might be very inconvenient for some CBOR decoders, though that could be avoided in a…

That is of course also possible.

Which reminds me that we specify CDDL control operators, but not prelude-like conventional names for the types created by these tags (e.g., cf. [3]).  Now Issue 6 [4].

Grüße, Carsten

[1]: https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-02.html#name-tag-factoring-with-oid-arra
[2]: https://tools.ietf.org/html/draft-ietf-cbor-tags-oid-02#page-8
[Yessss… :-)]
[3]: https://www.rfc-editor.org/rfc/rfc8746.html#section-5
[4]: https://github.com/cbor-wg/cbor-oid/issues/6

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 29 Oct 2020 14:02:51 -0700

I see.

So if you are doing DN’s in CBOR this way, it’s kind “in for a penny, in for a pound” and you want to handle the mentioned example using what is described in section 5.

CWT seems a little ambiguous as to whether thusly encoded OIDs are allowed as a label/key. Section 3 says:

   To keep CWTs as small as possible, the Claim Keys are represented
   using integers or text strings.

This seems more of a statement of design intent rather than a prohibition against other types of Claim Keys, but one could interpret it as a prohibition.

Thanks

LL

> On Oct 29, 2020, at 1:25 PM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Laurence,
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 31 Oct 2020 21:36:51 +0100

> This seems more of a statement of design intent rather than a prohibition against other types of Claim Keys, but one could interpret it as a prohibition.

It is neither: It is a statement of fact.
The dual of this statement is:
If the label (map key) is not an integer or a text string, this label is not a Claim Key.
(And, since Claims use Claim Keys, the key/value pair is not a Claim, and ... the whole thing is not a CWT.)

[We had an interesting discussion over at JSONpath about normative statements.
The upshot was that this is a normal way to phrase a normative statement, even without RFC 2119 language.  RFC 2119 language would not be wrong here, but it is not needed.  Just like an ABNF rule “id = 1*ALPHA” would not need an RFC 2119 statement with it that dollar signs MUST NOT occur in ids, unless that is for some reason a misunderstanding that suggests itself.]

Grüße, Carsten