Subject: Re: [kitten] CAMMAC open issues

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Dec 2013 13:37:06 -0500 (EST)

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Dec 2013 13:17:29 -0500

> other verifiers.  I'll let you pick the MAX, though.

I'm pretty sure MAX here is to be taken literally, not as a placeholder.
The change Tom proposes has no effect on the number of verifiers that
can be encoded, or on the encoding when at least one verifier is
present.  However, it reduces the encoding size by something like 4
octets when no verifiers are present.

-- Jeff