Use of VAPID in JMAP WebPush
draft-ietf-jmap-webpush-vapid-10

Thank you to Daniel for addressing my original comments.  I'm changing my ballot to 'no objection'.  

I have one comment remaining:

In Section 3, the parenthetical (65 octets specifically) won't be true with a larger ECDSA public key.  I had merely eliminated the parenthetical in my suggested text.  The public key will always start with a 0x04 octet, but it won't be 65 octets in length.

-------------------------------------------
Below are my original comments (just for the record).

---------------------------

Thank you for a well written, clear draft.  These should be easy to resolve.

Section 3:  While RFC8292 specifies ECDSA directly, it only mentions P-256.
This draft should aim to allow algorithm agility in terms of ECDSA key size as
VAPID and JWT allow.  How about:

"The ECDSA public key (current systems use the P-256 curve) [FIPS186], in
uncompressed form described in [X9.62] Annex A that is encoded using base64url
encoding [RFC7515], that the push service will use to authenticate the
application server."

Section 6:  Since none of the referenced RFCs has Key Rotation as a topic,
please add a couple of sentences on key rotation here.  [note:  some of what
you have in the key rotation section can easily be used.]

-----------------------

# Internet AD comments for draft-ietf-jmap-webpush-vapid-05
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S2

* "MUST contain the following ... The ECDSA public key"

  I'm a little surprised by what, to me, looks like a lack of algorithm
  agility.  I don't know enough about VAPID to know if algorithm agility
  is feasible, but ... it seems like something IETF protocols should
  generally be aiming towards.

### S5

* "If there is a mismatch, the client MAY retry creating the
   PushSubscription"

  Why MAY and not SHOULD?  I assumed this would be the logical desired
  behavior.

# Orie Steele, ART AD, comments for draft-ietf-jmap-webpush-vapid-08 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-jmap-webpush-vapid-08.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


Thanks to Thomas Fossati for the ART ART Review.

### What does use mean?

```
101	   PushVerification notifications.  The server MUST use the application
102	   server key that was advertised in the capabilities object at the time
103	   the PushSubscription was created.
```

I think this means: verify a digital signature using the applicationServerKey as described in https://datatracker.ietf.org/doc/html/rfc8292#section-4.2 ?

This must seems underspecified, or to assume more JMAP knowledge than I have.
The word "sign" only appears in the security considerations, a brief description of how this "signing" key is used before then would be helpful, even if its just calling out to sections in other specs.

### new public key format for jmap (sigh)

```
90	   *  applicationServerKey: "String"
91	      The ECDSA public key (current systems use the P-256 curve)
92	      [FIPS186], in its uncompressed form as described in [X9.62] Annex
93	      A and encoded using base64url encoding [RFC7515], that the push
94	      service will use to authenticate the application server.
```

I see that this came up in the ART ART review:

https://mailarchive.ietf.org/arch/msg/art/7hYM8qI5Seg9C75sy5atqRLolPA/

Following through the W3C references, we land on:

https://www.rfc-editor.org/rfc/rfc8292#section-3.2

Specifically:

https://www.rfc-editor.org/rfc/rfc8292#section-2.4

```
   Note:  X9.62 encoding is used over JWK [RFC7517] for two reasons.  A
      JWK does not have a canonical form, so X9.62 encoding makes it
      easier for the push service to handle comparison of keys from
      different sources.  Secondarily, the X9.62 encoding is also
      considerably smaller.
```

I suggest adding a direct reference to this.

And also a comment like you have on the list "this is to enable copy pasting of the existing text encoded keys".

        applicationServerKey: "String"

        The ECDSA public key (current systems use the P-256 curve) [FIPS186],
        in its uncompressed form as described in [X9.62] Annex A and encoded
        using base64url encoding [RFC7515], that the push service will use to
        authenticate the application server.

It seems one should either use a representation that includes the cryptographic
specifiers (eg SubjectPublicKeyInfo) or one should have a field with the key
type, eg applicationServerKeyType: "ECDSA".

This might be the case for [X9.62], but I cannot tell as the resource does not
seem to be publicly available. I guess since this format is also used in RFC8292,
it is too late to raise a DISCUSS on this to fix, unfortunately.


The first part of the Security Considerations seems to deal with regular protocol
operational edge cases and not security considerations. Consider moving these to
a more appropriate place (maybe its own new Section)

Thank you to Paul Kyzivat for the GENART review.

I am supporting Deb's and Erik's ballots about lack of agility.