Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered....

From: Bill Mills <[email-masked]>
Date: Fri, 27 Mar 2015 18:03:11 +0000 (UTC)

Ping on this to resolve. 

     On Wednesday, November 19, 2014 7:07 PM, Benjamin Kaduk <[email-masked]> wrote:

 On Wed, 19 Nov 2014, Nico Williams wrote:

> 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.

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

> (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.)

_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Tom Yu <[email-masked]>
Date: Fri, 27 Mar 2015 14:47:20 -0400

> Ping on this to resolve. 

I'm not sure I remember the context for this, so it might take a while
for me to reconstruct it.

---

From: Tom Yu <[email-masked]>
Date: Tue, 31 Mar 2015 17:36:33 -0400

Here are the KDF OID related changes that I think should happen to the
algorithm agility draft.

Change the Appendix A ASN.1 module IMPORTS subclause that mentions
PK-INIT-SPEC from

      PKAuthenticator, DHNonce
          FROM KerberosV5-PK-INIT-SPEC {
            iso(1) identified-organization(3) dod(6) internet(1)
            security(5) kerberosV5(2) modules(4) pkinit(5) };
            -- as defined in RFC 4556.

to

      PKAuthenticator, DHNonce, id-pkinit
          FROM KerberosV5-PK-INIT-SPEC {
            iso(1) identified-organization(3) dod(6) internet(1)
            security(5) kerberosV5(2) modules(4) pkinit(5) };
            -- as defined in RFC 4556.

(This adds id-pkinit to the imports).

Change the OID list in Section 6 from

   id-pkinit-kdf OBJECT IDENTIFIER           ::= { id-pkinit 6 }
       -- PKINIT KDFs
   id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER   ::= { id-pkinit-kdf 1 }
       -- SP800 56A ASN.1 structured hash based KDF using SHA-1
   id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 }
       -- SP800 56A ASN.1 structured hash based KDF using SHA-256
   id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 }
       -- SP800 56A ASN.1 structured hash based KDF using SHA-512
   id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf 4 }
       -- SP800 56A ASN.1 structured hash based KDF using SHA-384

to

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

   id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
        ::= { id-pkinit-kdf sha1(1) }
        -- SP800-56A ASN.1 structured hash based KDF using SHA-1

   id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
        ::= { id-pkinit-kdf sha256(2) }
        -- SP800-56A ASN.1 structured hash based KDF using SHA-256

   id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
        ::= { id-pkinit-kdf sha512(3) }
        -- SP800-56A ASN.1 structured hash based KDF using SHA-512

   id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
        ::= { id-pkinit-kdf sha384(4) }
        -- SP800-56A ASN.1 structured hash based KDF using SHA-384

and also duplicate that in the Appendix A ASN.1 module.  Inserting it
right after the IMPORTS clause might be a good place.

We can debate whether the component identifiers for the KDF OIDs should
be just <hashname> or ah-<hashname>.

We might also want to duplicate the id-pkinit definition from RFC 4556
in Section 6 (but not the Appendix A ASN.1 module), to make the full OID
easier for a casual reader to derive.

Any comments?

-Tom

---

From: Nico Williams <[email-masked]>
Date: Tue, 31 Mar 2015 17:01:19 -0500

> (This adds id-pkinit to the imports).

OK.

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

Ah, that's nice.  The Heimdal ASN.1 compiler shows this as
"label-less" in the comments in the header file it generates.

> right after the IMPORTS clause might be a good place.

OK.

> be just <hashname> or ah-<hashname>.

I don't think that would be a breaking change, though in general OID
naming changes could be.  The safe way to do this would be to leave
compatibility values behind:

id-pkinit-kdf-sha384 OBJECT IDENTIFIER ::= id-pkinit-kdf-ah-sha384

But I don't care.

> easier for a casual reader to derive.

Sure.

> Any comments?

Not really.  LGTM.

Nico
--

---

From: Tom Yu <[email-masked]>
Date: Tue, 31 Mar 2015 18:07:15 -0400

> id-pkinit-kdf-sha384 OBJECT IDENTIFIER ::= id-pkinit-kdf-ah-sha384

I was intending to indicate, e.g., { id-pkinit-kdf sha384(4) } vs
{ id-pkinit-kdf ah-sha384(4) } , not the reference identifiers for the
entire OIDs (id-pkinit-kdf-ah-sha384 vs id-pkinit-kdf-sha384).