Re: [Hls-interest] File extension and MIME-Type for an HLS encryption key

[Valentijn Siebrands <[e-mail]>]

Hi Will,

So this goes back to:
https://dashif-documents.azurewebsites.net/Ingest/master/DASH-IF-Ingest.html#HLS_Ingest_Encryption
right?



*6.2.3. EncryptionThe ingest source MAY choose to encrypt the media
segments and publish the corresponding keyfile to the Receiving entity.*
My opinion:
For players it would be good to use either .key (=what it is) or .drm (it's
usage) both mimed as application/octet-stream. However, for *ingest*, one
generally doesn't ingest a key to a packager or 'processor'. Although the
Ingest spec mentions it and one could do it that way, it needs more than
just a keyfile, in the end getting the keyid:key pair(s) in the right place
and map them accordingly based on track type and time is one of the reasons
why CPIX and SPEKE are there. So for ingest, .cpix or .xml would be a
better fit

My main point is that we should make a clear distinction here: "files" used
by packagers for applying encryption (eg .cpix) , "files" used by players
(mainly CDM's). (eg .key or .drm)

Imho history has shown us that references to things that mean 2 things
'close' to each other in related specifications lead to common mistakes,
especially developers working with DRM and the specification(s) need
clarity, red is red and blue is blue.
Smooth is generally referred to as both an ingest and playback
specification. The "Dash-IF Ingest spec" tries to replace that very Smooth
ingest spec. We should reflect the lesson learned: A clear distinction,
this one is for packaging, the other for the player.

Regards

V







On Tue, Jun 29, 2021 at 6:03 PM Law, Will <wilaw=[e-mail]>
wrote:

> Is there any consensus on what the file extension and MIME-Type should be
> for an encryption key delivered to a HLS  player? The spec defines no
> constraints on this question.
>
>
>
> The DASH IF is standardizing an Ingest Specification which covers the
> ingest of CMAF-based content in both HLS and DASH formats. We’ll likely
> choose ‘.key’ as the file extension and are considering
> ‘application/octet-stream’ as the Mime-Type in the absence of objections.
> Asking here in case there is a de-facto industry standard already in use,
> or opinion on whether we should go to the length of registering a new
> ‘encryption key’ MIME-type with IANA.
>
>
>
> Cheers
>
> Will
>
>
> --
> Hls-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest
>


-- 

Valentijn Siebrands

Solutions Architect

*M2A Media*

Tel: [phone]