Re: [Anima] Voucher RFC8366-bis: support for other types/encodings of certificates?

[Esko Dijk]

Forgot to mention: this thread is based on an open Github issue - 
https://github.com/anima-wg/constrained-voucher/issues/281 
This checks whether cBRSKI can be extended to new cert formats if those become 
popular. That seems ok, using either option 1 or 2.

> So either way we need to do something now in RFC8366-bis to avoid rolling
> that module again later on.

With option 2, we can adapt the RFC8366-bis YANG descriptions now, to prepare 
for new/other cert and key types in the future.
With option 1, we can just do nothing now but it would require an update of 
RFC8366-bis again for each new cert/key type that gets added.

So option 2 is some work (now). Certain YANG field descriptions need to be 
generalized to allow the (future) new key and cert types.

> Are you interested in it?
> Are you writing code?

For now and the coming year, I don't have any plans to use C509 certs or write 
code for it! If no-one has such plans, we can also decide to go for option 1.

> I was hoping (my head in the sand) you wouldn't bring this up :-)

I was digging in that sand too deep and found something :)  If we treat support 
for a new cert format (in the DTLS handshake, and in the Voucher) as simply a 
"new Voucher format" , we don't have to do anything special for this case.
Nothing on top of the things already defined now in 
draft-eckert-brski-discovery. The "new Voucher format" could even have its own 
media type to distinguish its use of different cert/key encoding.

Esko

-Original Message-
From: Michael Richardson  
Sent: Thursday, December 14, 2023 14:38
To: Esko Dijk ; anima@ietf.org
Subject: Re: [Anima] Voucher RFC8366-bis: support for other types/encodings of 
certificates?


Esko Dijk  wrote:
> How would the voucher / voucher-request best support such new
> certificate formats/types? Two main approaches are possible:

Yeah.
So either way we need to do something now in RFC8366-bis to avoid rolling
that module again later on.

> So with option (2) the existing fields just hold binary data of some
> format, by default it's X509/ASN.1 DER. If the "cert-type" field is
> present it identifies the format of binary data e.g. X509, C509, etc.

> If we do nothing now, we will default to option 1. TBH I'm not even
> sure if option 2 is feasible with current YANG definitions and all the
> legacy around it. But I still wanted to raise this question, just in
> case anyone's interested :-)

Are you interested in it?
Are you writing code?

> PS Also for discovery operations, discovering a Registrar that supports
> a particular (deviating) certificate type X may then be needed. This
> could be viewed as just a different type of Voucher that needs to be
> supported.

I was hoping (my head in the sand) you wouldn't bring this up :-)


--
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] Voucher RFC8366-bis: support for other types/encodings of certificates?

[Michael Richardson]

Esko Dijk  wrote:
> How would the voucher / voucher-request best support such new
> certificate formats/types? Two main approaches are possible:

Yeah.
So either way we need to do something now in RFC8366-bis to avoid rolling
that module again later on.

> So with option (2) the existing fields just hold binary data of some
> format, by default it's X509/ASN.1 DER. If the "cert-type" field is
> present it identifies the format of binary data e.g. X509, C509, etc.

> If we do nothing now, we will default to option 1. TBH I'm not even
> sure if option 2 is feasible with current YANG definitions and all the
> legacy around it. But I still wanted to raise this question, just in
> case anyone's interested :-)

Are you interested in it?
Are you writing code?

> PS Also for discovery operations, discovering a Registrar that supports
> a particular (deviating) certificate type X may then be needed. This
> could be viewed as just a different type of Voucher that needs to be
> supported.

I was hoping (my head in the sand) you wouldn't bring this up :-)


--
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

[Anima] Voucher RFC8366-bis: support for other types/encodings of certificates?

[Esko Dijk]

Here a question that came up, due to work in COSE WG to define a CBOR-encoded 
version of the X509 certificate: called "C509 certificate", see 
draft-ietf-cose-cbor-encoded-cert-07.

Possibly this new C509 certificate format, or other types may become desirable 
for BRSKI Pledges to use. In particular for constrained BRSKI (cBRSKI), where 
C509 can reduce the size of messages and/or codebase on the Pledge.

How would the voucher / voucher-request best support such new certificate 
formats/types? Two main approaches are possible:


  1.  Define new fields for the new certificate format in the YANG definition. 
So all of the fields that currently hold X509 format are "cloned" to fields for 
the new format: e.g. pinned-domain-cert, proximity-registrar-cert, 
pinned-domain-pubk, etc.
  2.  Re-use the existing fields for the new certificate format.  Add a single 
new field "cert-type" in YANG that has an integer denoting "certificate type". 
The int value could be taken from existing IANA registry 
(link)

So with option (2) the existing fields just hold binary data of some format, by 
default it's X509/ASN.1 DER. If the "cert-type" field is present it identifies 
the format of binary data e.g. X509, C509, etc.

If we do nothing now, we will default to option 1. TBH I'm not even sure if 
option 2 is feasible with current YANG definitions and all the legacy around 
it. But I still wanted to raise this question, just in case anyone's interested 
:-)

PS Also for discovery operations, discovering a Registrar that supports a 
particular (deviating) certificate type X may then be needed. This could be 
viewed as just a different type of Voucher that needs to be supported.

Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima