Ignore unescaped leading/trailing spaces in RDN type/value

[liggitt]

RFC2253 explicitly says to ignore unescaped leading and trailing space characters in RDN type/values

RFC4514 (which obsoletes RFC2253) does not indicate leading/trailing space characters are to be ignored, but does say they are to be escaped:

3.  Parsing a String Back to a Distinguished Name

   The string representation of Distinguished Names is restricted to
   UTF-8 [RFC3629] encoded Unicode [Unicode] characters.  The structure
   of this string representation is specified using the following
   Augmented BNF [RFC4234] grammar:

      distinguishedName = [ relativeDistinguishedName
          *( COMMA relativeDistinguishedName ) ]
      relativeDistinguishedName = attributeTypeAndValue
          *( PLUS attributeTypeAndValue )
      attributeTypeAndValue = attributeType EQUALS attributeValue
      attributeType = descr / numericoid
      attributeValue = string / hexstring

      ; The following characters are to be escaped when they appear
      ; in the value to be encoded: ESC, one of <escaped>, leading
      ; SHARP or SPACE, trailing SPACE, and NULL.
      string =   [ ( leadchar / pair ) [ *( stringchar / pair )
         ( trailchar / pair ) ] ]

      leadchar = LUTF1 / UTFMB
      LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
         %x3D / %x3F-5B / %x5D-7F

      trailchar  = TUTF1 / UTFMB
      TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /

given that, if we see leading or trailing unescaped spaces, I think ignoring them is the most reasonable thing to do

[johnweldon]

LGTM

[stevekuznetsov]

@liggitt Don't we also want a test with spaces that are inside the value? To test the trailing reset case.

[liggitt]

They were existing test cases with internal spaces