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

[Brian Hibbard <[e-mail]>]

Hello All,

Based on Kurt's feedback, if there are no objections, my plan is to move forward with adding a statement to the document stating that the flaws in DN presentation 

* are directly from the OpenSSL
* that there presented only as examples
* they are subject to change (as is all the output from the tool) from version to version
* hopefully future versions of the tool will be both correct and consistent according to RFC 4514

I'll put this disclaimer where output is first presented, and will craft the words a little more nicely. 

I'll include RFC 4514 as an informative Reference.

If anyone has any objections or clarifications, please speak up soon.  


Thank you,
-b


On Jan 13, 2011, at 8:56 AM, Kurt Zeilenga wrote:

> 
> 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 <[e-mail] <mailto:[e-mail]>>
>>>> *Date: *January 6, 2011 10:35:07 AM CST
>>>> *To: *Kurt Zeilenga <[e-mail]
>>>> <mailto:[e-mail]>>
>>>> *Cc: *Alexey Melnikov <[e-mail]
>>>> <mailto:[e-mail]>>,
>>>> [e-mail]
>>>> <mailto:[e-mail]>,
>>>> [e-mail] <mailto:[e-mail]>
>>>> *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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>