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

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 2 Jul 2018 15:40:57 -0500

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),
> [email-masked]
> 
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Jul 2018 17:20:01 -0400

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 <[email-masked]> wrote:
> 
> Hi folks,
>

---

From: Sean Leonard <[email-masked]>
Date: Mon, 16 Jul 2018 14:12:53 -0400

I was reviewing the secdispatch agenda and came across this agenda item. I think it is a useful draft. ISE is an appropriate avenue.

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 <[email-masked]> wrote:
> 
>      at-validation-parameters ATTRIBUTE :: {
>        TYPE ValidationParams
>      id-attr-validation-parameters OBJECT IDENTIFIER ::        { 1 3 6 1 4 1 2312 18 8 1 }
> 
>      ValidationParams :: SEQUENCE {
>> On Jul 2, 2018, at 4:40 PM, Benjamin Kaduk <[email-masked]>; wrote:
>> 
>> Hi folks,
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Jul 2018 14:33:41 -0400

> 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

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Jul 2018 16:51:06 -0400

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

-- 

Best regards,
Kathleen