Re: [Anima] 48h timeout: Constrained BRSKI hackathon / any objections to ask for early allocation
Thanks Toerless,
I support this early allocation! One minor comment:
> Optional parameters: cose-type
Carsten also flagged this. This is a mistake in the registration text I
believe. Because the format we define already indicates COSE_Sign1 there is no
support for any other cose-type's needed. Hence, there are no optional
parameters for this media type. It should be
Optional parameters: N/A
(But that shouldn't stop us from requesting the early allocation.)
Esko
-Original Message-
From: Anima On Behalf Of Toerless Eckert
Sent: Tuesday, July 20, 2021 23:20
To: anima@ietf.org
Subject: [Anima] 48h timeout: Constrained BRSKI hackathon / any objections to
ask for early allocation
Dear ANIMA WG
The constrained BRSKI team is actively working on their impleemntations, also
in the hackathon (see hackathon wiki for daily time and meeting coordinates).
Today we ran into the issue that the implementations need early allocations
codepoints so as to not run into implementation/interop issues later on
(attempting to find some temporary code poins, change later).
The RFC7120 process expects WG chairs (in section 3.1.c) to vet with the
WG that there is consensus in the WG to ask for early allocation. Given
how we already went through the same process for RFC8366 (CMS voucher),
i think there will be no concerns, so i hope a short deadline for
this mail is appropriate.
Please chime in with support and/or reasons if/why you see an issue.
Appended the mail i would send to ADs in 48h unless there are concerns.
Cheers
Toerless
-
To: war...@kumari.net, rwil...@cisco.com
Cc: ops-...@ietf.org, anima@ietf.org, anima-cha...@ietf.org
Subject: Early allocation request for draft-ietf-anima-constrained-voucher
(according to RFC7120)
Dear Rob, dear Warren,
As chairs of the ANIMA WG, we hereby request your AD approval
for early allocation of code points from IANA according to RFC7120
for draft-ietf-anima-constrained-voucher.
This is similar to the early registration request we did for what
is now RFC8366 (voucher), where we requested voucher encoding with CMS
(application/voucher-cms+json) in 2019.
We have now active development and interop work (during IETF111 Hackathon)
for the new encoding option for the constained voucher via COSE. It would
help the ongoing pre-production implementations a lot if they would not have to
come up with non-assigned code-points now.
Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-13
to be pushed soon after datatracker opens again, until then:
https://github.com/anima-wg/constrained-voucher/blob/master/constrained-voucher.txt
We request two early allocations depending on each other:
1. IANA "Media Types" applications registry
https://www.iana.org/assignments/media-types/media-types.xhtml#application
Name TemplateReference
voucher-cose+cborapplication/voucher-cms+json
[draft-ietf-anima-constrained-voucher]
Template according to draft, section 12.5/12.5.1:
This section registers the 'application/voucher-cose+cbor' in the
IANA "Media Types" registry. This media type is used to indicate
that the content is a CBOR voucher or voucher request signed with a
COSE_Sign1 structure [I-D.ietf-cose-rfc8152bis-struct].
Type name: application
Subtype name: voucher-cose+cbor
Required parameters: none
Optional parameters: cose-type
Encoding considerations: COSE_Sign1 CBOR vouchers are COSE objects
signed with one signer.
Security considerations: See Security Considerations, Section
Interoperability considerations: The format is designed to be
broadly interoperable.
Published specification: THIS RFC.
Applications that use this media type: ANIMA, 6tisch, and other
zero-touch imprinting systems
Additional information:
Magic number(s): None
File extension(s): .vch
Macintosh file type code(s): none
Person & email address to contact for further information: IETF
ANIMA WG
Intended usage: LIMITED
Restrictions on usage: NONE
Author: ANIMA WG
Change controller: IETF
Provisional registration? (standards tree only): NO
2. CoAP content type registy
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
Media typeEncoding ID References
- --
application/voucher-cose+cbor TBD3
[draft-ietf-anima-constrained-voucher]
The ANIMA WG chairs have verified that the required conditions for
early allocation from RFC7120, Section 2 are met:
a) Standards Action (document is standards track ANIMA WG draft)
b) The WG draft adequately describes the desired semantics.
c) The WG participants actively working on implementations of the
draft have confirmed that the semantic of the code point is
stable to the extend that it is clear that
Re: [Anima] Registrar certificate EKU bits
Hello all, I have run into the same issue and decided to check the RFCs on this behaviour. Turns out, it is correct behaviour per specifications. See RFC5280 section 4.2.1.12. If the EKU is present, it will restrict the allowed usage purposes of the certificate to only those items listed in the EKU. So, if a client needs to use such certificate for DTLS/TLS, it needs to add id-kp-clientAuth. And if a server needs to use such certificate for DTLS/TLS it needs id-kp-serverAuth. Consequence for a Registrar server, that MUST have id-kp-cmcRA set, is that it also needs id-kp-serverAuth set in the EKU. Older DTLS 1.2 stacks for example may not check EKU yet in such a way (e.g. an older Scandium I used did not check) but I expect never 1.2/1.3 stacks to check EKU. @Michael this could be worth adding to our constrained-BRSKI draft as a clarification, as it seems non-trivial. (It was to me for sure.) And maybe also keep this for considerations for a BRSKI-bis document. Regards Esko -Original Message- From: Anima On Behalf Of Alan DeKok Sent: Tuesday, July 20, 2021 22:54 To: Michael Richardson Cc: Anima WG Subject: Re: [Anima] Registrar certificate EKU bits On Jul 20, 2021, at 4:40 PM, Michael Richardson wrote: > > When debugging another issue, I found that my test Registrar had stopped > being able to connect to my MASA. Some upgrades to Openssl, Apache meant > that one of those two decided the Extended Key Usage for the client > certificates had better be right. > > What I found: > 1) If there is no EKU, then it's all okay. > 2) If there is an EKU, and it contains only cmcRA, then it is rejected. > 3) If I add "clientAuth" EKU, then it works. > > I don't know if this is enforced in Apache (via some callback), or within > OpenSSL. Having run into similar issues, I suspect a combination of both. OpenSSL does it's own validations, and the application using OpenSSL can add more. For EAP, we've added our own certificate validation callbacks, largely to shut off much of the automatic behavior of OpenSSL. i.e. the "heavy lifting" of checking ASN.1 formats and certificate chains is up to OpenSSL. But the validity of the contents of each cert is up to the application. > There are nothing logged in Apache, so I think it's autocratic actions by > a minor patch level of OpenSSL, and Apache probably needs to override the > behaviour. Or, it could be Apache's certificate verify callback. > The lack of logging on the server is a serious problem. That is a wide-spread issue. We've added voluminous debug logging, which is horrible for the average user, but allows anyone *reading* it to trivially debug fairly complex issues. > What does occur is that there is a TLS level response, an SSL Alert, saying > that the certificate was rejected. "Failed" Why? "Failed". > Perhaps someone else will find this email useful. > Mostly, it convinces me to never set any EKU bits. > I guess, I need to set serverAuth too, now that I think about it. Yes. Alan DeKok. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] constrained resources at root for debugging connectivity
Hi, There is already a "CoAP ping" described in RFC 7252 that can be used. It does not access any resource, just the CoAP server endpoint at CoAP message layer. As a side effect of this ping your DTLS stack will set up the connection which is handy. So I don't think we need a resource at / that produces 2.05 , this is for the maintainer of the server to decide how to allocate that resource space. Besides we have already defined some well-known resources accessible with GET ( in core/est/brski) that the client could make use of to test connectivity. Even a non-existing resource in the /.well-known/X space could be used just to get a 4.04 which confirms the server is working properly. This is even better that trying to GET a resource of who knows how large size. Esko -Original Message- From: Anima On Behalf Of Michael Richardson Sent: Tuesday, July 20, 2021 15:39 To: anima@ietf.org Cc: c...@ietf.org Subject: [Anima] constrained resources at root for debugging connectivity It was said in a private exchange: > There is no CoAP resource at the root / hence the 4.04. (Only the > MASA has a test HTTP resource at / ) I thought, what we need is a CoAP Ping/echo. And I remembered: https://www.ietf.org/archive/id/draft-ietf-core-echo-request-tag-13.html#section-2.2 but, this is for the server to validate that the client is really there. Should we recommend that Registrar put something at / that produces a 2.00? (lowercase recommend) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
Hi Toerless, > Is that a correct understanding how CoAP would work ? Agree, the content-format is stored as a single var-length uint in a CoAP Option (not part of the fixed header but one of the optional elements). > Now, there is in the COSE header also a parameter paramaeter called "content > type" In my implementation I don't use the 'content type' header in COSE because it is duplicate. The type is given at CoAP level already so there is no ambiguity, so the "SHOULD" in RFC 8152 doesn't apply. We may mention in the draft not to use this 'content type' for live-generated vouchers and voucher-requests. If the object is created to be transported over other ways (e.g. email, USB stick, etc) then I would opt for including that 'content type' possibly. Although the filename (*.vch) in that case will indicate the exact media type. > ... would be the case if we would not use TBD3 in CoAP for the COSE > message, but instead "18" to indicate only application/cose; > cose-type="cose-sign1" ID=18 Correct, then there might be ambiguity w.r.t. other / future Voucher and Voucher Request formats that may be transported between Pledge and Registrar in operations on the *same* resource (e.g. /rv). But as long as such formats aren't defined it will also work in practice. For example my servers should also accept content-format 18 just as TBD3. So all in all I would say leaving out the 'content type' parameter always will just work and it will only be needed once a new content type is defined that also uses COSE_Sign1 encoding and that new type is used on BRSKI resources like /rv. Esko -Original Message- From: Toerless Eckert Sent: Tuesday, July 20, 2021 21:39 To: draft-ietf-anima-constrained-vouc...@ietf.org; Carsten Bormann Cc: anima@ietf.org Subject: draft-ietf-anima-constrained-voucher COSE confusion Wrt to the discussion today at he Hackathon, i am trying to figure out how the header hierarchy for constrained voucher would work: We use a CoAP session. As a payload of CoAP, we indicate a COSE message, so somewhere in a CoAP header we have a (hopefully ?) binary field for the message type, and the value would be the TBD value to be assigned for cose vouchers in https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats e.g.: application/voucher-cose+cbor ID=TBD3 Is that a correct understanding how CoAP would work ? Now, there is in the COSE header also a parameter paramaeter called "content type", and if i read RFC8152 correctly, that field SHOULD be present and i guess also have the value TBD3, so there is some duplication here. I am not so much worried about this, i just don't understand RFC8152 text "Applications SHOULD provide this header parameter if the content structure is potentially ambiguous", and i wonder if/how that could ever be the case. I can only imagine his would be the case if we would not use TBD3 in CoAP for the COSE message, but instead "18" to indicate only application/cose; cose-type="cose-sign1" ID=18. Cheers Toerless ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
On 2021-07-21, at 09:58, Esko Dijk wrote: > > If the object is created to be transported over other ways (e.g. email, USB > stick, etc) then I would opt for including that 'content type' possibly. Probably not needed: https://www.ietf.org/archive/id/draft-ietf-cbor-file-magic-02.html#name-cbor-tags-for-coap-content-f So once you have a content-format number, you can use file-magic and that pre-registered tag to package the voucher in a file(1) compatible wrapper. Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Creating CBOR-based media types and content formats
We had interesting discussions yesterday about how to fix the media-type and content-format registrations for CBOR-based anima vouchers. I’m growing a bit tired of dispensing the ancient wizardry that is required each time such a registration is needed, so I started writing it up: https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-types.html Comments and PRs very welcome. I plan to submit this as a -00 on Sunday; probably too late for DISPATCH (but I wouldn’t mind some discussion over there as well). Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
Or you can go the other way around, go for tag 18, put a content-format number that you registered (along a media-type) for an *unprotected* voucher (payload) into the protected header. (You might still want a content-format number/media type for the entire voucher, but you may not need a tag.) Grüße, Carsten > On 2021-07-21, at 14:04, Carsten Bormann wrote: > > On 2021-07-21, at 09:58, Esko Dijk wrote: >> >> If the object is created to be transported over other ways (e.g. email, USB >> stick, etc) then I would opt for including that 'content type' possibly. > > Probably not needed: > > https://www.ietf.org/archive/id/draft-ietf-cbor-file-magic-02.html#name-cbor-tags-for-coap-content-f > > So once you have a content-format number, you can use file-magic and that > pre-registered tag to package the voucher in a file(1) compatible wrapper. > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Authors/: IPR poll for draft-richardson-anima-jose-voucher (and others if need be)
Working on IETF111 chair slides i just stumbled over one process step: a) Dear authors of draft-richardson-anima-jose-voucher and ANIMA WG: This is the IPR poll for draft-richardson-anima-jose-voucher We need for each of you authors to make an IPR statement about the draft. As applicable, for example: [1] "I am not aware of any IPR against this document" [ Note: I think if some IPR that was declared against other IETF documents also applies aainst this document, it needs to be re-declared for this document.] b) Dear ANIMA WG participants: if any of you has IPR knowledge against this document, now would be a good time to bring it up. The IETF IPR rules do ask you to do so: https://www.ietf.org/standards/ipr/ "During the standards process any IETF contribution covered by patents or patent applications owned by a participant or their sponsor must be disclosed, or they must refrain from participating." Aka: The only difference between authors and participants is that participants do not need to report that they are no aware of any IPR. In general, you should not be unaware of IPR with your name on it. Note that we did adopt the early IPR disclosure at WG adoption process only at IETF110, so we have not done an IPR poll against draft-ietf-anima-constrained-voucher (from which this draft is a split-off). Currently, there are no IPR disclosures against that constrained voucherit, so there is now of course good time to check this voluntarily. Officially, the IPR poll for those legacy WG document when going through WG last call. There are no IPR disclosures for the original voucher (RFC8366), so i am hopeful that this also means there are no against the constrained work, so this could be pain free and just involvs 2 incantations of [1] from Michael and Thomas. Cheers Toerless ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
Thanks, Esko I find it architecturally somewhat weird to have this "level skip": Normally, if you have a container format, that container format itself would have to indicate the type of its components, and you would not need to or want to expose the type of any component outside of the container. I guess COSE and its registries were designed this way because the fact that applications may want to know about the payload type even before wanting to bother about its signature. I can not quite build an example workflow though to prove that need. Personally, i would prefer to mandate the content-format even if duplicate, just for any type of diagnostics that may not have access to the whole stack into which the COSE object is embedded. Unless of course size-concerns significantly outweigh potential diagnostic benefits. Cheers Toerless On Wed, Jul 21, 2021 at 07:58:58AM +, Esko Dijk wrote: > Hi Toerless, > > > Is that a correct understanding how CoAP would work ? > > Agree, the content-format is stored as a single var-length uint in a CoAP > Option (not part of the fixed header but one of the optional elements). > > > Now, there is in the COSE header also a parameter paramaeter called > > "content type" > > In my implementation I don't use the 'content type' header in COSE because it > is duplicate. The type is given at CoAP level already so there is no > ambiguity, so the "SHOULD" in RFC 8152 doesn't apply. > We may mention in the draft not to use this 'content type' for live-generated > vouchers and voucher-requests. If the object is created to be transported > over other ways (e.g. email, USB stick, etc) then I would opt for including > that 'content type' possibly. Although the filename (*.vch) in that case will > indicate the exact media type. > > > ... would be the case if we would not use TBD3 in CoAP for the COSE > > message, but instead "18" to indicate only application/cose; > > cose-type="cose-sign1" ID=18 > > Correct, then there might be ambiguity w.r.t. other / future Voucher and > Voucher Request formats that may be transported between Pledge and Registrar > in operations on the *same* resource (e.g. /rv). But as long as such formats > aren't defined it will also work in practice. > For example my servers should also accept content-format 18 just as TBD3. > So all in all I would say leaving out the 'content type' parameter always > will just work and it will only be needed once a new content type is defined > that also uses COSE_Sign1 encoding and that new type is used on BRSKI > resources like /rv. > > Esko > > -Original Message- > From: Toerless Eckert > Sent: Tuesday, July 20, 2021 21:39 > To: draft-ietf-anima-constrained-vouc...@ietf.org; Carsten Bormann > > Cc: anima@ietf.org > Subject: draft-ietf-anima-constrained-voucher COSE confusion > > Wrt to the discussion today at he Hackathon, i am trying to figure out > how the header hierarchy for constrained voucher would work: > > We use a CoAP session. > As a payload of CoAP, we indicate a COSE message, so > somewhere in a CoAP header we have a (hopefully ?) binary field for > the message type, and the value would be the TBD value to be assigned > for cose vouchers in > https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats > > e.g.: > > application/voucher-cose+cbor ID=TBD3 > > Is that a correct understanding how CoAP would work ? > > Now, there is in the COSE header also a parameter paramaeter called > "content type", and if i read RFC8152 correctly, that field SHOULD > be present and i guess also have the value TBD3, so there is > some duplication here. I am not so much worried about this, > > i just don't understand RFC8152 text "Applications SHOULD provide this header > parameter if the content structure is potentially ambiguous", and i > wonder if/how that could ever be the case. I can only imagine his > would be the case if we would not use TBD3 in CoAP for the COSE > message, but instead "18" to indicate only application/cose; > cose-type="cose-sign1" ID=18. > > Cheers > Toerless -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
On 2021-07-21, at 18:27, Toerless Eckert wrote: > > I find it architecturally somewhat weird to have this "level skip”: Depending on the key and its usage, you may want to include the context in the signing input that this is a voucher. So that would support Toerless’ unease. Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] constrained resources at root for debugging connectivity
Esko Dijk wrote:
> There is already a "CoAP ping" described in RFC 7252 that can be
> used. It does not access any resource, just the CoAP server endpoint at
> CoAP message layer. As a side effect of this ping your DTLS stack will
> set up the connection which is handy.
I recalled that later in the day that CoAP "ping" is not connected to CoAP
"echo" :-)
I think that there is also potentially a need for a way to debug possible MTU
issues.
Is there a way to use Olaf's "coap-client" to do the ping?
I don't see an option, and it also doesn't seem to be commonly built with DTLS.
We also have the issue of CCM8 vs OpenSSL that I thought got solved, but it
appears that it has not been, so one needs a tool built with mbedtls or wolfSSL.
> So I don't think we need a resource at / that produces 2.05 , this is
> for the maintainer of the server to decide how to allocate that
> resource space.
> Besides we have already defined some well-known resources accessible
> with GET ( in core/est/brski) that the client could make use of to test
> connectivity.
> Even a non-existing resource in the /.well-known/X space could be used
> just to get a 4.04 which confirms the server is working properly. This
> is even better that trying to GET a resource of who knows how large
> size.
BTW, I've changed my /version.json so that it now looks for and returns the
client certificate that it saw:
curl
--cert spec/files/product/00-D0-E5-02-00-2E/device.crt
--key spec/files/product/00-D0-E5-02-00-2E/key.pem
https://masa.honeydukes.sandelman.ca/version.json
->
{"version":"1.1.0","revision":"582044cfc536fd295e8bdcd3b90f30453d7784d3","Hostname":"masa.honeydukes.sandelman.ca","client_certificate":"-BEGIN
CERTIFICATE-\nMIICBjCCAYugAwIBAgIEXKnlyDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB\nGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry\ndW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa\nMBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJlMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAEey+I0TtIhm8ivRJY36vF5ZRHs/IwhQWRc2Ql70rN+aYLZPOIXYc6\nZzlO62kDYBo3IPrcjkiPVnhoCosUBpTzbqOBhzCBhDAdBgNVHQ4EFgQU/g+KaX9o\nDEKY2K3NGe7Vr/9geDAwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S\nAaATDBEwMC1EMC1FNS0wMi0wMC0yRTArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l\neWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNpADBmAjEAuEwTKPMzS/Xm\nAhR4tFtDo3YHoPoBsaw/6UUYDHot4EoKy2L8AlriFzti/iNmH67/AjEAnRjH2R0T\n98DZjBIhz7W8LM52AeymMdCtsJyuDRjtVuncGEfMO/OWuFFx5qwYR63I\n-END
CERTIFICATE-\n"}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] 48h timeout: Constrained BRSKI hackathon / any objections to ask for early allocation
Carsten Bormann wrote: > On 20. Jul 2021, at 23:19, Toerless Eckert wrote: >> >> Optional parameters: cose-type > Ugh. removed from git copy. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Creating CBOR-based media types and content formats
Carsten Bormann wrote:
> We had interesting discussions yesterday about how to fix the
> media-type and content-format registrations for CBOR-based anima
> vouchers.
Thank you for your input, and for trying to remove yourself from the loop.
> I’m growing a bit tired of dispensing the ancient wizardry that is
> required each time such a registration is needed, so I started writing
> it up:
>
https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-types.html
> Comments and PRs very welcome.
I did find reading it invoked a new appreciation for Arcane Wizardry.
Specifically, I found that sections 3 and 4 didn't tell me anything that I
recognized as important for filing in the template.
"The Encoding considerations are often used in a way that is different from
the intention in Section 4.8 of [RFC6838], which is a simple selection
between "binary" and various alternatives that are now all obsolete. "
so, really, it's always binary now?
Maybe, just say that somewhere.
I don't think you should hide the example in the appendix.
Rather, I think that you should make it the core of the document, explaining
each bit of arcana. If it's worth publishing this as a new RFC, then it's
worth obsoleting RFC6838. Otherwise, I suggest some nice HTML, maybe in the
new-fangled single-hop-over-building wiki.
("Go big, or go home")
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Authors/: IPR poll for draft-richardson-anima-jose-voucher (and others if need be)
Toerless Eckert wrote: > Working on IETF111 chair slides i just stumbled over one process step: > a) Dear authors of draft-richardson-anima-jose-voucher and ANIMA WG: > This is the IPR poll for draft-richardson-anima-jose-voucher > We need for each of you authors to make an IPR statement about the draft. "I am not aware of any IPR against this document" signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Cbor] Creating CBOR-based media types and content formats
>
>> https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-types.html
>
>> Comments and PRs very welcome.
>
> I did find reading it invoked a new appreciation for Arcane Wizardry.
>
> Specifically, I found that sections 3 and 4 didn't tell me anything that I
> recognized as important for filing in the template.
Right, Section 2 is the one that is collecting the information about
registration.
(Section 3 and 4 haven’t been written yet, anyway.
I thought it would be a good idea to get Section 2 out as input for the ANIMA
constrained voucher.
But it doesn’t discuss media type parameters yet, so it isn’t complete either.)
> "The Encoding considerations are often used in a way that is different from
> the intention in Section 4.8 of [RFC6838], which is a simple selection
> between "binary" and various alternatives that are now all obsolete. "
>
> so, really, it's always binary now?
Well, for CBOR-based protocols, yes.
If you have a JSON-based protocol that can only represent “true” and “false”,
this might qualify for “7bit”.
(But if that protocol ever needs to be extended to alternatively carry, say, a
number, you’d have to make a JSON-foreign rule of limiting the number to 999
characters, or you run into trouble with “7bit”.
Once you add strings that can contain more than just enumerated ASCII values,
you are solidly in binary land, as UTF-8 is “binary" in this selection.)
Here, the fact that MIME stands for Multimedia Internet *Mail* Extensions
(where “Mail” means SMTP) comes through.
(I think you briefly brushed into that history with RFC 7030 EST, which is
combining E-Mail Content-Transfer-Encoding with HTTP.
[Utterly amazing how this could clear the IESG.]
You fixed that in RFC 8951, without making it entirely clear that you changed
the meanings of the media types to now be base64-legacy, which by the way, with
the right line breaks, is 7-bit...)
> Maybe, just say that somewhere.
I thought I did, but I certainly can make it more obvious.
> I don't think you should hide the example in the appendix.
>
> Rather, I think that you should make it the core of the document, explaining
> each bit of arcana.
That sounds like a great project for long winter evenings at the fireside.
(Macintosh file type code(s)? Fragment identifier considerations?)
(I forgot to encapsulate the example in ~~~ wiggles so you can copy-paste.)
> If it's worth publishing this as a new RFC, then it's
> worth obsoleting RFC6838.
It has no normative intent (*) (and it doesn’t cover a tenth of 6838).
I do think that it will be worth publishing, after a lot of feedback has been
obtained from the people who actually have been around when the arcana were
invented.
I also think that the next update of 6838 might want to structure that template
in a more meaningful way.
> Otherwise, I suggest some nice HTML, maybe in the
> new-fangled single-hop-over-building wiki.
> ("Go big, or go home")
I think my parser is failing here.
Grüße, Carsten
(*) That is a lie: In fact, examples are always more normative than descriptive
text, frantic disclaimers notwithstanding.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
Esko Dijk wrote: > Agree, the content-format is stored as a single var-length uint in a > CoAP Option (not part of the fixed header but one of the optional > elements). >> Now, there is in the COSE header also a parameter paramaeter called "content type" > In my implementation I don't use the 'content type' header in COSE > because it is duplicate. The type is given at CoAP level already so > there is no ambiguity, so the "SHOULD" in RFC 8152 doesn't apply. Agreed. Also, we use CORE-SID encoding, which means that we essentially start off with a SID value that is unique to voucher (or voucher-request). Combined with the Content-format (which replaces the MIME-Type info in CoAP), it's pretty clear what we have. > We may mention in the draft not to use this 'content type' for > live-generated vouchers and voucher-requests. If the object is created > to be transported over other ways (e.g. email, USB stick, etc) then I > would opt for including that 'content type' possibly. Although the > filename (*.vch) in that case will indicate the exact media type. Yes! > For example my servers should also accept content-format 18 just as TBD3. Esko, do you think the draft needs to include this option? I prefer not to include. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
Toerless Eckert wrote: > I find it architecturally somewhat weird to have this "level skip": > Normally, if you have a container format, that container format itself > would have to indicate the type of its components, and you would not > need to or want to expose the type of any component outside of the > container. I find the eContentType business in SMIME insecure. It presuposes that there are very generic CMS decryption system in the OS which will be handing the inner contents to some OS-generic thing for display. But, in actual email use of SMIME, we actually have an inner Mime-Type there already. And I think, in almost all other cases, we wouldn't want to use a generic CMS decryption thing. So, I don't think of the COSE as a separate layer. It's not. The thing is a voucher, and vouchers are signed artifacts. Like protons. They contain YANG-serialized CBOR inside (like quarks) This stuff inside doesn't have an existence: you never get to mess with the quarks without knowing how they are contained. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] draft-ietf-anima-constrained-voucher COSE confusion
> >> Now, there is in the COSE header also a parameter paramaeter called "content >> type" > > In my implementation I don't use the 'content type' header in COSE because it > is duplicate. It is not: the REST-level (here CoAP) Content-Type is the media-type of the whole thing (as packaged in COSE-Sign1), while the COSE content-type is just the media-type of the payload. Except in somewhat unlikely cases, these are not the same. > For example my servers should also accept content-format 18 just as TBD3. No, no, no… You just created busywork for interoperability testing. Please decide for one option here and stick with that! Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Iotdir early review of draft-ietf-anima-constrained-voucher-12
Henk Birkholz via Datatracker wrote: > Reviewer: Henk Birkholz Thank you for this review! > (0) Title > The title implies that this document defines a message or document called > 'Constrained Voucher Artifacts' used in 'Bootstrapping Protocols'. The first > sentence contradicts this by saying 'This document defines a protocol'. This > "IETF'ler Human" also suspects that "Voucher Artifacts" are kind of redundant, > but that was okay in RFC8366 so that seems to be okay here. https://github.com/anima-wg/constrained-voucher/issues/132 The title reflects a history that thought we'd write two documents. > (1) Abstract > The abstract requires more (concise!) context and outline of the general > problem so that context-specific terms used can be easily understood, e.g., > 'Pledge' or its relationship to 'owner'. Imagine the abstract being the only > thing visible in a document indexing and management system and phrase it as > such. The "new" CoAP protocol defined seems to be a complement to an HTTPS > protocol, which the reader has to guess is defined either by RFC8366 or BRSKI > (this is cleared up early in the Intro). Why is it not CoAPS, if its complement > is HTTPS? Ultimately, you shall not use references in an abstract and that is > the root cause for this need for guessing here, I think. https://github.com/anima-wg/constrained-voucher/issues/133 > (2) Introduction > OSCORE and EDHOC are suddenly used and not introduced. > Terms, such as 'Pledge' or 'Registrar' could be better introduced or it should > be very clearly stated that this memo cannot be used without a clear > understanding of other documents (and which documents that exactly are and > why). It is not very clear to the reader why YANG and SID are suddenly > appearing here (which again becomes pretty obvious when you read other > documents). In general, the Intro requires more context. I've tacked this onto the issue: https://github.com/anima-wg/constrained-voucher/issues/124 > (3) Overview of Protocol > It is not immediately clear what 'proximity' means here (the term is not listed > in the Terminology section). A quick recap of roles and interactions would not > hurt, I think, but that can also be addressed by adding more contextual text to > the Intro. "Most Pledges using these constrained": maybe just remove the > "these" - it made me read it as a back-reference to time-based vouchers. The > term "pinned" used here could benefit a from a tad bit more expositional text - > it is a term relevant to a lot of security aspects in this memo and deserves a > proper introduction. https://github.com/anima-wg/constrained-voucher/issues/134 > (4) Discovery, URIs and Content Formats > Maybe an example of EST and BRSKI URIs helps the reader to see the > difference/optimization more easily? The terms URI and URL or both used in this > section. Are they used dedicatedly with their distinct meanings or are they > used interchangeably? Sometimes the term 'end point' is also spelled > 'end-point'. Why is there a fall-back (as MAY) to Content-Format 50 for the > shorter URLs? https://github.com/anima-wg/constrained-voucher/issues/135 > (5) Extensions to BRSKI > 'CoRE Link Format parsing' is suddenly used and it is not clear here in the > context why avoiding that is useful. I am not sure that 'reconnect' is the > appropriate term to use when writing about resources available via a single UDP > port. https://github.com/anima-wg/constrained-voucher/issues/136 Reconnect because DTLS might get renegotiated, because we might go from COAP to COAPS, and it's just extra round trips. > (6) Extensions to EST-coaps > The example '/sen' for simple enrollment is used here, but not really > introduced in the document. Is that intentionally so? Yes, because it's in draft-ietf-ace-est-coaps. https://github.com/anima-wg/constrained-voucher/issues/137 > (7) Pledge Extensions > '/att' is introduced here and it might not be obvious to a reader where that > comes from and what it exactly represents. Maybe a small example for "it MUST > use the Subject Distinguished Name fields from its IDevID unmodified." would > help here? Is '/crts' the short-name for '/cacerts'? So - in general, maybe > there should be a complete list of short-names used or are these intentionally > just used as examples? https://github.com/anima-wg/constrained-voucher/issues/138 > (8) Registrar Extensions > "for operational or security reasons" - that could be a topic for the TBD in > the Security Considerations. Agreed. > (9) BRSKI-MASA Protocol > Some of the consideration about "CoAPS for the BRSKI MASA is deemed > unrealistic" can probably also fuel the Security Considerations. https://github.com/anim
[Anima] [Technical Errata Reported] RFC8366 (6646)
The following errata report has been submitted for RFC8366,
"A Voucher Artifact for Bootstrapping Protocols".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6646
--
Type: Technical
Reported by: Aman Mangal
Section: 5.2
Original Text
-
{
"ietf-voucher:voucher": {
"created-on": "2016-10-07T19:31:42Z",
"expires-on": "2016-10-21T19:31:42Z",
"assertion": "verified",
"serial-number": "JADA123456789",
"idevid-issuer": "base64encodedvalue==",
"pinned-domain-cert": "base64encodedvalue==",
"domain-cert-revocation-checks": "true",
"last-renewal-date": "2017-10-07T19:31:42Z"
}
}
Corrected Text
--
{
"ietf-voucher:voucher": {
"created-on": "2016-10-07T19:31:42Z",
"expires-on": "2016-10-21T19:31:42Z",
"assertion": "verified",
"serial-number": "JADA123456789",
"idevid-issuer": "base64encodedvalue==",
"pinned-domain-cert": "base64encodedvalue==",
"domain-cert-revocation-checks": true,
"last-renewal-date": "2017-10-07T19:31:42Z"
}
}
Notes
-
domain-cert-revocation-checks is defined as boolean in the YANG specification
in section 5.3 of the same RFC 8366. Boolean value in JSON are represented
using true/false without the quotes.
Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--
RFC8366 (draft-ietf-anima-voucher-07)
--
Title : A Voucher Artifact for Bootstrapping Protocols
Publication Date: May 2018
Author(s) : K. Watsen, M. Richardson, M. Pritikin, T. Eckert
Category: PROPOSED STANDARD
Source : Autonomic Networking Integrated Model and Approach
Area: Operations and Management
Stream : IETF
Verifying Party : IESG
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] Argh?!: Re: draft-ietf-anima-constrained-voucher COSE confusion
On Thu, Jul 22, 2021 at 02:47:33AM +0200, Carsten Bormann wrote: > > > >> Now, there is in the COSE header also a parameter paramaeter called > >> "content type" > > > > In my implementation I don't use the 'content type' header in COSE because > > it is duplicate. > > It is not: the REST-level (here CoAP) Content-Type is the media-type of the > whole thing (as packaged in COSE-Sign1), while the COSE content-type is just > the media-type of the payload. > Except in somewhat unlikely cases, these are not the same. Argh! (as in: why was this not obvious to me until you said so...) So: if we wanted to support the COSE content-type field semantically correctly, we should ask for another registry entry: application/voucher-cbor TBD4 I can not find a single example with content type in https://github.com/cose-wg/Examples crazy.. Cheers Toerless > > For example my servers should also accept content-format 18 just as TBD3. > > No, no, no… You just created busywork for interoperability testing. > Please decide for one option here and stick with that! > > Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Authors/: IPR poll for draft-richardson-anima-jose-voucher (and others if need be)
Toerless Eckert wrote: > Working on IETF111 chair slides i just stumbled over one process step: > a) Dear authors of draft-richardson-anima-jose-voucher and ANIMA WG: > This is the IPR poll for draft-richardson-anima-jose-voucher > We need for each of you authors to make an IPR statement about the draft. "I am not aware of any IPR against this document" Best regards Thomas ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] constrained resources at root for debugging connectivity
Is there a way to use Olaf's "coap-client" to do the ping?
I don't see an option, and it also doesn't seem to be commonly built
with DTLS.
No, I have a three lines of code for doing a ping, from pledge; not from
coap_client
Peter
Michael Richardson schreef op 2021-07-21 21:36:
Esko Dijk wrote:
There is already a "CoAP ping" described in RFC 7252 that can be
used. It does not access any resource, just the CoAP server endpoint
at
CoAP message layer. As a side effect of this ping your DTLS stack will
set up the connection which is handy.
I recalled that later in the day that CoAP "ping" is not connected to
CoAP
"echo" :-)
I think that there is also potentially a need for a way to debug
possible MTU
issues.
Is there a way to use Olaf's "coap-client" to do the ping?
I don't see an option, and it also doesn't seem to be commonly built
with DTLS.
We also have the issue of CCM8 vs OpenSSL that I thought got solved,
but it
appears that it has not been, so one needs a tool built with mbedtls or
wolfSSL.
So I don't think we need a resource at / that produces 2.05 , this is
for the maintainer of the server to decide how to allocate that
resource space.
Besides we have already defined some well-known resources accessible
with GET ( in core/est/brski) that the client could make use of to
test
connectivity.
Even a non-existing resource in the /.well-known/X space could be used
just to get a 4.04 which confirms the server is working properly. This
is even better that trying to GET a resource of who knows how large
size.
BTW, I've changed my /version.json so that it now looks for and returns
the
client certificate that it saw:
curl
--cert spec/files/product/00-D0-E5-02-00-2E/device.crt
--key spec/files/product/00-D0-E5-02-00-2E/key.pem
https://masa.honeydukes.sandelman.ca/version.json
->
{"version":"1.1.0","revision":"582044cfc536fd295e8bdcd3b90f30453d7784d3","Hostname":"masa.honeydukes.sandelman.ca","client_certificate":"-BEGIN
CERTIFICATE-\nMIICBjCCAYugAwIBAgIEXKnlyDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB\nGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry\ndW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa\nMBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJlMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAEey+I0TtIhm8ivRJY36vF5ZRHs/IwhQWRc2Ql70rN+aYLZPOIXYc6\nZzlO62kDYBo3IPrcjkiPVnhoCosUBpTzbqOBhzCBhDAdBgNVHQ4EFgQU/g+KaX9o\nDEKY2K3NGe7Vr/9geDAwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S\nAaATDBEwMC1EMC1FNS0wMi0wMC0yRTArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l\neWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNpADBmAjEAuEwTKPMzS/Xm\nAhR4tFtDo3YHoPoBsaw/6UUYDHot4EoKy2L8AlriFzti/iNmH67/AjEAnRjH2R0T\n98DZjBIhz7W8LM52AeymMdCtsJyuDRjtVuncGEfMO/OWuFFx5qwYR63I\n-END
CERTIFICATE-\n"}
--
Michael Richardson. o O ( IPv6 IøT
consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
