[PATCH] Prepare for additional PAC types

[Heiko Wundram]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey,

Am 21.08.2015 um 02:09 schrieb Andrew Bartlett:
> Yes, we should be able to pull and push the same blob, byte for 
> byte.
> 
> We prefer this standard as a way of ensuring we do not get the 
> marshalling wrong.  It also ensures signatures are preserved (where
> applicable).

I understand the latter (and already considered it), but the problem
with the corresponding UPN_DNS_INFO structure is that an
alignment/padding/non-overlap isn't fixed/required by the
specification, and neither are the contents of padding bytes, so that
it's nigh impossible to replicate the original data structure if it
wasn't normalized (padding on words, UPN/DNS order, no overlap) except
by passing it around verbatim as a DATA_BLOB.

For example, UPN_DNS_INFO allows (judging by the specification) that
the domain name isn't stored as a separate buffer, but that the
corresponding pointer simply refers to the domain part of the UPN.
Which would make the two strings overlap in the serialization and
which would have to be handled by the push/pull in a non-obvious way.
On the same note, from what I gathered the original reverse-engineered
specification which someone used to specify PAC_UNKNOWN_12 had several
padding bytes or contained the strings in NULL-terminated form (after
the structure, between the strings, after the domain string), but that
isn't required by the specification, either, and wouldn't be the
result of a "normalized" serialization based on the specs.

Considering that I haven't found a use for the structure (PAC) where
an original signature must be preserved (it's only actually
pull/pushed when the PAC is resigned anyway, otherwise it's only
pushed), is this layout-preservation actually a sensible restriction
to impose on UPN_DNS_INFO?

Thanks,

- -- 
Heiko Wundram.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV1tpaAAoJEJ/eyTFUqXhd0toP/1/9XkV7seF9k2DTPud65Z9t
R7IO9M6aLqGTO2zupXBhX7WahogOPhZh4OXqEuupZeeSeVQcHJJd7v6bu6DEkdw2
o8VNj68EV2TnRZO5VQFYaoGwdtwHVfaf6ogikDoM+LsV2FERJPO2wniTKHITh2so
EsLwf3MIgU6w7Ntu13rSf3OcNqCGuhU9ikYOc5J/OubsWJZ3MAgZaSjahddmkJ/8
Wi0qEGMjVKNUKYLuNdgv+gbacg2TA+yAtAU6rwJ50oKTV/E9ViWVx3oT2Bq/uoan
lMBTa2HB6KlvwG7B/qpJOvW3xCT4dLrNv34s/Myk06qkcDwRN7ZpG5rglVgG2pyb
u6wxv3PugUPJw3xe9Ai06Ps32qWTcYcB4O+WpV7VEkrTmXjznw/qNbCG/SoISCf6
5jGXwywiNZ6PgvuYGjUGts8t5Y13PWap58MGtotAMVqhvf9KEwnt7wfo/wo9XxOG
JyYCUYSSfj6WPze5WlPnx2VONFuKChrScY+OiwwUD7LJTcVwy6ED7lKorcdscM5W
btXNEKD2fzP7E7gOj0o//JXfP6eh6SgknO6b7fUJvAeK/tH+xwjc3GtbfQ6dczWv
jQMQw9t3yIb12i3jQzr4xdBacFxm0UxP2MTKY17JY5p75ztv2O5XfxCH3hp3e/Bb
qdU1qQGxj0+r9WckqXLh
=QsyV
-----END PGP SIGNATURE-----