Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <51E6D5FF.6030802@bbn.com>
Date: Fri, 19 Jul 2013 14:34:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <23E19953-DFC2-4331-B497-60BC0FFDEB37@ripe.net>
References: <A4234F86-EC27-4EB5-B988-D61019E80A7B@ripe.net>
 <51E6D5FF.6030802@bbn.com>
To: Stephen Kent <kent@bbn.com>
Cc: Sandra Murphy <Sandra.Murphy@sparta.com>,
 "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] Erratum for RFC6486? (manifests)
Precedence: list

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
> 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.
>=20
> 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.

I proposed to change this text in 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.

To:

         The validity times of the EE certificate MUST encompass the =
time
         interval from thisUpdate to nextUpdate.
=20

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
> reason to change this text.

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.=20

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
> we might take that into consideration when suggesting this model.


As I understand there are three cases with regards to stale and invalid =
based on time (ignoring other cases):

-1 Manifest is current
       =3D now is after thisUpdate and before nextUpdate &&
       =3D now is within EE Certificate validity time

-2 Manifest is stale
       =3D now is after nextUpdate
       =3D now is within EE Certificate validity time

-3 Manifest is invalid
       =3D 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
> the manifest are either both stale or current.

I agree that best practices would be good, both for CA and RP.

Is this something to discuss shortly?

As a start=85

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=20
 - I think RPs are free to poll more frequently
 =85.

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