Date: Fri, 6 Dec 2013 13:37:06 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
In-Reply-To: <ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu>
Message-ID: <alpine.GSO.1.10.1312061329390.27579@multics.mit.edu>
References: <ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: kitten@ietf.org
Subject: Re: [kitten] CAMMAC open issues
Precedence: list

On Thu, 7 Nov 2013, Tom Yu wrote:

> Here are what I think are the remaining open issues for CAMMAC.
>
> Wrapping of CAMMAC:
>
> Do we recommend enclosing a CAMMAC inside an AD-IF-RELEVANT?  RFC 4120
> says that authorization data are critical, i.e., an implementaiton
> must reject unrecognized authorization data.  Alternatively, we could
> require that CAMMAC be enclosed in an AD-KDCIssued, and drop the
> consequently redundant "svc-verifier" from CAMMAC.

It looks like this bit got all the follow-up and no one replied to the 
rest.

> Minor encoding change:
>
> Do we change "other-verifiers" from "[3] SEQUENCE OF Verifier" to
> "[3] SEQUENCE (SIZE (1..MAX)) OF Verifier OPTIONAL"?
>
> I think we should do this because it would reduce the encoding size in
> what I believe will be the common case of no additional verifiers.

That seems okay; we don't have any reason to expect an unbounded number of 
other verifiers.  I'll let you pick the MAX, though.

> Motivations text:
>
> I'm still looking over Ben's suggestions for the rewording of the
> "Motivations" section.
>
> CAMMAC-BINDING:
>
> I think I'll cover this in a separate message.

Okay.

-Ben