The new definition at https://tools.ietf.org/html/rfc5958 shows,
OneAsymmetricKey ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKeyPrivateKey,
attributes[0] Attributes O
On Mon, May 25, 2020 at 3:15 AM Michael Osipov <1983-01...@gmx.net> wrote:
[...]
> So I read the discussions. RFC 2744 shall not be changed, people
> admitted that the spec of SASL GS2 mechs is wrong and should be changed,
> but this has not happened yet. It remained at UNSPEC all the years.
>
> S
Hello Michael, Thomas,
Thank you a lot for review and suggestions.
I’ve fixed most of the issues except of fundamental one
I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype.
Updated webrev is available at:
http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/
Also
I find the duplication of parsing code annoyed. I'll see if I can consolidate
them into one.
--Max
> On May 20, 2020, at 1:37 PM, Valerie Peng wrote:
>
>
> True, the current handling of the extra bytes in parseKey() and decode() are
> kind of opposite, one does not allow any extra bytes but
Am 2020-05-24 um 22:29 schrieb Thomas Maslen:
[Off-list reply just to you two gents. Feel free to forward it to the list
if it helps, or ignore it if it doesn't]
I'm just adding my 0.02 on zero vs 255 for the "no address" type in a
channel binding
-- Forwarded message --
From:
