Re: [lamps] EST CSR attrs discussion

[Michael Richardson <[e-mail]>]

Dan Harkins <[e-mail]> wrote:
    >   Sorry, I wasn't aware that this issue was being discussed and I wasn't
    > on the lamps/spasm list. But I'm largely responsible-- i.e. to blame-- for
    > the CSR Attrs text in RFC 7030 so perhaps I can try and explain.

okay.

RFC7030 section 4.5.2 includes the example:

       MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
       BgcrBgEBAQEWBggqhkjOPQQDAw==


obiwan-[~](2.6.6) mcr 10076 %base64 -d </tmp/k1 | dumpasn1 -
  0  65: SEQUENCE {
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
 13  18:   SEQUENCE {
 15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 24   7:     SET {
 26   5:       OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
       :       }
       :     }
 33  22:   SEQUENCE {
 35   9:     OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14)
 46   9:     SET {
 48   7:       OBJECT IDENTIFIER '1 3 6 1 1 1 1 22'
       :       }
       :     }
 57   8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
       :   }

which sure looked to me like it's asking for extensionRequest with value 1.3.6.1.1.1.22.
Is it in fact asking for an extension of 1.3.6.1.1.1.22?
And ecPublicKey should have value 1.3.132.0.34.

(which presumably, also means you'd better provide a key of that algorithm)

It seems that some errata needs to be files.

The RFC899[45] design team included Max Pritikin, who seemed fine with the idea
that we could send values, but maybe he just missed this point.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide