Get local authorities to attributes #43
Conversation
…f a list Signed-off-by: Marcos Yacob <marcos.yacob@hpe.com>
MarcosDY
requested review from
evan2645,
amartinezfayo,
azdagron and
rturner3
as code owners
| @@ -128,7 +140,19 @@ message RevokeJWTAuthorityResponse { | |||
| message GetX509AuthorityStateRequest {} | |||
|
|
|||
| message GetX509AuthorityStateResponse { | |||
| repeated AuthorityState states = 1; | |||
| // Autority currently beign used for signing operations. | |||
| AuthorityState Active = 1; | |||
There was a problem hiding this comment.
| AuthorityState Active = 1; | |
| AuthorityState active = 1; |
| @@ -83,7 +83,19 @@ service LocalAuthority { | |||
| message GetJWTAuthorityStateRequest {} | |||
|
|
|||
| message GetJWTAuthorityStateResponse { | |||
| repeated AuthorityState states = 1; | |||
| // Autority currently beign used for signing operations. | |||
There was a problem hiding this comment.
| // Autority currently beign used for signing operations. | |
| // Authority currently being used for signing operations. |
| @@ -128,7 +140,19 @@ message RevokeJWTAuthorityResponse { | |||
| message GetX509AuthorityStateRequest {} | |||
|
|
|||
| message GetX509AuthorityStateResponse { | |||
| repeated AuthorityState states = 1; | |||
| // Autority currently beign used for signing operations. | |||
There was a problem hiding this comment.
| // Autority currently beign used for signing operations. | |
| // Authority currently being used for signing operations. |
Signed-off-by: Marcos Yacob <marcos.yacob@hpe.com>
There was a problem hiding this comment.
I don't see a reason to keep the "State" field in the AuthorityState message with these fields present. I also wonder if tainted should have its own field in the Get(X509|JWT)AuthorityState response (repeated AuthorityState tainted).
What's the criteria for something being old? How does that differ from prepared? And how do you distinguish? Is old just all non-active, non-tainted keys that are older than the active key?
Let's say we have the following keys, ordered by descending creation date.
K5
K4
K3
K2
K1
Anything newer than the active key set, that is also not tainted, is "prepared". So If K3 is "active", then K4 and K5 is "prepared". Anything older than the active key set, that is also not tainted, is "old" (well maybe... it might never have been used), so K2 and K1 are "old".
K5 <-- prepared
K4 <-- prepared
K3 <-- active
K2 <-- old
K1 <-- old
Now, we might constrain these buckets and say that there can be at most one "prepared" key, and only one "old" key by the way we construct our RPCs and state changes.
Seems like there can be any number of tainted keys.
| // Authority without state, This in an error condition and should | ||
| // never be encountered. | ||
| AuthorityState unknown = 4; |
There was a problem hiding this comment.
I don't see a good reason to return this. The caller can't do anything with it. If this situation was ever encountered, server logs would probably suffice?
There was a problem hiding this comment.
agree, there is no reason to return unknown authorities, even we must never get into this situation
| // Authority without state, This in an error condition and should | ||
| // never be encountered. | ||
| AuthorityState unknown = 4; |
There was a problem hiding this comment.
Same comment as the unknown state in GetJWTAuthorityStateResponse
Old was previously activate, or just a Prepared key that moved into Old state in case we force to have a new Prepared key, |
Signed-off-by: Marcos Yacob <marcos.yacob@hpe.com>
* Update get local authorities to return authorities by state instead of a list * Remove Status from responses Signed-off-by: Marcos Yacob <marcos.yacob@hpe.com>
* Update get local authorities to return authorities by state instead of a list * Remove Status from responses Signed-off-by: Marcos Yacob <marcos.yacob@hpe.com>
* Update get local authorities to return authorities by state instead of a list * Remove Status from responses Signed-off-by: Marcos Yacob <marcos.yacob@hpe.com>
Update get local authorities to return authorities by state instead of a list