Javascript Object Signing and Encryption
charter-ietf-jose-04

Changed charter milestone "Adopt document describing the use of the NIST algorithm SLH-DSA in JOSE  (as proposed standard)", set description to "Adopt document describing the use of the NIST algorithm NL-DSA in JOSE  (as proposed standard)"

[Ballot comment]
Just one suggestion about the following text: `The WG will evaluate, and potentially adopt, documents dealing with algorithms that would fit the criteria of being IETF consensus algorithms.`

Let's clarify that those documents will have an intended status of "proposed standards" as opposed to other algorithms that are clearly identified as "informational".

[Ballot comment]
I understand this is not part of the update, but just noticing it now...

This charter:

> Standards Track document(s) specifying how to use existing cryptographic algorithms and defining their algorithm identifiers. The working group will not invent new cryptographic algorithms.
> ...
> Standards Track document(s) defining CBOR-based representations corresponding to all the above, building upon the COSE and CWT specifications in the same way that the above build on JOSE and JWT.

COSE charter:

> The COSE working group will deal with two types of documents going forward:
> Documents that describe the use of cryptographic algorithms in COSE.

This leads me to think there is a small overlap about COSE. That should not be a big problem, but at least I think it would be good to list COSE as one of the working groups JOSE should coordinate with.

[Ballot comment]
I understand this is not part of the update, but just noticing it now...

This charter say:

> Standards Track document(s) specifying how to use existing cryptographic algorithms and defining their algorithm identifiers. The working group will not invent new cryptographic algorithms.
> ...
> Standards Track document(s) defining CBOR-based representations corresponding to all the above, building upon the COSE and CWT specifications in the same way that the above build on JOSE and JWT.

COSE charter say:

> The COSE working group will deal with two types of documents going forward:
> Documents that describe the use of cryptographic algorithms in COSE.

This leads me to think there is a small overlap about COSE. That should not be a big problem, but at least I think it would be good to list COSE as one of the working groups JOSE should coordinate with.

[Ballot block]
I find the itemized charter bullets and the milestones rather unmatched? all milestones only cover 1 bullet point.


One nit:

    An Informational document defining test vectors for these new specifications.

I would also add the optional plural here as done for the other documents, eg Informational document(s)
As I can see, one wouldn't want to delay the test vector document until the last item is ready for RFC and test vector publication.

[Ballot comment]
One nit:

    An Informational document defining test vectors for these new specifications.

I would also add the optional plural here as done for the other documents, eg Informational document(s)
As I can see, one wouldn't want to delay the test vector document until the last item is ready for RFC and test vector publication.

[Ballot comment]
When the JOSE WG was reopened in January 2023, the proponents and AD forgot to add charter scope to handle maintenance of prior JOSE work.  This charter revision adds this scope.

[Ballot comment]
It seems that the use of MD URL makes the text difficult to read (probably a datatracker rendering issue).

The 4th paragraph starting with "A multi-decade research activity..." is a little long (suggest to skip the first sentence). Having two sentences starting with "Some" makes this paragraph rather vague. Finally, once ZKP abbreviation is introduced, then let's use it.

s/This group is chartered to work on the following deliverables/This group is chartered to work on the following goals/ as later in the charter "One or more of these goals may be combined into a single document" (which would make sense).

About the CBOR encoding, should CDDL be mentioned ? Should CBOR WG be listed in the interested parties ?

[Ballot comment]
Basically LGTM. There was one paragraph I found a little stilted, I provide some suggestions below. Take 'em or leave 'em, up to you.

While this sentence is grammatical, IMO it's a little denser to parse than it needs to be: "Concurrent to the growth of adoption of these standards to express and communicate sensitive data has been an increasing societal focus on privacy." Perhaps something like this instead? "As adoption of these standards to express and communicate sensitive data has grown, so too has an increasing societal focus on privacy." (Arguably "grown ... increasing" is redundant and "increasing" could be dropped but I don't think it hurts if you want to emphasize by repetition.)

For similar reasons maybe reword "Common privacy themes in identity solutions are user consent, minimal disclosure, and unlinkability." For example, "User consent, minimal disclosure, and unlinkability are common privacy themes in identity solutions."

[Ballot comment]
My previous feedback (https://datatracker.ietf.org/doc/charter-ietf-jose/ballot/329647/#benoit-claise) was not taken into account. So here it is again:

I always prefer to see the milestones, to understand how long the charter
completion could take, and to see the logical order of the document delivery.
However, I know that some people don't consider the milestones part of the
charter. Let's not redo the discussion here, but can you please order the
milestones in a logical order. For example, I guess that the following entry
should be number 1.
  (7) An Informational document detailing Use Cases and Requirements
  for JSON Object Signing and Encryption (JOSE).

[Ballot block]
I support Pete's points on this.  One further point:

The proposed charter makes the following change to deliverable (1):
CURRENT: "integrity protection to data, including (but not limited to) JSON data structures."
PROPOSED: "... integrity-protected data using JSON-based data structures, including (but not limited to) JSON data structures."
This appears to change the antecedent of the "including ..." clause to the metadata instead of the data.  I don't think this change is what the WG intended.  For example, it would not be acceptable for the group to work on an ASN.1 data structure that was somehow "JSON-based".

Proposed change:
OLD: "including (but not limited to) JSON data structures."
NEW: "where the data to be protected includes (but is not limited to) JSON data structures"
... in both (1) and (2)

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for
  JSON with encryption, digital signatures, and message authentication
  codes (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such
  as encryption, digital signatures, and message authentication
  codes (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for JSON
  with encryption, digital signatures, and message authentication codes
  (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such
  as encryption, digital signatures, and message authentication
  codes (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for JSON
  with encryption, digital signatures, and message authentication codes
  (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such
    as encryption, digital signatures, and message authentication
    codes (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot block]
I think some of the changes have de-clarified things for me. Below are my suggestions, but I don't want to end up de-clarifying things for Barry in the process. So these are here for discussion purposes. If everyone thinks these changes make them happy too, then great.


OLD
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services for JSON
  with encryption, digital signatures, and message authentication codes
  (MACs).
NEW
  With the increased usage of JSON in protocols in the IETF
  and elsewhere, there is now a desire to offer security services such as
  encryption, digital signatures, and message authentication codes
  (MACs) using the JSON data format.

OLD
  The WG will develop a generic syntax that can be
  used by applications to secure JSON-data,
NEW
  The WG will develop a generic syntax that can be
  used by applications to encode security data in JSON
  format,

In (1) and (2), change "representing" to "specifying a representation of". The current text just doesn't make sense.

[Ballot comment]
This was formerly a BLOCK, moved to a COMMENT:

> The WG will develop a generic syntax that can be used by
> applications to secure JSON-data, but it will be up to the
> application to fully specify the use of the WG's documents
> much the same way S/MIME is the application of CMS to
> MIME-based media types.

When I've asked App folks who are working on new JSON-based protocols and formats about JOSE, the feedback I've gotten is that they don't see the applicability of JOSE to their work.  It's possible that this is simply short-sightedness, but it disturbs me.  I'd like to have some assurance that there is some real communication between JOSE development and the target uses -- the JSON-based applications -- and that the needs of those targets are being fed into JOSE now, during the development cycle.

Part of this probably involves pushing items 7 and 8 up to the top, working on them actively -- with direct input from the target users -- before nailing down the details.

--- UPDATE for -01-02 ---
The following text was added in -01-02:
The WG will strive to gather use cases to ensure the broadest possible applicability of the mechanism.

That, in addition to discussion with the chairs, makes me happy that we will collectively connect with potential users and collect use cases, dispel myths, figure out who can and should make use of this, and sing "Kumbayah".

[Ballot comment]
I always prefer to see the milestones, to understand how long the charter completion could take, and to see the logical order of the document delivery.
However, I know that some people don't consider the milestones part of the charter. Let's not redo the discussion here, but can you please order the milestones in a logical order.
For example, I guess that the following entry should be number 1.
  (7) An Informational document detailing Use Cases and Requirements
  for JSON Object Signing and Encryption (JOSE).

[Ballot comment]
I always prefer to see the milestones, to understand how long the charter completion could take, and to see the logical order of the document delivery.
However, I know that some people don't consider the milestones part of the charter. Let's not redo the discussion here, but can you please order the milestones in a logical order.
For example, I guess that the following entry should be number 1.
  (7) An Informational document detailing Use Cases and Requirements for
  JSON Object Signing and Encryption (JOSE).

[Ballot block]
I have two points:

1.
> The WG will develop a generic syntax that can be used by
> applications to secure JSON-data, but it will be up to the
> application to fully specify the use of the WG's documents
> much the same way S/MIME is the application of CMS to
> MIME-based media types.

When I've asked App folks who are working on new JSON-based protocols and formats about JOSE, the feedback I've gotten is that they don't see the applicability of JOSE to their work.  It's possible that this is simply short-sightedness, but it disturbs me.  I'd like to have some assurance that there is some real communication between JOSE development and the target uses -- the JSON-based applications -- and that the needs of those targets are being fed into JOSE now, during the development cycle.

Part of this probably involves pushing items 7 and 8 up to the top, working on them actively -- with direct input from the target users -- before nailing down the details.

2.
> (1) A Standards Track document or documents specifying how
> to apply JSON-structured integrity protection to data,
...
> (2) A Standards Track document or documents specifying how
> to apply a JSON-structured encryption to data,

I know this text is from the original charter, but I don't understand what "JSON-structured integrity protection" and "JSON-structured encryption" mean.  "JSON-structured data" makes sense.  But how does the adjective "JSON-structured" apply to the noun "encryption"?