On 7/7/18 6:59 PM, John C Klensin wrote: > 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". 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
