Subject: Re: [GNAP] Key Rotation

From: Aaron Parecki <[email-masked]>
Date: Tue, 6 Jul 2021 14:28:43 -0700

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 7 Jul 2021 00:30:59 +0200

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 <[email-masked]> a écrit :

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 7 Jul 2021 09:57:54 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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.
> 
>                 • We allow rotation of the token value at client instance request...
>                 • Specifically: the continuation access token is bound to a key
> 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.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 7 Jul 2021 16:10:33 +0200

Hi Justin,

I suggest
https://github.com/decentralized-identity/keri/blob/master/kids/kid0005.md
as a potential method (at least for discussion on a pre-rotation scheme).

Fabien

Le mer. 7 juil. 2021 à 15:57, Justin Richer <[email-masked]> 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
>
>> 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

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 7 Jul 2021 14:14:37 +0000

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.

Best

--thomas

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

 — Justin

On Jul 6, 2021, at 6:30 PM, Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:

Hi there,

Fabien

Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <[email-masked]<mailto:[email-masked]>> 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.

Aaron

On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <[email-masked]<mailto:[email-masked]>> 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.

 — Justin
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 7 Jul 2021 10:20:47 -0400

My take as an individual:

Keys are so intrinsic to GNAP’s architecture, for both client instances and tokens, I argue we’d be amiss to not mention their management over time, which would include rotation. There’s nothing in the spec right now except that it’s allowed to happen (ie, “the client instance’s key or its most current rotation”), and this discussion is to raise exactly how much we ought to specify that throughout GNAP.

I think Aaron’s point is an important one though: if you have a key management scheme in place, you should be able to just use that as-is without GNAP knowing anything about it at the protocol level. What we’re talking about is an in-protocol dynamic way to manage the associated keys.

 — Justin

> On Jul 7, 2021, at 10:14 AM, Thomas Hardjono <[email-masked]> wrote:
> 
> 
> From: TXAuth [[email-masked] <mailto:[email-masked]>] on behalf of Justin Richer [[email-masked] <mailto:[email-masked]>]
> On Jul 6, 2021, at 6:30 PM, Fabien Imbault <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
> Hi there,
> 
> Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> a écrit :
> On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 7 Jul 2021 10:21:46 -0400

Interesting, this mechanism seems to assume a specific key type (they all look to be the same length values, for example). It feels less like rotation and more like a key derivation function, but I would need to learn more about how it actually functions.

Thank you for passing that along!

 — Justin

> On Jul 7, 2021, at 10:10 AM, Fabien Imbault <[email-masked]> wrote:
> 
> Hi Justin,
> 
> I suggest https://github.com/decentralized-identity/keri/blob/master/kids/kid0005.md <https://github.com/decentralized-identity/keri/blob/master/kids/kid0005.md> as a potential method (at least for discussion on a pre-rotation scheme). 
> 
> Fabien
> 
> 
> Le mer. 7 juil. 2021 à 15:57, Justin Richer <[email-masked] <mailto:[email-masked]>> a écrit :
>> On Jul 6, 2021, at 6:30 PM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi there,
>>

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 7 Jul 2021 14:32:31 +0000

Yes, keys are so intrinsic to many things in this digital world :-)

I'm just pointing out that it may be over-reach for GNAP to define a key-rotation mechanism/procedure (TLS WG never did).

>>> if you have a key management scheme in place, 
>>> you should be able to just use that as-is without GNAP knowing anything about it at the protocol level.

Agree. This is true for TLS and IPsec as well, and many other protocols.

--thomas

________________________________________
From: Justin Richer [[email-masked]]
Sent: Wednesday, July 7, 2021 10:20 AM
To: Thomas Hardjono
Cc: Fabien Imbault; GNAP Mailing List; Aaron Parecki
Subject: Re: [GNAP] Key Rotation

 — Justin

On Jul 7, 2021, at 10:14 AM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> wrote:

Best

--thomas

From: TXAuth [[email-masked]<mailto:[email-masked]>] on behalf of Justin Richer [[email-masked]<mailto:[email-masked]>]

— Justin

On Jul 6, 2021, at 6:30 PM, Fabien Imbault <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Hi there,

Fabien

Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> 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.

Aaron

On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> 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.

— Justin
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 7 Jul 2021 16:40:14 +0200

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 <[email-masked]> a écrit :

>
> As much as I like the direction of GNAP, is key-rotation (i.e. key
> management) even part of the GNAP charter?
>
> On Jul 6, 2021, at 6:30 PM, Fabien Imbault <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi there,
>

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 7 Jul 2021 11:27:39 -0400

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 <[email-masked]>
wrote:

>> 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).
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 12 Jul 2021 20:51:04 +0300

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.

Thanks,

                Yaron

From: TXAuth <[email-masked]> on behalf of Adrian Gropper <[email-masked]>
Date: Wednesday, July 7, 2021 at 18:28
To: Fabien Imbault <[email-masked]>
Cc: Justin Richer <[email-masked]>, Thomas Hardjono <[email-masked]>, GNAP Mailing List <[email-masked]>, Aaron Parecki <[email-masked]>
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 <[email-masked]> 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?

Best

--thomas

 — Justin

Hi there,

Fabien

Aaron

 — Justin

-- TXAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/txauth

---

From: Andrii Deinega <[email-masked]>
Date: Mon, 19 Jul 2021 14:38:34 -0700

Hi WG,

I shared a couple of my thoughts/ideas on this topic in
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105#issuecomment-806153772
and would like to bring them here again

Another option would be to introduce the client key management URI (similar
to Token Management URI) which accepts an object with similar properties to
what "DPoP proof JWT" has and where the goal of the AS is to make sure that
that the client does have key material.

Upsides

1. may work for all currently defined, as well as for future key formats
pretty much in the same fashion
2. no need to advertise the client key management URI using the Discovery
mechanism which is great and inlined with "the protocol minimizes the need
for any pre-flight discovery"
3. each client may have its own (independent) client key management URI

Basically, this approach looks similar to what was also suggested before
with "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"...

Regards,
Andrii

On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer <[email-masked]>
wrote:

> 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.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *From: *TXAuth <[email-masked]> on behalf of Adrian Gropper <
> [email-masked]>
> *Date: *Wednesday, July 7, 2021 at 18:28
> *To: *Fabien Imbault <[email-masked]>
> *Cc: *Justin Richer <[email-masked]>, Thomas Hardjono <[email-masked]>,
> GNAP Mailing List <[email-masked]>, Aaron Parecki <[email-masked]>
> *Subject: *Re: [GNAP] Key Rotation
>
>
>
> 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.
>
>
>
> -- TXAuth mailing list [email-masked]

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 19 Jul 2021 22:05:42 +0000

Hi Yaron,

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

So perhaps we need to use tighter words or definitions, specially if the goal is for GNAP to have wide adoption and co-exist with existing infra.

I think a Key-ID makes sense because that's how many systems today identify keys in their key-database (e.g. SA database in IPsec).

The question becomes *what* exactly is a Key-ID in the context of GNAP.

Is it an Octet string of a given length (i.e. with length less than or equal the key-length in bits)?

>>>  I don’t think we should assume an external key management service.

Wanting a KeyID to identify crypto keys is different from wanting a key management protocol that implements a key lifecycle (e.g. that includes key-gen, key rotation, key deletion, key archiving, etc. etc.).

Best

--thomas

On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
                Yaron

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

- Adrian

On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> a écrit :

Best

--thomas

 — Justin

On Jul 6, 2021, at 6:30 PM, Fabien Imbault <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

Hi there,

Fabien

Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> 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.

Aaron

On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> 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.

 — Justin
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
-- TXAuth mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 21 Jul 2021 17:08:44 +0200

Hi Thomas,

We already identify keys in the protocol, cf 7.1.1 key references. In that
same section, we are quite open to any mechanism ("The means of
dereferencing this value are out of scope for this specification").
Does that cover your concerns?

Cheers
Fabien

Le mar. 20 juil. 2021 à 00:06, Thomas Hardjono <[email-masked]> a écrit :

> So perhaps we need to use tighter words or definitions, specially if the
> goal is for GNAP to have wide adoption and co-exist with existing infra.
>
> I think a Key-ID makes sense because that's how many systems today
> identify keys in their key-database (e.g. SA database in IPsec).
>
> Wanting a KeyID to identify crypto keys is different from wanting a key
> management protocol that implements a key lifecycle (e.g. that includes
> key-gen, key rotation, key deletion, key archiving, etc. etc.).
>
>
>
> Best
>
> --thomas
>
>
>
> From: TXAuth <[email-masked]<mailto:[email-masked]>> on
> behalf of Adrian Gropper <[email-masked]<mailto:
> [email-masked]>>
> Cc: Justin Richer <[email-masked]<mailto:[email-masked]>>, Thomas
> Hardjono <[email-masked]<mailto:[email-masked]>>, GNAP Mailing List <
> [email-masked]<mailto:[email-masked]>>, Aaron Parecki <[email-masked]
> <mailto:[email-masked]>>
> On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault <[email-masked]
> From: TXAuth [[email-masked]<mailto:[email-masked]>] on
> behalf of Justin Richer [[email-masked]<mailto:[email-masked]>]
> <mailto:[email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>> wrote:
>
> Hi there,
>
> Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> a
> écrit :
> On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> -- TXAuth mailing list [email-masked]<mailto:[email-masked]>

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 21 Jul 2021 16:03:33 +0000

Thanks Fabien,

My general concern was GNAP going into specifying a full key management protocol (which is not a bad idea in itself, but would probably need a separate WG).

Section 7.1.1 is good (including the line on dereferencing).

Also, related to the discussion on "key rotation",  I think Section 6.1 and 6.2 is good.

Best

--thomas

________________________________________
From: Fabien Imbault [[email-masked]]
Sent: Wednesday, July 21, 2021 11:08 AM
To: Thomas Hardjono
Cc: Yaron Sheffer; GNAP Mailing List; Justin Richer
Subject: Re: [GNAP] Key Rotation

Hi Thomas,

We already identify keys in the protocol, cf 7.1.1 key references. In that same section, we are quite open to any mechanism ("The means of dereferencing this value are out of scope for this specification").
Does that cover your concerns?

Cheers
Fabien

Le mar. 20 juil. 2021 à 00:06, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Yaron,

Best

--thomas

On Mon, Jul 12, 2021 at 10:51 AM Yaron Sheffer <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

Thanks,
                Yaron

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

- Adrian

On Wed, Jul 7, 2021 at 10:40 AM Fabien Imbault <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> 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 <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> a écrit :

Best

--thomas

From: TXAuth [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>] on behalf of Justin Richer [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]

 — Justin

On Jul 6, 2021, at 6:30 PM, Fabien Imbault <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>> wrote:

Hi there,

Fabien

Le mar. 6 juil. 2021 à 23:29, Aaron Parecki <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>> 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.

Aaron

On Tue, Jun 15, 2021 at 10:52 AM Justin Richer <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>> 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.

 — Justin
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/txauth
-- TXAuth mailing list [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/txauth