From bd3af8b6642534b9cc5445c5b7fd71b80707fe7c Mon Sep 17 00:00:00 2001
From: Justin Richer <justin@bspk.io>
Date: Thu, 8 Feb 2024 11:48:22 -0500
Subject: [PATCH 1/4] add definition for generic "sign"
---
draft-ietf-gnap-core-protocol.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/draft-ietf-gnap-core-protocol.md b/draft-ietf-gnap-core-protocol.md
index c714f16..b8dad4b 100644
--- a/draft-ietf-gnap-core-protocol.md
+++ b/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.
From e5e5249f19d3ed435b425025527115a1709131ee Mon Sep 17 00:00:00 2001
From: Justin Richer <justin@bspk.io>
Date: Fri, 9 Feb 2024 12:34:38 -0500
Subject: [PATCH 2/4] add discussion of symmetric crypto drawbacks
---
draft-ietf-gnap-core-protocol.md | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/draft-ietf-gnap-core-protocol.md b/draft-ietf-gnap-core-protocol.md
index b8dad4b..6ab7046 100644
--- a/draft-ietf-gnap-core-protocol.md
+++ b/draft-ietf-gnap-core-protocol.md
@@ -82,6 +82,7 @@ normative:
informative:
RFC4107:
+ RFC5652:
RFC6202:
RFC6973:
RFC7518:
@@ -6146,10 +6147,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 (see {{RFC5652}} for further discussion).
+
+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
From 1d6bcc106d1cca247a4967cf8a9c71b7030b0f21 Mon Sep 17 00:00:00 2001
From: Justin Richer <justin@bspk.io>
Date: Fri, 9 Feb 2024 14:19:53 -0500
Subject: [PATCH 3/4] remove CMS reference
---
draft-ietf-gnap-core-protocol.md | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/draft-ietf-gnap-core-protocol.md b/draft-ietf-gnap-core-protocol.md
index 6ab7046..a5a89be 100644
--- a/draft-ietf-gnap-core-protocol.md
+++ b/draft-ietf-gnap-core-protocol.md
@@ -82,7 +82,6 @@ normative:
informative:
RFC4107:
- RFC5652:
RFC6202:
RFC6973:
RFC7518:
@@ -6147,7 +6146,7 @@ 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.
+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
@@ -6155,7 +6154,7 @@ 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 (see {{RFC5652}} for further discussion).
+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
From cf7c96bee716e69489cac50ae5733dc458e46d39 Mon Sep 17 00:00:00 2001
From: Justin Richer <justin@bspk.io>
Date: Fri, 9 Feb 2024 14:46:09 -0500
Subject: [PATCH 4/4] stupid whitespace
---
draft-ietf-gnap-core-protocol.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-ietf-gnap-core-protocol.md b/draft-ietf-gnap-core-protocol.md
index a5a89be..f00eca7 100644
--- a/draft-ietf-gnap-core-protocol.md
+++ b/draft-ietf-gnap-core-protocol.md
@@ -6146,7 +6146,7 @@ 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.
+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