Conversation
- Add trackBaseKey catalog field for base key material signaling - Add Key management subsection documenting out-of-scope nature - Add keyId scoping options (single track, session, or multiple) - Add informative reference to draft-jennings-moq-e2ee-mls - Add SecureObjects section references for keyId and trackBaseKey - Update encryption example with trackBaseKey
wilaw
left a comment
There was a problem hiding this comment.
Thanks for submitting this PR. In general LGTM, although raised a few questions which I'd like resolved before approving.
| ToDo - content protection for LOC-packaged content. | ||
| MSF supports end-to-end encryption of media content using MoQ Secure Objects | ||
| {{SecureObjects}}. When encryption is enabled, the payload of LOC-packaged | ||
| media objects is encrypted and authenticated, while relays can still route |
There was a problem hiding this comment.
Is it authenticated, or just encrypted?
There was a problem hiding this comment.
it is both. Secure Object uses AEAD with AAD protection scheme. So the payload and private extensions are encrypted and authenticated along with GroupId, ObjectId and Immutable Extensions.
More details here: https://datatracker.ietf.org/doc/html/draft-jennings-moq-secure-objects-04#section-3
draft-ietf-moq-msf.md
Outdated
| Depending on the key management mechanism in use, a keyId MAY be scoped to: | ||
|
|
||
| * A single track | ||
| * A single MSF session |
There was a problem hiding this comment.
A 'MSF Session' is not defined in the draft.
There was a problem hiding this comment.
That's right, should I call is MoQ Session instead ?
| For LOC-packaged tracks with encryption enabled (see {{SecureObjects, Section 4}}): | ||
|
|
||
| * The immutable header extensions (including Group ID and Object ID) remain | ||
| in plaintext and are authenticated |
There was a problem hiding this comment.
How are the immutable header extensions authenticated?
There was a problem hiding this comment.
The immutable header extensions are passed to as AAD ( Additional Authenticated Data) part of the protect() operation. Please see https://datatracker.ietf.org/doc/html/draft-jennings-moq-secure-objects-04#section-3.5
| The default and RECOMMENDED value is "moq-secure-objects" as defined in | ||
| {{SecureObjects}}. If this field is absent, the track content is unencrypted. | ||
|
|
||
| Table 5: Registered encryption schemes |
There was a problem hiding this comment.
Should this be an IANA managed table?
There was a problem hiding this comment.
Yes or we refer to appropriate section from Secure Objects once add the details in that draft ?
|
Can you add examples for Widevine, PlayReady and FairPlay? Thanks! |
Co-authored-by: Will Law <2762250+wilaw@users.noreply.github.com>
suhasHere
left a comment
There was a problem hiding this comment.
Responding to Will's review
| For LOC-packaged tracks with encryption enabled (see {{SecureObjects, Section 4}}): | ||
|
|
||
| * The immutable header extensions (including Group ID and Object ID) remain | ||
| in plaintext and are authenticated |
There was a problem hiding this comment.
The immutable header extensions are passed to as AAD ( Additional Authenticated Data) part of the protect() operation. Please see https://datatracker.ietf.org/doc/html/draft-jennings-moq-secure-objects-04#section-3.5
| The default and RECOMMENDED value is "moq-secure-objects" as defined in | ||
| {{SecureObjects}}. If this field is absent, the track content is unencrypted. | ||
|
|
||
| Table 5: Registered encryption schemes |
There was a problem hiding this comment.
Yes or we refer to appropriate section from Secure Objects once add the details in that draft ?
|
@wilaw I merged some of your suggestions and responded to others. Please let me know. Thanks |
Fixes #115 #115