Subject: [kitten] now that I've volunteered....

From: Bill Mills <[email-masked]>
Date: Mon, 17 Nov 2014 22:24:04 +0000 (UTC)

Can someone please point me at the info for the draft I'm going to do a few edits on?  
Thanks,
-bill

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 17 Nov 2014 17:36:50 -0500 (EST)

> Can someone please point me at the info for the draft I'm going to do a

I believe that would be this one:
https://tools.ietf.org/html/draft-ietf-krb-wg-pkinit-alg-agility-07

As for the few edits, those should be here:
http://www.ietf.org/mail-archive/web/kitten/current/msg03820.html

-Ben

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Nov 2014 23:20:52 +0000 (UTC)

There are outstanding questions here, I have a copy with local edits now.  The issues are:

0) conforming to the new stricter DTD parsing -- done

1) "a preference to reassign the error code" 

    I need specifics here on what needs to happen.

2) move 2 references to informative -- done

3) Include informative reference to MD4 spec, seems optional from that message.  Include it?  I agree that rfc6150 seems sufficient since it's noting the retirement of MD4, and the reader can find the MD4 spec through that route.

4) "OID id-pkinit-kdc has been assigned, but not defined in the module":  What needs to be done here?  I need suggested text.

-bill

P.S.  as editor I'm happy to scribe for the WG but this is outside my expertise to get this language right.

On Monday, November 17, 2014 2:36 PM, Benjamin Kaduk <[email-masked]> wrote:

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Tue, 18 Nov 2014 00:33:25 -0500

>     I need specifics here on what needs to happen.

KRB5KDC_ERR_NO_ACCEPTABLE_KDF should have the value 100 instead of 82.
(This has already been changed in MIT krb5 and the change has shipped.)

---

From: Bill Mills <[email-masked]>
Date: Tue, 18 Nov 2014 16:35:24 +0000 (UTC)

Fixed this.  Thanks.

On Monday, November 17, 2014 9:33 PM, Greg Hudson <[email-masked]> wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Nov 2014 13:58:16 -0500 (EST)

On Mon, 17 Nov 2014, Bill Mills wrote:

>
> 3) Include informative reference to MD4 spec, seems optional from that
> message.  Include it?  I agree that rfc6150 seems sufficient since it's
> noting the retirement of MD4, and the reader can find the MD4 spec
> through that route.

If it was me I would think about including it, but I'm fine leaving it
out, too.

> 4) "OID id-pkinit-kdc has been assigned, but not defined in the module":
> What needs to be done here?  I need suggested text.

I think this is a typo and id-pkinit-kdf is what was meant ('f', not 'c').

The text to be added is going to be in Appendix A, in the definition of
KDFAlgorithmId, extending the comment with probably something like:
The object identifier of the KDF, taken from the arc iso(1)
identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2)
pkinit(3) kdf(6).

We should probably also mention the component identifier 'kdf' where the
OIDs are laid out in section 6, so:

id-pkinit-kdf OBJECT IDENTIFIER           ::= { id-pkinit kdf(6) }

I guess we should probably come up with component identifiers for its
children as well (the next four lines).  Anyone have thoughts on that?  I
don't know how conventional "SHA-1", "SHA-256", etc. are for such things.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Wed, 19 Nov 2014 19:56:16 +0000 (UTC)

OK, for the first bit....

> identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2)

Is the following ccorrect?

KDFAlgorithmId ::= SEQUENCE { 
    kdf-id            [0] OBJECT IDENTIFIER, 
    -- The object identifier of the KDF, taken from the 
    -- arc iso(1) identified-organization(3) dod(6) 
    -- internet(1) security(5) kerberosV5(2) pkinit(3) 

    -- kdf(6).    
    ...
} 

-bill

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Nov 2014 15:01:38 -0500 (EST)

>     -- internet(1) security(5) kerberosV5(2) pkinit(3)

That looks like what I was asking for, yes. (Thanks!)
I'm not sure I can decree whether it is correct, not really being an ASN.1
expert.  I presume that if it's incorrect, someone will speak up about it.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Nov 2014 14:18:55 -0600

> expert.  I presume that if it's incorrect, someone will speak up about it.

When in a module definition, the above compiles.

FOO DEFINITIONS ::=
BEGIN
EXPORTS kdf-id-arc, KDFAlgorithmId;

kdf-id-arc OBJECT IDENTIFIER ::= {
    iso(1) identified-organization(3) dod(6) internet(1) security(5)
    kerberosV5(2) pkinit(3) kdf(6)
}

kdf-id-test OBJECT IDENTIFIER ::= { kdf-id-arc foo(1) }

KDFAlgorithmId ::= SEQUENCE {
    kdf-id            [0] OBJECT IDENTIFIER, -- should be from kdf-id-arc
    ...
}

END

---

From: Tom Yu <[email-masked]>
Date: Wed, 19 Nov 2014 15:23:39 -0500

> I think this is a typo and id-pkinit-kdf is what was meant ('f', not 'c').

I agree that it's probably a typo and should be id-pkinit-kdf.

> identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2)

Are we implying that KDF OIDs must only come from that arc in the
future?  Anyway, it might be easier to refer to it by a shorter
identifier, e.g., "taken from the arc id-pkinit-kdf", and define
id-pkinit-kdf in the module as well.  We should also id-pkinit to the
IMPORTS clause if we do that.

> don't know how conventional "SHA-1", "SHA-256", etc. are for such things.

RFC 6955 and others seem to lean toward lowercase and unhyphenated (for
the base hash algorithm name).

---

From: Tom Yu <[email-masked]>
Date: Wed, 19 Nov 2014 15:29:55 -0500

Also it would be good to change

          supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,

to

          supportedKDFs     [4] SEQUENCE (SIZE (1..MAX)) OF
                                    KDFAlgorithmId OPTIONAL,

to avoid semantic ambiguity between an omitted supportedKDFs and an
included but empty one.

I think this will not be controversial, because I doubt anyone relies on
that semantic distinction, and the document doesn't specify the
difference in semantics between them.

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Nov 2014 14:33:08 -0600

> IMPORTS clause if we do that.

I don't think we should require that KDF OIDs only come from that arc.
Rather, we would be creating a registry with that arc from which
protocol action assignments should be taken.

(One nice result from using OIDs is that private use assignments are
feasible with no communication with any external entity.  There's no
reason to preclude this.  Nor is there a way in x.680 to constrain the
OBJECT IDENTIFIER type to specific arcs, IIRC -- this wouldn't stop
us, of course.)

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Nov 2014 22:07:12 -0500 (EST)

> protocol action assignments should be taken.

Agreed, we shouldn't require that KDF OIDs only come from that arc.
I'm not sure I'm parsing the second sentence correctly.

Tom, do you have any interest in fleshing out Nico's example into
something suitable for Bill to include in the document's appendix?

Thanks,

Ben