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

Brian Hibbard <> Thu, 06 January 2011 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 252E43A6C4F for <>; Thu, 6 Jan 2011 08:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lrDKpUmpmvdn for <>; Thu, 6 Jan 2011 08:33:09 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:266::2]) by (Postfix) with ESMTP id C61A73A6C2F for <>; Thu, 6 Jan 2011 08:33:08 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.2) with ESMTP id p06GZ8pP016423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jan 2011 10:35:13 -0600 (CST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Brian Hibbard <>
In-Reply-To: <>
Date: Thu, 06 Jan 2011 10:35:07 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Kurt Zeilenga <>
X-Mailer: Apple Mail (2.1082)
X-Mailman-Approved-At: Thu, 06 Jan 2011 08:35:23 -0800
Cc: Alexey Melnikov <>,,
Subject: Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jan 2011 16:33:10 -0000

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.


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 see
> 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.)