Subject: Re: [sidr] key rollover and algorithm migration

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 06 Jul 2010 15:42:10 +0200

Hi all,

this discussion seems to have calmed down somewhat, but the conclusion
is not entirely clear to me. When this thread was active I did not have
time to properly read all messages and respond. I would like to give my
delayed input now, coming from the implementation we have been working
on at the RIPE NCC.

- AIA

First of all the question was raised whether AIA fields would need to be
supported at all. Several people mentioned that it's useful for
discovery if not for validation; and they would like to keep it.

I just want to confirm that our validator supports bottom-up validation
of _downloaded_ objects using the AIA pointers. It starts by building up
the chain up to a known TA (you have to point the validator to a TA file
as well). If the chain can not be built validation fails. Then actual
validation is done top-down for this chain only.

We figured this would be useful for validating a specific object that
may be published somewhere outside of (next to) a 'normal' repository.
Maybe the use case is not that strong for ROAs, but there may be a
stronger case for other object types in future.

- Key roll-over algorithm

Our software currently implements a specific way to do roll-overs. At
the time we implemented this it wasn't 100% clear to us how this
*should* be done, and indeed whether there should be some prescribed way
to do this.

So, when we build this we thought that our implementation did not
conflict with any drafts (as known at that time). Having said that our
software can be changed if it turns out that it's wrong in general, or
just not in line with a prescribed way to approach this problem.
However, we are not likely to change anything as long as the prescribed
way to do this remains a moving target.

I would like to submit to the wg how we currently implement these
roll-overs. This is not the only possible approach and maybe not the
best, but hopefully it's useful input when considering a draft.

Currently our software implements key roll-overs using the following
approach:
  - it uses stable publication directory for a 'logical CA'
  - a 'logical' CA publishes CRLs and manifests for *each* of its keys
  - but it only publishes child objects for the 'active' key
  - old keys only publish a CRL and a manifest containing just this CRL
  - child certificates have a stable URI based on their public key

I guess the big assumptions here are:
a) It's okay that two keys share a publication directory. The manifest
for a key (using a strict filename pattern: keyhash.mnf*) tells you what
to expect for the specific key.

*: we plan to change the extenstion .mnf to .mft as specified by the
latest repos draft later.. This was implemented before the draft
contained this recommendation..

b) It's okay for a key pair to *not* publish *all* valid objects issued
by it... This eliminates the need that the child certificate should have
a different publication point for the new key.

So, consider this starting situation:

rsync://repo/TA
	CN=RTA,O=RIPE%20NCC,C=NL.cer		<- Trust Anchor
	CN=RTA,O=RIPE%20NCC,C=NL.crl
	CN=RTA,O=RIPE%20NCC,C=NL.mnf
	CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer	<- Parent key1 cert

rsync://repo/PARENT_CA
	jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl
	jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf
	xSDgrpWpxMdHx-9tHN7QKtlILFw.cer		<- Child key1 cert
						AIA -> jfs24...cer
						CRL -> jfs24...crl

rsync://repo/CHILD_CA
	xSDgrpWpxMdHx-9tHN7QKtlILFw.crl
	xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf
	ITg3GhNYIyZQ78D5Zt3sXJkmeLc.roa		EE-AIA -> xSD..cer
						EE-CRL -> xSD..crl

Now we perform a key roll-over for the PARENT_CA. When this happens our
system triggers a new certificate request one level down for the
CHILD_CA. The repositories now look like this:

rsync://repo/TA
	CN=RTA,O=RIPE%20NCC,C=NL.cer		<- Trust Anchor
	CN=RTA,O=RIPE%20NCC,C=NL.crl
	CN=RTA,O=RIPE%20NCC,C=NL.mnf
	CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer	<- Parent key1 cert
	CN=FrN8YYiB-9CUT_B833qvigzedIc.cer	<- Parent key2 cert

So, our offline TA now certifies two keys for our production parent CA

rsync://repo/PARENT_CA
	jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl		<- Key1 crl
	jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf		<- Key1 manifest
	FrN8YYiB-9CUT_B833qvigzedIc.crl		<- Key2 crl
	FrN8YYiB-9CUT_B833qvigzedIc.mnf		<- Key2 manifest
	xSDgrpWpxMdHx-9tHN7QKtlILFw.cer		<- Child key1 cert
						AIA -> FrN8..cer
						CRL -> FrN8..crl

These keys (certificates) use the same publication point. We have a CRL
and manifest for each key. Furthermore the Child-Key1.cer is re-issued
under the new 'active' key. It is now pointing to the new, 'active',
key's certificate and CRL.

The old key no longer publishes any new objects. It just maintains a CRL
and manifest that contains just the CRL file so that it can still revoke
previously issued certificates should there ever be any reason.

rsync://repo/CHILD_CA
	xSDgrpWpxMdHx-9tHN7QKtlILFw.crl
	xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf
	_jrinG02UFGiBXx1wgiQDJo0uww.roa		EE-AIA -> xSD..cer
						EE-CRL -> xSD..crl

Upon receiving a new certificate a new ROA object is generated. Strictly
speaking this is not necessary, but currently our software is not doing
smart enough checks to determine this. It assumes that a new certificate
means more resources or a different validity time, so a new ROA object
is generated automatically.

The old ROA object is no longer published, but it still validates for
people that downloaded it and use the AIA pointers to construct a
validation chain -- as our validator does. There was no reason to revoke
the old EE, and its parent certificate is updated to use the new chain.

One thing to note is that our implementation is using a fully hosted
model for the moment. So child CAs are _hosted_ and live in the same
environment as our production CA. That means that we can actually
trigger the child CA to request a new certificate, and perform triggered
effects for itself like re-issuing a ROA object, when the parent has its
new key 'activated'.

We do plan to implement support for remote child CAs using the up-down
protocol in the near future. And when we do we will no longer be able to
trigger a re-issuance request for the child CA. I see two possible
approaches:

A) The parent CA re-issues anyway based on the last known request
without informing the child CA -- there is no way to tell the child
using up-down.

B) The old key remains active for *this* child CA, until it requests on
its own initiative. When it does the new key becomes active for this
child as well. And the system keeps track of this internally..

I think option B is the more elegant of the two in that this offers the
least surprises to the child. On the other hand option A has a possible
use case for un-planned roll-overs. It allows for a re-key followed by
revocation of the old production key. In principle this should not
affect the child unless the child is using its old certificate out of band.

Regards,

Tim Bruijnzeels

Senior Software Engineer
RIPE NCC

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 7 Jul 2010 12:50:51 +0200

Hi Tim,

Thanks for this email and keep the discussion going. Let me add some comments inline.

Regards,
Roque.

> stronger case for other object types in future.

I agree that we need to maintain the AIA support for bottom-up fetching mechanism.

The initial question that Steve raised was whether or not the AIA should points to a publication point instead of a certificate file. IMHO, RFC 5280 section 4.2.2.1 is ambiguous in  the sense that it requires to be a directory for LDAP but a file for FTP and HTTP as fetching mechanism.

By pointing to a publication point rather than a certificate, you can fetch from that point a group of certificates, and thus handle key-roll over smoothly (particularly when you are maintaining the same subject during the roll-over) as you can list the OLD and CURRENT certs when doing the bottom-up fetch.

In the current SIDR specifications, we are changing the subject name in every roll-over, so there is probably not that much of a benefit AFAIK.

> - Key roll-over algorithm

(skip)

> the old EE, and its parent certificate is updated to use the new chain.

We though about the RIPE implementation. One problematic corner case raised:

- Imagine I am a relying party and I am using a PARENT CA cert as TA (jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer).
- If there is a key-roll over of the PARENT CA and If I am doing TOP-DOWN validation using that TA cert; during the Key roll-over process, I will lose all the signed materials (particularly ROAs) as they are not longer published. The new ROA will not validate as I do not have the RIPE TA.

This may be the case of a hosted client wanting to use its own cert as TA. Again, a corner case that you may want to think about.

> affect the child unless the child is using its old certificate out of band.

Tim, I am not falling you on which CA is doing the key roll-over.

	- If it is the "Down CA", you should check Section 8 of the draft-ietf-sidr-res-certs-18 document.
	- If it is the "UP CA", what you can do is to keep all the CSR that you receive for your subordinates. When you do a key-roll over of the UP CA, you can re-sign and re-publish all the certificates for the subordinates. As you are using the same subject key, this should work smoothly. After a given period (depending if it is an emergency roll-over), you should revoke the old certs.

Regards,
Roque

> 
> 
> Regards,
> 
> Tim Bruijnzeels
> 
> 
> 
> Senior Software Engineer
> RIPE NCC
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Wed, 7 Jul 2010 21:03:06 +1000

>  - child certificates have a stable URI based on their public key

As far as I can tell this matches the procedure described in the res-certs document.

> contained this recommendation..

I share this understanding (thats its okay to have two manifests and two CRLs in the same repository publication point within the scope of this key rollover procedure).

> a different publication point for the new key.

Again, I share this understanding. The procedure described in the draft for key rollover allows the CA with the new key to issue and publish subordinate objects that have precisely the same publication point as the comparable subordinate object that was issued by the CA with the old key. This deliberate overwriting of the published object implies that the CA with the old key has, at this point, extant valid subordinate objects that are not published. 

> without informing the child CA -- there is no way to tell the child

This is the procedure described in the res-cert draft relating to key rollover - i.e. the entity can complete a key rollover without having to await child entities undertaking a reissuance request against the CA with the new CA.

> child as well. And the system keeps track of this internally..

One issue here is that in such a case the old key is kept active for an indeterminate period. If this old key has been compromised, then is it really appropriate to keep this key in an active state? If the CA wants to retire the old key, why should it be held up awaiting an action by the child that may not occur for weeks, months,...?

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 07 Jul 2010 17:29:58 +0200

> As far as I can tell this matches the procedure described in the res-certs document.

Right. Thanks for pointing this out (and thank you Roque).

I think we started our implementation before this section was added to
the res-certs document. But it's been a while and the initial
implementation was done by another developer. Our implementation is very
close though. The most notable difference is that revocation (step 7-8)
is only done manually when a key is lost or compromised.

Section 8 - where the key roll over is documented - starts with this:
"  The following notes provide some additional commentary on the
   considerations that lie behind some of the design choices that were
   made in the design of this certificate profile.  These notes do not
   constitute a formal part of the profile specification, and the
   interpretation of key words as defined in RFC2119 are not applicable
   in this section of the document. "

So the key roll over section is not a formal specification, it's an
example used to justify design choices. And as far as I know there is no
formal specification to this effect at the moment.

Steve suggested that there should be one at the start of this email
thread. My question to Steve, Roque and Sean, and the wg in general is
why? Is there really only one way to do this right?

Don't get me wrong, I think it's quite useful to discuss this. But
should all implementers be forced to do this the same way?

> This may be the case of a hosted client wanting to use its own cert as TA. Again, a corner case that you may want to think about.

So a TA roll over requires a different approach.

I am not sure how this is done 'normally'. I am no PKI expert, so if
anyone has clear ideas about this I think it would be useful to share.

Would it be legal two have two different certificates for the same key?

That way we could have two repositories -- just for the TA level:

the old TA repository:

rsync://repo/TA
 	CN=RTA,O=RIPE%20NCC,C=NL.cer	<- OLD Trust Anchor, old key
 	CN=RTA,O=RIPE%20NCC,C=NL.crl
 	CN=RTA,O=RIPE%20NCC,C=NL.mnf
 	CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer	<- Parent key1 cert

and a new one:

rsync://repo/TA-NEW
 	CN=RTA,O=RIPE%20NCC,C=NL.cer	<- NEW Trust Anchor, new key
 	CN=RTA,O=RIPE%20NCC,C=NL.crl
 	CN=RTA,O=RIPE%20NCC,C=NL.mnf
 	CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer	<- Parent key1 cert

so both repositories have a certificate for 'parent key1', signed by a
different key but having the same subject public key and sia.

This may be completely wrong.. as I said I am not a pki expert, so
someone speak up ;)

In any case we never considered the requirement that any level CA
certificate should be usable as TA. So our current implementation does
not address this issue. Our validator _currently_ even requires a TA to
be self-signed.

I think it complicates implementation a great deal if we must assure
that CA certificates on every level should be usable as TAs and be
roll-over-able without affecting RPs that still use the old key. Can
someone confirm that this is requirement?

A possible work around I can see here is to allow for some time between
steps 3 and 4 of the process described in the res-certs document, and
publish the NEW certificate before activating it. This could give
relying parties time to use the new certificate as another TA next to
the 'current' certificate. But like I said, I think this makes the whole
system more complicated.

> One issue here is that in such a case the old key is kept active for an indeterminate period. If this old key has been compromised, then is it really appropriate to keep this key in an active state…

True. I guess there is no real reason, unless we would need the
'prepare' state somehow because of Roque's concerns.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 8 Jul 2010 07:24:54 +1000

[...]
> the 'current' certificate. But like I said, I think this makes the whole

what was _not_ documented in the notes in the res-certs drafts was for the entity performing the key rollover to wait for <a period> between steps 3 and 4 to allow the NEW CA certificate to be published and to allow Relying Parties to collect this certificate and load it into their local cache. That way, when the NEW CA executes step 5, replying parties will be in a position to recognise these subordinate objects as valid. Some previous thoughts of the appropriate value of the period was 24 hours, assuming that Relying Parties use a refresh cycle of a similar or shorter duration.

[...]

> 'prepare' state somehow because of Roque's concerns.

I was trying to point out that not only is there no compelling reason to do so, but this procedure (Option B) introduces a vulnerability vector if a party cannot retire a potentially compromised key. I believe that it is strongly preferable that a key owner can retire a key from use without awaiting on external dependencies, which is one of the attributes of the key rollover procedure described in the res-cert draft.

Geoff

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 8 Jul 2010 09:58:55 +0200

Hi Tim,

> Would it be legal two have two different certificates for the same key?

Yes, you MAY have more than one certificate for the same CA entity. Think about key roll-overs for identity CAs. You need to change your key, but not your DN (name, email, address, etc).

Check section 4.1.2.6 of RFC 5280:
"   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN).  The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer field.  A CA
   MAY issue more than one certificate with the same DN to the same
   subject entity."

> different key but having the same subject public key and sia.

You do not necessarily need two publication points, they can both be in the same one. However, your example simplifies construction of the manifest.

> not address this issue. Our validator _currently_ even requires a TA to

Again, this is a corner case but you cannot control what the RP will be doing and what tools they will be using.

> the 'current' certificate. But like I said, I think this makes the whole

Correct, but my point was that during that time you need to publish all signed materials under both CAs, the OLD and the CURRENT.

Roque.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 8 Jul 2010 21:15:24 +1000

> Correct, but my point was that during that time you need to publish all signed materials under both CAs, the OLD and the CURRENT.

I disagree here Roque. You may want to think carefully about the AIA pointers of the subordinate certificates, and think about why the documented procedure says:

 5.    The CURRENT CA will generate new certificates for
                     all existing subordinate CA and EE certificates,
                     and publish those products in the same repository
                     publication point and with the same repository
                     publication point name as the previous OLD
                     subordinate CA and EE certificates.  The keys in
                     these reissued certificates must not change.

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 8 Jul 2010 13:44:23 +0200

Hi Geoff,
>                     these reissued certificates must not change.

The use case that I presented refers when a RP uses (for whatever reason) the OLD CA cert as TA and performs TOP-DOWN validations using the OLD CA SIA information.

Between step 5 and 7 (i.e. since I generate the new material signed by the CURRENT CA and until I revoke the OLD CA cert), when accessing the OLD CA publication point (following Tim example), the RP will only be able to validate a manifest and a CRL. All the rest of the material in that publication point is signed by the CURRENT CA that the RP cannot validate as its TA is the OLD CA cert. It should be expected that the RP will eventually change its TA to the CURRENT CA cert sometime before step 7.

I agree that having the OLD and CURRENT signed subordinate certs/signed materials in the same publication point generates a problem with AIA pointers downstream.

What do you think about this particular case?

Roque.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 8 Jul 2010 22:00:52 +1000

> What do you think about this particular case?

I said in an earlier posting on the same topic that what was _not_ documented in the notes in the res-certs drafts was for the entity performing the key rollover to wait for <a period> between steps 3 and 4 to allow the NEW CA certificate to be published and to allow Relying Parties to collect this certificate and load it into their local cache. That way, when the NEW CA executes step 5, relying parties will be in a position to recognise these subordinate objects as valid. Some previous thoughts of the appropriate value of the period was 24 hours, assuming that Relying Parties use a refresh cycle of a similar or shorter duration. If a RP choses an intermediate CA as a TA then it has to factor in the potential for the CA to perform a key rollover, and it has to perform the switch of the locally chosen TA within <a period>.

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Jul 2010 21:13:01 +0900

> Think about key roll-overs for identity CAs.

we do not have identity certs in sidr

randy

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 8 Jul 2010 14:56:42 +0200

Hi Geoff,

Just considering this case:

>  If a RP choses an intermediate CA as a TA then it has to factor in the potential for the CA to perform a key rollover, and it has to perform the switch of the locally chosen TA within <a period>.

Wouldn't it be the case that since the RP perform the locally chosen TA switch until the end of <a period> it will not be able to validate the subordinate certs?

Roque.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 08 Jul 2010 17:56:28 +0200

Hi Roque,

> Wouldn't it be the case that since the RP perform the locally chosen TA switch until the end of <a period> it will not be able to validate the subordinate certs?

The way I see it the extra time between steps 3 and 4 should allow the
RP to *add* the new certificate to its TA*s*. By adding the NEW cert to
a list of TAs and treating their subordinate objects cumulatively the RP
could prepare itself for the switch. Then when the switch is activated
the old certificate is effectively phased out, at least for top-down
purposes.

But I still think that it is an open question whether any CA should be
expected to support the use of its certificates as TAs by others. There
is an existing proposal about the TA structure and discussion about an
alternative. I don't really want to start that whole discussion here
again, but it goes to show that TAs require some special treatment.

My feeling is that implementation is made a lot more difficult if the
must-be-usable-as-TA requirement is imposed on all levels. In other
words: if a CA actually wants to be able to act as a TA it can take
measures to do so. Use the appropriate format (to be determined) with a
suitable roll-over (phase out?) strategy. If a RP chooses to make a CA
that is not prepared to this a TA, then maybe it's also up to the RP to
just update when that CA rolls over..

Cheers
Tim

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 8 Jul 2010 21:49:20 +0200

Hi Tim,
> the old certificate is effectively phased out, at least for top-down

yeah you are right, that would work. I would also add a time period between 6 and 7 to allow the new material to be fetch before revoking the old cert.

> just update when that CA rolls over..

But you cannot tell to the RP who to trust.

Roque

---

From: Geoff Huston <[email-masked]>
Date: Fri, 9 Jul 2010 08:51:42 +1000

> the old certificate is effectively phased out, at least for top-down

Yes, thanks Tim, I can confirm that this was indeed the intent.

> just update when that CA rolls over..

Again, I agree with this perspective.

  Geoff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Jul 2010 16:57:35 -0400

>stronger case for other object types in future.

I agree completely with this argument for retaining AIA.

>*should* be done, and indeed whether there should be some prescribed way

I believe that we need to have a single, prescribed way to do this; 
each CA needs to know what is expected of it by its subordinate CAs 
and by all RPs. I believe we should have a separate document that 
clearly articulates what a CA is required to do. There are CA-local 
aspects to this procedure, as Geoff's text notes.  The parameters for 
those belong in the CPS for the CA. The current description is not 
normative and I think that needs to change.

>way to do this remains a moving target.

certainly fair.

>   - child certificates have a stable URI based on their public key

I don't understand this description based on the language above. 
After a lot of careful reading I believe that I understand what Geoff 
described in Section 8 of the res-certs I-D. Since Geoff later said 
that your description matches his text, I won't worry about my lack 
of understanding above :-).

>contained this recommendation..

I feel strongly that the repository structure document needs to 
mandate the file extensions, not make them recommendations. But, that 
aside, I agree that it's OK to have two manifests and two CRLs at the 
same pub point, associated with the old and new CA instances. The 
naming convention for manifests and CRLs (which also needs to be a 
standard to make this work), accommodates this nicely.

>...

I deleted your example in part because it seems to specific to the 
remotely managed CA model, as you note later.

>is generated automatically.

I think one should not mandate generating new ROAs when they are not 
strictly required.  Again, in an up/down protocol model the CA that 
is rekeying can't
generate ROAs for its children anyway, so ...

>effects for itself like re-issuing a ROA object, when the parent has its

The fact that your model is based on experience building the hosted 
CA approach is worrisome to me.  We need to publish standards that 
are not biased by this specific model.  I'm not saying that what you 
have done is wrong, but I don't want SIDR to pursue an approach that 
is influence by that model, since it is not the general case (even if 
it becomes the most common case).

>affect the child unless the child is using its old certificate out of band.

I think it's appropriate for the rekeying CA to reissue certs for its 
children, i.e., option A above. But, it may not be OK to delete the 
old cert immediately.  I worry about race conditions for RPs.

So, to summarize, I suggest:

	- the design notes in section 8 of res-cert (that deal with 
key rollover) need to be removed and made into a separate, standards 
track document document. As Geoff has already noted, that text needs 
to be updated to insert delays in the process to minimize the 
likelihood that an RP will acquire an inconsistent set of repository 
objects.  I am still concerned that such delays may not suffice, but 
I'll need to make a case for that when we have a revised description.

	- we do not assume strict top-down tree walk for RPs when we 
analyze possible race conditions re rekeying.

	- the respos-struct document needs to mandate file extensions 
and naming conventions, rather than merely proposing them as 
recommendations.  If we say that we can have two manifests and two 
CRLs in a directory, one per CA key instance, then it seems important 
that we all agree on how the names for these files are generated.

Finally, I am concerned that we have made almost no progress on the 
top-level questions I posed about alg migration. Geoff responded to 
my message, I replied to him, and then the discussion stopped.

My concern is that we could adopt a simple key rollover scheme and 
associated repository structure that is very different from what we 
may determine that we need for alg migration. If so, then when we add 
support for alg migration, we probably will impose an overlay on the 
repository system that makes the overall system much more complex. 
Moreover, I anticipate that we will gain a lot of experience with key 
rollover in 2-3 years. But, alg migration may not begin for 5 years 
or longer. if we use the same procedure for both, we will have 
experience from the key rollover process that translates directly 
into alg migration. If not, then we will have little basis for 
confidence when it comes to alg migration.  That may not satisfy the 
goal that Tim set for us, and it may cause us terrible problems down 
the road.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 14 Jul 2010 12:36:17 +1000

> I believe that we need to have a single, prescribed way to do this; each CA needs to know what is expected of it by its subordinate CAs and by all RPs. I believe we should have a separate document that clearly articulates what a CA is required to do. There are CA-local aspects to this procedure, as Geoff's text notes.  The parameters for those belong in the CPS for the CA. The current description is not normative and I think that needs to change.
> 

You are proposing that the procedure as described in section 8 of  draft-ietf-sidr-res-certs-18.txt be placed into a normative form in its own document?

The addition noted in the WG mail thread was the addition of a delay between steps 3 and 4, to allow Relying Parties to collect the new CA and add it to their local repository caches.

Is there a suggested period for local RPs to refresh their local repository cache at this point?

> I don't understand this description based on the language above. After a lot of careful reading I believe that I understand what Geoff described in Section 8 of the res-certs I-D. Since Geoff later said that your description matches his text, I won't worry about my lack of understanding above :-).

I can confirm that I believe that the description matches the text in the draft.

> I feel strongly that the repository structure document needs to mandate the file extensions, not make them recommendations.

MUST not MAY?

> But, that aside, I agree that it's OK to have two manifests and two CRLs at the same pub point, associated with the old and new CA instances. The naming convention for manifests and CRLs (which also needs to be a standard to make this work), accommodates this nicely.

I agree here.

> I think it's appropriate for the rekeying CA to reissue certs for its children, i.e., option A above. But, it may not be OK to delete the old cert immediately.  I worry about race conditions for RPs.

"delete" or "revoke"?

The procedure describes "overwriting" at the repository publication point (in order to preserve the integrity of the AIA pointer of subordinate products), but does NOT propose revocation of the overwritten subordinate products of the CA with the old key.

> 	- the design notes in section 8 of res-cert (that deal with key rollover) need to be removed and made into a separate, standards track document document. As Geoff has already noted, that text needs to be updated to insert delays in the process to minimize the likelihood that an RP will acquire an inconsistent set of repository objects.  I am still concerned that such delays may not suffice, but I'll need to make a case for that when we have a revised description.

agreed

> 
> 	- we do not assume strict top-down tree walk for RPs when we analyze possible race conditions re rekeying.

specifically, it may be useful to consider RPs performing AIA "walks" as described in Tim's note, in which case preservation of the integrity of the AIA chain during the process is of importance.

> 
> 	- the respos-struct document needs to mandate file extensions and naming conventions, rather than merely proposing them as recommendations.  If we say that we can have two manifests and two CRLs in a directory, one per CA key instance, then it seems important that we all agree on how the names for these files are generated.

this seems appropriate to me

> 
> Finally, I am concerned that we have made almost no progress on the top-level questions I posed about alg migration. Geoff responded to my message, I replied to him, and then the discussion stopped.

my apologies - other circumstances have arisen that take my attention.

> 
> My concern is that we could adopt a simple key rollover scheme and associated repository structure that is very different from what we may determine that we need for alg migration. If so, then when we add support for alg migration, we probably will impose an overlay on the repository system that makes the overall system much more complex. Moreover, I anticipate that we will gain a lot of experience with key rollover in 2-3 years. But, alg migration may not begin for 5 years or longer. if we use the same procedure for both, we will have experience from the key rollover process that translates directly into alg migration. If not, then we will have little basis for confidence when it comes to alg migration.  That may not satisfy the goal that Tim set for us, and it may cause us terrible problems down the road.

My concerns, as noted in the rpki-algs draft, is to avoid what could be construed as gratuitous duplication in the RPKI on the basis that what would be highly undesireable was an outcome where a ROA could be validated with algorithm A, but an equivalent assertion could not be validated in the realm of algorithm B.

Geoff

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 14 Jul 2010 12:27:09 +0200

Hi Steve,

Geoff already replied to you and the list. I agree with his points.

I do have one remaining comment though. It seems to me that the
algorithm described in section 8 of res-cert is targeting key roll overs
for normal operational CAs. Not CAs that want to be used as TAs...

I expect that a planned TA 'roll over' in practice requires a long
transition period where top-down validation has to work for both the old
and new TA. The additional time between step 3 and 4 is probably not
good enough for this, or is it? I expect it should be okay for RPs to
keep using only the old TA until it expires, and to already start using
the new TA (only) as soon as it's published.

In other words I think it might be good to think about another algorithm
targeting TAs specifically as well. That way we can keep this one as
simple as possible. Any TA roll over strategy will likely have strong
ties to the TA structure -- which is still under discussion.

I would suggest that whatever structure is chosen by the WG we make it
possible for normal CAs that *want* to act as TAs to do so, but we do
not require CAs that do *not* want to act as TAs to support a TA roll
over. Given the two TA proposals I think it should be possible for CAs
to add one level of indirection and present a TA that points to their
'normal' CA cert:
 - The ETA approach can be used to just put the normal cert in a bag
 - The simpler approach could use an additional TA-CA that signs an
additional certificate sharing the same pub key, SIA etc as the 'normal'
CA cert. Thus pointing RPs down to the same tree.

But.. I guess there is still a lot of stuff to discuss here.. which is
again why I would propose to leave the TA roll overs out for now.

Finally, below I just want to give some specific answers to us using a
hosted set up:

> At 3:42 PM +0200 7/6/10, Tim Bruijnzeels wrote:
<snip>
> strictly required.  Again, in an up/down protocol model the CA that is
> rekeying can't generate ROAs for its children anyway, so ...

Sure, I put something on our back-log to prevent this unnecessary
re-issuance. This is a bug related to an over-active propagation of the
internal eventing mechanism that is fairly easy to fix.

> The fact that your model is based on experience building the hosted CA
> approach is worrisome to me.  We need to publish standards that are not
> biased by this specific model.  I'm not saying that what you have done
> is wrong, but I don't want SIDR to pursue an approach that is influence
> by that model, since it is not the general case (even if it becomes the
> most common case).
> 

I understand and agree. The reason that I stressed that we are using a
hosted setup is precisely because:
 a) I can not be as certain whether stuff will be the same for remote
 b) I want to invite people that do have that experience to jump in..

As it turns out in this specific case there is no problem for child CAs,
the parent does not have to wait for a remote child CA when it re-keys
to request a new certificate, it can 'push' and just re-issue as
described in section 8 of the res-certs draft.

Cheers
Tim

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jul 2010 10:48:37 -0400

>for normal operational CAs. Not CAs that want to be used as TAs...

are you referring to a CA that uses the WG-selected method to publish
info to make it accessible as a TA, or are you referring to the local 
TA management mechanisms that are described in 
draft-reynolds-rpki-ltamgmt-00?

>described in section 8 of the res-certs draft.

OK.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jul 2010 10:43:09 -0400

At 12:36 PM +1000 7/14/10, Geoff Huston wrote:
>>  I believe that we need to have a single, prescribed way to do 
>>this; each CA needs to know what is expected of it by its 
>>subordinate CAs and by all RPs. I believe we should have a separate 
>>document that clearly articulates what a CA is required to do. 
>>There are CA-local aspects to this procedure, as Geoff's text 
>>notes.  The parameters for those belong in the CPS for the CA. The 
>>current description is not normative and I think that needs to 
>>change.
>>
>
>You are proposing that the procedure as described in section 8 of 
>draft-ietf-sidr-res-certs-18.txt be placed into a normative form in 
>its own document?

I am proposing that a revised, updated version of that text become a 
stand alone, standards track document.

>The addition noted in the WG mail thread was the addition of a delay 
>between steps 3 and 4, to allow Relying Parties to collect the new 
>CA and add it to their local repository caches.
>

I think we discussed this on the list, and suggested at least once 
per day. However,  I also recall that we removed mention of this from 
the architecture document and agreed to create a new document that 
would contain suggested operational practices.  I don't know that 
anyone is generating that document, yet.

>>mandate the file extensions, not make them recommendations.
>
>
>MUST not MAY?

yes. My reasoning is two-fold:

	- we have seen a lot of examples where folks see conventions 
described in a non-normative fashion in an RFC, and then code is 
created that relies on the conventions.  This seems like a perfect 
case where a developer might be tempted to do precisely that.

	- I see no benefit to allowing other file extensions to be used here.

>>  I think it's appropriate for the rekeying CA to reissue certs for 
>>its children, i.e., option A above. But, it may not be OK to delete 
>>the old cert immediately.  I worry about race conditions for RPs.
>
>
>"delete" or "revoke"?

delete.

>The procedure describes "overwriting" at the repository publication 
>point (in order to preserve the integrity of the AIA pointer of 
>subordinate products), but does NOT propose revocation of the 
>overwritten subordinate products of the CA with the old key.

yes, I understand (although I didn't understand at first :-)).  If 
one does not delete (overwrite) then the AIA pointer would have to 
become a pointer to the directory, vs. the file.  But, I agree that 
your current description of how to perform key rollover is consistent 
with the current definition of the AIA pointer.

>specifically, it may be useful to consider RPs performing AIA 
>"walks" as described in Tim's note, in which case preservation of 
>the integrity of the AIA chain during the process is of importance.

that's one good example, but I have another one in mind.  If one 
begins a top-down tree walk, one may encounter repositories that are 
temporarily unreachable, or directories that are locked. I'd like to 
allow RP software to skip over these, and come back later.  I 
envision parallel repository accesses, to help avoid possible DoS 
vulnerabilities. Since we assume that an RP will usually (although 
not always) have a local copy of repository system data, it has info 
that could allow it to try to skip over directories or whole 
repositories that are inaccessible. I wan tot make sure that our key 
rollover design does not preclude such behavior.
>
>...
>
>>
>>  Finally, I am concerned that we have made almost no progress on 
>>the top-level questions I posed about alg migration. Geoff 
>>responded to my message, I replied to him, and then the discussion 
>>stopped.
>

no problem.  We ought not be the only two people who care about this :-)!

>...
>
>My concerns, as noted in the rpki-algs draft, is to avoid what could 
>be construed as gratuitous duplication in the RPKI on the basis that 
>what would be highly undesireable was an outcome where a ROA could 
>be validated with algorithm A, but an equivalent assertion could not 
>be validated in the realm of algorithm B.

I agree that we want to avoid "gratuitous duplication in the RPKI" 
and that's why I believe that we need to think through the process, 
to avoid the stuation you cite.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 15 Jul 2010 17:17:36 +0200

Hi Steve,

On 7/14/10 4:48 PM, Stephen Kent wrote:
> info to make it accessible as a TA, or are you referring to the local TA
> management mechanisms that are described in draft-reynolds-rpki-ltamgmt-00?
> 

No, I was still referring to the remark made by Roque that the algorithm
in section 8 (res-cert) would cause problems for RPs that choose to use
a CA cert somewhere in this chain as their TA. Top-down will break for
the old key's certificate. The extra time between step 3 and 4 was
proposed to give these RPs a little more time to adjust.

I believe that this extra time should be good enough. It's an algorithm
that in my experience is implementable and I am very much in favour of
preserving the AIA one level down.

I regret proceeding to go into too much detail about possible other *TA*
roll overs. I was thinking about 'draft-iets-sidr-ta' and
'draft-weiler-sidr-trust-anchor-format' as possible ways for any CA to
publish their own certificate as TAs. I am afraid I confused the
discussion by going into the how and why this is more difficult. My main
point is that it is, in my mind, a different ball game and therefore I
would suggest to not place additional constraints on normal key roll
overs except for the extra time between step 3 and 4 already proposed.

It may be interesting to discuss possible roll over scenarios for the
two TA drafts I am referring to as well, but probably that should be
done in its own thread. It may also be interesting to discuss this in
Maastricht.

I hope this makes my point more clear.

Cheers
Tim

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Jul 2010 15:59:55 -0400

>I hope this makes my point more clear.

Tim,

Thanks for the clarifications.

Let's talk about this in Maastricht.

Steve

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Jul 2010 18:45:38 -0400

At Wed, 16 Jun 2010 10:29:42 -0400, Stephen Kent wrote:
> 
> At 3:37 PM -0700 6/15/10, Robert Kisteleki wrote:
> >On 2010.06.14. 8:22, Rob Austein wrote:
> >>So (a) I'm not sure I agree with the problem as stated, but (b) we
> >>might just want to get rid of the AIA pointer anyway, or at least make
> >>it purely advisory (not a res-certs profile conformance violation if
> >>the AIA pointer is whacked).  Not sure yet.  Maybe both :).
> >
> >Please don't kill AIA, it's useful for discovery. I agree that you 
> >don't need to use it in verification though.
> 
> I was just thinking about Robert's plan to use RPKI certs to verify 
> signed RPLS objects.  This application needs AIA and the other 
> bottom-up cert path discovery methods that are common for PKI apps. 
> I don't know if we will have other such apps in the future, but if 
> so, this is an example of a situation where we cannot always rely on 
> a top-down cert acquisition methodology.

I am fine with keeping the AIA extension in the profile, so long as
I'm not required to reject otherwise valid certificates because of
disagreements between the AIA URI and the path at which I found the
certificate in question.

In other words, and unsurprisingly, I agree with RobK.

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Jul 2010 18:31:28 -0400

[Reviewing old list mail en route to Maastricht, I see a few I should
have answered, this is one of them]

At Tue, 06 Jul 2010 15:42:10 +0200, Tim Bruijnzeels wrote:
...
>   - child certificates have a stable URI based on their public key

This is essentially the same approach that I took.

> without informing the child CA -- there is no way to tell the child

This is what I do -- reissue with the same child key as the previous
child certificate.  The child will find out about that its certificate
has been reissued the next time it polls its parent.

The child has to expect the possibility of this sort of thing anyway,
as there are other reasons why the parent might unilaterally reissue,
eg, the child's resources might shrink, in which case the parent
pretty much has to revoke the old (now overclaiming) child
certificate, which in turn means that the parent has to issue a new
child certificate unless it wants to leave the child dead in the
water.  Waiting for the child to get around to asking the parent for a
new certificate that shrinks the child's resources sounds like a
(very) bad plan, so this pretty much has to be a unilateral action on
the part of the parent.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 26 Jul 2010 17:59:29 +1000

> You are proposing that the procedure as described in section 8 of  draft-ietf-sidr-res-certs-18.txt be placed into a normative form in its own document?

In collaboration with George Michaelson and Steve Kent, we have lifted out section 8 of draft-ietf-sidr-res-certs-18.txt and placed into a normative form in its own document. This is in the drafts repository as draft-huston-sidr-keyroll-00.txt.

I would like to request via the WG chairs that the WG adopt this document as a WG document.

Thank you

  Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 26 Jul 2010 04:45:30 -0400 (Eastern Daylight Time)

Thank you, Geoff.  We'll definitely cover this in the meeting on 
Wednesday.

Can you tell me/us what the relationship is between the draft 
draft-huston-sidr-keyroll-00.txt you mention 
below and the recently announced draft:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

         Title           : CA Key Rollover in the RPKI
         Author(s)       : G. Huston, et al.
         Filename        : draft-huston-sidr-aao-profile-0-keyroll-00.txt
         Pages           : 8
         Date            : 2010-07-26

This document describes an algorithm to allow an entity who
undertakes the role of a Certification Authority in the Resource
Public Key Infrastructure to perform a rollover of its key pair.
This document also notes the requirements placed on Relying Parties
who maintain a local cache of the objects that have been published in
the distributed Resource Public Key Infrastructure repository
publication structure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-huston-sidr-aao-profile-0-keyroll-00.txt

I'm thinking cut-and-paste error in creating the new draft name, but 
that's just me.

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Mon, 26 Jul 2010 19:20:00 +1000

Hi,

Yes, that was indeed a cut and paste error - my apologies.

I believe that the repository now also contains http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt, which is the draft I was referring to in my request for WG adoption.

Thank you,

  Geoff

On 26/07/2010, at 6:45 PM, Sandra Murphy wrote:

> Thank you, Geoff.  We'll definitely cover this in the meeting on Wednesday.
> 
> Can you tell me/us what the relationship is between the draft draft-huston-sidr-keyroll-00.txt you mention below and the recently announced draft:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> I'm thinking cut-and-paste error in creating the new draft name, but that's just me.
> 
> 
> --Sandy
>