Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format
draft-ietf-sip-authid-body-03

[Ballot discuss]
Section 4: It explains why third party call control is hard, but doesn't explain what to do about it -- it just says that other headers "MAY be used", but neither says what they are, nor gives a pointer to where this is defined.

Section 8: what good does it do for a party to be able to verify an AIB signature if, as noted, it can't tell that it is an AIB, let alone what it contains? 

Here are some comments from Eric Rescorla of the Security Directorate:

--
First, let me restate what I take to be the rationale for this
work:

(a) A lot of important SIP information is in message headers.
(b) Message headers aren't conventionally protected by S/MIME.
(c) The current solution is to take the whole SIP message
    and S/MIME sign it.
(d) This causes a lot of bloat as well as confusion because
    some headers are mutable.

What Jon is proposing is basically to produce an S/MIME message
that contains a subset of the headers (and whatever body if
necessary) that are to be validated. While gross, I think this
is probably the right technical approach.

However, I think this document could use some editorial
improvement. I'd like to see two things:

(1) An explicit list of which headers are included in each
    case.
(2) An explicit discussion of what security properties one is
    supposed to be able to infer from any particular AIB.

I think this would make it much clearer. At the moment, I'm
uncomfortable making security assessments.


Detailed comments:
S 1: Your examples use @atlanta.com. Isn't it convention to
    use @example.com now?

S 2: When would you use message/sip as opposed to message/sipfrag?
    Do they have different security implications?

    I think this section also needs some explanation of how to
    construct the AIB, rather than just an example.

S 4 : Having multiple AIBs seems confusing. I think you really
    do need to describe how the linkages work.

S 6: Why isn't this SHOULD a MUST?

S 7: In the first sentence I would think that the user agent
    MUST verify the signature.

    I don't understand why the To header in the response should
    match the To header in the request? Maybe my SIP ignorance
    is showing here if the To/From headers don't swap, but maybe
    a note would help i that case.

[Ballot comment]
I found this text a little unclear:

>  Unsigned AIBs MUST NOT be honored by any recipients.

I'd suggest changing it to say that Unsigned AIBs should be treated according
to the rules set out in Section 7 for AIBs that do not validate; if that doesn't make
sense, then some clarifying text that explains what "MUST NOT be honored" will
imply (identity not displayed?  message discarded?)

In this text:

>  Note that this means that the recipients of the
>  request, even if they are unable to inspect the AIBF, will still be
  > able to see who signed that body (although it will not necessarily be
  > obvious that the body contains an AIB).

Does it really mean "inspect the AIB Format" or "inspect the AIB?"

An example showing multiple AIBs (Section 4.) would be valuable, I believe.

[Ballot discuss]
Formalism DISCUSS:
This document does not contain the registration form specified for content-disposition parameters in RFC 2183. Neither does it contain a reference to RFC 2183.