Subject: [sipcore] Draft new version: draft-ietf-sipcore-sec-flows-02

From: Brian Hibbard <[email-masked]>
Date: Fri, 22 Jan 2010 15:16:30 -0600

Greetings,

A new version of the Sec Flows draft is now available.

Below is a summary of the remaining OPEN ISSUES and TODO items, each  
by section.

===========
OPEN ISSUES
===========

3.2.   MESSAGE Message Over TLS
OPEN ISSUE: There should be some more information about how this
    MESSAGE is associated with the handshake example.  The dump in
    Section 3.1 is slightly confusing in that example.com and  
example.net
    both resolved to the same address, so reverse lookup shows both
    domains as example.com.

6.   Additional Test Scenarios
OPEN ISSUE: From first bullet, "peer's URI"...What URI?  An AoR for
    the user?  From or To values?  Contacts?  Request-URIs?  For request
    URIs, do we need to discuss the effects of retargeting?  Do we need
    to consider some of the current History-Info discussions?

OPEN ISSUE: From second bullet: What if all you've got is an IP
    address?  Do we disallow IPAddress entries in subjectAltName?  IP
    addresses can appear in the subjectAltName (rfc5280 says so.)  Their
    handling is specified in domain-certs (I believe they will appear as
    "DNS:192.168.0.1"; we need to have someone -- from pkix? --  
ascertain
    this.  If this is the case, then their handling is specified in S7.1
    of domain-certs.

OPEN ISSUE: First sub-bullet (Wildcard matching is not allowed
    against these dNSName entries): Is there something that can be
    referenced here?  In particular, RFC2818 explicitly allows wildcards
    in dNSName entries.  It is not obvious to me whether the  
proscription
    against wildcards in RFC4474 should apply to general use of TLS, or
    just to identity.

OPEN ISSUE: Should we have at least one case for SIP EKU?

Appendix A.   Making Test Certificates
OPEN ISSUE: The information in this section needs to be verified with
    the latest software versions.  How to do conversions between
    supported types needs to be updated accordingly.  Any Windows users
    out there want to volunteer for verify the Windows side of these?

Appendix B.   Certificates for Testing
OPEN ISSUE: Should we discuss certificate chains?  We aren't really
    trying to be a tutorial.  Would it be helpful to add a non-root CA
    and hosts signed by that non-root CA to help with testing events?   
We
    do imply non-root CAs in Section 6.

Appendix C.   Message Dumps
OPEN ISSUE: All of this binary bit-exact stuff needs to be verified
    by other than myself.  I'm looking into ways to make this easier for
    someone else to review and verify.  Any code I make available will  
be
    OpenSSL-centric. -BCH

=====
TODOs
=====
These are mainly issues I need to fix in the binary-generated content.

2.2.   Host Certificates
TODO: Fix subjectAltName DNS:com to DNS:example.com and DNS:net to
    DNS:example.net.

3.2.   MESSAGE Message Over TLS
TODO: Actually use the allOneLine convention.  This will be fixed in
    a change to binary-generated content.

TODO: Remove the Contact headers.

4.1.   MESSAGE Message with Signed Body
TODO: For generated-content, change "hello" to "Hello!" to be
    consistent.

TODO: Actually use the allOneLine convention.  This will be fixed in
    a change to binary-generated content.

4.2.   MESSAGE Message with Encrypted Body
TODO: For generated-content, change "hello" to "Hello!" to be
    consistent.

TODO: Actually use the allOneLine convention.  This will be fixed in
    a change to binary-generated content.

4.3.   MESSAGE Message with Encrypted and Signed Body
TODO: Actually use the allOneLine convention.  This will be fixed in
    a change to binary-generated content.