Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows

Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Thu, 13 January 2011 14:53 UTC

Return-Path: <Kurt.Zeilenga@Isode.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80953A6B9D for <apps-discuss@core3.amsl.com>; Thu, 13 Jan 2011 06:53:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.934
X-Spam-Level:
X-Spam-Status: No, score=-100.934 tagged_above=-999 required=5 tests=[AWL=-1.335, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tCecf9EG0g1 for <apps-discuss@core3.amsl.com>; Thu, 13 Jan 2011 06:53:58 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7162A3A6B9A for <apps-discuss@ietf.org>; Thu, 13 Jan 2011 06:53:58 -0800 (PST)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TS8SkQAJULdE@rufus.isode.com>; Thu, 13 Jan 2011 14:56:19 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
In-Reply-To: <4D2C0BC2.7050002@ericsson.com>
Date: Thu, 13 Jan 2011 06:56:16 -0800
Message-Id: <627F499B-09E6-4896-A45F-6E29C1C611BC@Isode.com>
References: <4BF3DB9C-02D5-4778-9D30-694F8DB74A8D@estacado.net> <1B9BC3F1-3FA4-4FAF-BD32-2FE8417840FD@estacado.net> <4D2C0BC2.7050002@ericsson.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
X-Mailer: Apple Mail (2.1082)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: Adam Roach <adam@nostrum.com>, draft-ietf-sipcore-sec-flows@tools.ietf.org, apps-discuss@ietf.org, Brian Hibbard <brian@estacado.net>
Subject: Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2011 14:53:59 -0000

On Jan 10, 2011, at 11:50 PM, Gonzalo Camarillo wrote:

> Hi Kurt,
> 
> could you please have a look at Brian's explanation below and let us
> know whether or not you are happy with it?

My general view is that our examples and discussions should well use established syntaxes.  Inconsistent use of syntaxes not only reduces readability of individual documents containing such inconsistencies, but tends to cause confusion in the whole series of documents.   With DNs, we see significant confusion over whether the RDNs are to be written least-to-most specific or most-to-least specific.   This document adds to that confusion.

As far as the desire to use actual output of a tool a developer might use, I note that I would hope that bugs in such tools, such as those in its use of formal syntaxes, would be corrected over time.

So, I would suggestion that, either one don't use the exact output of the tools and noting this in the I-D OR using the exact output in the tools and noting both that flaws in that output and the fact that different versions of these tools might produce different output.

-- Kurt

> 
> Thanks,
> 
> Gonzalo
> 
>>> *From: *Brian Hibbard <brian@estacado.net <mailto:brian@estacado.net>>
>>> *Date: *January 6, 2011 10:35:07 AM CST
>>> *To: *Kurt Zeilenga <Kurt.Zeilenga@Isode.com
>>> <mailto:Kurt.Zeilenga@Isode.com>>
>>> *Cc: *Alexey Melnikov <alexey.melnikov@Isode.com
>>> <mailto:alexey.melnikov@Isode.com>>,
>>> draft-ietf-sipcore-sec-flows@tools.ietf.org
>>> <mailto:draft-ietf-sipcore-sec-flows@tools.ietf.org>,
>>> apps-discuss@ietf.org <mailto:apps-discuss@ietf.org>
>>> *Subject: **Re: Apps-team review: draft-ietf-sipcore-sec-flows *
>>> 
>>> Hello Kurt,
>>> 
>>> Thank you for your input.   The inconsistencies in presentation of DN
>>> that you're talking about are the actual results of the dumps of the
>>> OpenSSL "x509" certificate tool.  The use of the tool in this context
>>> is only to examine the content of the certificates for learning and
>>> testing purposes, and in the draft, to show what  designers and
>>> testers would see in their environments.   It is only because those
>>> are the actual results from the tool most likely to be used by readers
>>> of this document, that we are partial to leaving the dumps as they are.  
>>> 
>>> With that said, if you remain convinced that consistency  of
>>> presentation is the more important factor here, I will go and make
>>> changes to the x509 dumps.
>>> 
>>> Regards,
>>> Brian
>>> 
>>> On Dec 15, 2010, at 9:21 AM, Kurt Zeilenga wrote:
>>> 
>>>> I have been selected as the Applications Area Review Team reviewer
>>>> for this draft (for background on apps-review, please
>>>> seehttp://www.apps.ietf.org/content/applications-area-review-team).
>>>> 
>>>> Please resolve these comments along with any other Last Call comments
>>>> you may receive. Please wait for direction from your document
>>>> shepherd or AD before posting a new version of the draft.
>>>> 
>>>> Document: draft-ietf-sipcore-sec-flows (rev-07 reviewed)
>>>> Title: Example call flows using Session Initiation Protocol (SIP)
>>>> security mechanisms
>>>> Reviewer: Kurt Zeilenga
>>>> Review Date: 12/15/2010
>>>> IETF Last Call Date: [include if known]
>>>> IESG Telechat Date: 2011-01-20
>>>> Summary: This draft is basically ready for publication as an
>>>> Informational RFC but has a few issues that should be fixed before
>>>> publication.
>>>> Major Issues: None.
>>>> Minor Issues:
>>>> 
>>>> I see some inconsistencies in how Distinguished Names (DNs) are
>>>> presented in the RFC.
>>>> 
>>>> For instance (from 2.1):
>>>> Issuer: C=US, ST=California, L=San Jose, O=sipit,
>>>>         OU=Sipit Test Certificate Authority
>>>> 
>>>> vs. (also from 2.1)
>>>> DirName:/C=US/ST=California/L=San Jose/O=sipit/
>>>>         OU=Sipit Test Certificate Authority
>>>> 
>>>> The former kind of looks like the LDAP DN format but, if that's what
>>>> was intended, the RDNs appear in the incorrect order.  Note that in
>>>> the LDAP DN format, the most specific element appears first (the
>>>> reverse of how they appear in the BER/DER encoding of a DN).  Also,
>>>> there should be no spaces after the RDN separators (the commas).
>>>> 
>>>> The latter appears to be DCE format.
>>>> 
>>>> I would think it appropriate to use a single format for all DNs and,
>>>> if one chooses to use the LDAP DN format, that values ought to be
>>>> constructed per RFC 4514.  I note that Appendix A of RFC 4514
>>>> discusses presentation issues of Distinguished Names.
>>>> 
>>>> Nits: The usual (many acronyms are not spelled out on first use, etc.)
>>> 
>> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss