Subject: [sidr] TA questions

From: Robert Kisteleki <[email-masked]>
Date: Thu, 05 Nov 2009 09:50:10 +0100

Hi,

I'm proxying two questions from our development team regarding the TA draft:

1) How do the authors envision key roll overs for the RTA?

Even though the draft allows for re-publication of the self-signed RTA with 
new resources, it does not seem to address key roll overs for that RTA. It 
seems one would have to publish a new ETA to support this, which would make 
invalidating the previous RTA (if that's ever needed) difficult.

2) Can we have a more clear pointer the RTACMS object for relying parties?

The current proposal has the ETA CA point to a directory. See page 7 of the 
draft for an ascii-art representation of this. This means that relying 
parties will have to find the actual RTACMS object in this directory 
themselves. Probably rsync the whole thing and loop over the entries to 
figure out which is which.

Robert

---

From: George Michaelson <[email-masked]>
Date: Sat, 7 Nov 2009 06:26:16 +0800

On 05/11/2009, at 4:50 PM, Robert Kisteleki wrote:

> Even though the draft allows for re-publication of the self-signed  
> RTA with new resources, it does not seem to address key roll overs  
> for that RTA. It seems one would have to publish a new ETA to  
> support this, which would make invalidating the previous RTA (if  
> that's ever needed) difficult.

Nowhere in the document does it say that the ETA and RTA keys are  
linked. Therefore it's not clear to me *WHY* the ETA has to  
necessarily roll when an RTA re-keys.

If an RTA publisher wanted to roll their RTA key, then it seems  
feasible by having the ETA simply use the key conservatively and  
assume an indefinite lifetime. The important caveat is that the RTA  
should be treated with the same level of respect as any trust anchor.

> The current proposal has the ETA CA point to a directory. See page 7  
> of the draft for an ascii-art representation of this. This means  
> that relying parties will have to find the actual RTACMS object in  
> this directory themselves. Probably rsync the whole thing and loop  
> over the entries to figure out which is which.

Robert, the ETA certificate has an SIA. The ETA SIA *should* point to  
a directory, which will contain a CMS object, and a CRL. It *can*  
contain the ETA too. What else does this directory contain, that a  
relying party is not interested in seeing?

Relying party software, assuming it trusts this ETA, periodically  
scans this SIA space and picks up all valid CMS signed objects and  
loads the payload RTAs, again assuming that it trusts the ETA. It  
needs to see the CRL too.

CMS is quite recognisable, testable, provable. Thats the whole point.  
The ETA can be signing over more than one RTA (for instance, key  
rollover) so there can be more than one CMS bundle to be seen, signed  
by the ETA.

-George

---

From: Robert Kisteleki <[email-masked]>
Date: Sat, 07 Nov 2009 18:23:32 +0900

George Michaelson wrote:
>> Even though the draft allows for re-publication of the self-signed RTA 
>> with new resources, it does not seem to address key roll overs for 
>> that RTA. It seems one would have to publish a new ETA to support 
>> this, which would make invalidating the previous RTA (if that's ever 
>> needed) difficult.
> 
> linked. Therefore it's not clear to me *WHY* the ETA has to necessarily 
> roll when an RTA re-keys.
> 
> If an RTA publisher wanted to roll their RTA key, then it seems feasible 
> by having the ETA simply use the key conservatively and assume an 
> indefinite lifetime. The important caveat is that the RTA should be 
> treated with the same level of respect as any trust anchor.

The document does say that there is one SIA for the ETA. It also says that 
one CMS bag can contain exactly one RTA. So the only option to publish more 
RTAs (while doing a rollover, or just because) is to publish multiple bags 
at the SIA location. Is that the intention? I'm wondering if that's enough 
if the RTA needs an unplanned key rollover, for which there could be better 
support.

>> of the draft for an ascii-art representation of this. This means that 
>> relying parties will have to find the actual RTACMS object in this 
>> directory themselves. Probably rsync the whole thing and loop over the 
>> entries to figure out which is which.
> 
> Robert, the ETA certificate has an SIA. The ETA SIA *should* point to a 
> directory, which will contain a CMS object, and a CRL. It *can* contain 
> the ETA too. What else does this directory contain, that a relying party 
> is not interested in seeing?

Perhaps an mpeg of the cat? Why does the RP need to download everything and 
check which one looks like a CMS object, which is a CRL and what's 
unimportant, after?

> Relying party software, assuming it trusts this ETA, periodically scans 
> this SIA space and picks up all valid CMS signed objects and loads the 
> payload RTAs, again assuming that it trusts the ETA. It needs to see the 
> CRL too.
> 
> rollover) so there can be more than one CMS bundle to be seen, signed by 
> the ETA.

The document is not clear on whether there could be multiple CMS bags in the 
directory pointed to by the ETA SIA. But even when this is corrected, we 
still have the recognition problem stated above. This is what I'm after here.

Robert

---

From: Roque Gagliano <[email-masked]>
Date: Sun, 8 Nov 2009 06:43:08 +0900

Hi,

Here are some comments on the document, some reflects the conflict  
that Robert mentioned about being more clear that one EE ETA cert is  
valid at any particular time, some are typos.

Roque.

--------------------

2.1.  A Compound Trust Anchor Structure

	 The ETA issues a CRL and one EE certificate.

(Roque) I believe it needs to be explained that more than one ETA EE  
cert may be issued during the life-time of the ETA CA however at any  
particular moment there is only one valid EE cert.

4.2.  RPKI Trust Anchor Object Validation

   2.  Use the public key in the EE certificate to verify the
           signature on the RTA Trust Anchor Object.

(Roque) s/EE certificate/ETA EE certificate

       *  Each time an RTA certificate is re-issued, or prior to the
          expiration of the ETA EE certificate, the ETA generates a
          Cryptographic Message Syntax (CMS) [RFC3852] signed-data
          object, the payload of which is an RTA certificate.

(Roque) If the ETA EE cert validity period is identical to the RTA  
validity period as stated in a previous bullet, the second condition  
("prior to the expiration of the ETA EE certificate") would be the  
same as in the following section:
"If a trust anchor chooses to reissue its RTA certificate before the  
expiration of that certificate."

5.  Relying Party use of Trust Anchor Material

       *  The ETA's CRL and CMS objects are retrieved from the
          publication point referenced by the SIA in the ETA  
certificate.
(Roque) s/CMS objects/CMS object

   Relying Parties SHOULD perform this retrieval and validation
    operation at intervals no less frequent than the nextUpdate time of
    the published ETA CRL, and SHOULD perform the retrieval operation
    prior to the expiration of the ETA EE certificate, or upon  
revocation
    of the ETA EE certificate.

(Roque) If the retrieval operation is for both the CRL and the CMS, I  
do not understand the last sentence because the RP is not aware of the  
revocation until it has retrieve the CRL and in at that time it  
already has the new CMS. So, I would:
	s/, or upon revocation of the ETA EE certificate//

--------------------

-------------------------------------------------------------
Roque Gagliano
LACNIC
[email-masked]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE

---

From: Robert Kisteleki <[email-masked]>
Date: Sun, 08 Nov 2009 12:03:51 +0900

> particular moment there is only one valid EE cert.

In light of the recent discussion, this is not necessarily true. If (I mean, 
if) the solution to multiple RTAs is multiple CMS objects, then ther wil be 
multiple ETA EEs. Note that I'm not in favor of that solution, but we're not 
yet in solution space.

>          publication point referenced by the SIA in the ETA certificate.

Probably not, see above. There may be multiple CMS objects and one CRL.

Robert