Subject: Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02

From: John C Klensin <[email-masked]>
Date: Sat, 07 Jul 2018 15:40:43 -0400

IESG,

After a discussion with the IETF Chair as required by RFC 2026
and concluding that discussion could not satisfy my concerns,
this note constitutes an appeal of the conflict review decision
on draft-mavrogiannopoulos-pkcs8-validated-parameters-02 posted
last month.  Because IESG conflict review decision are not
binding on the Independent Submission Editor, this appeal is not
a request that the IESG take a different position on that
document but about the mechanisms, reasoning, and process that
appear to have been followed in this case (including what appear
to be some substantive errors in that process).

In the interest of transparency and because some people might
perceive an overlap between this appeal and some of the issues
being discussed in the context of the RFCplusplus BOF, I am
copying this message to the IETF list.

Summary:

The provisions for IESG conflict review specified in RFC 4846
and the IESG's explanation of its own procedures for such
reviews in RFC 5742 assume a careful review that is
well-grounded in specifics and that gives the Independent
Submission Edition information to aid in evaluating a document.
In particular, if the IESG is going to ask that something not be
published because it conflicts with IETF work or requires IETF
review, those documents (especially 4846) assume it is obligated
to identify the relevant work, WG, or requirement.   Nothing in
4846 assumes the possibility of the IESG saying something that,
in this context, amounts to "the IETF touched this once,
therefore a document should not be published without IETF review
and IESG approval".    Neither those documents nor any other
IETF procedure allow the IESG to request a document not be
published (or other action taken) simply on the basis of the
IESG's preferences.  The IESG's statement, including the lack of
specific documentation and comments that actually relates to the
underlying documents, suggests that is what occurred here.

The fact that the IESG's conflict review report is only
advisory to the Independent Submission Editor does not change
the above or the nature of this appeal — it is important for
the Internet community that any action taken by the IESG be
carefully considered and follow the spirit of working
cooperatively to make the Internet better, rather than being (or
even appearing to be) expressions of IESG power.

Note that this appeal is about the IESG action, is intended to
avoid similar actions in the future, and is unaffected by any
decisions the ISE might make about next steps with this
particular document.

This appeal requests that the conflict review posted on
2018-06-21 be withdrawn or otherwise reversed and requests
additional actions to prevent the problems represented by that
review in the future.

Actions requested:
(1)	The IESG should withdraw the decision announced on
2018-06-21 and explain to the community why it occurred.  If the
IESG thinks it is wise to submit a new evaluation to the ISE,
that should be done in a timely fashion and in line with the
suggestions below.
The IESG should recognize that any request to block publication
on the basis that a document conflicts with IETF work or
requires processing in the IETF must identify the
standards-track work, existing standard, or WG involved and that
work must be specifically described in the review (or
readily-available supporting materials that represent IESG
consensus such as ballots or evaluation history).   In
particular, "IESG has concluded that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG
approval" is a statement about an IESG conclusion (a very weak
one given three "yes" ballots and eight "no objections") and not
the "appropriate justification" required by Section 5 paragraph
7 of RFC 4846.
.
(2)	 The IESG should also note that, if they prefer that the
document be considered for processing in the IETF Stream, rather
than the Independent Submission Stream, it will normally be more
appropriate for them to request a delay while the document is
considered in those contexts rather than requesting that
publication be blocked (note that RFC 4846 explicitly provides
for such a delay request).  A document proposing or documenting
new work that has been considered but rejected for IETF
processing is almost by definition not in conflict with (or an
end run around) IETF work.   The exception would be a "path not
followed" document, but this would explicitly state that it was
different from the IETF consensus.  If there is no
specifically-relevant active IETF work, relevant standards do
not explicitly require IETF review of their applications,  and
authors can make a persuasive case that the Internet community
would benefit from publication of the document for the
community's information, the document is an appropriate
candidate for Independent Submission processing.   

In particular, if the IESG believes that a document should be
considered for adoption (or recommendation for processing as an
AD sponsored individual submission) by a particular WG or other
process, it should make the needed inquiries and report the
results to the ISE and author(s), not say, as the IESG
Evaluation Record does, "the appropriate way to proceed is for
this to go through the IETF process as well, specifically
SECDISPATCH. If the IETF decides it does not want to take it on,
then we can revisit this question."  RFC 4846 was intended to be
very specific that the conflict review process was not to be an
iterative negotiation between the IESG and the ISE as to whether
a document conflicts with IETF work: it either does or it
doesn't.

(3)	The IESG should recognize that the primary use case for a
"do not publish" finding when there is no current or immediately
anticipated work on the subject matter in the IETF occurs when a
document appears to modify (including updating, revising,
interpreting, etc.) a standards track specification.

(4)	The IESG should consider whether adding another response
category to the list in RFC 5742 would be helpful.  That
category would be something like "After review, the IESG has
concluded that this document is insufficiently clear that it is
not an IETF standard but is, instead, an alternative to one, a
critique, or otherwise does not fit within the standards
process.  The IESG believes it should not be published without
considerable revisions to make the relationship clear in the
body of the document, not just boilerplate".  That
recommendation should identify particular sections or areas of
interest and should, ideally, suggest specific changes.

(5)	The IESG should remind itself (and update RFC 5742 if
needed) that the category paragraphs are there for the IESG's
own convenience and do not limit what can be said, e.g., if
special circumstances arise, the scope of review should reflect
them as long as those circumstances fall within the requirements
of RFC 4846 (i.e., that this is a conflict review and not a
technical one).
Specific comments on this particular document and situation to
support the appeal.
(a)	Despite the claim in comments in the IESG evaluation record,
RFC 5208 (see the evaluation history at
https://datatracker.ietf.org/doc/conflict-review-mavrogiannopoulos-pkcs8-validated-parameters/history/
and the one specific comment associated with the three "yes"
ballots) was an AD sponsored Informational draft that was never
developed by the IETF as standards track work or otherwise.
PKCS#8 was an externally-developed corporate standard for which
change control was handed off to the IETF, with at least an
implicit agreement that the IETF would not take actions which
impeded the further development or practice of that
specification or its existing uses (see the IESG note about
backward compatibility in 5208).  

(b)	PKCS#8, whether in the form described in RFC 5208 or in the
newer description in 5958, is, as the name implies, a syntax or
data structure, not a comprehensive standard in which all values
are defined.  Both the current I-D and such earlier examples as
RFC 8351 supply specific sets of values for use with that syntax
and descriptions of how they are applied and interpreted.  As
such, they do not extend or alter the basic specifications in
any way, much less conflict with them or with present or future
work that might be done based on those specifications if such
work actually existed. 

(c)	 The current I-D does not modify or conflict with 5958 or
any other set of identifying values for PKCS#8 any more than
registering a new media type conflicts with or modifies RFC 2045
or 6838 or adding a new URN namespace conflicts with or modifies
RFC 8141.  In each case, there may be questions as to whether
the new arrangements and their descriptions are clear and
consistent with the base framework or syntax description.  Those
are technical issues that were excluded from conflict reviews by
RFC 4846 and 5958 but, if the IESG considers it appropriate, RFC
4946 encourages informal communications between ADs and the ISE
about such issues.

(d)	The present Internet-Draft appears to depend on an OID
allocated consistent with PKCS#8 and RFC 5208.  The use of
mechanisms rooted in an OID structure, reinforced in this case
by the IANA Considerations of RFC 5958, indicates that there is
no conflict with IETF work or requirement for IETF review to
register or use the technique described in the specification,
nor is there any reasonable basis for blocking publication on
the basis of such conflicts.  I suppose one could argue the
community does not benefit from publication of this
specification for its information, but that argument lies
outside the scope of IESG conflict reviews.  Additionally, the
OID in the case of this document is in a vendor specific branch
and therefore the draft in its current state does not have wide
applicability outside of that vendors usage.  This seemed to
have been overlooked in the IESG evaluation.

(e)	This I-D was introduced to the SAAG mailing list in August
2017.  The I-D received one positive response and one question
but no other activity.  This should be taken as an additional
indication that there is no actual conflict with any ongoing
IETF work.  Presumably SAAG would have suggested that some other
WG examine it if that were thought to be appropriate at that
time.   In addition, as the SECDISPATCH experiment was
introduced on the SAAG mailing list immediately following the
I-D being posted, that introduction presented an excellent
opportunity for the Security ADs to recommend use of SECDISPATH
for the document if appropriate.    The intent of the review
called for by RFC 4846 and its predecessors was to facilitate a
formal check but to do so in the context of a cooperative
relationship between the ISE (and predecessor roles) and the
IESG, not to encourage (or even allow) a last-stage surprise in
situations in which relevant Area Directors had ample warning
about the specification.  RFC 5742 appears to this reader to be
consistent with that approach.

thank you for your consideration and best regards,
   john

---

From: Russ Housley <[email-masked]>
Date: Sat, 7 Jul 2018 16:25:41 -0400

I want to add additional information to this one point in John's appeal.

> have been overlooked in the IESG evaluation.

The OID in question could only be assigned by the owner of the arc.  However, once assigned, the arc owner can make it available to anyone to use.  That seems to be the intent here.  That is, anyone that wants to include the private key validation attribute in a PKCS#8 package can do so with the OID ({ 1 3 6 1 4 1 2312 18 8 1 }) that is assigned and published in the Internet-Draft.

Russ

---

From: John C Klensin <[email-masked]>
Date: Sat, 07 Jul 2018 17:11:45 -0400

--On Saturday, July 7, 2018 16:25 -0400 Russ Housley
<[email-masked]> wrote:

>> by the IANA Considerations of RFC 5958, indicates that there
>> is no conflict with IETF work or requirement for IETF review
>> to register or use the technique described in the
>> specification, nor is there any reasonable basis for blocking
>> publication on the basis of such conflicts.  I suppose one
>> could argue the community does not benefit from publication
>> of this specification for its information, but that argument
>> lies outside the scope of IESG conflict reviews.
>> Additionally, the OID in the case of this document is in a
>> vendor specific branch and therefore the draft in its current
>> state does not have wide applicability outside of that
>> vendors usage.  This seemed to have been overlooked in the
>> IESG evaluation.
> 
> The OID in question could only be assigned by the owner of the
> arc.  However, once assigned, the arc owner can make it
> available to anyone to use.  That seems to be the intent here.
> That is, anyone that wants to include the private key
> validation attribute in a PKCS#8 package can do so with the
> OID ({ 1 3 6 1 4 1 2312 18 8 1 }) that is assigned and
> published in the Internet-Draft.

Russ,

Thanks for the clarification.  Again, as far as the appeal is
concerned, neither publication of a document describing the use
of that OID nor its actual use alters 5802 (or 5958) in any way.
If the IESG has concluded that each new OID (or a description of
its use) should be reviewed and approved in the IETF before
being used, the right (and, AFAIK, only) way to do that would be
to update the IANA Considerations section of RFC 5958 to require
it.  My guess, given my understanding of how OIDs work, falls
into the "good luck with that" category, but it would be
procedurally correct, which trying to block such description
documents on the grounds that they extend 5802 appears to me not
to be.

As to the arc owner giving others permission to use the OID
--assuming that is different from just making a description
available -- I see nothing in the I-D that does that unless one
construes "full conformance with the provisions of BCP 78 and
BCP 79" as doing so.  Perhaps it has been done elsewhere, in
which case I'd hope that the final version of this document
would at least reference that action.  But, if that permission
does not exist, then use of this thing (as distinct from
understanding that it is out there and what it is if it is
encountered) as a matter for the vendor and its customers.

best,
   john

---

From: Melinda Shore <[email-masked]>
Date: Sat, 7 Jul 2018 18:18:21 -0800

On 7/7/18 1:11 PM, John C Klensin wrote:
> BCP 79" as doing so.  

That seems to be a gap in the document.  At any rate the
usual reasons for publishing this sort of thing are to
either establish a basis for interoperability or to reserve
a code point.  Since this OID comes from Nikos's private arc
I'm assuming that it's not the latter.  Also note that it
falls under a "gnutls" object hierarchy within Nikos's arc,
and it may be being used more broadly - dunno.

The attribute seems to me to be generally useful to the community
more broadly and it's reasonable to think the goal here was to
document it so that others can use and/or implement it. I'm sure
there are other possibilities that haven't occurred to me and
guessing someone's intent can go wrong pretty easily, anyway,
so I've written to Nikos to ask him rather than try to make
inferences about it.

Melinda

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 7 Jul 2018 22:28:35 -0400

Sent from my mobile device

> On Jul 7, 2018, at 5:11 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

I agree with your assessment. Additionally, to the point Russ raised, there really wasn’t interest from others to use it when this draft was discussed on the SAAG list. 

Best regards,
Kathleen

---

From: John C Klensin <[email-masked]>
Date: Sat, 07 Jul 2018 22:59:58 -0400

Melinda (and others),

Please note that there are two questions here, with, at least to
me, are entirely different.  The one you are addressing is about
whether the ISE should publish the document and, if so, what
technical and other changes should be made to the I-D before
that is done.  Speaking personally, my free advice to Nicos is
to make it a lot more clear in the text that this is not an IETF
standard or other approved document or use of PKCS#8, why he
wants the document in the RFC Series rather than just put up on
some Red Hat web pages, that this is an OID in a Red Hat arc,
and what uses, if any, he expects or invites organizations who
are part of Red Hat's customer base to make use of it.  And my
free advice to Adrian is that he not publish the thing unless
those issues are clarified to his satisfaction.

None of that has anything to do with the appeal.

The IESG has recommended that this document not be published
because they have concluded that it "extends an IETF protocol in
a way that requires IETF review and should therefore not be
published without IETF review and IESG approval."  That raises
several questions, including whether RFC 5208 is actually "an
IETF protocol", whether adding a new OID definition like this
"extends" PKCS#8 in that way that RFC 4846 and 5742 anticipated
and, even if it did, if, given the nature of OIDs and their
descriptions and of the IANA Considerations of 5208 and 5958,
there is anything about this document that "requires IETF
review".  It also raises more general questions such as whether
the procedures the IESG is using for thee reviews and the way in
which their reasoning is documented is consistent with the level
of transparency and openness we expect, whether the statements
suggested by RFC 5742 are sufficient to inform authors and the
ISE, and, if the IESG erred in making a "do not publish"
recommendation in this case, whether there is anything that can
usefully be done to reduce the chances of similar errors in the
future.

And those are the subjects of the appeal.

best,
    john

--On Saturday, July 7, 2018 18:18 -0800 Melinda Shore
<[email-masked]> wrote:

>> available -- I see nothing in the I-D that does that unless
>> one construes "full conformance with the provisions of BCP 78
>> and BCP 79" as doing so.  
> 
> The attribute seems to me to be generally useful to the
> community more broadly and it's reasonable to think the goal
> here was to document it so that others can use and/or
> implement it. I'm sure there are other possibilities that
> haven't occurred to me and guessing someone's intent can go
> wrong pretty easily, anyway, so I've written to Nikos to ask
> him rather than try to make inferences about it.
> 
> Melinda
>

---

From: Melinda Shore <[email-masked]>
Date: Sat, 7 Jul 2018 20:10:49 -0800

On 7/7/18 6:59 PM, John C Klensin wrote:
> review".  
Right, and I don't think the answers to those questions are
nearly as clear as your appeal suggests.  The attribute's
inclusion doesn't mandate that the primes be validated but
it makes it possible that they are, and I think that if there's
a semantic change to the protocol the IESG has a point.  After all,
it's not just some random chunk of data that's irrelevant
to handling the private key.  But I really don't know what
the intent here was so I'm just not sure, and I'm hopeful
that a little more clarity about the context and intended use
might put some of those questions to rest.

Melinda

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Jul 2018 08:09:05 -0400

--On Saturday, July 7, 2018 20:10 -0800 Melinda Shore
<[email-masked]> wrote:

> inclusion doesn't mandate that the primes be validated but it
> makes it possible that they are, and I think that if there's a
> semantic change to the protocol the IESG has a point.

IMO, only if there is something in the PKCS#8 specs that says to
validate, or not validate, primes.  

However, the more important point for me is that, if the IESG
has said, e.g.,  "because this alters the way that RFC 5208 and
5859 treat validation of Primes, we think it alters an IETF
specification and must be processed in the IETF", we would be
having a rather different discussion or no discussion at all (at
least I wouldn't be part of it).  I'm fairly indifferent whether
that part of the response appeared in the text of the response
or in something recorded in the evaluation record as long as it
is clear that it is the IETF's opinion and not that of one AD
and, in the light of the ISE's ability to consider IESG advice
and then not take it, I find the question of whether that type
of conclusion would, in this case, be a conflict evaluation or a
technical one to be fairly uninteresting.

The main objection, in the simplest possible terms, is to the
IESG saying "... extends an IETF protocol in a way that requires
IETF review"  without identifying the protocol and why, in
fairly specific terms, the IESG thinks it is being extended.  I
believe that exactly the things that cause you to say that
things are now as clear as the appeal suggests are the ones that
cause me to claim that the IESG owes the community more
explanation of why it made the decision it did and that future
decisions like this should not be approved without that type of
explanation being present.  There is also a question as to
whether comments in the evaluation record are sufficient for
that purpose because the community has no way to tell whether
those were just comments by one ADs or information the IESG as a
whole relied on when deciding to approve the "do not public"
request.

> After
> all, it's not just some random chunk of data that's irrelevant
> to handling the private key.  But I really don't know what the
> intent here was so I'm just not sure, and I'm hopeful that a
> little more clarity about the context and intended use might
> put some of those questions to rest.

Agreed completely on the substance and what should be in the
document.

best,
   john