Here is what i would like to see fixed in the draft for adoption
(no idea what hat i am wearing - contributor and/or chair)
and also some questions.
Line numbers from nits
> 13 This document describes a serialiation of the RFC8366 voucher format
> 14 to a JSON format is then signed using the JSON Object Signing and
> 15 Encryption mechanism described in RFC7515.
Welcome to the club of people too lazy to use spell checkers.
(1) suggested replacement text to provide better context setting:
RFC8366 defines a digital artefact called voucher as a YANG-defined JSON
document that has been signed using a Cryptographic Message Syntax (CMS)
structure.
This memo introduces a variant of the voucher structure in which CMS is
replaced by the JSON Object Signing and Encryption (JOSE) mechanism described
in RFC7515
to better support use-cases in which JOSE is preferred over CMS.
(2) Up to the point where an AD or other higher power might have objections,
i really would like to see this document marked as an Update to RFC8366 so
that we have a breadcrump trail from RFC8366 to this document (personally
i am never quite sure what the strict requirements are for such a marking).
> 51 Table of Contents
>
> 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
> 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 55 3. JSON Web Signatures . . . . . . . . . . . . . . . . . . . . . 3
> 56 3.1. Unprotected Header . . . . . . . . . . . . . . . . . . . 4
> 57 3.2. Protected Header . . . . . . . . . . . . . . . . . . . . 4
> 58 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4
> 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
> 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
> 61 6.1. Media-Type Registry . . . . . . . . . . . . . . . . . . . 4
> 62 6.1.1. application/voucher-jose+json . . . . . . . . . . . . 4
> 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
> 64 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 5
> 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
> 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 5
> 67 9.2. Informative References . . . . . . . . . . . . . . . . . 6
> 68 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
> 69 A.1. Example Voucher Request (from Pledge to Registrar) . . . 7
> 70 A.2. Example Parboiled Voucher Request (from Registrar to
> 71 MASA) . . . . . . . . . . . . . . . . . . . . . . . . . . 9
> 72 A.3. Example Voucher Result (from MASA to Pledge, via
> 73 Registrar) . . . . . . . . . . . . . . . . . . . . . . . 12
> 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
>
> 76 1. Introduction
>
> 78 [RFC8366] describes a voucher artifact used in [RFC8995] and
> 79 [RFC8572] to transfer ownership of a device to from a manufacturer to
> 80 an owner. That document defines the base YANG module, and also the
> 81 initial serialization to JSON [RFC8259], with a signature provided by
> 82 [RFC5652].
(3) I like to avoid playing "can you remember that RFC number", by prefacing
newly
introduced RFC numbers with their title or otherwise better known abbreviations.
"A Voucher Artifact for Bootstrapping Protocols", [RFC8366] describes a voucher
artifact used in i"Bootstrapping Remote Secure Key Infrastructure (BRSKI)",
[RFC8995] and
"Secure Zero Touch Provisioning (SZTP)" RFC8572] to transfer ownership of a
device from a manufacturer to an owner. That document defines the base YANG
module,
and also the initial mapping to "The JavaScript Object Notation (JSON) Data
Interchange Format",
[RFC8259], with a signature provided by "Cryptographic Message Syntax (CMS)",
[RFC5652].
Sure, thats a mouthfull of name dropping, but beter than numbers bingo.
Likewise full titles would be better for following instances, like CBOR, but i'l
not comment on all places, you get the idea.
(4) Also note the replacement of serialization to mapping as you use mapping in
th
following paragraphs. Not sure what the best word is, but lets use it
consistently.
> 84 Other work, [I-D.ietf-anima-constrained-voucher] provides a mapping
> 85 of the YANG to CBOR [RFC8949] with a signature format of COSE
> 86 [RFC8812].
>
> 88 This document provides an equivalent mapping of JSON format with the
> 89 signature format in JOSE format [RFC7515].
(5) Here a quick reason why this document exist should be. Something like:
The encoding specified in this document is required for
[I-D.ietf-anima-brski-async-enroll]
and may be required and/or preferred in other use-cases, for example when
JOSE is already used in other parts of the use-case, but CMS is not.
> 91 This document does not extend the YANG definition of [RFC8366] at
(6) Would s/extend/change/ be correct ? "change" would be better if correct.
If "change" is not correct, then i am missing something.
> 92 all, but accepts that other efforts such as
> 93 [I-D.richardson-anima-voucher-delegation],
> 94 [I-D.friel-anima-brski-cloud], and
> 95 [I-D.ietf-anima-brski-async-enroll] do. This document supports
> 96 signing any of the extended schemas defined in those documents and
> 97 any new documents that may appear after this one.
(7) How will any scheme select which type of voucher to use in between "cms" or
"jose" ?
Seems to me we are implying and maybe should write out somehing like this:
With the availability of different encoded vouchers, it is up to the
specification of how the voucher is transported to indicate/decide which
voucher format
is used/carried. There is no provison across the different voucher formats
that a receiver could safely recognize which format it uses unless
additional context is provided. For example, [RFC8995] provides this context via
the MIME-Type for the voucher payload.
(i hope this is a correct assessment).
I think this document might be the first one that warrants this warning given
how this seems like the first new voucher format defined by itself without
being tied to a use-case - like constrained-voucher is really constrained-brski,
although the same note would make sense there too. Or we also split that
up...
> 109 [RFC7515] defines two serializations: the JWS Compact Serialization
> 110 and the JWS JSON Serialization. This document restricts itself to
> 111 the JWS Compact Serialization (JWT) format.
(8) ...because ... ?!
> 113 The [RFC8366] JSON structure consists of a nested map, the outer part
> 114 of which is:
>
> 116 { "ietf-voucher:voucher" : { ..some items }}
(9) is "some items" the "inner part" ? If so then maybe use that term bcause
you are also using "outer part", so i would wonder where the "inner part" is
if it wasn't showing up in the structure.
> 118 this is considered the JSON payload as described in [RFC7515] section
> 119 3.
(10) It is actually called the JWS payload if i read rfc7515 correctly, and i
wonder if this whole draft would also not more correctly be called
draft-richardson-anima-jws-voucher
> 121 The JSON Compact Serialization is examplained in section 3.1 or
> 122 section 7.1, and works out to:
>
> 124 BASE64URL(UTF8(JWS Protected Header)) || '.' ||
> 125 BASE64URL(JWS Payload) || '.' ||
> 126 BASE64URL(JWS Signature)
>
> 128 Note that this results in a long base64 content (with two
> 129 interspersed dots). The content is transmitted within the HTTPS
> 130 session in this base64 format, even though HTTP can accomodate binary
> 131 content. This is done to be most convenient for available JWT
> 132 libraries, and for humans who are debugging.
(11) Is there anything that constrains these objects to HTTP(s) ?
If not, then maybe rephrase to "When using HTTP/HTTPs, the voucher is
transmitted in the base64 ..."
> 134 There are a number of attributes. They are:
>
> 136 3.1. Unprotected Header
>
> 138 There is no unprotected header in the Compact Serialization format.
>
> 140 3.2. Protected Header
>
> 142 The standard "typ" and "alg" values described in [RFC7515] are
> 143 expected in the protected headers.
>
> 145 It remains to be determined (XXX), what values, if any, should go
> 146 into the "typ" header, as in the [RFC8995] use cases, there are
> 147 additional HTTP MIME type headers to indicate content types.
>
> 149 The "alg" should contain the algorithm type such as "ES256".
>
> 151 If PKIX [RFC5280] format certificates are used then the [RFC7515]
> 152 section 4.1.6 "x5c" certificate chain SHOULD be used to contain the
> 153 certificate and chain. Vouchers will often need all certificates in
> 154 the chain, including what would be considered the trust anchor
> 155 certificate because intermediate devices (such as the Registrar) may
> 156 need to audit the artifact, or end systems may need to pin a trust
> 157 anchor for future operations. This is consistent with [RFC8995]
> 158 section 5.5.2.
I'll have to hink about this more once its WG draft ;-)
> 160 4. Privacy Considerations
>
> 162 The Voucher Request reveals the IDevID of the system that is
> 163 onboarding.
> 165 This request occurs over HTTPS, however the Pledge to Registrar
> 166 transaction is over a provisional TLS session, and it is subject to
> 167 disclosure via by a Dolev-Yao attacker (a "malicious
> 168 messenger")[onpath]. This is explained in [RFC8995] section 10.2.
(12) I am not quite clear what belongs here and what belongs into other
documents, but the way i see it:
This document does not change any privacy considerations over rfc8366 AFAIK
as long as they belong to the voucher payload. Only the JOSE header is
new. So it would be good to make such a statement (no change, not aware of
privacy considerations for the jose header).
On the other hand, it looks to me as if the Dolev-Yao attack (please add a
reference for it) is not mentioned by name in 8366 nor 8995, so it
is perfectly fine to have the section here, but it should be written
somehwat more independent of 8995. E.g.: Instead of "The Voucher Request,
write "When transporting vouchers over a non-confidential path, the voucher
(independent of CMS or JOSE signature) reveals the ..."
(13) There should be a section "Updates to rfc8366" which just two sentences:
This document adds the new JOSE (JWS ?) signature option to vouchers.
This document adds privacy considerations for transporting vouchers.
>
> 170 5. Security Considerations
>
> 172 The issues of how [RFC8366] vouchers are used in a [RFC8995] system
> 173 is addressed in
EOUTOFCOFFEE ?
> 211 8. Changelog
Yes, please maintain that ;-)
>
> 319 The following is an example request sent from a Pledge to the
> 320 Registrar. This example is from the Siemens reference Registrar
(14) ^ using [RFC8995]
> 321 system.
> 388 A.2. Example Parboiled Voucher Request (from Registrar to MASA)
(15) If you want to keep "parboiled", please add a reference to where an
explanation is what it means.
THE END
Thanks again for this work, folks
Cheers
Toerless
On Thu, Jul 01, 2021 at 06:33:35PM +0200, Toerless Eckert wrote:
> [apologies for mixing up june with july. resending to be formally correct.
> Thanks Bill!]
>
> This emails starts a two week call for adoption for
> draft-richardson-anima-jose-voucher
> The adoption call does end when July 14 has passed for everyone on planet
> earth.
>
> Justification:
>
> This draft is a core normative dependency for the ANIMA WG document
> draft-ietf-anima-brski-async-enroll (BRSKI-AE). It does effectively
> not constitute new work, but was separated out during development
> of that draft so that the jose-signed-voucher can more easily be
> referenced and reused by other work in the IETF that may not need to
> inherit, refer to the whole BRSKI-AE solution.
>
> Toerless, for the ANIMA chairs.
>
> On Thu, Jul 01, 2021 at 08:44:08AM +1200, Brian E Carpenter wrote:
> > > The JSON Compact Serialization is examplained in section 3.1 or section
> > 7.1
> >
> > examplained?? A great word, but not in my dictionary.
> >
> > Mainly I can't understand this draft because it's way outside my expertise,
> > but it seems necessary so I would support adoption.
> >
> > Regards
> > Brian
> >
> > On 30-Jun-21 12:30, Michael Richardson wrote:
> > >
> > > I have reposted draft-richardson-anima-jose-voucher.
> > > It's very short. Most of the document is examples.
> > >
> > > Can we adopt this so that it does not keep brski-async-enroll from
> > > progressing when the time comes?
> > >
> > > [email protected] wrote:
> > > > Name: draft-richardson-anima-jose-voucher
> > > > Revision: 01
> > > > Title: JOSE signed Voucher Artifacts for Bootstrapping
> > > Protocols
> > > > Document date: 2021-06-23
> > > > Group: Individual Submission
> > > > Pages: 15
> > > > Html:
> > > https://www.ietf.org/archive/id/draft-richardson-anima-jose-voucher-01.html
> > > > Diff:
> > > https://www.ietf.org/rfcdiff?url2=draft-richardson-anima-jose-voucher-01
> > >
> > > > Abstract:
> > > > This document describes a serialiation of the RFC8366 voucher format
> > > > to a JSON format is then signed using the JSON Object Signing and
> > > > Encryption mechanism described in RFC7515.
> > >
> > >
> > > --
> > > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> > > Sandelman Software Works Inc, Ottawa and Worldwide
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
