Merge pull request #528 from ietf-wg-gnap/define-sign

add definition for generic "sign"

draft-ietf-gnap-core-protocol.md

@@ -203,6 +203,8 @@ This document contains non-normative examples of partial and complete HTTP messa
 
 This document uses the term "mutual TLS" as defined by {{RFC8705}}. The shortened form "MTLS" is used to mean the same thing.
 
+For brevity, the term "signature" on its own is used in this document to refer to both digital signatures (which use asymmetric cryptography) and keyed MACs (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or keyed MAC over a given signature base. The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation.
+
 ## Roles
 
 The parties in GNAP perform actions under different roles.
@@ -6158,10 +6160,17 @@ the RS whose focus is to provide an API or the client software whose focus is to
 ## Symmetric and Asymmetric Client Instance Keys {#security-symmetric}
 
 Many of the cryptographic methods used by GNAP for key-proofing can support both asymmetric and symmetric
-cryptography, and can be extended to use a wide variety of mechanisms. Implementers will find useful the available guidelines on cryptographic key management provided in {{RFC4107}}. While symmetric
+cryptography, and can be extended to use a wide variety of mechanisms.
+Implementers will find useful the available guidelines on cryptographic key management provided in {{RFC4107}}. While symmetric
 cryptographic systems have some benefits in speed and simplicity, they have a distinct drawback
 that both parties need access to the same key in order to do both signing and verification of
-the message. This means that when the client instance calls the AS to request a token, the
+the message.
+When more than two parties share the same symmetric key,
+data origin authentication is not provided.  Any party that knows the
+symmetric key can compute a valid MAC; therefore, the
+contents could originate from any one of the parties.
+
+Use of symmetric cryptography means that when the client instance calls the AS to request a token, the
 AS needs to know the exact value of the client instance's key (or be able to derive it) in
 order to validate the key proof signature. With asymmetric keys, the client needs only to
 send its public key to the AS to allow for verification that the client holds the associated