[lamps] Re: About MSJ's proposal for the new Attestation OID Registry in draft-ietf-lamps-csr-attestation

[Peter Gutmann <[e-mail]>]

Mike Ounsworth <[e-mail]> writes:

>... just ... this seems overly complicated to me:
>
>AttestationStatement ::= SEQUENCE {
>   type   ATTESTATION-STATEMENT.&id({AttestationStatementSet}),
>   bindsPublicKey [0] BOOLEAN DEFAULT TRUE,
>   stmt   ATTESTATION-STATEMENT.&Type(
>              {AttestationStatementSet}{@type}),
>   attrs  [1] Attributes {{AttestAttrSet}} OPTIONAL
>}

ASN.1 2002 is what happens when a bunch of academics spend a lot of time in a
bubble filled with similar-minded types and decide to second-system the hell
out of something (ASN.1 1988) that was orignally simple and (mostly) worked.
It's how we got things like the van Wijngarden grammar for Algol 68, you know
there's Algol buried underneath there somewhere but damned if you can extract
it from stuff like "b) NEST1 preludes{a} : NEST1 standard prelude with
DECS1{c}, NEST1 library prelude with DECSETY2{c}, NEST1 system prelude with
DECSETY3{c}, where (NEST1) is (new EMPTY new DECS1 DECSETY2 DECSETY3)".

This one definitely needs some "this is what this stuff looks like when
encoded" text added to guide implementers, but see also the final paragraph
below.

>So this is not really about 1988 vs 2002 syntax, but rather about why there
>is so much machinery here.

For some historical context: It's PKIX, or at least the logical successor to
PKIX, and this is how they did standards.  And that's not snark [0], it's very
much a PKIX standard, that's the way they are.  At some point - possibly a
decade or more after it's published - someone will actually get around to
implementing it and then anyone else who might have to use it looks at what
they've done and copies it (SCVP springs immediately to mind) [1].  In
particular given that PKIX excelled at creating vague, ambiguous, and partly
incomprehensible standards which in some cases even the people who wrote them
couldn't explain [2] you pretty much had to follow this route to locate the
various parts of it that you needed to support in order to talk to the other
side's implementation (CMP in this case is the one that springs to mind).

This does seem a lot like one of the numerous PKIX standards that ended up
getting close to, if not actually, zero implementation interest, which means
it may not be worth losing too much sleep over.  That's the pragmatic
approach, if someone is paying you to lose sleep over it that's obviously
another matter.

Peter.

[0] Well, maybe a bit.
[1] That would be one way to tie it down, make sure you're the one
    implementation of it and then anyone who comes along later has to copy
    however you chose to interpret it.
[2] Not saying this draft is like that, I'm saying that's how PKIX worked, and
    this looks like it'd be a PKIX document.