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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
