Re: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round

["Max Pritikin (pritikin)" <[e-mail]>]

Take a look at the pre v5 version I’ve posted. Section 2.2 includes the following:
https://github.com/ietf-roll/anima-bootstrap/blob/master/dtbootstrap-anima-keyinfra-05.txt

Does this help?

- max

2.2.  Secure Imprinting using Vouchers

   A voucher is a cryptographically protected statement to the Pledge
   device indicating authorizing a zero-touch imprint on the Registrar
   domain.  Generically the voucher imparts the following information to
   the Pledge:

   Assertion Basis  Indicates the method that protects the imprint.
      This might include discrete ownership verification, assured
      logging operation or reliance on Pledge endpoint behavior such as
      secure root of trust of measurement.  Only some methods are
      normatively defined in this document.  Other methods are left for
      future work.

   Registrar Authentication  Indicates how the Pledge can authenticate
      the Registrar.  This might include an indication of the PKIX trust
      anchor used by the Registrar, or an indication of shared PKIX
      trust anchor and additional CN-ID or DNS-ID information to
      complete authentication.  Symetric key or other methods are left
      for future work.

   Anti-Replay Protections  Time or nonce based information constrain
      vouchers to time periods or bootstrap attempts.

   A number of boostrapping scenarios can be met using differing
   combinations of this information.  All scenarios address the primary
   threat of a MiTM Registrar gaining control over the Pledge device.
   The primary voucher combinations are referred to within this document
   by name:

                |Assertion   |Registrar ID    |Pledge ID | Validity    |
                |Log-|Veri-  |Trust  |CN-ID or|serial    | RTC | Nonce |
                | ged|  fied |Anchor |DNS-ID  |number    |     |       |
   --------------------------------------------------------------------|
   Audit        |  X |       | X     |        | X        |     | X     |
   -------------|----|-------|-------|--------|----------|-----|-------|
   Nonceless    |  X |       | X     |        | X        |     |       |
   Audit        |    |       |       |        |          |     |       |
   -------------|----|-------|-------|--------|----------|-----|-------|
   Owner Audit  |  X |   X   | X     |        | X        |     | X     |
   -------------|----|-------|-------|--------|----------|-----|-------|
   Owner ID     |    |   X   | ?     |  X     | X        | X   |       |
   -------------|----|-------|----------------|----------|-------------|
   BearerVoucher|  X |       |   wildcard     | X        | ?           |
   -------------|----|-------|----------------|----------|-------------|
   MasterVoucher|    |       |   wildcard     | wildcard | X   |       |
   -------------|------------|----------------|----------|-----|-------|




Pritikin, et al.          Expires June 22, 2017                [Page 11]
Internet-Draft                   BRewSKI                   December 2016


   Audit Voucher  An Audit Voucher is named after the logging assertion
      mechanisms that the Registrar then "audits" to enforce local
      policy.  The Registrar mitigates a MiTM Registrar by auditing that
      an unknown MiTM registrar does not appear in the log entries.
      This does not direct prevent the MiTM but provides a response
      mechanism that ensures the MiTM is unsuccessful.  This advantage
      is that actual ownership knowledge is not required on the MASA
      service.

   Nonceless Audit Voucher  An Audit Voucher without a validity period
      statement.  Fundamentally the same as an Audit Voucher except that
      it can be issued in advance to support network partions or to
      provide a permanent voucher for remote deployments.

   Ownership Audit Voucher  An Audit Voucher where the MASA service has
      verified the Registrar as the authorized owner.  The MASA service
      mitigates a MiTM Registrar by refusing to generate Audit Voucher's
      for unauthorized Registrars.  The Registrar uses audit techniques
      to suppliment the MASA.  This provides an ideal sharing of policy
      decisions and enforcement between the vendor and the owner.

   Ownership ID Voucher  An Ownership ID Voucher is named after
      inclusion of the Pledge's CN-ID or DNS-ID within the voucher.  An
      example Ownership Voucher is defined in
      [I-D.ietf-netconf-zerotouch].  The MASA service mitigates a MiTM
      Registrar by identifying the specific Registrar authorized to own
      the Pledge.

   Bearer Voucher  A Bearer Voucher is named after the inclusion of a
      Registrar ID wildcard.  Because the Registrar is not specifically
      identified this voucher type must be treated as a secret and
      protected from exposure as any 'bearer' of the voucher can claim
      the Pledge device.  Theoretically "nonced" and "nonceless" bearer
      vouches can exist.  Publishing a nonceless bearer voucher
      effectively turns the specified Pledge into a "TOFU" device with
      minimal mitigation against MiTM Registrars.

   Master Voucher  A Master Voucher is named after the inclusion of a
      Pledge ID wildcard.  Because the Pledge is not specifically
      identified publishing a nonceless Master Voucher would turn all
      Pledges that trust the MASA into TOFU devices.  This would be a
      significant security consideration as it puts too much power in
      the hands of the vendor MASA service.  Wildcard Pledge IDs MUST
      NOT be accepted.

   [[EDNOTE: Exact definitions of Assertion, ID and Validity methods
   come from the voucher document.  Included are normative statements on
   how Registrar and Pledge operate on these informations after
   verifying the voucher]]


> On Dec 17, 2016, at 12:56 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Toerless Eckert <[e-mail]> wrote:
>> - Including certificate in the voucher allows those vouchers to
>> lie around at an owner much longer. Their validity is as long as that
>> of the included CA certificate (eg: >= 10 years). The validity of
>> a public key is typically much shorter (eg: <= 1 year).
> 
> A certificate is valid as long as the CA that vouches for the DN renews
> the certificate.  They keys can be renewed, and algorithms can even be
> replaced.  That's the payoff from the overhead of the PKI.
> 
> => This is what we need to capture into the document.
> 
> A public key has no expiry date, since it has no date associated with it.
> When you say that a public key is "typically" shorter, you are really
> expressing a good crypto-hygiene suggestion to the owner of the public.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>