Subject: pk-init-29

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sat, 12 Nov 2005 17:56:35 -0800

From pk-init-29

   If there is a supportedCMSTypes field in the AuthPack, the KDC must
   check to see if it supports any of the listed types.  If it supports
   more than one of the types, the KDC SHOULD use the one listed first.
   If it does not support any of them, it MUST return an error message
   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].

How to the client figure out what CMS encryption types the server supports
in the failure case ? I guess this is not really important since the encKey
case is not supported.

But it got me thinking more about the issue. How is the signature algorithm
negotiated when sha-1WithRSAEncryption is going to be deprecated in a
couple of years.

Love

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 12 Nov 2005 21:14:39 -0800

the signature algorithms are not negotiated, but configured.

________________________________

From: [email-masked] on behalf of Love Hörnquist Åstrand
Sent: Sat 11/12/2005 5:56 PM
To: [email-masked]
Subject: pk-init-29

From pk-init-29

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sun, 13 Nov 2005 16:04:46 +0100

A this is noted in the document that this is how pk-init "supports"
algorithm agility wrt signature algorithms ?

Love

"Liqiang(Larry) Zhu" <[email-masked]> writes:

> -------------------------------------------------------------------------------
> From: [email-masked] on behalf of Love H?rnquist ?strand

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 13 Nov 2005 12:04:33 -0800

PKINIT protocol messages support arbitrary crypto algorithm, for that, I am willing to assert that PKINIT has crypto-agility.
 
IMO, crypto-agility does not mean all algorithms have to be negotiated on the wire. Using your example, if SHA1 has to go away, then it does not help to add a negotiation mechanism, because if SHA1 is not acceptable, why even try to negotiate it?
 
nevertheless, if your intention is to add another unsigned-error message, I do not see any value of doing that right now, rather we should make sure we can do that in the future when we can sign the error message.
 
If nothing else, I will look into that when we do the hash update. do you think this is an acceptable compromise?
 
-- Larry

From: Love Hörnquist Åstrand [mailto:[email-masked]]
Sent: Sun 11/13/2005 7:04 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: pk-init-29

Love

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Nov 2005 14:47:51 -0500

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> IMO, crypto-agility does not mean all algorithms
    Liqiang(Larry)> have to be negotiated on the wire. 

No, that's exactly what it means.

For Love's initial question it is fine if the client sends all the
algorithms it supports because if the server returns an error then the
client cannot succeed.

We do need to look at hash agility both for the DH KDF and for
signatures and for cert selection.  We don't need to support
negotiation today but we do need to confirm we can add it in a
backward compatible manner.

In other words it needs to be the case that a KDC must return a well
defined and unique error for each use of hashes and it must be the
case that this error is intended to take TD.