--On Saturday, July 7, 2018 16:25 -0400 Russ Housley
<housley@xxxxxxxxxxxx> wrote:
> I want to add additional information to this one point in
> John's appeal.
>
>> (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.
>
> 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
