Subject: [sidr] Validation reconsidered and X.509v3 extension OIDs

From: Rob Austein <[email-masked]>
Date: Tue, 19 Jul 2016 13:18:29 +0200

Reminding the WG of an old issue I raised years ago for validation
reconsidered which, as far as I know, has not yet been addressed.

If we change the validation algorithm, we really should also change
the object identifiers used in the X.509v3 extensions used to convey
the resources.

The reason for this is simple: the RFC 3779 validation algorithm has
shipped, long since.  My implementation has been part of OpenSSL for
the last decade, and while it's not enabled by default on all
platforms, it is on some, and is available as a configuration option
on others.  It is far too late to change this, that ship has sailed.

So if we're talking about changing the validation algorithm now, we
need to label the algorithm we're using, so that validation code knows
which algorithm it's supposed to follow.  Otherwise, we'll get
different validation results at different sites depending on which
algorithm they're using this week, different routing decisions as a
consequence, dogs and cats living together, mass hysteria.

The solution to this is simple: change the extension OIDs.  X.509's
"critical extension" mechanism will take care of the rest.

This will require some kind of phase-in/phase-out process during which
the new OIDs appear and the old OIDs vanish, and will require RP code
to implement the new OIDs, but these are trivial issues given that the
RP behavior has to change in any case, that being the point of the
entire validation reconsidered exercise.

Yes, this will be a bit painful, but I view it as in essence exposing
a problem that already exists, rather than sweeping it under the rug.

Sorry for reminding the WG of this yet again at what some may consider
a late date, but I have raised this issue before, I just haven't
(re)raised it in the last few months.

---

From: Russ Housley <[email-masked]>
Date: Tue, 19 Jul 2016 08:43:00 -0400

Does this apply to the Certificate Policy OID too?  If memory is correct, the current CP has a normative pinter to RFC 3779.

Russ

On Jul 19, 2016, at 7:18 AM, Rob Austein <[email-masked]> wrote:

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

---

From: Rob Austein <[email-masked]>
Date: Tue, 19 Jul 2016 15:14:56 +0200

At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote:
> 
> Does this apply to the Certificate Policy OID too?  If memory is
> correct, the current CP has a normative pinter to RFC 3779.

Good catch.

Not sure a policy OID change is necessary, although might be simplest.
If there's a reference, we either need to change the OID or change the
definition of what the OID means.

IIRC, the OpenSSL library code doesn't do anything RFC-3779-specific
for the policy OID, it just follows the usual rules; it's the RP code
built on top of the library that demands that particular policy OID.
So at least in the OpenSSL case, changing the policy OID may not have
any noticeable effect on correctness of software behavior.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 19 Jul 2016 16:14:58 +0200

Hi Rob, WG,

I can see how this can help to make the behaviour of RPs consistent. If this is left as local policy then differences can occur w.r.t. RPs using reconsidered, or not and it's unpredictable for CAs to understand how RPs would behave.

I am not sure that I got your and Russ's point entirely correct, but are you suggesting that we update section 4.8.10 (IP resources extension) in RFC6487 (Resource Certificate Profile) so that it doesn't use the normal RFC3779 critical extension with its corresponding OID, but uses essentially the same resource extension with a different OID to indicate that validation should be done differently? If this is not what you meant some more precise pointers to which OID in which RFC and section need updating would be appreciated :)

Other than that I can prepare some text and slide ware to discuss this further, here and Thursday morning.

Thanks,

Tim

> On 19 Jul 2016, at 13:18, Rob Austein <[email-masked]> wrote:
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2016 10:22:24 -0400

Rob,

I agree with your suggestion to create a new OID for this purpose. This 
can be noted in the document under discussion.

I also agree with Russ's comment that the cert policy needs to be 
updated to reflect the fact that use either OID is OK (if we stick with 
one policy OID).

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 20 Jul 2016 16:52:51 +0200

Hi,

So, to be clear I think this is the related text in section 9 of RFC 6487:

   A new document will be issued as an update to this RFC.  The CP for
   the RPKI [RFC6484] will be updated to reference the new certificate
   profile.  The new CP will define a new policy OID for certificates
   issued under the new certificate profile.

And references in 6484 (CP) to 6487 should be reviewed and reference the validation-reconsidered instead (since it updates the profile), and we should have another OID instead of the one section 1.2. But there is no need to use a different OID for the RFC3779 extensions used. Right?

..just trying to make sure I am looking at the right things here, please correct me if the above is wrong.

Thanks
Tim

> On 20 Jul 2016, at 16:22, Stephen Kent <[email-masked]> wrote:
> 
> Rob,
> 
> I agree with your suggestion to create a new OID for this purpose. This can be noted in the document under discussion.
> 
> I also agree with Russ's comment that the cert policy needs to be updated to reflect the fact that use either OID is OK (if we stick with one policy OID).
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2016 13:50:35 -0400

Tim,

> And references in 6484 (CP) to 6487 should be reviewed and reference the validation-reconsidered instead (since it updates the profile), and we should have another OID instead of the one section 1.…
Thanks for reminding me of the text in section 9 of 6487. Immediately 
after the paragraph you cite the text says that an update to 6487 
requires establishing a timeline for a three phase transition process, 
something we have yet to discuss, and which is not yet part of the 
validation reconsidered I-D.

I believe that Rob suggested using a different OID for the 3779 
extensions because he wants currently-deployed code to continue to work 
with any software that relies on the cert validation procedure defined 
in 3779. A new OID for the extensions would allow software to know which 
type of processing is to be used when encountering a cert extension. So, 
for that reason, and to be consistent with the notion of a phased 
transition process, I believe there is a need for a new OID for the 3779 
extensions.

Steve

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Jul 2016 04:56:12 -0400

> any noticeable effect on correctness of software behavior.

During the SIDR session today, there seemed to be some confusion about which OIDs we are taking about.

The first two are from RFC 3779.  They appear here in the IANA registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1

The two OIDs are: 
	1.3.6.1.5.5.7.1.7	id-pe-ipAddrBlocks
	1.3.6.1.5.5.7.1.8	id-pe-autonomousSysIds	

In addition, RFC 6484 assigned an OID for the certificate policy.  It appears here in the IANA registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.14

The OID is:
	1.3.6.1.5.5.7.14.2	id-cp-ipAddr-asNumber

I think this is a very good candidate for early IANA code point allocation.  I think that our AD can assist with that.

Russ

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 21 Jul 2016 12:36:10 +0200

Hi Russ,

Thank you for the pointers. I am traveling now but I will get back to it.

Thanks
Tim

> On 21 Jul 2016, at 10:56, Russ Housley <[email-masked]> wrote:
> 
> 
> On Jul 19, 2016, at 9:14 AM, Rob Austein <[email-masked] <mailto:[email-masked]>> wrote:
> 
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 <http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1>
> 
> The two OIDs are: 
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.14 <http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.14>
> 
> The OID is:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidr <https://www.ietf.org/mailman/listinfo/sidr>