Re: [GNAP] Key Rotation

Fabien Imbault <> Tue, 06 July 2021 22:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BF2D3A1866 for <>; Tue, 6 Jul 2021 15:31:17 -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 LEn6PBDvBl2i for <>; Tue, 6 Jul 2021 15:31:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E9A33A1864 for <>; Tue, 6 Jul 2021 15:31:12 -0700 (PDT)
Received: by with SMTP id h6so597780iok.6 for <>; Tue, 06 Jul 2021 15:31:12 -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=htOdzIC5ZhV8JYDSvBvHbls48Ny2ppbs1YNYL8IWYkc=; b=n8RGm5Ka8wczdyO/hlIoDkkTyFaNfeJzBdPGv13zX3S388rKloRQ7Y2zOjTDzO/2N8 sfxfTr3d5o6+E+f/46xQH7diQVYA2lVadoR14xYgzX06vhVHWgAeOhDDF6CiDn5XVG4Q C/8MsSNZaebFIy984igoAYphSCNYWjKQvPqp+kxjx0CLX+mIscD+sImmee17vpXNrFye PJmg5QcKIkZU/Z84s61J3RUIo3os5j+CtrXAYfgaJAE9fTcbZ1d98CZA8BolNKBZdkTz aHgGppTr2cN22tdwj/I9pdKmjmMLNj/uunv0mGRa7P9k9OZhzGqhiFIweZ7GReJ+7N1q AjAQ==
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=htOdzIC5ZhV8JYDSvBvHbls48Ny2ppbs1YNYL8IWYkc=; b=YxgJFxlIMDXQXr8BDeg4P0cbE+NkbmHsiJD+OLfjewaW+B2WMFDBj17m1pIaeK55co orCqk+WXnzzA3P+Ih0NOH0XCNeCetLvp6wsBkS2Gls6SevVsz344W8V1TvNTwZVZ/yGy 5YZtGgAbCW4/+3BOa8S//JkTwqa0QNdritVotqZC0JmdNy1WcZhxuQRosTdmdtVSfBl1 FkrQJyTHVtckhx1ICKyofHhMkJ7ykjhzzNckBXqxhKVaaNTEdX9YW4j+JyXJPIR/1RrF DCoit+SkEYgTMDgOGlg5LUehlA8CK/Ne2duVp6fbCVctLyfARfSdrHotRsJL8Dl5bUR7 R+KA==
X-Gm-Message-State: AOAM533YUkdeyqFS1LICYwDY+1ilWeqgY8zIjfTBmog0XB+CBKn7NLLJ pmu/yQDMLyHkgdu5+lRBJAoEhUs+GMzmHd16ww6q8xrp
X-Google-Smtp-Source: ABdhPJzHGOjlckamepqtofdXm0jrmQcS9FVfwIREa0sesPzBU1PxJGMgVYiPWdQ69cQLaYMGH9QVWt5/unhDFmB4cVQ=
X-Received: by 2002:a5e:de06:: with SMTP id e6mr3673230iok.74.1625610670611; Tue, 06 Jul 2021 15:31:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Wed, 07 Jul 2021 00:30:59 +0200
Message-ID: <>
To: Aaron Parecki <>
Cc: Justin Richer <>, GNAP Mailing List <>
Content-Type: multipart/alternative; boundary="00000000000090a3fe05c67bfa31"
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: Tue, 06 Jul 2021 22:31:17 -0000

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

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?
> 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