[Anima] pinned-domain-certificate and other BRSKI comments

[Michael Richardson <[e-mail]>]

Max, some comments as I catch up with your changes.
(maybe I should raise these in github, but I'm writing on airplanes, etc)

In brski-07 section 3.2 we give the example as:

An example JSON payload of a voucher request from a Pledge:

    {
     "ietf-voucher:voucher": {
       "nonce": "62a2e7693d82fcda2624de58fb6722e5",
       "created-on": "2017-01-01T00:00:00.000Z",
       "assertion": "proximity"
       "pinned-domain-cert": "<base64 encoded certificate>"
     }
   }

1) Would you object if I filled in an actual encoded certificate value?
   (I'd like to also put the throw-away private key in an appendix so that
   any examples we have can be repeated by others and also validated.)

2) as ietf-voucher.yang leaves the encoding to BRSKI, can we write, instead
   of base64 encoded certificate, can we write instead:
      RFC-urlsafe base64 encoded DER.
   that makes it clear that it is not PEM with "-----BEGIN"... etc.

   I also suggest we write base64url just because I think it's
   more ubiquitous and many people aren't even aware that they are using
   producing it.
   (see: https://tools.ietf.org/html/rfc4648#section-5 )
   (I'm all for implementations accepting both base64url, and base64
   kind, but we have say something about which one one should produce)

3) In the case that the voucher request is unsigned, the serial number for
   the pledge, and the pointer to the MASA will have to come from the
   IDevID certificate used in the TLS client connection.
   I think that we should have authoritative language that says that it
   always comes from the TLS ClientCertificate, and never from a signed
   voucher request.  Otherwise, implementers might do different things and
   when the results are different, it will be hard to figure out what
   went on.
   While I think that the cert info is optional in the PKCS7 signed wrapping,
   I think that we should say SHOULD NOT add it.

4) >application/voucherrequest  The request is a "YANG-defined JSON<

   Is it reasonable that this is "format=pkcs7" (the default), and that
   we will grow/migrate via format=jwt or format=cwt?

5) I think we still haven't gotten prior-signed-voucher described right.
   While it makes sense to provide the pledge's voucher request, I
   thought that if the Registrar already had a voucher (probably expired)
   then it ought to provide that in prior-signed-voucher.  After all,
   that's what the field *IS* called.

6) section 3.3:
   If a nonce is not provided the MASA server MUST authenticate the Registrar
   as described in EST section 3.3.2.
   
   I take it that we reference 3.3.2 specifically because do not want to
   do HTTP-based authentication.  I would guess the sales channel integration
   basically means to have the MASA pin the Registrar's cert in some fashion.

   I think that we should be leaving the door open here to other ways of
   getting authorization, such as OAUTH2 based things.  I don't know if we
   actually need to say anything here.

7) id-kp-cmcRA.  I found it rather hard to get this bit set.  This is a
   software (openssl) plumbing problem, and not a reason to throw this
   requirement under the bus.
   However in the case of an nonceful audit log policy, it seems that many
   non-enterprise Registrars will be operated using self-signed single
   certificates.   I'd like to make this as easy as possible.

8) Response media type: application/voucher+cms.
   I think I'drather register application/voucher; format=cms.

   Let me stop here and start a new email about this.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [