Sent from my mobile device
> On Jul 7, 2018, at 5:11 PM, John C Klensin <john-ietf@xxxxxxx> wrote:
>
>
>
> --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.
>
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
> 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
>
>
>
