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 |
