Re: [Secdispatch] Consideration of draft-mavrogiannopoulos-pkcs8-validated-parameters

[Kathleen Moriarty <[e-mail]>]

Regrettably, I can't stay for the discussion due to a conflict, but am
wondering if a different title for this sort of draft might help in
the future?

Perhaps for drafts like this with the next attribute for PKCS#8,
something along the lines of: "Validation Parameter Extension for
PKCS#8 Objects" would help.

I do agree with this being appropriate for the ISE.

Best regards,
Kathleen

On Mon, Jul 16, 2018 at 2:33 PM, Kathleen Moriarty
<[e-mail]> wrote:
> On Mon, Jul 16, 2018 at 2:12 PM, Sean Leonard <[e-mail]> wrote:
>> I was reviewing the secdispatch agenda and came across this agenda item. I think it is a useful draft. ISE is an appropriate avenue.
>
> +1
> I also looked at this draft and think it's appropriate for an ISE
> publication.  It's a private extension and when on the SAAG list
> previously, there was little attention paid to it.
>
> I reached out to original PKCS authors (Russ already responded on his
> own), and they didn't see the need for IETF wide review either.  Here
> is the response:
>
> "The idea behind having an "Attributes" field in the PKCS #8
> PrivateKeyInfo object, similar to other X.500-era syntax, was to
> provide an easy way for applications to add information into the
> object.  The OID provides a unique identifier and has its own
> registration process.  The I-D proposes such an attribute.
>
> It seems reasonable to expect that people would want a way to publish
> the attributes they're using, without changing PKCS #8."
>
> I'm confused as to why it was held up as there isn't much information
> in the conflict review, hence checking back with PKCS authors.
> Additional text may be helpful to make these points more clear.
>
> Best regards,
> Kathleen
>
>>
>> I agree with point (2) about hashAlg. It should be AlgorithmIdentifier. Actually it should be DigestAlgorithmIdentifier, which is a subset of acceptable instances of AlgorithmIdentifier.
>>
>> With respect to point (1), note the spelling: Section 3 appears to be a typo. The CMS standard [RFC5652] tends to spell out “Algorithm”, such as “digestAlgorithm”, “contentEncryptionAlgorithm”, etc. “Alg” is the second most common, such as “bodyHashAlg”, “signAlg”, etc. (see, e.g., [RFC5752]).
>>
>> Sean
>>
>>> On Jul 2, 2018, at 5:20 PM, Russ Housley <[e-mail]> wrote:
>>>
>>> The Internet-Draft looks fine to me.  I think it should be published as an RFC.  I offer two minor comments/questions.
>>>
>>> (1) I think that the same ASN,1 should appear in Section 3 and Appendix B:
>>>
>>>      at-validation-parameters ATTRIBUTE :: {
>>>        TYPE ValidationParams
>>>        IDENTIFIED BY id-attr-validation-parameters }
>>>
>>>      id-attr-validation-parameters OBJECT IDENTIFIER ::        { 1 3 6 1 4 1 2312 18 8 1 }
>>>
>>>      ValidationParams :: SEQUENCE {
>>>        hashAlg OBJECT IDENTIFIER,
>>>        seed OCTET STRING }
>>>
>>> (2) Should the hashAlg be an AlgorithmIdentifier?  The current definition of OBJECT IDENTIFIER does not allow parameters.  I do not know of any hash algorithms that need parameters today, but there has been talk about such parameters over the years (see RFC 6210).  The safe thing to do seems to allow them, even though they are likely to be absent.
>>>
>>> Russ
>>>
>>>> On Jul 2, 2018, at 4:40 PM, Benjamin Kaduk <[e-mail]>; wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> This is a super-short draft, but it seems potentially useful in some
>>>> scenarios (allowing for proof of primality to be included in-band in PKCS#8
>>>> objects).  Hopefully a few people can take a look...
>>>>
>>>> -Ben
>>>>
>>>> On Mon, Jun 18, 2018 at 03:02:49PM -0700, RFC ISE (Adrian Farrel) wrote:
>>>>> Hi SECDispatch,
>>>>>
>>>>> I'm the Independent Submissions Editor, and I have a couple of questions
>>>>> you could help me with.
>>>>>
>>>>> draft-mavrogiannopoulos-pkcs8-validated-parameters has been proposed for
>>>>> publication as an Independent Submission RFC. Along the way it was briefly
>>>>> discussed on the SAAG list where (my interpretation) there was no
>>>>> objection, but also no enthusiasm.
>>>>>
>>>>> During the IESG conflict review (cf. RFC 5742), the AD asked that the draft
>>>>> be considered by SECDispatch. I think the questions to be asked are:
>>>>>
>>>>> - Is this work that a body of people want to bring into the IETF to polish
>>>>> and publish? In other words, would *you* like to help work on the draft
>>>>> and find a venue in the IETF to do that work (here, a new WG, AD
>>>>> sponsored, ...)?
>>>>>
>>>>> - Is the proposed approach harmful in any way (especially to
>>>>> implementations of 5208 or 5958)?
>>>>>
>>>>> - Does the proposed extension constitute a security vulnerability of
>>>>> itself that is a cause for concern to anyone?
>>>>>
>>>>> We are somewhat used to 2 week review periods but owing to the unusual
>>>>> nature of this request and the run up to IETF-102 I suggest a four week
>>>>> period to make any determination. So please send your thought by Monday
>>>>> 16th July (which also gives you a chance to find me in person in
>>>>> Montreal). I've asked the chairs to help with any consensus calls should
>>>>> they prove necessary.
>>>>>
>>>>> Many thanks,
>>>>> Adrian
>>>>> --
>>>>> Adrian Farrel (ISE),
>>>>> [e-mail]
>>>>>
>>>>> _______________________________________________
>>>>> Secdispatch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/secdispatch
>>>>
>>>> _______________________________________________
>>>> Secdispatch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/secdispatch
>>
>> _______________________________________________
>> Secdispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secdispatch
>
>
>
> --
>
> Best regards,
> Kathleen



-- 

Best regards,
Kathleen