►
From YouTube: COSE WG Interim Meeting, 2021-01-20
Description
COSE WG Interim Meeting, 2021-01-20
A
We
should
be
recording
now
so
hello,
everyone
and
happy
new
year.
This
is
a
code
interim
meeting.
This
is
an
official
itf
meeting
as
such
the
noteworld
applies.
A
A
A
A
So,
moving
on
to
our
document
status,
we
have
the
cash
alex
8152
beast,
alex
already
near
fcq
with
a
missing
reference,
and
that
is
the
same
as
it
was
during
the
previous
meeting
for
the
eighth
150
to
be
struck.
I
believe
matthew
has
made
maybe
all
the
changes,
or
at
least
most
of
them,
and
I
believe
they
are
discussing
with
ben.
If
there
is
anything
else
that
needs
to
be
changed.
A
Next
one
we
are
scheduled
for
the
x
509,
we
are
scheduled
for
the
telechat
tomorrow.
A
I
don't
know
if
there
is
any
new
thing
for
me
to
say
here
about
that.
I
believe,
and
all
the
members
of
the
iesg
have
no
objections
now
for
the
draft.
A
So,
yes,
that's,
maybe
the
most
important
part
here.
The
only
thing
that
maybe
we
should
and
briefly
discuss
is
there
are
examples
already
provided
by
jonathan,
maybe
to
be
good
to
reference,
those
in
the
draft.
I
imagine
this
should
be
an
editorial
change,
given
that
examples
are
not
normative
texts,
they
are
informative
and,
yes,
I
imagine
this
should
be
like
editorial
change.
B
A
Yes,
so
the
open
issues
in
github,
so
my
understanding
is
that
we
need
to
improve
the
wording
and
provide
a
little
bit
of
explanations.
Why,
for
example,
the
x5u
parameter.
C
D
E
E
B
E
But
yeah,
so
this
is
actually
the
second
time
that
cozy
x509
has
been
on
the
agenda
for
the
isg.
So
most
of
us
have
looked
at
it
quite
extensively
already
and
it
should
be
fairly
straightforward,
but
I
will
definitely
check
the
github
issues.
B
Yeah
I
mean
I
basically
think
jose
is
basically
trying
to
x59
is
trying
to
solve
the
same
problem
that
jws
is
trying
to
solve.
So
the
big
question
is:
why
is
any
of
this
different
from
jws
and
if,
if,
if
you
either
believe
it's
the
same
problem,
you
you
believe
it's
not
the
same
problem
or
there
is
in
which
case.
Maybe
it
should
be
the
same,
and
if
it's,
if
it's
not
the
same
either
you
should
make
it
the
same
or
file
errata
against
jws.
F
Counter
arguments,
michael,
the
counter
argument
is
that
jws
is
something
that
we
aspire
to
move
to,
but
requires
an
ecosystem
revolution,
and
the
compressed
x-509
in
theory
is,
can
be
done
with
in
a
more
of
a
fax
effect
kind
of
thing.
Incrementally
this
is.
F
B
I
mean
we
did
add
x5
bag,
which
jw
s
doesn't
have.
So
that
is
one
variant
but
variation,
but
I'm
not
sure
if
I
think
x5
bag
is
all
that
important,
but
anyways.
B
H
Yeah
my
take
on
this
would
be
that
jws
was
around
when
when
this
work
was
done,
so
we
actually
had
a
chance
to
learn
from
that
and
yeah
jim
jim
actually
tried
to
learn
from
that,
and
that's
why
coz
509
is
different
in
some
detail.
H
So
maybe
it's
a
good
idea
to
document
these
learnings
a
little
bit
better.
So
it's
easier
to
understand
why
x509
cozy
x59
is
different
from
what
jws
says.
E
H
Well,
I
think
that
document
would
be
most
worth
a
while
if
it
actually
had
first
experience
from
using
cosex
509
as
well.
So
I
I
actually
think
it
would
be
good
to
have
that
as
a
separate
document.
But
that,
of
course
makes
understanding
the
document
at
the
moment
and
why
why
it's
a
little
bit
different
from
the
jws
one
is
harder
than
it
could
be.
E
A
Okay,
so,
okay,
then
I
will
wait
for
also
ben
to
see
the
issues
in
github
and
yeah,
basically,
depending
on
that
see,
if
I
just
need
to
improve
a
little
bit,
the
explanations
like
having
some
editorial
changes,
so
it's
really
more
important
to
have
some
substantial
changes
here.
A
A
There
was
the
working
group
last
call.
I
didn't
see
any
objections
to
that
and
I
believe
during
the
last
meeting
there
was
some
support
for
its
being
ready
from
this
working
group's
point
of
view.
A
C
Hi
this
is
jonathan
hamill,
so
I
I
raised
an
issue
on
the
list
about
the
status
of
the
early
code
point
allocation.
A
We
were
supposed
to
look
at
that
with
matthew,
how
we
still
haven't
done
that,
but
we
should
be
doing
it
very
soon.
I
hope-
and
my
understanding
is
that
this
is
an
issue
just
in
terms
of
the
examples
and
as
such
had
like
worst
cases
that
we
will
need
to
fix
the
examples,
or
do
you
see
any
other
problems
that
could
arise.
A
A
A
I
Thank
you
so
I
will
this
will
be
two
presentations.
I
will
discuss
the
changes
and
planned
updates
for
the
next
version
and
then
we'll
discuss
issues
so
next
slide
and
we
submitted
the
version
zero.
Six
yesterday,
yeah
next,
so
changes
from
zero
five
to
zero.
Six.
A
lot
of
these
are
actually
things
that
were
presented
at
the
last
interim
as
planned
updates,
and
then
we
have
done
that.
So
we
have
mentioned
more
certificate
profiles.
I
I
Based
on
that,
we
see
that
there
are
some
strange
extensions
and
there
are
definitely
quite
a
lot
of
attributes.
So
we
have
introduced
the
possibility
to
encode
attributes
as
a
oid
and
raw
their
string
to
be
able
to
compress
everything
out.
There
then
also
noted
that,
basically,
all
certificates
on
the
web
web
have
a
single
attribute
per
relative,
distinguished
name.
I
I
I
They
have
changed
and
simplified
the
algorithm
registry,
so
it
now
in
code,
it's
a
in
for
the
whole
algorithm
identifier,
including
parameters.
Instead
of
only
being
an
int
associated
with
the
oid,
then
we
notice
that
the
signature
value
encoding
for
ecdsa
did
not
work.
I
There
was
a
mathematical
formula
previously,
but
we
noticed
that
that
actually
implied
that
you
knew
the
issue
public
key,
which
you
typically
don't.
If
you
process
a
single
certificate,
but
we
found
out
that
could
actually
simplify
this
and
make
it
better.
So
now
the
rule
is
instead,
instead
of
padding
to
a
fixed
length,
you
just
pad
two.
So
both
the
integrals
have
the
same
length
which
is
actually
simpler.
Then
we
changed
from
sadly
to
broccoli,
for
the
comparison
table
probably
provides
a
little
bit
better
and
faster
compression.
I
We
wanted
to
compare
with
the
best
we
have
significantly
restructured
iana
table
to
make
them
easier
to
understand
and
better
so
now
they
have
the
default
yd
and
their
encode
of
the
what
they
encode
and
so
on,
and
better
also,
some
more
information,
better
structure
and
more
information,
and
there
was
a
request
to
use
these
the
example
certificates
for
ad
hook
and
that
required
a
private
subject.
Private
key,
that's
now
added
the
the
asn.n
one
was
hopelessly
outdated.
I
I
I
So
this
are
the
current
plans
for
zero
seven.
We
want
to
have
an
example.
I
e
certificate,
which
michael
has
promised
to
provide
in
january.
Then
we,
it
was
a
request
from
some
more
deployment
guidance
for
iot,
basically,
some
guidance
on
what
different
choices
lead
to
which
sizes
and
so
on.
I
Then
we
are
planning
to
use
the
tool
we
have
to
download
a
lot
of
tls
certificates
and
or
certificate
change
exchange
and
try
to
compress
them
to
see
that
the
algorithm
work,
those
known
collection
of
urls,
the
most
popular
is
alexa,
but
that
alexa
million.
I
guess
it's
called,
but
that's
now
it's
not
free
anymore.
I
Then
there
are
some
specifications
left
for
the
extensions
plan
to
for
some
of
the
extensions.
We
definitely
support
like
the
full
extension
for
some
other.
We
might
support
a
subset
based
on
how
complex
the
extension
is
and
what
we
see
is
actually
used
on
the
web.
I
At
least
that's
the
plan
yeah
and
that
is
planned
to
be
done
in
zero.
Seven,
then
we
plan
to
do
comparison
with
broccoli
for
for
tls
chains,
so
we
plan
to
take
some
example
chains,
for
example,
from
tools.idf
and
then
compare
the
dersha
and
the
c
percent
there,
plus
broccoli
and
c
burp,
plus
broccoli
and
yeah-
that
we
also
hope
to
have
maybe
in
zero,
seven
or.
I
Any
comments
that
are
next,
then
some
we,
while
working
starting
to
look
at
chains.
We
see
that
there's,
of
course,
quite
a
lot
of
duplicated
data
when
you
start
with
chains.
I
Mainly,
the
issue
field
is
duplication
of
a
subject
field
in
typically
the
next
certificate,
or
if
it's
a
self-issued
certificate
in
the
same
certificate
and
very
similar
with
the
key
identifiers.
The
authority
key
identifier,
is
just
the
duplicate
of
the
subject:
key
identifier
in
another
certificate
and
for
self-issued
certificates,
which
seem
to
be
actually
quite
common.
That
tls
servers
send.
Then
you
might
also
have
another
authority,
cert
issue,
key
identifier,
so
basically
the
subject
field
is
duplicated
three
times
in
the
same
certificate.
I
Yes,
the
note
that
this
could
this
could
definitely
be
compressed
and
kerstenburg
right
here
that
seaboard
pack
might
help
with
that's
probably
a
good
idea.
I
have
not
thought
about
that.
Yes,.
F
So
you're
talking
about
compression
here
across
certificates,
yes
and
and
to
my
reading,
we
haven't
done
anything
about
that
and
I
don't
really
know.
I
would
agree
with
you
that
seabor
pack
might
be
the
right
answer
to
do
that
for
that.
But
then
I
think
we
also
need
to
ask
the
question
how
long
the
chains?
F
What
are
these
chains,
where
are
they
used?
How
long
are
they-
and
I
I
I
they
could
be
quite
there
and
carson
just
had
a
comment
in
the
chat
which
I
agree
with
and
we
could
define
a
profile
of
it,
but
I
I
don't
know
we
haven't
really
made
a
lot
of
progress
on
that
lately.
Have
we.
H
No,
the
the
problem
really
is
that
it's
extremely
hard
to
define
a
zebra
pact
without
having
a
good
set
of
use
cases
in
mind
and
given
that
this
is
a
use
case
that
we
actually
reasonably
understand
and
that
we
actually
can
get
corpuses
from
that
we
can
run
experiments
on.
It
seems
to
me
that
that
the
the
basic
approach
of
zero
pack
to
have
a
base
document
that
defines
mechanisms
and
then
then
specific
documents
that
define
how
to
use
these
mechanisms
in
a
specific
environment
that
would
actually
work
very
well.
H
H
So
that's
another
way
to
to
develop
super
pic
to
integrate
the
the
table
building
or
the
static
dictionary
building
with
environments
that
can
make
use
of
that.
F
Carson
also
there's
the
issue.
If,
if
if
we
are
we're
primarily
dealing
with
compression
of
chains
of
certificates,
then
I
would
actually
want
to
say
what
happens
if
we
just
take.
We
just
take
some
simple
sibor
representation
of
the
certificates
without
doing
a
lot
of
of
the
optimization
we're
doing
right
now
and
applied
seabor
pact
to
it
right,
it
might
actually
be
simpler
than
some
of
the
things
we're
doing,
but
but
if,
in
the
degenerate
case
of
one
certificate,
that
gains
us
nothing
right.
F
H
F
I
I
As
I
said,
the
savings
for
self-issued
certificates
are
even
bigger
benefits
of
doing
something
like
this
is
that
you
provide
large
savings.
Negative.
Is
that
you
provide
extra
if
even
both
this
and
see
where
your
extra
complexity
and
the
the
compression
of
the,
if
you
use
it
for
compression
it
becomes
two
paths
you
need
to
pass
over
everything
twice
and
for
for
the
tl
when
used
in
theories
where
you
already
have
broccoli
compression.
Basically,
this
this
would
achieve
basically
similar
things.
I
A
So
just
a
question
for
the
last
flight
and
figure
that
you
provide
and
they're
when
using
completely
or
what
are
they
exactly
for
and.
I
I
B
So
this
is
lawrence
lundblade.
I
was
a
question
of
if
you
have
any
comments
about
certificate,
size
versus
code
size
and
seems
like
there's
a
number
of
things
they're
being
proposed
here
that
reduce
the
certificate
size,
but
it
will
that
will
increase
code
size
and
I
I
I'm
mostly
asking
just
like.
If
there's
you
know
been
thinking
about
the
use
cases-
and
you
know-
is
code
size,
an
issue
yeah.
I
B
I
I
think
we
need
to,
I
think,
that's
something
we
should
consider.
I
think
the
specification
is
not
set
in
stone.
It
would
be
very
good
to
hear
feedback
that
this
only
gives
one
byte
optimization,
but
it
uses
a
lot
of
code.
I
think
we
should
skip
this
yeah,
but
I
think
it's
also
depends
on
what
assumption
you
have.
If
you,
your
assumption
is
that
you
have
c
more
packed,
then
maybe
your
code
size
is
not
increasing
very
much
yeah.
B
B
A
So,
do
you
have
any
ideas,
how
we
can
try
to
evaluate
the
different.
I
I
don't
know
one
step
would
be
to
depends
on
what
we
do.
I
think
you
could
get
numbers
for.
I
could
we
will.
We
will
look
at
change
to
the
next
version,
so
I
can
at
least
provide
example,
change
and
example,
sizes
and
compare
with
with
what
you
get
when
you
get
broccoli,
compression
and
so
on.
Then
me
or
someone
else
need
to
look
at
the
sea
seaboard
pack.
A
Okay,
so
if
there
are
no
other
comments,
we
can
go
on
to
the
next
presentation.
B
B
D
I
mean
there
were
a
number
of
pros
and
cons
lifted.
I
tried.
B
So
the
the
the
there's
yeah
there's
two
issues
with
byte
string.
Wrapping
one
was
what
you
hash
and
that's
we
had
some
previous
discussion
about
that.
This
is
a
separate
issue.
This
is
about
whether
the
overall
compressed
certificate
is
a
seaward
sequence
like
it
is
now
or
it
turns
into
a
data
item
you
know,
and
if
it
stands
as
a
sea
war
sequence,
you
can't
just
drop
a
sequel
sequence
into
another
seaboard
protocol
you
have
to
because
it
just
would
it
doesn't
work.
B
It
can
confuse
the
decoders,
so
you
have
to
wrap
it
in
a
in
a
byte
string.
So
that's
the
second
issue
is
this:
should
this
be
a
data
item
or
should
it
remain
a
seabor
sequence
and
the
you
know
the
implications
for
you
know
putting
it
in
another
in
another
seaboard
protocol?
B
Yeah
yeah,
you
can
wrap
it.
We
you
either
wrap
it
with
an
array
or
you
wrap
it.
In
a
byte
string
and
like
with
the
cose
x,
509
headers,
unlike
x5
or
c5
c5t
c5
chain,
there
is
byte
string
wrapping
there
so
that
that
all
works,
but
anyway
we
don't
have
to
go
into
it.
Now.
I
just
wanted
to
to
see
if
anybody
read
the
email
and
I'll
I'll
resend
it.
D
A
D
Presentation:
okay,
duran
salander,
I'm
going
to
talk
about
some
of
the
issues
next
slide.
Please.
D
If
you
haven't
seen
it
and
that's
mainly
in
terms
of
the
number
of
issues,
it's
mainly
issues
regarding
things
we
think
are
necessary
to
do
or
the
comments
that
we
we
track,
but
there
are
also
I
mean
this
is
open
for
for
anyone
to
to
comment
and
add
issues.
Please
please
use
that
and
hopefully
we'll
get
adopted
at
some
point
and
then
we'll
move
this
to
to
the
cozy
working
group
issue
tracker.
D
D
Here's
the
first
and
that's
this
is
a
request
to
specify
zebra
encoding
of
certificate
signing
request.
So
this
was
this
particular
issue
was
posted
by
stefan
ristisol,
who
may
be
on
the
call
now.
D
Yes,
I
see
him
here
so
yes,
great
great,
if
you're
here,
stefan
I'll,
ask
you
in
a
minute
to
to
motivate
this,
but
just
to
say
that
this
is.
We
have
got
this
request
previously
also,
and
there
is
already
a
first
sketch
for
how
to
do
this,
but
first
stephen,
would
you
like
to
just
provide
motivate
why
you
think
this
is
useful
and
what's
your
use
case
so.
G
We
worked
on
ad
hoc
implementation
and
we
wanted
to
use
ad
hoc
with
cbor
encoded
certificates
and
for
that
reason
we
need
such
certificates
from
somewhere,
and
I
read
the
documentation.
I
read
the
draft
and
I
noticed
that
that
that's
not
specified
so
I
mean
certificate.
Signing
requests
are
not
specified,
and
I
think
this
is
important
in
the
iot
environment,
especially
for
devices
which
may
use
ad
hoc
to
generate
certificate,
signing
requests
and
yeah.
So
that
was
the
motivation
for
posting.
My
issue.
D
Okay
thanks,
so
I
I
mean
I
agree
with
stefan.
I
think
this
is
a
good
motivation.
This
has
been
actually
requested
for
people
that
are
trying
to
use
tls
as
well.
D
So
it's,
I
think
the
idea
is
that
you,
you
would
have
sort
of
the
same
type
of
encoding
of
of
of
the
different
certificate
related
items,
but
anyway
there
is
a
first
sketch,
and
the
question
here
in
the
issue
is
basically
is
this:
something
that
we
should
try
to
align
with
or
even
take
over
in
cozy.
D
So
this
first
sketch
is
in
a
draft
on
enrollment
using
using
est
with
all
score,
and
this
is
an
appendix-
and
we
note
that
this
this
format
is
is
the
first
is
the
first
sketch
really
of
of
what.
So.
There
are
some
examples
here
of
things
that
we
would
like
to
to
have
in
in
in
the
csr
like
subject:
public
key
algorithm
or
encoding
of
attributes
in
specifying
extension
requests,
and
that
so
that's
things
that
we
already
define
for
seaboard
certificates,
so
it
makes
sense
to
align
them
and
yeah.
D
So
the
question
is:
is
this
something
that
we
think
that
the
we
should
work
on
in
cosi?
Or
should
we
just
hope
that
ace
will
adopt
this
and
that
they
will
travel
somehow
in
parallel?
D
We
have
the
fortune
that
one
of
the
authors
of
the
seaboard
certificate
draft
is
actually
the
contributor
of
this.
This
particular
example
here,
so
we
could.
We
are
free
to
take
this
example
and
move
it
out
of
that
draft
and
put
it
into
this
draft
or
a
separate
cozy
draft.
H
I
think
it's
good
to
to
actually
evolve
these
in
parallel,
so
I
think
we
should
keep
a
very
close
eye
on
this
and
probably
the
the
easiest
way
to
keep
a
close
eye
on
it
would
be
to
do
it
in
the
same
document
if
it
turns
out
to
be
difficult
to
do
that,
we
can
always
extract
it
into
a
separate
document
later.
E
D
D
D
D
If
you
have
none
proof
of
possession
algorithms
by
by
jim
shot
and
hemapraphal
chandra,
I
think
now
the
basic
idea
is
we
replace
the
signature
in
the
csr
with
a
mac
and
generated
by
a
with
a
mac
computer
with
a
key
which
is
computed
with
the
shared
secret
using
the
different
health
monkeys
of
the
requesting
endpoint
and
the
ca,
and
it's
described
in
section
six
of
this
rfc.
It's
pretty
straightforward
and
there
are
advantages
with
using
this.
That
would
be,
the
csr
will
be
smaller,
which
is
I
mean.
D
The
mac
instead
of
the
signatures
is
a
good
good
reason
why
to
use
the
addictive
common
keys,
but
it
also
requires
the
requester
to
have
access
to
the
static
detail,
monkey
of
the
ca,
and
then
there
are
different
variants
of
of
acquiring
the
acquiring
the
ca
development.
Key
this
could
be
part
of
the
enrollment
functionality,
so,
for
example,
in
esd
you
could
use
various
of
these
different
functions
to
acquire
trust
anchors.
D
So
well
same
question
here:
do
you
think
that
we
should
specify
also
this
in
in
same
draft
or
should
we
does
this
motivate
that
we
should
actually
put
all
the
csr
related
stuff
in
a
separate
draft.
D
Okay,
I
don't
hear
any
objection
or
any
preference
for
doing
this
in
a
separate
draft,
so
the
working
assumption
here
is
that
we,
yes,
we
try
to
do
this.
G
Next
slide,
please
just
a
second.
I
have
one
question
regarding
this
issue
and
namely
so
this
means
that
the
ca
also
authenticates
with
static
difficulty
right.
G
D
Yeah,
so
so
it
prints,
I'm
not
just
speaking
in
principle,
and
I
don't
know
exactly
how
to
signal
this
or
to
how
to
set
it
up.
But
but
this
this,
the
enrollment
request
requires
one
trust
anchor
for
to
be
able,
in
this
case,
to
be
able
to
generate
the
shared
secret
and
commute
and
the
mac
and
so
on.
D
But
the
certificate
coming
back.
The
enrolled
certificate
could
be
signed
with
with
another
key
with
the
signature
key
of
the
ca.
So
there
might
be
multiple
trust
anchors.
D
G
Do
I
trust
anchors
must
be
there.
D
D
A
D
D
E
Yeah
I'm
in
a
similar
boat.
We
should
definitely
have
some
way
to
convey
revocation
information,
but
we
can
take
some
time
to
think
about
which
ones
actually
make
sense
in
this
format.
D
I
don't
think
we
need
to
spend
much
time
time
on
this,
but
since
this
was
an
issue
and
now
looking
very
simply
at
carson
what
should
be
the
file
extension
for
for
these?
These
objects,
the
seaboard
certificate
and
the
zebra
encoded
variants.
Here,
maybe
we
should,
if
you
have
a
good
opinion,
maybe
you
could
just
fill
in
the
the
issue.
Make
a
comment
on
the
issue
on
this:
do
you
think
it's
something
worth
bringing
up
here
or
anyone
else,
of
course,
who
find
this
interesting.
F
I
was
recently
trying
to
do
a
I'm
encoding,
something
in
cbor
somewhat
internally.
That
sometimes
makes
it
to
disk,
and
I
wouldn't
mind
having
a-
and
I
think-
and
I
previously
had
a
magic
number
at
the
beginning
of
the
file
when
it
was
bespoke
encoded,
and
so
I'm
actually
thinking
about
how
to
do
this
in
a
standard
way
in
seabor
and
so
actually
that
certificate
it
would
be
useful
to.
F
It
would
actually
be
worth
thinking
about
whether
we
should
the
file
format
actually,
maybe
should
be
a
sebor
sequence,
with
the
second
sequence
being
the
certificate
and
the
first
one,
just
being
a
magic
number
that
can
be
thrown
away
when
you
transfer
it
across
the
wire
or
something
like
that.
But
I
think
that's
actually
kind
of
something
reasonable,
because
if
it
is
stored
on
disk
knowing
which
what
thing
you
need
to
it,
you
it
goes
with
and
other
stuff
like
that
is
actually
kind
of
really
useful.
In
the
end,
great.
F
D
Are
knowledgeable
in
this
and
then
see
the
I
know
the
practical
implications.
Please
please
provide
some
answer
here
or
or
maybe
we
should
even
ping
the
seaboard
working
group
for
thinking
about
this
unless
they
are
doing
it
already
so
just
to
wrap
up.
There
is
a
final
point.
Final
slide.
This
last
slide
just
a
reminder,
michael
you
kindly
volunteered
to
provide
an
example
looking
forward
to
that
thanks
and
now
for
the
chartered.
D
So
there
was
an
interest
in
in
looking
at
seabor
encodings
of
things
related
to
certificates,
namely
csrs.
Something
related
to
certificates
was
that
it
csrs
and
something
related
to
certificate.
Yes,
yes,
exactly
sorry,
revocation
something
related
to
revocation,
so
maybe
something
like
that
should
be
added
to
the
charter.
If
we
think
that
is
the
right
way
to
go.
A
Good
okay,
so
it
seems
to
me
that
there
are
people
who
consider
this
interesting
and
so
far
there
is
no
one
opposing.
D
Okay,
fine
karsten
also
posted
the
comment
on
the
on
the
charter,
which
I
commented
on
and
it's
in
the
chat,
and
I
could
add
that
at
the
same
time,
when
I'm
making
a
proposal
for
update
of
the
charter.