Subject: [sidr] Erratum for RFC6486? (manifests)

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 16 Jul 2013 11:39:39 +0200

Dear WG,

RFC6486 has this to say about the validity times of EE certificates in manifests:

http://tools.ietf.org/html/rfc6486#section-5.1

         In the case of a "one-time-use" EE certificate, the validity
         times of the EE certificate MUST exactly match the thisUpdate
         and nextUpdate times of the manifest.

         In the case of a "sequential-use" EE certificate, the validity
         times of the EE certificate MUST encompass the time interval
         from thisUpdate to nextUpdate.

This causes some issues for our RP software, and I believe it would be better to remove the difference between one-time-use and sequential-use here, and go with something like this instead:

         The validity times of the EE certificate MUST encompass the time
         interval from thisUpdate to nextUpdate.

Reasons:

1) RP can not distinguish between one-time-use and sequential-use

RPs don't know which case they are dealing with, and guessing is error-prone.

So, in our case we are checking for a condition we don't know how to handle, and in the end we just warn about it.. I am happy to remove this confusing warning, but then what's the point of limiting this in the RFC?

2) Stale vs expired manifests

See sections 6.3 and 6.4.

If a manifest EE certificate is expired, then the manifest is invalid. However, if the EE certificate is still valid, but it's past the "nextUpdate" time, then it should be considered "stale". The restriction in 5.1 prevents that manifests with one-time-use EE certificates can have this stale state. Yet, this is something a CA may well want to use, e.g.:

 - issue EE certificate validity time of 1 week
 - nextUpdate time 1 day

The idea being that under normal circumstances a new manifest would be issued within 24 hours (or less), and RPs should use the *latest* manifest available to them, but… in case the RP can't reach the repository, or there is an outage, stale manifests could be used for some time (per local policy of RPs).

We currently allow users to accept stale manifest for X days (default = 0 days). To circumvent the issue that one-time-use EE certs would be invalid as soon as they go stale we also accept expired manifest for the same time.. I think this is wrong (e.g. CAs will no longer mention the EE cert on the CRL if it's expired), and again I am more than happy to remove this hack..

In short: I think CAs should have the freedom to choose longer validity times for one-time-use EE certificates. As far as I know *all* implementations use one-time-use anyway, so if this is not permitted, then the difference between 6.3 and 6.4 becomes moot in practice.

Cheers
Tim

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Jul 2013 17:27:25 -0400

At Tue, 16 Jul 2013 11:39:39 +0200, Tim Bruijnzeels wrote:
> This causes some issues for our RP software, and I believe it would
> be better to remove the difference between one-time-use and
> sequential-use here, and go with something like this instead:
> 

I support this change

> In short: I think CAs should have the freedom to choose longer
> validity times for one-time-use EE certificates.

Agreed.

> As far as I know *all* implementations use one-time-use anyway,

The rpki.net implementation has always used sequential-use manifest EE
certificates.  We set the notAfter time of the manifest EE certificate
to match the notAfter time of its issuing CA certificate, on the
theory that the only reason we're even bothering with a separate EE
certificate is that PKIX doesn't allow us to use the CA certificate
directly.  If we were designing X.509 all over again to support this,
I'd class manifests as something to be covered directly by the CA
certificate, just as CRLs are.  But we're not revising X.509.

Manifest EE certificates are required to use RFC 3779 inheritance, so,
barring a key compromise, there's generally no pressing reason to
regenerate a manifest EE certificate.  We can always revoke the
manifest EE certificate if really necessary, but optimizing for the
key compromise case seems perverse. :)

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Jul 2013 13:35:59 -0400

Tim,

Section 5.1 of RFC 6486 is titled "Manifest Generation Procedure." This 
it is a set of directions to the CA creating the manifest, not 
directions to an RP verifying a
manifest. Section 6 is the discussion of what a relying party is 
supposed to do with a manifest. My quick re-read of Section 6 does not 
call for an RP to check that the validity time is consistent with the 
single-use vs. sequential-use EE cert criteria in 5.1. So, the primary 
concern you cited, i.e., that an RP cannot know which test to apply, is 
not a valid
reason to change this text.

I agree that the invalid vs. stale disparity that arises because of the 
directions to
CAs on manifest EE cert generation is an awkward one. Your example of a 
manifest with
a planned daily update, but a cert that is valid for a week, is an 
reasonable operational
model. If RPs continue to fetch data based on what has changed, then a 
manifest that is
slated to change, but doesn't, doesn't impose an addition sync load. If 
an RP were to
fetch data based on when it says it will expire, then this might be less 
desirable. So
we might take that into consideration when suggesting this model.

If we had guidelines for best practices for pub point management, with 
suggested
rates of change, we might better understand the possible impact of this 
operational
model. For example, if the recommended frequency of CRL issuance is 
daily, then the
manifest ought to change daily as well, the there's a decent chance that 
the CRL and
the manifest are either both stale or current.

So, while I believe that there is no need to change the 5.1 text based 
on the
RP concern you cited, I support a change to that text to allow CAs more
flexibility in managing the EE cert validity in manifests, and to remove the
single-use vs. sequential-use EE cert distinction.

Would you like to propose and share text for the suggested change? We 
may have to
issue a new RFC, updating 6486, since this does represent a technical 
change to
how we say a CA should behave.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 19 Jul 2013 14:34:25 +0200

Hi Steve,

I think we agree for the most part on the idea to remove the restriction for single use EE certificate. To quote and answer to the end of your mail first:

Sandy, I am not sure, but this may be short topic for one of the sessions. Especially if we want to say anything about best practices for CAs.

> So, while I believe that there is no need to change the 5.1 text based on the
> Would you like to propose and share text for the suggested change? We may have to
> issue a new RFC, updating 6486, since this does represent a technical change to

I proposed to change this text in section 5.1:

To:

That said I think there are quite a few details left that are worth discussing.

> Section 5.1 of RFC 6486 is titled "Manifest Generation Procedure." This it is a set of directions to the CA creating the manifest, not directions to an RP verifying a
> manifest. Section 6 is the discussion of what a relying party is supposed to do with a manifest. My quick re-read of Section 6 does not call for an RP to check that the validity time is consistent with the single-use vs. sequential-use EE cert criteria in 5.1. So, the primary concern you cited, i.e., that an RP cannot know which test to apply, is not a valid

Although I agree in general with the approach to "be strict in what you send, and liberal in what you accept" I just found this instance confusing. It was not 100% clear to me if I should care as an RP. 

In any case, I am happy to remove this check, and only care about valid, stale, invalid..

> I agree that the invalid vs. stale disparity that arises because of the directions to
> CAs on manifest EE cert generation is an awkward one.

> Your example of a manifest with
> a planned daily update, but a cert that is valid for a week, is an reasonable operational
> model. If RPs continue to fetch data based on what has changed, then a manifest that is
> slated to change, but doesn't, doesn't impose an addition sync load. If an RP were to
> fetch data based on when it says it will expire, then this might be less desirable. So

As I understand there are three cases with regards to stale and invalid based on time (ignoring other cases):

-1 Manifest is current
       = now is after thisUpdate and before nextUpdate &&
       = now is within EE Certificate validity time

-2 Manifest is stale
       = now is after nextUpdate
       = now is within EE Certificate validity time

-3 Manifest is invalid
       = now is outside of (after) EE Certificate validity time

The current text allows for all three states to exist for multi-use EE certificates, but only 1 and 3 can exist for single use. I want remove this restriction, because RP treatment of "stale" is different from "invalid", and as a CA I want to be able influence this.

> If we had guidelines for best practices for pub point management, with suggested
> rates of change, we might better understand the possible impact of this operational
> model. For example, if the recommended frequency of CRL issuance is daily, then the
> manifest ought to change daily as well, the there's a decent chance that the CRL and

I agree that best practices would be good, both for CA and RP.

Is this something to discuss shortly?

As a start…

W.r.t. RP:
 - I would advise against fetching new manifests based on the expiry of the EE cert if that date is after the nextUpdate.
 - I would advice that RPs fetch new data at least in advance of the 
 - I think RPs are free to poll more frequently
 ….

W.r.t. CAs:
 - I would advise to limit the nextUpdate time to a window that forms the 'optimal compromise' between:
        - being overrun by RPs trying to get new data
        - workload of generating new certificates
        - too slow propagation times for new products - to -router

  - The RIR implementations all use 24 hours I think, this seems reasonable.

  - I would advise that longer EE certificate time should be used to prevent that manifests are immediately invalid if RPs
    only fetch close to the nextUpdate time, and are unsuccessful for whatever reason

Al that is best current practice for the current implementation.

I think that a faster notification mechanisms and propagation times are a real need expressed by operators and should be addressed in future work.

Tim

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 26 Jul 2013 16:28:40 +0000

>Sandy, I am not sure, but this may be short topic for 
>one of the sessions. Especially if we want to say anything 
>about best practices for CAs.
....
>That said I think there are quite a few details left that are worth discussing.

The conversation stopped with that, which means people lost interest, or 
they're waiting for the discussion.

So I added it to the agenda.

(And baring any response about time constraints from presenters or those interested in a discussion, the talks will be bound to agenda slots by Monday.)

--Sandy, speaking as co-chair

________________________________________
From: [email-masked] [[email-masked]] on behalf of Tim Bruijnzeels [[email-masked]]
Sent: Friday, July 19, 2013 8:34 AM
To: Stephen Kent
Cc: Murphy, Sandra; [email-masked] list
Subject: Re: [sidr] Erratum for RFC6486? (manifests)

Hi Steve,

To:

-1 Manifest is current

-2 Manifest is stale

-3 Manifest is invalid

As a start…

W.r.t. RP:

W.r.t. CAs:

Tim

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Jul 2013 04:20:51 -0400

Sandy,

I think this is a good topic to cover, but I also think the doc
needs to be an update, vs. an erratum.

Steve