Use next update time as mft EE expiry time (#589)

defaults/krill.conf

@@ -205,47 +205,26 @@
 # they are presented old versions of Manifests thus withholding them from discovering
 # new RPKI objects.
 #
-# Manifests have two important dates included in them:
-# 1- the 'next update time'
-# 2- an expiration time
-#
-# When the next update time is passed manifests will become 'stale'. This means
-# the Validators may either warn about the objects listed in these manifests, or
-# they may even reject these objects altogether. There is current discussion about
-# aligning this behaviour in the IETF - but for the moment the outcome will vary
-# between Validator implementations.
-#
-# When the expiration time (not after time on the embedded EE certificate of the
-# Manifest) passes, then the Manifest will be considered invalid by all Validator
-# implementations.
-#
-# So, if Validators are subject to replay attacks of Manifests they will be
-# unaware until these times have passed. After these times the Manifest and all
-# listed RPKI objects will become invalid. When ROA objects become invalid, this
-# typically means that the Route Announcement will be considered "Not Found", rather
-# than invalid. So, typically they would not be dropped, but they are no longer
-# protected by RPKI.
-#
-# One could therefore argue that short times should be used. However, if the times
-# chosen are too short, then this will leave your CA vulnerable to possible
-# operational issues with its RPKI repository - or outages of your CA itself.
-#
-# So, in short, the chosen values are a balance between the wish to limit the
-# vulnerability to replay attacks vs the time an operator has to solve operational
-# issues.
-#
-# Krill uses the following defaults:
-#
-# The "next update" time is 24 hours:
-# timing_publish_next_hours = 24
-#
-# The "not after time" on the EE certificate is 7 days from issuance:
-# timing_publish_valid_days = 7
-#
-# Krill will automatically re-publish new Manifests if they would become stale
-# in 8 hours. Because re-publication happens hourly, this leaves the operator
-# with a minimum of 7 hours to fix issues if re-publication should fail.
-# timing_publish_hours_before_next = 8
+#
+# Krill issues manifests with a default next update and validity period of 24 hours.
+# This means that the maximum replay window is 24 hours. Krill checks every 10 minutes
+# whether the next update time is less then 8 hours (by default) in the future, and in
+# that case it will re-issue them to avoid that Validators would end up with expired
+# manifests. This means that an operator has a minimum of just under 8 hours to deal
+# with issues with their CA or Publication Server before RPKI Validators would notice.
+#
+# The default values can be overridden, but with care.. make the next update interval
+# too short and this causes too much work for all RPKI validators, puts load on your
+# publication server and shortens your window to deal with issues. Make it too long
+# and you could be vulnerable to replay attacks. Re-issue to quickly and again you
+# cause extra load to RPKI validators and publication server.
+#
+# All that said.. if you are willing to accept the, in practice, small risk of a replay
+# attack then you could for example opt for 48 hours next update and re-issue every
+# 24 hours. That way you would have a full day to fix issues.
+#
+# timing_publish_next_hours = 24           # (must be 2 or higher)
+# timing_publish_hours_before_next = 8     # (must be 1 or higher)
 
 
 #

src/daemon/ca/publishing.rs

@@ -1403,7 +1403,6 @@ impl ManifestBuilder {
         let this_update = Time::five_minutes_ago();
         let now = Time::now();
         let next_update = Time::now() + Duration::hours(issuance_timing.timing_publish_next_hours);
-        let valid_until = Time::now() + Duration::days(issuance_timing.timing_publish_valid_days);
 
         let entries = self.entries.iter().map(|(k, v)| FileAndHash::new(k, v));
 
@@ -1417,7 +1416,7 @@ impl ManifestBuilder {
             );
             let mut object_builder = SignedObjectBuilder::new(
                 signer.random_serial()?,
-                Validity::new(this_update, valid_until),
+                Validity::new(this_update, next_update),
                 crl_uri,
                 aia.clone(),
                 mft_uri,

src/daemon/config.rs

@@ -152,10 +152,6 @@ impl ConfigDefaults {
         90
     }
 
-    fn timing_publish_valid_days() -> i64 {
-        7
-    }
-
     fn timing_publish_next_hours() -> i64 {
         24
     }
@@ -289,8 +285,6 @@ pub struct Config {
 
 #[derive(Clone, Debug, Deserialize)]
 pub struct IssuanceTimingConfig {
-    #[serde(default = "ConfigDefaults::timing_publish_valid_days")]
-    pub timing_publish_valid_days: i64,
     #[serde(default = "ConfigDefaults::timing_publish_next_hours")]
     pub timing_publish_next_hours: i64,
     #[serde(default = "ConfigDefaults::timing_publish_hours_before_next")]
@@ -510,7 +504,6 @@ impl Config {
         let roa_aggregate_threshold = 3;
         let roa_deaggregate_threshold = 2;
 
-        let timing_publish_valid_days = ConfigDefaults::timing_publish_valid_days();
         let timing_publish_next_hours = ConfigDefaults::timing_publish_next_hours();
         let timing_publish_hours_before_next = ConfigDefaults::timing_publish_hours_before_next();
         let timing_child_certificate_valid_weeks = ConfigDefaults::timing_child_certificate_valid_weeks();
@@ -520,7 +513,6 @@ impl Config {
         let timing_roa_reissue_weeks_before = ConfigDefaults::timing_roa_reissue_weeks_before();
 
         let issuance_timing = IssuanceTimingConfig {
-            timing_publish_valid_days,
             timing_publish_next_hours,
             timing_publish_hours_before_next,
             timing_child_certificate_valid_weeks,
@@ -684,12 +676,6 @@ impl Config {
             ));
         }
 
-        if self.issuance_timing.timing_publish_valid_days < 1
-            || self.issuance_timing.timing_publish_valid_days < (self.issuance_timing.timing_publish_next_hours / 24)
-        {
-            return Err(ConfigError::other("timing_publish_valid_days must be 1 or bigger, and must be at least as long as timing_publish_next_hours"));
-        }
-
         if self.issuance_timing.timing_child_certificate_valid_weeks < 2 {
             return Err(ConfigError::other(
                 "timing_child_certificate_valid_weeks must be at least 2",

test-resources/krill-init-multi-user.conf

@@ -205,47 +205,26 @@ service_uri = "https://localhost:3001/"
 # they are presented old versions of Manifests thus withholding them from discovering
 # new RPKI objects.
 #
-# Manifests have two important dates included in them:
-# 1- the 'next update time'
-# 2- an expiration time
-#
-# When the next update time is passed manifests will become 'stale'. This means
-# the Validators may either warn about the objects listed in these manifests, or
-# they may even reject these objects altogether. There is current discussion about
-# aligning this behaviour in the IETF - but for the moment the outcome will vary
-# between Validator implementations.
-#
-# When the expiration time (not after time on the embedded EE certificate of the
-# Manifest) passes, then the Manifest will be considered invalid by all Validator
-# implementations.
-#
-# So, if Validators are subject to replay attacks of Manifests they will be
-# unaware until these times have passed. After these times the Manifest and all
-# listed RPKI objects will become invalid. When ROA objects become invalid, this
-# typically means that the Route Announcement will be considered "Not Found", rather
-# than invalid. So, typically they would not be dropped, but they are no longer
-# protected by RPKI.
-#
-# One could therefore argue that short times should be used. However, if the times
-# chosen are too short, then this will leave your CA vulnerable to possible
-# operational issues with its RPKI repository - or outages of your CA itself.
-#
-# So, in short, the chosen values are a balance between the wish to limit the
-# vulnerability to replay attacks vs the time an operator has to solve operational
-# issues.
-#
-# Krill uses the following defaults:
-#
-# The "next update" time is 24 hours:
-# timing_publish_next_hours = 24
-#
-# The "not after time" on the EE certificate is 7 days from issuance:
-# timing_publish_valid_days = 7
-#
-# Krill will automatically re-publish new Manifests if they would become stale
-# in 8 hours. Because re-publication happens hourly, this leaves the operator
-# with a minimum of 7 hours to fix issues if re-publication should fail.
-# timing_publish_hours_before_next = 8
+#
+# Krill issues manifests with a default next update and validity period of 24 hours.
+# This means that the maximum replay window is 24 hours. Krill checks every 10 minutes
+# whether the next update time is less then 8 hours (by default) in the future, and in
+# that case it will re-issue them to avoid that Validators would end up with expired
+# manifests. This means that an operator has a minimum of just under 8 hours to deal
+# with issues with their CA or Publication Server before RPKI Validators would notice.
+#
+# The default values can be overridden, but with care.. make the next update interval
+# too short and this causes too much work for all RPKI validators, puts load on your
+# publication server and shortens your window to deal with issues. Make it too long
+# and you could be vulnerable to replay attacks. Re-issue to quickly and again you
+# cause extra load to RPKI validators and publication server.
+#
+# All that said.. if you are willing to accept the, in practice, small risk of a replay
+# attack then you could for example opt for 48 hours next update and re-issue every
+# 24 hours. That way you would have a full day to fix issues.
+#
+# timing_publish_next_hours = 24           # (must be 2 or higher)
+# timing_publish_hours_before_next = 8     # (must be 1 or higher)
 
 
 #

test-resources/krill-init.conf

@@ -205,47 +205,26 @@ service_uri = "https://localhost:3001/"
 # they are presented old versions of Manifests thus withholding them from discovering
 # new RPKI objects.
 #
-# Manifests have two important dates included in them:
-# 1- the 'next update time'
-# 2- an expiration time
-#
-# When the next update time is passed manifests will become 'stale'. This means
-# the Validators may either warn about the objects listed in these manifests, or
-# they may even reject these objects altogether. There is current discussion about
-# aligning this behaviour in the IETF - but for the moment the outcome will vary
-# between Validator implementations.
-#
-# When the expiration time (not after time on the embedded EE certificate of the
-# Manifest) passes, then the Manifest will be considered invalid by all Validator
-# implementations.
-#
-# So, if Validators are subject to replay attacks of Manifests they will be
-# unaware until these times have passed. After these times the Manifest and all
-# listed RPKI objects will become invalid. When ROA objects become invalid, this
-# typically means that the Route Announcement will be considered "Not Found", rather
-# than invalid. So, typically they would not be dropped, but they are no longer
-# protected by RPKI.
-#
-# One could therefore argue that short times should be used. However, if the times
-# chosen are too short, then this will leave your CA vulnerable to possible
-# operational issues with its RPKI repository - or outages of your CA itself.
-#
-# So, in short, the chosen values are a balance between the wish to limit the
-# vulnerability to replay attacks vs the time an operator has to solve operational
-# issues.
-#
-# Krill uses the following defaults:
-#
-# The "next update" time is 24 hours:
-# timing_publish_next_hours = 24
-#
-# The "not after time" on the EE certificate is 7 days from issuance:
-# timing_publish_valid_days = 7
-#
-# Krill will automatically re-publish new Manifests if they would become stale
-# in 8 hours. Because re-publication happens hourly, this leaves the operator
-# with a minimum of 7 hours to fix issues if re-publication should fail.
-# timing_publish_hours_before_next = 8
+#
+# Krill issues manifests with a default next update and validity period of 24 hours.
+# This means that the maximum replay window is 24 hours. Krill checks every 10 minutes
+# whether the next update time is less then 8 hours (by default) in the future, and in
+# that case it will re-issue them to avoid that Validators would end up with expired
+# manifests. This means that an operator has a minimum of just under 8 hours to deal
+# with issues with their CA or Publication Server before RPKI Validators would notice.
+#
+# The default values can be overridden, but with care.. make the next update interval
+# too short and this causes too much work for all RPKI validators, puts load on your
+# publication server and shortens your window to deal with issues. Make it too long
+# and you could be vulnerable to replay attacks. Re-issue to quickly and again you
+# cause extra load to RPKI validators and publication server.
+#
+# All that said.. if you are willing to accept the, in practice, small risk of a replay
+# attack then you could for example opt for 48 hours next update and re-issue every
+# 24 hours. That way you would have a full day to fix issues.
+#
+# timing_publish_next_hours = 24           # (must be 2 or higher)
+# timing_publish_hours_before_next = 8     # (must be 1 or higher)
 
 
 #