View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009867 | 10000-014: PubSub | Spec | public | 2024-09-30 12:00 | 2024-09-30 12:00 |
| Reporter | Matthias Damm | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Product Version | 1.05.04 RC1 | ||||
| Summary | 0009867: Need clarification for handling of SecurityGroup configuration changes | ||||
| Description | It is possible to change the configuration of a SecurityGroup when it is in use. Such a change includes modification of SecurityPolicy and lifetime of keys. It is not defined what happens with the existing keys in this case. Especially a change of SecurityPolicy makes it impossible to continue with the existing keys. But also a change of lifetime is a problem since it is used to calculate the time of key rotation in case of pre-fetched keys. I think we should require to invalidate all existing keys (behaviour like InvalidateKeys Method) if the SecurityPolicyUri or KeyLifetime of a SecurityGroup is changed. A change of MaxFutureKeyCount or MaxPastKeyCount should be no problem. A change of SecurityGroupId shall be rejected since it must be identical to the name and a name change would be a delete and add. | ||||
| Tags | No tags attached. | ||||
| Commit Version | |||||
| Fix Due Date | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-09-30 12:00 | Matthias Damm | New Issue |
