Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Tue, 29 Sep 2020 19:35:42 GMT, Jamil Nimeh wrote: > Regarding the end-of-content identifier, that looks good. Thanks for fixing > the indentation for the right-side ASN.1 > interpretation of the bytes. My only remaining question is whether the > corresponding hex dumps on the left should match > the indentation levels as well. I don't have a strong opinion either way on > that one but if you're indenting for each > element at the same nest level it seems like that could potentially chew up a > lot of horizontal space. Was the extra > indentation for the second octet string done for readability? Max had requested the current offset of the byte values, so it was easy to see where each new value started and to keep the offsets on a modulo boundary. The formatter on the right is largely decoupled from the hex value tabular form on the left while keeping the correspondence between the formatted items and the bytes. - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Tue, 29 Sep 2020 19:40:46 GMT, Roger Riggs wrote: > > > > Regarding the end-of-content identifier, that looks good. Thanks for fixing > > the indentation for the right-side ASN.1 > > interpretation of the bytes. My only remaining question is whether the > > corresponding hex dumps on the left should match > > the indentation levels as well. I don't have a strong opinion either way on > > that one but if you're indenting for each > > element at the same nest level it seems like that could potentially chew up > > a lot of horizontal space. Was the extra > > indentation for the second octet string done for readability? > > Max had requested the current offset of the byte values, so it was easy to > see where each new value started and to keep > the offsets on a modulo boundary. The formatter on the right is largely > decoupled from the hex value tabular form on > the left while keeping the correspondence between the formatted items and the > bytes. If you and Max find that better from a visual perspective then that works for me. Thanks for clarifying that. - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Tue, 29 Sep 2020 19:20:42 GMT, Roger Riggs wrote: >> Also in that last example, it seems to suggest that the second octet string >> is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered >> by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to >> suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? >> Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > >> Also in that last example, it seems to suggest that the second octet string >> is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered >> by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to >> suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? >> Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > > Yes, all of the enclosed items should be at the same indent level. (A bug as > it turns out). > I chose to indent the END-OF-CONTENT line at the same level to terminate the > list of tag-values at that level > All of the items enclosed are at the same level. > > The updated output is: > : 24 80 ; UNIVERSAL CONSTRUCTED > OCTET STRING [INDEFINITE] > 0002: 04 02 61 62 ; OCTET STRING [2] > 'ab' > 0006: 04 02 63 64 ; OCTET STRING [2] > 'cd' > 000a: 00 00 ; END-OF-CONTENT Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra indentation for the second octet string done for readability? - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Tue, 29 Sep 2020 15:20:13 GMT, Jamil Nimeh wrote: > Also in that last example, it seems to suggest that the second octet string > is nested within the first one since it > sits at a second indent layer. They are both primitives completely covered by > their two byte values so shouldn't they > sit at the same indentation level? Or is the indentation not there to suggest > nested substructures and is more for > separation between elements? Or is this what you mean by "lost an indent"? > Also, should the end of content be at the > same indentation level as the initial indefinite length encoding? Yes, all of the enclosed items should be at the same indent level. (A bug as it turns out). I chose to indent the END-OF-CONTENT line at the same level to terminate the list of tag-values at that level All of the items enclosed are at the same level. The updated output is: : 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' 000a: 00 00 ; END-OF-CONTENT - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Tue, 29 Sep 2020 14:49:49 GMT, Roger Riggs wrote: >> Can you post an example output of that cert? What about indefinite length? >> (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, >> 2, 'c', 'd', 0, 0) > > For your example the output is: > : 24 80 ; UNIVERSAL CONSTRUCTED > OCTET STRING [INDEFINITE] > 0002: 04 02 61 62 ; OCTET STRING [2] > 'ab' > 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' > 000a: 00 00 ; END-OF-CONTENT ``` > > It seems to have lost an indent, I'll take a look at that. Also in that last example, it seems to suggest that the second octet string is nested within the first one since it sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the same indentation level as the initial indefinite length encoding? - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Tue, 29 Sep 2020 14:27:29 GMT, Weijun Wang wrote: >> Are there any other comments or suggestions? > > Can you post an example output of that cert? What about indefinite length? > (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, > 2, 'c', 'd', 0, 0) For your example the output is: : 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' 000a: 00 00 ; END-OF-CONTENT ``` It seems to have lost an indent, I'll take a look at that. - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Tue, 29 Sep 2020 14:20:50 GMT, Roger Riggs wrote: >> Just some comments based on the output example. > > Are there any other comments or suggestions? Can you post an example output of that cert? What about indefinite length? (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, 2, 'c', 'd', 0, 0) - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Mon, 21 Sep 2020 14:04:19 GMT, Weijun Wang wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Small cleanups to javadoc and code > > Just some comments based on the output example. Are there any other comments or suggestions? - PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Mon, 21 Sep 2020 00:19:53 GMT, Weijun Wang wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Small cleanups to javadoc and code
>
> test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 228:
>
>> 226: break;
>> 227:
>> 228: case TAG_OctetString:
>
> I'd rather print nothing for OCTET STRING. My understanding of it is opaque
> octets and not meant to be printable.
Octet Strings can may contain printable strings and it is useful to print them.
A heuristic is used to determine if they are printable and the length is
limited to avoid spewing garbage.
> test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 362:
>
>> 360: switch (tag & 0xc0) {
>> 361: case TAG_APPLICATION:
>> 362: return "APPLICATION " + cons + (tag & 0x1f);
>
> I am not sure how important it is to print out "cons". Also, the tag here is
> usually shown as "[1]" in ASN.1
> definition. Of course, if you choose this style, you might want to avoid
> using brackets for length.
It provides a more complete info on the tag even though the application may not
have publicly defined its values.
-
PR: https://git.openjdk.java.net/jdk/pull/268
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
On Sun, 20 Sep 2020 14:14:51 GMT, Roger Riggs wrote: >> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter >> >> Debugging functions that utilize ASN.1, DER, and BER encoded streams is >> difficult without test utilities to show the contents. >> The ASN.1 formatter reads a stream and produces annotated output of the >> tags, values, and structures. >> When used with the test library jdk.test.lib.hexdump.HexPrinter the >> annotations are synchronized >> with the hex formatted output. >> >> Small changes to HexPrinter are included to improve the output readability. >> >> >> Example decoding of a .pem certificate: >> SEQUENCE [910] >> SEQUENCE [630] >> CONTEXT cons 0 [3] >> BYTE 2, >> BYTE 3, >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> SEQUENCE [76] >> SET [11] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.4.6 (CountryName) >> 'IN' >> ... >> SET [16] >> SEQUENCE [14] >> OBJECT ID [3] 2.5.4.3 (CommonName) >> Client1 >> SEQUENCE [30] >> UTCTIME [13] '150526221718Z' >> UTCTIME [13] '250523221718Z' >> ... >> SEQUENCE [290] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> NULL >> BIT STRING [271] >> CONTEXT cons 3 [123] >> SEQUENCE [121] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> OCTET STRING [2] >> SEQUENCE [44] >> OBJECT ID [9] 2.16.840.1.113730.1.13 >> OCTET STRING [31] '..OpenSSL Generated Certificate' >> SEQUENCE [29] >> OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> OCTET STRING [22] >> SEQUENCE [31] >> OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> OCTET STRING [24] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> BIT STRING [257] >> When used with the HexPrinter test utility, the formatting of the >> hexadecimal values is selected with the parameters to HexPrinter. >> >> : 30 82 03 8e ; SEQUENCE [910] >> 0004: 30 82 02 76 ; SEQUENCE [630] >> 0008: a0 03 ; CONTEXT cons >> 0 [3] >> 000a: 02 01 02 ; BYTE 2, >> 000d:02 01 03 ; BYTE 3, >> 0010: 30 0d ; SEQUENCE [13] >> 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID >> [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 001d:05 00; NULL >> 001f: 30 ; SEQUENCE [76] >> 0020: 4c ; >> 0021:31 0b; SET [11] >> 0023: 30 09 ; SEQUENCE >> [9] >> 0025:06 03 55 04 06 ; OBJECT >> ID [3] 2.5.4.6 (CountryName) >> 002a: 13 02 49 4e ; 'IN' >> >> ... ... >> >> 005b: 31 10 ; SET [16] >> 005d:30 0e; SEQUENCE >> [14] >> 005f: 06 ; OBJECT >> ID [3] 2.5.4.3 (CommonName) >> 0060: 03 55 04 03 ; >> 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 >> 006d:30 1e; SEQUENCE [30] >> 006f: 17 ; UTCTIME >> [13] '150526221718Z' >> 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; >> 007e: 17 0d ; UTCTIME >> [13] '250523221718Z' >> 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; >> >> ... ... >> >> 00db: 30 82 01 22; SEQUENCE >> [290] >> 00df: 30 ; SEQUENCE >> [13] >> 00e0: 0d ; >> 00e1:06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT >> ID [9] 1.2.840.113549.1.1.1 (RSA) >> 00ec: 05 00 ; NULL >> 00ee: 03 82 ; BIT STRING >> [271] >> 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; >> >> ... >> >> 01f0:
Re: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]
> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the > annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > : 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons > 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d:02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID > [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d:05 00; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021:31 0b; SET [11] > 0023: 30 09 ; SEQUENCE > [9] > 0025:06 03 55 04 06 ; OBJECT > ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d:30 0e; SEQUENCE > [14] > 005f: 06 ; OBJECT > ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d:30 1e; SEQUENCE [30] > 006f: 17 ; UTCTIME > [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME > [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22; SEQUENCE [290] > 00df: 30 ; SEQUENCE > [13] > 00e0: 0d ; > 00e1:06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID > [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING > [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201:a3 7b;
