Subject: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 12 Jul 2013 21:14:56 +0000

The chairs have queried the authors of draft-ietf-sidr-policy-qualifiers-00, Policy Qualifiers in RPKI Certificates.  The response was that the draft is ready for wglc.

There was general agreement on this draft during the adoption call, with one request for additional security considerations being addressed in the new version.  The draft is short and straightforward and the wg has not seen fit to comment further.

Even so, it is unusual to publish a draft with so little comment during the time it has been a wg draft.  The chairs will be looking for a stronger than usual response.  Can't publish without reviews!

This starts a 3 week wglc on draft draft-ietf-sidr-policy-qualifiers-00, Policy Qualifiers in RPKI Certificates.  Please do send comments to the list, indicating that you do or do not believe that the draft is ready for publication.

The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-policy-qualifiers-00.

--Sandy, speaking for the co-chairs

---

From: Randy Bush <[email-masked]>
Date: Fri, 12 Jul 2013 12:18:10 -1000

i do not support this draft.  it is not needed technically or
operationally.  it is a silly legal fantasy.

randy

---

From: George Michaelson <[email-masked]>
Date: Sat, 13 Jul 2013 14:39:18 +1000

I support this draft being sent to WGLC. I have read the draft.

PKI imposes operational outcomes which relate to legalisms. conditions of
use, conditions of operation of service, dimensions which lie outside the
routing plane, and barely come into play for most of the time, but when you
*want to know* about things, its useful to have a pointer in the signed
material. What we think about these legalisms is not the point: its the
ability to reference them which is under discussion here. There is no
current mechanism to do that. This draft proposes a mechanism.

I think it does no harm, and I think it will do some good. I certainly have
text which has been given to me by lawyers which I regard as highly
suitable to be pointed to, by this kind of thing, and I expect other
operators of (r)PKI would expect to be able to do the same.

A small amount of work is required by validators of RPKI certificates to
understand a new optional element can exist and not reject certificates for
having the OID in the ASN.1.

I can't think of anything in the draft which requires an 01, and if minor
nits came up I believe they could be fixed in IESG/AUTHOR48 timeframes.

-George

On Sat, Jul 13, 2013 at 7:14 AM, Murphy, Sandra <[email-masked]>wrote:

> The chairs have queried the authors of
> draft-ietf-sidr-policy-qualifiers-00, Policy Qualifiers in RPKI
> Certificates.  The response was that the draft is ready for wglc.
>
> There was general agreement on this draft during the adoption call, with
> one request for additional security considerations being addressed in the
> new version.  The draft is short and straightforward and the wg has not
> seen fit to comment further.
>
> Even so, it is unusual to publish a draft with so little comment during
> the time it has been a wg draft.  The chairs will be looking for a stronger
> than usual response.  Can't publish without reviews!
>
> This starts a 3 week wglc on draft draft-ietf-sidr-policy-qualifiers-00,
> Policy Qualifiers in RPKI Certificates.  Please do send comments to the
> list, indicating that you do or do not believe that the draft is ready for
> publication.
>
> The draft is available at
> http://tools.ietf.org/html/draft-ietf-sidr-policy-qualifiers-00.
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 12 Jul 2013 18:54:42 -1000

> current mechanism to do that. This draft proposes a mechanism.

CPS

---

From: Melinda Shore <[email-masked]>
Date: Fri, 12 Jul 2013 21:51:58 -0800

> CPS

I haven't been following as closely as I should have been (*clearly*),
but are you uncomfortable with the way the CPS mechanism is being
referenced?  Walking through the documents it looks like there are
several layers of indirection, but it's there.  But, several layers of
indirection.

Melinda

---

From: John Curran <[email-masked]>
Date: Sun, 14 Jul 2013 05:20:14 +0000

On Jul 12, 2013, at 6:18 PM, Randy Bush <[email-masked]> wrote:

> operationally. 

If that's the case for you, then don't use it on your certs.  However, your 
requirements don't necessarily encompass all RPKI users, and overall system
robustness is improved by having the policy qualifier language in RFC6487 
more clearly line up with RFC5280 since they are going to be in use by others.

FYI,
/John

---

From: Melinda Shore <[email-masked]>
Date: Sat, 13 Jul 2013 22:41:34 -0800

> more clearly line up with RFC5280 since they are going to be in use by others.

I think I'm coming down in largely the same place Randy is (with some
fuzz around the edges).  I'm not sure I understand the consequences of
not publishing this.

Melinda

---

From: John Curran <[email-masked]>
Date: Sun, 14 Jul 2013 07:15:15 +0000

> fuzz around the edges).  I'm not sure I understand the consequences of

There are really two issues here:

- RFC 6487 does not specifically allow or disallow a policy qualifiers;
  one may read the preface in section 4 as implying it is disallowed, but 
  the document is much more explicit regarding allowed/disallowed fields 
  in other extensions.  As RFC 5280 specifically defines the certificate 
  policies extension as containing a sequence of policy information terms 
  (each of which has object identifier (OID) and optional qualifiers), 
  inclusion of "exactly one policy" doesn't necessarily mean with or 
  without optional qualifiers.  A validator shouldn't have to guess at
  what it allowed in the specification, so RFC 6487 should be clarified
  (one way or the other) on the matter of policy qualifiers.

- If we're going to clarify RFC 6487, then it can be disallowing the 
  policy qualifiers already defined in RFC 5280 or by allowing them.
  Some of the users of RPKI specifications (ARIN) would like to allow
  them (in particular, the CPS pointer policy qualifier) and hence
  the reason for draft-ietf-sidr-policy-qualifiers-00.  You may not 
  see a need to include policy qualifier on the certificates that you
  issue, but providing a reference to CPS in the certificate may be 
  useful for both CA operators and certificate users on occasion.

Thanks,
/John

---

From: Randy Bush <[email-masked]>
Date: Sun, 14 Jul 2013 09:26:54 -1000

>> overall system robustness is improved by having the policy qualifier
>> language in RFC6487 more clearly line up with RFC5280 since they are
>> going to be in use by others.

robustness?  how does this increase *engineering* robustness?  this is
not the internet legal task force.  that's icann.

> I'm not sure I understand the consequences of not publishing this.

there are no *technical* consequences i can see.  it's rir lawyer fud.

randy

---

From: John Curran <[email-masked]>
Date: Sun, 14 Jul 2013 20:10:10 +0000

> not the internet legal task force.  that's icann.

Fix RFC 6487 to make it clear, one way or the other.  Not having some 
folks treat the current spec one way and some treat it another will 
improve *engineering* robustness.

> there are no *technical* consequences i can see.  it's rir lawyer fud.

Incorrect, as the origin of the extension was RFC5280.  As someone noted
earlier, PKI technology often provides mechanisms which may be used for 
expressing various legal concepts, but your usage of them is entirely up 
to you (or at least it should be, unless/until folks start forcing their 
legal perspectives on others by disallowing existing extensions...)

/John

---

From: Robert Loomans <[email-masked]>
Date: Mon, 15 Jul 2013 09:38:07 +1000

I have reviewed the draft and I think it is a useful clarification of an ambiguity in RFC 6487.

I support this draft going to wglc.

Rob

-- 
Robert Loomans                         email:       [email-masked]
Senior Software Engineer, APNIC        sip:    [email-masked]
http://www.apnic.net/                  phone:         +61 7 3858 3100

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Jul 2013 10:20:38 -0400

I agree with John's characterization of the issue being address by this I-D.

I support this I-D because I don't want the lack of a simple capability 
like this to
stand in the way of RPKI deployment in ARIN.

Steve

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 15 Jul 2013 14:22:39 +0000

Hi Sandy,

As I said during the call for adoption, I think this is an important omission from RFC6487 and the document is well written.

Before sending my support to advance to the IESG, I wanted to ask the author if they have tested the effects of this change on existing RP tools. Do they really set the certificate as invalid?

Roque

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 15 Jul 2013 16:53:40 +0200

On Jul 15, 2013, at 4:20 PM, Stephen Kent <[email-masked]> wrote:

> I support this I-D because I don't want the lack of a simple capability like this to

+1

As engineer I don't like having this here. On the other hand legal folk are now insisting that we include a message of the day pointing to terms and conditions in our rsync server. That considered, using a standard way to point to a CPS that includes all this information seems a lot more elegant, and appropriate.

If the document is accepted I think more discussion is needed though on what the RP can do with this information.

Currently our validator accepts, and ignores this. I am not convinced that it is good idea to bother operators with every CPS we encounter. And I am not sure what an operator is supposed to be able to do with this information.. choose to accept/reject all certificates and objects for a certain CPS? I am not in favour of text that is too restrictive.. that said, if this is accepted then I think that discussion needs to be resolved.

Tim

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 15 Jul 2013 16:58:41 +0200

Hi,

> If the document is accepted I think more discussion is needed though on what the RP can do with this information.

Sorry.. for snoozing.. it's not the adoption call of course, but last call.

My point stands though, I would like to know what I am supposed to do with this information. I prefer something liberal leaving this completely to the RP, or RP software even.

---

From: Andy Newton <[email-masked]>
Date: Mon, 15 Jul 2013 17:07:21 +0000

On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" <[email-masked]>
wrote:

>Before sending my support to advance to the IESG, I wanted to ask the
>author if they have tested the effects of this change on existing RP
>tools. Do they really set the certificate as invalid?

Yes, we have tested against the three RP suites. One did not require a
change while the other two required simple one line changes. Current
releases of all three now accommodate it.

-andy

---

From: Andy Newton <[email-masked]>
Date: Mon, 15 Jul 2013 17:10:57 +0000

From:  Tim Bruijnzeels <[email-masked]>
Date:  Monday, July 15, 2013 10:58 AM
To:  "[email-masked] list" <[email-masked]>
Subject:  Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

>My point stands though, I would like to know what I am supposed to do
>with this information. I prefer something liberal leaving this completely
>to the RP, or RP software even.
>
>

Tim,

Section 4 has the following:
 "However, this specification, like [RFC5280
<http://tools.ietf.org/html/rfc5280>],
 places no processing requirements on the URI included in the
 qualifier."

I hope that satisfies your concern.

-andy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 16 Jul 2013 09:37:42 +0200

Hi Andy,

> I hope that satisfies your concern.

It does. Thank you for clarifying.

Support.

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 16 Jul 2013 08:55:29 +0000

Thanks Andy.

Do you think we need to add something in the security section about the transition?

Something like:

"A RP that performs a strick validation based on RFC6487 and fails to support the updates described in this document, would incorrectly invalidate RPKI signed objects that implements the changes in Section 2. At the time of this writing, all known RP software suites (you can mention them as in IDR) were tested and supported the updates on this document" 

Roque

---

From: Andy Newton <[email-masked]>
Date: Tue, 16 Jul 2013 13:49:52 +0000

This sounds fine to me, though it is really an interoperability
considerations section thingy. The IETF does those now, right? :)

-andy

On 7/16/13 4:55 AM, "Roque Gagliano (rogaglia)" <[email-masked]> wrote:

>"A RP that performs a strick validation based on RFC6487 and fails to
>support the updates described in this document, would incorrectly
>invalidate RPKI signed objects that implements the changes in Section 2.
>At the time of this writing, all known RP software suites (you can
>mention them as in IDR) were tested and supported the updates on this
>document" 
>
>Roque
>

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Jul 2013 19:32:25 -0400

As the authors of this I-D already know, I had essentially the same
concerns as Tim, for the same reason: as the implementor of a
validation engine, I don't want to have to deal with whacky special
processing to support somebody else's lawyers.

I do not support publication of this document as an RFC, although I am
willing to stand aside of the WG achieves rough consensus that this
change is necessary.

My main reason for not supporting it is that, even with the text in
the I-D, this still looks like an attractive nuisance.  Given that we
already have an RIR which makes people sign an NDA to get a copy of
their TAL, it is not all that far-fetched to imagine that same RIR
adding a contractual requirement that one also promise to do
additional checks outside the core specification using this URI.  The
text currently in the I-D doesn't rule this out, it just says that the
I-D itself adds no such requirements.  Not terribly reassuring.

---

From: Sean Turner <[email-masked]>
Date: Fri, 19 Jul 2013 10:02:34 -0400

> stand in the way of RPKI deployment in ARIN.

+1 to supporting progression of this draft to the IESG

I hate qualifiers but understand why they wan them and if this somehow 
slows down adopting/deployment I'm good with letting it go.

spt

---

From: Danny McPherson <[email-masked]>
Date: Thu, 25 Jul 2013 17:05:44 -0400

I support the publication of this and understand the practical need.

-danny