Subject: Re: [sidr] Validation Reconsidered (again/again) question

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jan 2016 12:18:07 -0500

Geoff,

> ...
>> 2. How do you perform the validation of a CRL?
> RFC6487 provided no guidance, and referred to RFC5280, so that is still the case.
> nothing changes herre.
RFC 6487 modified the validation algorithm from 5280, and stated that the
revised algorithm applies to "resource certificates." A CA cert issued in
the RPKI is a resource certificate. Thus to verify the signature on a CRL
one must use a valid CA cert. Thus Sriram's question was, I believe, more
precisely stated as how does the revised validation procedure apply to a CA
cert, which is then used to verify the signature on a CRL.
>> How is it similar to or different from how you validate a ROA?
> There are no resources in a CRL so I presume that section 6.1 of RFC5280 is
> a good procedure to follow.
see comment above.
>> How do you walk the certificate hierarchy in the case of a CRL validation process?
>> I.e. How are the "encompassing" rules applied?
> huh - I’ll say it again just to be sure: CRLs have no resources.
but the CA cert used to verify a CRL signature does contain resources,
and that, I believe, was the issue Sriram was raising, and that my message
raised.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jan 2016 12:18:11 -0500

Geoff,

Happy new year.

> ...
>
>> Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a ROA.
>>
>> TA->CA 1->CA 2->ROA
>>
>>
>> Assume the TA cert contains address space T, U, V, W, X, Y and Z.
>>
>> Assume the CA 1 cert contains address space T, U, V, and W.
>>
>> Assume the CA 2 cert contains address space V and W.
>>
>> Let's say that the ROA EE cert issued by CA 2 contains address space V.
>>
>> CA 2 is about to receive address space Z from some other ISP, so it has asked
>> CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees,
>> and issues a new cert to CA 2 and that cert contains address space V and Z.
> CA1 has already issued a cert with subject “CA2” and resources (V,W) - lets call this cert No 1
>
> Do you mean:
>
> a) CA 1 issues a cert  with subject “CA2” and resources (V,Z) - lets call this cert No 2
>
> OR the combination of actions:
>
> b)    CA 1 issues a SECOND cert  with subject “CA2” and resources (V,Z)  - lets call this Cert No 2
>     AND
>        CA1 revokes the cert with subject “CA2” and resources (V,W) (which we call Cert No 1)
I intended the second case. Chris pointed out to me in a private message 
that
I failed to include W in this cert; my bad. I intended to have the new 
cert add Z to V and W.
>> Now, under the assumption about what "specific resource set" means, when
>> an RP tries to validate CA 2's ROA,
> Now I’m confused - originally the ROA was signed by an EE cert issued by CA 2’s Cert No 1
>
> so when you refer to CA 2’s ROA do you mean the ROA that was signed by an EE cert issued by CA 2’s Cert No 1,
> or do you mean a new ROA signed by an EE issued by CA 2’s Cert No 2?
No ROA is "signed" by any cert; a signature on a ROA (or a cert) is 
verified using a cert.

The ROA to which I refer is issued under CA 2 (your Cert 1), and it is 
not new.
I described the ROA when I trued to set the stage for the example:
     "Let's say that the ROA EE cert issued by CA 2 contains address 
space V."
>> the "specific resource set" will be V, and
>> so it will be valid, because V is in all of the certs from the TA through CA 1
>> to CA 2. Even though CA 2's cert contains Z, which is not contained
>> in CA 1's cert, this will not be considered in the validation of the ROA EE cert.
>> This is the desired outcome, because CA 2 has begun the process of getting its
>> new address space (Z), but that process has not broken its CA cert. I assume this
>> is an example of the reduced fragility that is so appealing.
> So I _think_ you are assuming that there is a new ROA, signed by an EE cert issued by
> the CA that has a CA cert issued by CA 1 with resources (V,Z), and evidently you are referring
> to this new ROA and its new EE cert.
no, it's the same ROA I defined in the intro to the example.

I'll stop at this point, because the remainder of your comments are
based on the assumption that this was a new ROA, which was not my intent.

Sorry for the typo in the resource set for "Cert 1" and for not being
more explicit in saying that the new Cert for CA 2 was issued by CA 1
as a replacement for the original CA 2 cert.

Steve

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 10 Jan 2016 19:18:41 +0000

Steve,

>and that, I believe, was the issue Sriram was raising, 
>and that my message raised.

To be fair, Geoff did respond to my question:
http://www.ietf.org/mail-archive/web/sidr/current/msg07453.html  
He said:
“I would’ve thought that if you can establish a chain of 
Issuer / subject certs that connect a chosen Trust Anchor
to the CA that issued the CRL then you have a sound reason to
accept the CRL. Given that the CRL has no resources there does not 
seem to be any resource attribute test that can be applied here.”

So, as I understand it now, when validating a ROA or a CRL,
the first basic step (Step #1) is this: 
(Geoff/Tim: This is a description based on my understanding;
please correct me if I got it wrong.)

Step #1: 
Gather the relevant resource CA certs in the cert-path: 
C0, C1, C2, ..., Cn,
where C0 is the TA’s cert and Cn is the final resource holder’s
cert who created the ROA or issued the CRL.
Before saying anything about the ROA or the CRL validity,
first perform a basic check to see if *cert-path is Valid*.    
The given *cert-path is Valid* if the following holds:
the signature on cert Ci is Valid when verified 
with the public key associated with cert C(i-1), for all i in 1 <= i <= n. 
In this basic validation process,
no consideration is given to the resources contained in the certs.
So at this step in the algorithm, it is not checked whether 
the resources contained in the certs are “encompassing” or not.
This step only cares about verifying the chain of issuer/subject 
relationships (the successive issuers’ signatures on the certs).
(Proceed to Step #2 if the *cert-path is Valid*.)

Step #2 (in the case of a ROA): 
(Recall that the holder of Cn issued the ROA)
The ROA is Valid if all of the following conditions hold:
(a) The signature on the EE cert is Valid (verified 
with the public key associated with Cn).
(b) The signature on the ROA is valid (verified with
the public key associated with the EE cert).
(c) The prefix resources in the ROA exactly match the 
resources listed in the EE cert.
(d) All the prefix resources in the ROA are contained in the
intersection of the resources listed 
in the set {C0, C1, ..., Cn}.

Step #2 (in the case of a CRL): 
(Recall that the holder of Cn issued the CRL)
The CRL is Valid if all the following conditions hold:
(a) The certificate(s) being revoked in the CRL 
is (are) certificates that were issued earlier 
by the subject (holder) of Cn. 
(b) The signature on the CRL is Valid (verified with 
the public key associated with Cn). 

(Note: No need to look into the list of resources listed in Cn
for CRL validation. Cn can issue a cert C(n+1)
and later revoke it at will by issuing a CRL.
When the CRL is received, for its validation purpose,  we don’t need to 
look at what resources are listed in the revoked cert C(n+1)
and their relation with the resources listed in cert Cn.
Because the resource cert that is being CRL’ed 
is meant to be discarded.) 

Sriram