[MS-DSCPM] § (Checksum): invalid BASE16 in example RRS feed

  • Question

  • I'd like to report an error in [MS-DSCPM]: Desired State Configuration Pull Model Protocol, publication date 9/15/2017. I am not actually using this protocol, so I do not require an urgent response.

    Section (Checksum) says:

     Checksum = "Checksum" : DQUOTE Check-sumvalue DQUOTE CRLF
     Check-sumvalue = BASE16 ; specified in [RFC4648]
       / 0x00 (Null Character) 

    Example: "Checksum":"8eDMbsSDig15Xx+B3msvRrDa5N1njaf5smVujQjhOeI="


    According to [RFC4648], BASE16 uses only the characters 0123456789ABCDEF (case insensitive). The string "8eDMbsSDig15Xx+B3msvRrDa5N1njaf5smVujQjhOeI=" is not valid BASE16 because it contains "M" and other disallowed characters. It looks like valid BASE64, though.

    The ValidateChecksum function in PowerShell-DSC-for-Linux formats a checksum in BASE16 and then compares strings, so I think the reference to BASE16 in section is correct, and the error is only in the example.

    On a further note, the use of "0x00 (Null Character)" seems suspicious. Sending null characters in HTTP header fields is not a common practice. I wonder whether [MS-DSCPM] really sends the null characters over the wire or whether they exist only in memory.

    • Edited by ranta Saturday, September 16, 2017 4:06 PM mention PowerShell-DSC-for-Linux
    • Changed type Jeff McCashlandModerator Tuesday, October 17, 2017 8:23 PM The user asked a question.
    Saturday, September 16, 2017 3:58 PM

All replies

  • Hello Ranta - 

    Thank you for your inquiry about MS-DSCPM open specification. We have created an incident for investigating this issue. One of the Open specifications team member will contact you by Monday.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Saturday, September 16, 2017 8:17 PM
  • Hi Ranta,

    Thank you for reporting this issue. I will investigate, and let you know what I find. 


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Monday, September 18, 2017 4:35 PM
  • The quotation marks in seem a bit off, too:

    • The ABNF contains an unquoted colon.
    • The examples have quotation marks at the left side of the colon, even though the ABNF doesn't mention DQUOTE there.

    I think should say this:

     Checksum = "Checksum:" DQUOTE Check-sumvalue DQUOTE CRLF
     Check-sumvalue = BASE16 ; specified in [RFC4648]
       / "" ; empty string

    Example: Checksum:"F1E0CC6EC4838A0D795F1F81DE6B2F46B0DAE4DD678DA7F9B2656E8D08E139E2"


    There are similar problems in other subsections of 2.2.2, and perhaps in

    Monday, September 18, 2017 8:37 PM
  • Hi Ranta,

    My investigation so far agrees with your conclusions with one minor exception: There should be a space after the colon in the element name:

    Checksum = "Checksum: " DQUOTE Check-sumvalue DQUOTE CRLF



    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Tuesday, September 26, 2017 6:21 PM
  • Hi Jeff,

    Did you capture a network trace and verify the space and DQUOTE characters from there?

    In PowerShell-DSC-for-Linux, the HeaderCallback function does

    colonPointer = strstr((char*)charContents, ":");

    memcpy(chunk->headerValues[chunk->size], colonPointer + 2, value_length);

    so it discards the character that follows the colon.

    Then, the IssueGetConfigurationRequest function does

    checksumResponse = headerChunk.headerValues[i];

    and passes that to the ValidateChecksum function, which expects to see neither space nor DQUOTE characters in the checksum string. So if the colon is followed by both a space and a DQUOTE, then I don't see how this could work.

    I suspect that the definition of Checksum in Section should not include DQUOTE at all, and that the examples should likewise not include quotation marks.

    Wednesday, September 27, 2017 8:12 AM
  • Hi Ranta,

    I did collect traces as you said. On the wire, the checksum looks like this:

     43 68 65 63 6B 73 75 6D 3A 20                   Checksum:
     31 31 32 36 39 39 39 30 42 43 34 42 46 44 37 45 11269990BC4BFD7E
     36 37 38 39 34 38 43 43 39 35 32 36 44 42 31 38 678948CC9526DB18
     44 30 41 41 35 37 45 32 43 42 42 31 42 36 44 34 D0AA57E2CBB1B6D4
     42 31 46 37 41 38 43 38 32 33 35 42 43 41 31 39 B1F7A8C8235BCA19
     0D 0A                                           ..

    And lack of checksum looks like:

     22 43 68 65 63 6B 73 75 6D 22 3A 22 22 "  C  h  e  c  k  s  u  m  "  :  "  "


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Wednesday, October 4, 2017 8:43 PM
  • Thanks, Jeff.

    From your traces, I deduce that the syntax is:

    Checksum = "Checksum:" SP Check-sumvalue CRLF / DQUOTE "Checksum" DQUOTE ":" DQUOTE DQUOTE Check-sumvalue = BASE16 ; specified in [RFC4648] Examples: Checksum: "F1E0CC6EC4838A0D795F1F81DE6B2F46B0DAE4DD678DA7F9B2656E8D08E139E2" "Checksum":""

    (I used SP, defined in Appendix B of [RFC5234], to call attention to the mandatory space character.)

    The quotation marks and lack of CRLF in the second alternative seem pretty bizarre, but I suppose the specification needs to match the implementation.

    • Edited by ranta Thursday, October 5, 2017 8:31 PM remove DQUOTE from around Check-sumvalue
    Thursday, October 5, 2017 8:30 PM
  • Hi Ranta,

    The syntax as described is seen when the Checksum is included in the Request body, as mentioned in sections and (also, my "lack of Checksum" example above). When Checksum is in the Response header (the above Checksum example), it uses the indicated syntax, only the double-quotes are not included, and a space is added after the colon. This is consistent across the header fields. 

    We are updating the document for the next release accordingly [Edited for actual update]:   Checksum

    The Checksum header field is defined only for use in a response message sent to a client as part of a GET request for the module and configuration.

     Checksum = "Checksum" : Check-SumValue CRLF

     Check-SumValue = DQUOTE check-basevalue DQUOTE/ DQUOTE DQUOTE

     check-basevalue = BASE16 ; specified in [RFC4648] 

    Example: "Checksum":"ef52442708671f7af8dc5a1fc444a601fa25d8290d6b91cda945427b26e07a15"


    Hope that helps!

    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Tuesday, October 17, 2017 8:22 PM