Subject: Re: [Secdispatch] Ciphertext format draft

From: Francesca Palombini <[email-masked]>
Date: Fri, 15 Jan 2021 15:06:32 +0000

FYI.

This has been posted to Secdispatch, and I thought CBOR and COSE might want to take a look. (Feel free to reply to the original thread in Secdispatch, to keep the conversation in one place).

Francesca

From: Secdispatch <[email-masked]> on behalf of Yaron Sheffer <[email-masked]>
Date: Friday, 15 January 2021 at 15:54
To: "[email-masked]" <[email-masked]>
Cc: "Keselman, Gleb" <[email-masked]>, Yoav Nir <[email-masked]>
Subject: [Secdispatch] Ciphertext format draft

Hi, we just submitted draft-sheffer-ietf-ciphertext-format-01 [1]. This is a CBOR-based set of headers for encrypted data, with the goal of enabling automation of large datasets that contain encrypted data, typically interspersed with plain data. Specifically we want to facilitate discovery of encrypted data (e.g., this database column contains ciphertext) and attributing this data back to the service that created the data and the key that was used to encrypt it.

We received good feedback on the SAAG list to change from generic TLV to CBOR, which we implemented in -01.

The authors would appreciate this list’s feedback regarding next steps.

Thanks,
                Yaron

[1] https://tools.ietf.org/id/draft-sheffer-ietf-ciphertext-format-01.xml

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Jan 2021 17:09:46 +0200

We would love feedback from the CBOR community, but to clarify: we are merely using CBOR in the simplest way possible, we are not proposing any changes to it.

                Yaron

From: Francesca Palombini <[email-masked]>
Date: Friday, January 15, 2021 at 17:06
To: "[email-masked]" <[email-masked]>, Cose Wg <[email-masked]>
Cc: "Keselman, Gleb" <[email-masked]>, Yoav Nir <[email-masked]>, Yaron Sheffer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Secdispatch] Ciphertext format draft

FYI.

Francesca

Thanks,

                Yaron

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Jan 2021 16:28:44 +0100

Hi Yaron,

Here is a quick update proposal to the CDDL:

var_header = {
        K_KEY_PROVIDER => uint,
        K_KEY_ID => bstr,
        ? K_KEY_VERSION => uint,
        ? K_AUX_DATA => bstr,
        ? K_NONCE => bstr,
        ? K_AUTH_TAG => bstr,
        ? K_AAD => bstr,
        * (k_ext .feature "header-extension") => any
}

k_ext = uint .ge K__EXTENSIONS

; K_RESERVED = 0
K_KEY_PROVIDER = 1
K_KEY_ID = 2
K_KEY_VERSION = 3
K_AUX_DATA = 4
K_NONCE = 5
K_AUTH_TAG = 6
K_AAD = 7
        ; extend from here
K__EXTENSIONS = 8

The idea is to use “.feature” to clearly identify extensions from the base set.

This would give you validator output like

** Features potentially used: header-extension: [1577, 4416, 3178, 2698]
/var_header/ {1: 2286, 2: /bstr/ h'686F74626564', 3: 4661,
 5: /bstr/ h'756E70726F70656E7365',
 6: /bstr/ h'6F7879616E746872617175696E6F6E65',
 7: /bstr/ h'636572656272616C6C79', 1577: /any/ "feeze",
 4416: /any/ "bronchiolitis", 3178: /any/ "mesole", 2698: /any/ "parvoline”}

so you know which extensions are in use.

Grüße, Carsten