[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] 2.0.0-M6 release and plan for 2.0.0 ?
|
Hi,
> 1) I would like to release a 2.0.0-M6 release for californium.
> Do you have issues or PRs you want to see integrated in this milestones release ?
Though it's required to update leshan, my stuff (plugtest + android) can be easy moved to afterwards.
So no objection for 2.0.0-M6 from my side.
> 2) About the 2.0.0 plan :
> https://github.com/eclipse/californium/milestone/3
> I think #174 and #104 could be closed thx to Achim's great work.
> I see #173 is assign to Achim, do you have update about it ?
I updated the issue #173 with a comment. That issue is currently my most concern about the 2.0.0 release :-):
But right now I'm too busy to work on that, so I postponed my 2 cents ;-(.
> #442 seems already/almost done.
The library part of californium is done, but my changes (too many and too dirty right now) for cf-android are still open. But neither 2.0.0-M6 nor 2.0.0 should depend on that cf-android app.
> Personally, I would like to add
> https://github.com/eclipse/californium/issues/484 to the plan.
OK.
> Another point, I would like to explore : verifying how Scandium handle self-signed certificate.
> Last time I checked it does not really like it.
I'm not sure, which advantage a "self-signed x509 certificate" should have over a RPK, when using DTLS.
Is your intention to support a "clientside DTLS implementation", which doesn't offer RPK and therefore using such a "self-signed x509 certificate" is intended?
If so, what did you not like about the handling?
My experience (but only TLS):
Server side: if the client's self-signed certs are added to the servers trusts, the "certificate_authorities" may get beasty large. Therefore I implemented a special X509ExtendedTrustManager, which returns an empty list for AcceptedIssuers, because according RFC5246, 7.4.4, page 54,
"the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary:"
That empty list shrinks the handshake data. It works, if that list is not required to select the right client cert to be used.
Scandium, as far as I understood, also sends that "certificate_authorities". Maybe adding some configuration to also use an empty list for that "certificate_authorities" in DTLS may improve the support for self-signed certs.
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Dienstag, 28. November 2017 16:16
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: [cf-dev] 2.0.0-M6 release and plan for 2.0.0 ?
Hi,
1) I would like to release a 2.0.0-M6 release for californium.
Do you have issues or PRs you want to see integrated in this milestones release ?
2) About the 2.0.0 plan :
https://github.com/eclipse/californium/milestone/3
I think #174 and #104 could be closed thx to Achim's great work.
I see #173 is assign to Achim, do you have update about it ?
#442 seems already/almost done.
Personally, I would like to add
https://github.com/eclipse/californium/issues/484 to the plan.
Another point, I would like to explore : verifying how Scandium handle self-signed certificate. Last time I checked it does not really like it.
Simon
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev
