Re: [GNAP] Key Rotation

Fabien Imbault <> Wed, 07 July 2021 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EDE33A191F for <>; Wed, 7 Jul 2021 07:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 Bvd9ZII_Ovej for <>; Wed, 7 Jul 2021 07:10:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EEEC3A191E for <>; Wed, 7 Jul 2021 07:10:47 -0700 (PDT)
Received: by with SMTP id a6so3685399ioe.0 for <>; Wed, 07 Jul 2021 07:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cEugg1OpzZOFDRTPSY0iEEVwkSqx7vVU02ZS720DXU4=; b=hRMSEgiFkpjGBW26Af2uBAoTBc5JKT+RmTLt3AaLxPQ7S3A8DhgTuiUk+ebkN5V+yz cx4cDjYLsQqhcSbnc1pU1AXKBUBEjvCbIpY5E1o1CUglCEePrAGpXrdYalLPXfPQ2x3g q4Q4bgxZ/eB57LouD1pQULvrkSgtQFJKetp2Bi3I8H2x0hZgNgrRYIG5U2GIKDPITvzx a7daSl2M9pmcVcfZJRzrPqw7bkJpTJn4FsvwiXwKkcBZVL0ySsKGAGAqyyHXqbE3XGNG GO//ZvlDP2MwRL1G93PRw9xcYC3/922qobQGhnEPS9Fc5TWx3MMVzrl99lGG3S/S+hWD BsdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cEugg1OpzZOFDRTPSY0iEEVwkSqx7vVU02ZS720DXU4=; b=lXiQ6mBFOGxqTZDB7Brx0QFssWvxcViU/DdsDurlfwBlehIg4V2YQ+Hxug6tIouX0l Ai2qp9kzTfmd5WQFfW9u03epl8kdppQd8u/UB28RyHmpz6a1NIiNBD1Di9aKb2ooNgbO zUU4j46WZfe0TSgLD8sWS4FUQHaFvbCzWikOjE5pYJEYpom7A7VPM8gEVvuAPLJYF1Xy mOfAh8tZPAbLOEd+4lxoH9uQHni2F2tYlYADRePTALL3mkIFgvfYi18uffrTw+39lXIJ hdpN/WbIyicrKil5CLp+hVOB7UTmSWFct/GifjvVtHLMd1bNajA2sYBoKCTzwEzE56Eh Rydg==
X-Gm-Message-State: AOAM531+e+KEfKZCatlzDuUPaBnnI8pm5f6T7H0z65AvDQuwEPHdqq2g RWmOsgZhcvf9EsOpl1LZoQxLuUJKFB12fpywKOA=
X-Google-Smtp-Source: ABdhPJwUL3qEKDx8XeXri40UhUnTnnU4X8SUMVMO1gf5oyDV9c7Fko8A6/Oa+u1v4vdveyHu5NC1itz/7FYtF31qcfc=
X-Received: by 2002:a05:6638:bc5:: with SMTP id g5mr10062853jad.47.1625667045027; Wed, 07 Jul 2021 07:10:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Wed, 07 Jul 2021 16:10:33 +0200
Message-ID: <>
To: Justin Richer <>
Cc: Aaron Parecki <>, GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="000000000000bdf20705c6891a9b"
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: Wed, 07 Jul 2021 14:10:52 -0000

Hi Justin,

I suggest
as a potential method (at least for discussion on a pre-rotation scheme).


Le mer. 7 juil. 2021 à 15:57, Justin Richer <> a écrit :

> 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.
> Fabien
> 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?
>> Aaron
>> 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