The first push is started at the time a SecurityGroupis assigned to the PubSubKeyPushTarget. The assignment is done with the Method ConnectSecurityGroupsor with a successful update of the PubSubKeyPushTargetswith PubSubConfigurationType CloseAndUpdate. The sequence for push is described in 5.4.4.3.

In a period of half the KeyLifetimeof a SecurityGroup, the SKS shall open a secure communication to each related PubSubKeyPushTargetsand shall call SetSecurityKeysto push the security keys for a SecurityGroupinto a Publisheror Subscriber. The SKS shall push the previous security key, the current key, and at least one future key to bridge longer unavailability time of the SKS. If it is not possible to push security keys to a PubSubKeyPushTargetdue to errors in establishing the communication or due to errors returned from the SetSecurityKeys Method call, the SKS shall retry pushing the security keys in a period of RetryInterval. If multiple future security keys are pushed, it is up to the SKS to define when security keys are pushed, but at a minimum it shall be at the half KeyLifetimeof the current key when only one future key is remaining.

Since the SKS is unaware of the state of a PubSubKeyPushTarget, it is recommended for a PubSubKeyPushTargetto persist security keys. This allows the PubSubKeyPushTargetto continue secured PubSub communication after a power cycle, as long as the outage time is smaller than the time covered with currentKey and FutureKeys. If keys are not persisted, it may take up to half the KeyLifetimeto get the first set of security keys. The PubSubKeyPushTargetspersisting security keys shall have an understanding of time (either synchronized or battery backup) allowing them to determine whether the current key is still valid to use, or whether to use a future keyfollowing a power interruption.