Return-Path: <mcr@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id C6F6E12F3CB
 for <anima@ietfa.amsl.com>; Thu, 13 Jul 2017 01:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
 autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id v1WbGTe8_pdY for <anima@ietfa.amsl.com>;
 Thu, 13 Jul 2017 01:08:21 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net
 [IPv6:2a01:7e00::f03c:91ff:feae:de77])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 56D87126C83
 for <anima@ietf.org>; Thu, 13 Jul 2017 01:08:21 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [89.248.140.19])
 by relay.sandelman.ca (Postfix) with ESMTPS id 761F71F906
 for <anima@ietf.org>; Thu, 13 Jul 2017 08:08:19 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179)
 id 08A74694; Thu, 13 Jul 2017 04:08:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima <anima@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 13 Jul 2017 10:08:18 +0200
Message-ID: <9183.1499933298@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/JdTi8SHuNqrUGFXgIxnTREZl6bw>
Subject: [Anima] pinned-domain-certificate and other BRSKI comments
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>,
 <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>,
 <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jul 2017 08:08:24 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


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 wrappin=
g,
   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=3Dpkcs7" (the default), and that
   we will grow/migrate via format=3Djwt or format=3Dcwt?

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 Registr=
ar
   as described in EST section 3.3.2.
=20=20=20
   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 integrati=
on
   basically means to have the MASA pin the Registrar's cert in some fashio=
n.

   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=3Dcms.

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

=2D-=20
]               Never tell me the odds!                 | ipv6 mesh network=
s [=20
]   Michael Richardson, Sandelman Software Works        | network architect=
  [=20
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [=20
=09



--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJZZypxAAoJEJVM4Vb9/EKQrQoH/Ar++0S0bVEc+fSryul3kEzH
JaO5S4rt0SOWJBVtMMLgcY7VCT4T0yf4Cs8CWiwR4dWvYIfuyEZXRfoBLWRAW539
SYFpvVRI13DzQEptvF68INnl1h1ECo0C6A+/H6XWPxj22J/kr7ffUmB7IWi4F7sQ
/EfCi/sFvg7gxl0fFlmRh3SXPn4iYypYx8ta9Esw72/Yub1ZVBtv2A3ardf51TMe
8P1u0FpcEIrd6nJpe23VXWOOl4Eb2w2vWh1JtmNkdQNtTYsHvcU/k1rlUZTW0LBN
e5VNld8JBmviEfOoeYL1WEKcCAQhA2NiZ4XEbIp77KD+kofa99YOZN7KpQSjg+0=
=2zHz
-----END PGP SIGNATURE-----
--=-=-=--