Draft: draft-ietf-gnap-core-protocol

Commentary: After discussion with , this PR now makes keys single - format - only as previously suggested . 
 To edit notification comments on pull requests , go to your . _ 
 Yaron : why are we sending a JWK as well as a cert ? Are we checking that the cert contains the same public key as the cert ?  : I would be OK with the different formats being mutually exclusive somehow . The AS would need to check that they ’re the same and throw an error if not . But this would also let the RC send over whatever it ’s got for its own keys every time . 
 The document has been changed to address this issue , copying my text that refers to the latest draft version : In Sec . 7.1 we allow the client to include multiple keys of different formats , provided they are " equivalent " . This does n't make sense , because the only reason to send multiple keys is that the sender suspects that the recipient does n't understand one of the formats . But if that 's the case , the recipient is not able to validate the MUST requirement that the two formats be equivalent . This could also lead to interesting key injection attacks . IMO we should only allow one key value / format for each request .
Paragraph (version A):
A key presented by value MUST be a public key in at least one
supported format.  If a key is sent in multiple formats, all the key
format values MUST be equivalent.  Note that while most formats
present the full value of the public key, some formats present a
value cryptographically derived from the public key.  See additional
discussion of public keys in security-symmetric.
Paragraph (version A):
A key presented by value MUST be a public key in at least one
supported format.  If a key is sent in multiple formats, all the key
format values MUST be equivalent.  Note that while most formats
present the full value of the public key, some formats present a
value cryptographically derived from the public key.
Paragraph (version A):
This non-normative example shows a single key presented in multiple
formats.  This example key is intended to be used with the httpsig-
binding proofing mechanism, as indicated by the "httpsig" value of
the "proof" field.
Paragraph (version B):
A key presented by value MUST be a public key and MUST be presented
in one and only one supported format, as discussed in security-
multiple-key-formats.  Note that while most formats present the full
value of the public key, some formats present a value
cryptographically derived from the public key.  See additional
discussion of the presentation of public keys in security-symmetric.
Paragraph (version B):
This non-normative example shows a single key presented in two
different formats.  This example key is intended to be used with the
httpsig-binding proofing mechanism, as indicated by the "httpsig"
value of the "proof" field.
Paragraph (version B):
Keys presented by value are allowed to be in only a single format, as
discussed in key-format.  Presenting the same key in multiple formats
is not allowed and is considered an error in the request.  If
multiple keys formats were allowed, receivers of these key
definitions need to be able to make sure that it's the same key
represented in each field and not simply use one of the key formats
without checking for equivalence.  If equivalence were not carefully
checked, it is possible for an attacker to insert their own key into
one of the formats without needing to have control over the other
formats.  This could potentially lead to a situation where one key is
used by part of the system (such as identifying the client instance)
and a different key in a different format in the same message is used
for other things, like calculating signature validity.
Paragraph (version B):
To combat this, all keys presented by value have to be in exactly one
supported format known by the receiver.  Normally, a client instance
is going to be configured with its keys in a single format, and it
will simply present that format as-is to the AS in its request.  A
client instance capable of multiple formats can use discovery to
determine which formats are supported, if desired.  An AS should be
generous in supporting many different key formats to allow different
types of client software and client instance deployments.