Skip to main content

Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates
draft-ietf-sidr-policy-qualifiers-02

Yes

(Adrian Farrel)
(Alia Atlas)

No Objection

(Barry Leiba)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Ted Lemon)

Note: This ballot was opened for revision 01 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (for -01) Unknown

                            
Alia Atlas Former IESG member
Yes
Yes (for -01) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2014-05-24 for -01) Unknown
Section 2:

It would be useful if there was a sentence in this section that explained why this change to RFC6487 is being made.

s/any optional policy qualifiers/any optional policy qualifier/
(the whole point is that there can only be one policy qualifier, right?)
Barry Leiba Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2014-05-26 for -01) Unknown
I have the exact same comment as Alissa: It would be useful if there was a sentence in this section that explained why this change to RFC6487 is being made.
Brian Haberman Former IESG member
No Objection
No Objection (2014-05-27 for -01) Unknown
I agree with Alissa that having a brief description of why this change is needed would be useful.
Jari Arkko Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-05-27 for -01) Unknown
I support Stephen's comments.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-05-26 for -01) Unknown
- general: Adding more to policy stuff in certs seems like a bad
plan.  However, since a CPS pointer URI doesn't impose any more
processing on the client, I'm ok with it, if those are the certs
with which RPs have to handle. (I assume this is the reason to
add this - that CAs are issuing such certs, right?)

- Section 4 says: "Checking of the URI might allow
denial-of-service (DoS) attacks, where the target host may be
subjected to bogus work resolving the URI." I think that's a little
unclear. It might be better to say "While de-referencing the URI is
not required for certificate validation, doing so could provide a
denial-of-service (DoS) vector, where the target host may be
subjected to bogus work de-referencing the URI."  Additionally, you
could also re-state a RECOMMENDATION that RPs don't de-ref the URI.
(Note: If you'd rather not make this change that's fine, its 
almost a nit.)
Ted Lemon Former IESG member
No Objection
No Objection (for -01) Unknown