Subject: [sidr] Last Call: <draft-ietf-sidr-policy-qualifiers-01.txt> (Policy Qualifiers in RPKI Certificates) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 11 Feb 2014 05:16:35 -0800

The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Policy Qualifiers in RPKI Certificates'
  <draft-ietf-sidr-policy-qualifiers-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-02-25. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document updates RFC 6487 by clarifying the inclusion of policy
   qualifiers in the certificate policies extension of RPKI resource
   certificates.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-policy-qualifiers/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-policy-qualifiers/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Feb 2014 16:10:24 -0500

Implementers do not do anything with a CPS pointer in a policy qualifier.  So, this addition will not impact interoperability.  That said, I understand that some people want this notice in the certificate, and I see no reason to prevent this document form moving forward.

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Feb 2014 08:09:37 +0900

> Implementers do not do anything with a CPS pointer in a policy
> qualifier.  So, this addition will not impact interoperability.

in other words it has no operational use

> That said, I understand that some people want this notice in the
> certificate, and I see no reason to prevent this document form moving
> forward.

wow, that encourages healthy discussion

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Feb 2014 14:52:49 -0500

> in other words it has no operational use

It has a legal significance.

The terms and conditions are specified within the four corners of the
certificate. This has huge importance in any legal dispute arising out of
the use or misuse of the certificate and allows the issuer to control their
exposure to litigation risk.

The fact that relying parties choose to ignore the policy information does
not mean that it does not affect their ability to hold the issuer liable.

-- 
Website: http://hallambaker.com/

---

From: Rob Austein <[email-masked]>
Date: Wed, 12 Feb 2014 16:06:19 -0500

Since we seem to be re-hashing some of the issues discussed during
WGLC of this draft:

I don't agree that this draft is harmless: I think it's an attractive
nuisance.  Given that we already have an RIR which makes people sign a
non-disclosure agreement (!) to get a copy of their trust anchor
locator, it's not all that far-fetched to imagine that same RIR adding
another contractual requirement in which the user of their trust
anchor locator is also made to promise that they will perform
additional checks outside the core specification using the URI
specified in the policy qualifier.  The draft doesn't rule this out,
it just says that the draft itself adds no such processing
requirements.  I do not find this particularly reassuring.

That said, the RIR in question has already demonstrated that they
don't need policy qualifiers to impose whacky restrictions outside the
scope of the protocol architecture, so denying them use of this policy
qualifier hack wouldn't gain the user community all that much.

---

From: George Michaelson <[email-masked]>
Date: Thu, 13 Feb 2014 09:09:51 +1000

Whilst I agree it has no operational consequence for current relying party
code, or consumers of the products of certificates embedded in online
systems, I don't agree with Randy's or Rob's conclusions regarding the
desirability or risks of this feature.

I think this is a useful addition to the qualities of information in a
certificate, and I support its status.

Since the drivers are non-operational, I don't feel it useful to try and
suggest there are any. I also think that should not preclude the adoption
of this requirement in certificates.

This is a documentation and risk-minimisation process which makes layer-9
happy.

-George

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Feb 2014 10:08:06 +0900

> It has a legal significance.

rhetorical question: in what juristiction(s)?

from 2804

   - The IETF, an international standards body, believes itself to be
     the wrong forum for designing protocol or equipment features that
     address needs arising from the laws of individual countries,
     because these laws vary widely across the areas that IETF standards
     are deployed in.  Bodies whose scope of authority correspond to a
     single regime of jurisdiction are more appropriate for this task.

this song has been repeated.

randy