Re: [GNAP] Key Rotation

Yaron Sheffer <> Mon, 12 July 2021 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 365D23A25AC for <>; Mon, 12 Jul 2021 10:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JLUxUxNXlSbm for <>; Mon, 12 Jul 2021 10:51:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 551E83A254D for <>; Mon, 12 Jul 2021 10:51:09 -0700 (PDT)
Received: by with SMTP id p3so407580ilg.8 for <>; Mon, 12 Jul 2021 10:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=LFivGdQ/OGUenF2weXupjURlqQiisHCVjRTJh5UBU2M=; b=bUL1ElPe+3hU+IKUypNPkef5LIkVsseX+trWrDcr1by9g+SM5Hglmk1KVlMX0bTObc f/UHol8A2EJjaYf3TB6Cmv9tvErtJ6dFTVY1Y8faNb1BUQOcj/vm76c4GjdwlE2tX1qo dVs0weaumCm4BYRq+mKBUFR+xzp0j7FvrOQ45zR9jnk/OIYujilsOagFuygWvcHywpgY rNBIVN2qoPG6PqYCRiNNoE5ToP2sfo36FMzTnGmetpWZJmx9Pinz672GakYIwyuS6VgV vf+qmLchTMrEp7j4Fm4zul9uQIAXEONOWpyk6F74Jtuy6X5iggTegCYOxxIzS1F/2opR p/XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=LFivGdQ/OGUenF2weXupjURlqQiisHCVjRTJh5UBU2M=; b=mUyTOYMnMQjuVkDm69WrWNAVHQYG4cjUMbzXrVj8gGMMyFo3jWkh859bbqkc8Wn6Ug IR8MjIp1oFrB0P8hP4ikXnHA6fPjKUNS08OfcrIAqGO+XImvNMEsVsH2NlETrAVAX4Vg NwA09pZgSN3hUx4FjzX2hM43E5gkmL496LyMwZJl7pBmbHpC4cQu3oEEwQh/Yejfc8tx ioXvJX8AcCqECJImTKi9hiWbCkwi892twAVWoZRUIjNDuzqEojipzYsUlWco5Ct5+HLP HGmL2Rx+yGGebExPLLZyQ8prYOAWHAhlc3ntaJelKPu7zZn8Rdd1fiNRk7/UgSYHZFor N2bg==
X-Gm-Message-State: AOAM531Xs+Xv4TbXHvjp4anpHZdkHE3s3QsxHOaB/XHiAzjCuhkda0LJ 0PoncKsxa4rKJlm0ZiIoa8s=
X-Google-Smtp-Source: ABdhPJx9b3bX9yr3QdbL05iwKYLcDQVosgzZrlW7b1KjEmShoIqXYrnA/y33N85HUq+qQYXy8D2hYg==
X-Received: by 2002:a92:d943:: with SMTP id l3mr36135ilq.37.1626112267912; Mon, 12 Jul 2021 10:51:07 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id e17sm5245558ilr.51.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jul 2021 10:51:07 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.50.21061301
Date: Mon, 12 Jul 2021 20:51:04 +0300
From: Yaron Sheffer <>
To: Adrian Gropper <>, Fabien Imbault <>
CC: Justin Richer <>, Thomas Hardjono <>, GNAP Mailing List <>, Aaron Parecki <>
Message-ID: <>
Thread-Topic: [GNAP] Key Rotation
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3708967866_439354522"
Archived-At: <>
Subject: Re: [GNAP] Key Rotation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Jul 2021 17:51:26 -0000

We absolutely need to support key rotation, and I don’t think we should assume an external key management service.


To me key rotation simply means a way to identify keys (a key ID) and the expectation that protocol parties should manage more than one key at a time: the current key and potentially older keys, up to some validity period.


If access tokens are bound to long-lived keys, we might need to add an explicit, non-opaque, key ID to access tokens.





From: TXAuth <> on behalf of Adrian Gropper <>
Date: Wednesday, July 7, 2021 at 18:28
To: Fabien Imbault <>
Cc: Justin Richer <>, Thomas Hardjono <>, GNAP Mailing List <>, Aaron Parecki <>
Subject: Re: [GNAP] Key Rotation


Whatever we do in terms of scope, GNAP should not ignore this key rotation issue. 


Regardless of what happened in the era of TLS and IPsec, today we're seeing the limits of federated security architectures and everyone needs help in the transition to zero-trust architectures. As I understand it, we're seeing part of this as the difference between OAuth2 client credentials and GNAP. 


If GNAP can do or say something useful about key rotation and client credentials, then I hope we do.


- Adrian


On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault <> wrote:

That's a valid point (i.e. you might use whatever system you want, as long as you make sure your keys are managed) although one could argue we should at the very minimum provide practical methods to ensure sufficient security. Which means we could still provide a way native to GNAP, in case people don't have their preferred method already?


Le mer. 7 juil. 2021 à 16:14, Thomas Hardjono <> a écrit :

As much as I like the direction of GNAP, is key-rotation (i.e. key management) even part of the GNAP charter? 

Key-rotation is a common problem for everyone, starting from the early days of IPsec/IKE.



From: TXAuth [] on behalf of Justin Richer []
Sent: Wednesday, July 7, 2021 9:57 AM
To: Fabien Imbault
Cc: GNAP Mailing List; Aaron Parecki
Subject: Re: [GNAP] Key Rotation

Aaron, that’s a great point about static registration. That leaves ephemeral or otherwise runtime keys, which might be good enough to just start a new request when needed?

Ben had previously posited a functional approach like sign(k2, sign(k1, (k2))): you use the old key (k1) to sign the new key (k2), then use the new key to sign that signature and present it. The thing that I get hung up on is having a way to do the key proofing for a new key that works consistently for all the different key types in use. The outer signature, signing with the new key, is easy: that’s the GNAP key proofing mechanism. The trick is carrying a signed object with the key material internally somehow — is there a way to handle that consistently across different proofing types?

There are a bunch of ways that it could be done with different proofing mechanisms and that might be the right approach. HTTP Message Signatures can attach multiple signatures. JWK-based-keys could use JWS to wrap the key content as part of the payload (so you’d get something like a nested JWT). MTLS is a strange one, but if you’re in certificate space you have other options like CA’s and OCSP to help manage your keys at a different level. So maybe GNAP just specifies the functional requirement at a high level and each proofing mechanism or deployment has to fill that somehow in its definition?

Still, something in me says that we should be able to do this in one consistent pattern, and I’d love to hear more ideas on how that could be handled. If we can crack that, then it becomes a matter of applying that to a bunch of different requests: grant update, token rotation, initial request, etc. This piece, at least, I believe can be applied pretty generically.

 — Justin

On Jul 6, 2021, at 6:30 PM, Fabien Imbault <<>> wrote:

Hi there,

As far as I know, key rotation remains a cumbersome process in most cases, to say the least. It's quite impressive how often that breaks (usually when a certificate expires somewhere).

The exception is caddy server, that does it really well. Works fine in production.

And then, as a proof of concept, there's DIF Keri that embeds key rotation as a primary requirement.


Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <<>> a écrit :
I do think it's important that a client instance should be able to rotate its keys, as this is a pretty common practice in other related specs.

You mentioned pre-registered clients which I think is an interesting case. I would expect in those cases the client instance wouldn't actually be rotating its keys on its own, instead the developer/administrator would go into the management console to rotate the keys there, and deploy the new keys to the client instance, more like how typical OAuth clients work today.

Coming up with the actual rotation method is definitely an interesting challenge, but there must be some prior art to draw from here. Wouldn't existing specs like Mutual TLS or even PGP have some mechanism that could be reused?


On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <<>> wrote:
In the GNAP protocol, most requests are bound to a key. There are pretty solid mechanisms for establishing those keys as part of the request, both dynamically and as part of some pre-registration step.

However, over time those keys could be rotated out by the parties that control them, and GNAP needs to be able to handle this.

        • Access tokens are bound to keys
                • We allow rotation of the token value at client instance request...
                • Should we allow rotation of the key also?
        • Grant transactions are also bound to keys
                • Specifically: the continuation access token is bound to a key
                • The key is initially the client instance’s key
                • Should the client be able to rotate this key separately?
        • Some client instances have registered keys
                • What happens when a client’s registered key rotates?

Secure rotation of a key would require some way for the presenter to prove possession of both the old and new keys simultaneously. It could be a matter of signing the request with the new key and include some artifact signed by the old key in the request, or the inverse of that. There are likely other methods out there, but this seems simplest.

What situations are people looking at for handling key rotation?

 — Justin
TXAuth mailing list<>
TXAuth mailing list<>

TXAuth mailing list

-- TXAuth mailing list