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

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Jul 2017 10:08:18 +0200

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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Jul 2017 11:21:38 +0200

>   The 'pinned-domain-cert' element of the voucher contains the domain
>   CA's public key.  The Pledge MUST use the 'pinned-domain-cert' trust
>   anchor to immediately complete authentication of the provisional TLS
>   connection.

At some point we have the option of having just the public key that
we wanted to pin, without any need for a certificate. This was in voucher-03,
as:

       "domain-certificate-identifier": {
         "subject": "base64-encoded Subject DER"
       },

because, I think that the "Subject DER" was a SubjectPublicKeyInfo object.
We have lost this along the way.   I really wanted this. The usage scenario
is a constrained pledge.  It sends it's IDevID as an opaque blob for
it's TLS ClientCertificate, and the Registrar uses a raw public key to
authenticate.  Once the Pledge gets the voucher, it finds the same public key
in the voucher, and it's good.  SubjectPublicKeyInfo is pretty the smallest
structure that can contain a public key.

You may ask, but, what's the point of doing EST at all if you can't speak
enough certificate to actually do an enrollment?  Well, there are three
things that appeal:
  1) if no ACP, an LDevID may not be a goal, the secured EST channel might
     be used for other things. (Such as RESTCONF like session reversal)
     It could be used as an ACE RS/AS connection, and there might be
     symmetric key bound assertions returned and/or evaluated.
     
  2) it could be that IDevID and the MASA/Registrar identies are in RSA,
     (DSA?), or uses bigger/safer ECDSA or EdDSA keys that the Pledge doesn't
     understand, but enrollment will use some simpler subset.
     
  3) the "LDevID" might not be in a PKIX format at all. CWT can do it all.

Am I off the ANIMA scope? Yes.

Can we deal with putting enough ASN1 parsing to pull a public key out
of a self-signed certificate?  Probably... but it will have a cost.

Can we add another field that contains just the public key? Yes.
I'm not sure we can remove the pinned-domain-certificate though, so
we'll be burning those bytes across the link.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Jul 2017 19:15:24 +0200

>   The Registrar MUST use a certificate that chains to the pinned-
>   domain-cert as its TLS server certificate.

I wonder if it should say:

+   The Registrar MUST use a certificate that chains from the pinned-
+   domain-cert as its TLS server certificate.

Or maybe we want "descends"?   Perhaps "server certificate" should be
ServerCertificate, which is the name of the actual payload.

next paragraph:

>   The Pledge's PKIX path validation of a Registrar certificate's
>   validity period information is as described in Section 2.4.

>   Once the
>   PKIX path validation is successful the TLS connection is no longer
>   provisional.

Is there some way we can call the the last sentence out louder?
UPPERCASE it all?  I dunno.  I think people might really need to be hit over
the head here.

section 3.5, I changed:
-        <t>To indicate Pledge status regarding the Voucher the client
+        <t>To indicate Pledge status regarding the Voucher, the pledge

I think this is clear. I'm not certain about the comma :-)

section 3.6:
>   The registrar MUST HTTP POSTs the same Voucher Request as when
>   requesting a Voucher.  It is posted to the /requestauditlog URI
>   instead.  The "idevid-issuer" and "serial-number" informs the MASA

It seems to me that a Registrar should also be able to post any
voucher.  Even an expired one.
So not just a voucher request.  (The distinction being who
signed it).  While generally a Registrar is going to consult the
audit log before asking for a voucher, it could well do so afterwards.
I think this has value in the Pledge is offline case: a Registrar on the
Internet side of the air-gap firewall (with the USB drive...) could take
responsability to consult the audit log periodically.

[StatsCanada's airgap firewall used UUCP via 9-track tapes to move email
cross their airgap firewall]

I think section 3.7 should be 3.6.1, as it's the reply to 3.6.
(I'm gonna do that in the XML)

Section 3.7 needs to say what to do if version!=1.
Could we remove the version from the response and change the URL to
/requestauditlog/v1 ?

(I read to the end of the diffs, and found nothing else that stirred me)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: peter van der Stok <[email-masked]>
Date: Fri, 14 Jul 2017 09:21:49 +0200

>    we will grow/migrate via format=jwt or format=cwt?
What does "grow" mean?

Peter

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jul 2017 15:16:41 +0200

> What does "grow" mean?

I mean, extend the protocol through additional RFCs.