►
From YouTube: WG-KMS Bi-Weekly Meeting for 20220322
Description
WG-KMS Bi-Weekly Meeting for 20220322
A
B
A
A
B
A
Is
a
good
name,
I
should
steal
it,
you
can
it's
it's
effectively
a
dead
project,
but
you're
welcome
to
take
it.
It's
a
better
name
than
whatever
the
original
so
yeah
I
mean.
If
we
want
you
know
we
can.
We
can
spend
some
time
making
issues
if
that
folks
folks
want
to
work
on
that
together.
Real
quick,
get
an
idea
of
what's
what's
what's
left
right
so
like,
if
we
think
about
it.
So
what's
the
current
state
of
their
reporter
stuff,
I
think.
B
B
We
have
two
layers
of
kegs,
but,
for
example,
I
did
I'm
not
sure
if
I'm
using
yet
the
new
model
that
anish
did
with
the
with
the
new
version
two
alpha
one
on
the
grp
cesar,
but
I
also
I
there
is
some
kind
of
gopc
listening
to
the
unix
socket,
but
I
don't
know
if
it's
using
the
right
model
and
it's
kind
of
yeah.
I
have
baked.
A
C
Yeah
one
question
was
that
in
terms
the
structure
for
this
repo,
so
I
think
there
are
two
things
right
like
one
is
obviously
the
key
generation
part
of
it
and
then
the
one
in
my
poc
was
using
the
crypto
library
which
is
very
similar
to
what
the
api
server
does
and
then
the
second
piece
is
the
encryption
part
of
it
so,
but
which
is
very
similar
to
what
citadel
has.
So
that's
what
I
took
tried
the
aacbc,
I
think
for
the
key
generation.
A
A
A
C
A
A
So
that
way,
when
you
observe
their
data
later,
you
are
not
like
you
understand
that
it
was
you
that
did
it
and
you
did
it
in
this
way.
So
that
way,
if
we
do
want
to
add
flexibility,
it's
not
like
this
implicit
like.
Oh,
I
don't
know
what
this
is
so
I'll
assume
it's
a
sdcm
instead
of
being
like
well,
I
know
it's
gcm
because
I
wrote
it
down.
C
A
C
B
So
currently
there
is,
there
is
a
local
cac,
it
is
asgcm
with
128
bits
of
keys
and
it
has
rotation.
It
has
kind
of
a
max
encryption
counter,
and
the
only
thing
that's
not
solved
is
how
to
start
right
so
because
this
was
where
I
was
not
sure,
and
then
I've
seen
that
anish
added
this
key
to
the
to
the
proto.
So
this
is
something
that
is
still
missing
so
so
the
thing
library
gives
you
like
rotation
and
a
lot
of
additional
benefits,
and
it
has
also
protobuf.
B
So
when
you
want
to
store
the
encrypted
keck
it,
you
can
immediately
put
it
into
bytes
and
encrypted
bytes
and
set
it
along
in
the
in
the
protobuf.
But
the
question
is:
are
we
find
that
thing
handles
nearly
everything
and
we
just
completely
trust
the
library
or
do
we
want
to
see
if
we
can
encode
additional
information
on
top
of
it?
Because
then
we
start
to
think
we
think
in
ways
where
it
might
lose
itself
with
its
benefits.
A
A
A
C
So
the
upstream
key
vault
is,
I
think,
fine,
which
is
very
similar
to
what
we
today
do
today
right
like
today,
just
encrypting
the
deck
using
the
kms
plugin,
like
azure
keyword.
We
have
no
control
over
how
it
encrypts
it
so
the
encryption
of
local
keck
using
the
api
server
we
won't
have
control,
so
the
encryption
of
deck
using
the
local
keck
will
be
with
areas
gcm.
C
A
A
A
I
don't
know
if
you
want
to
use
the
word
upstream
famous,
but
that's
what
I
got
right
now,
so
I
think
you're
not
at
kristoff.
Your
question
is,
I
think,
is
related
to
item
number
two,
which
is
the
management
of
this
local
kick
roughly,
I
think,
is
what
it
comes
down
to
us.
If
we,
if
we
use
kink,
I
think,
are
we.
I
guess
how:
how
strong
is
that
library's
opinions
and
how
this
is
done?
Is
there?
B
B
B
B
Okay,
so
they
have
so.
This
is
their
very
strong
opinions.
What
they
let
the
users
do,
so
they
don't
want
the
user
to
shoot
in
the
hand
in
the
foot.
So
basically
they
have
several
abstraction
layers.
For
example,
we
have
the
the
key
handle,
which
basically
is,
is
just
a
high-level
measure
which
enables
you
to
so.
They
have
also
the
so
hand,
has
basically
a
key
set.
B
B
Is
this
is
google
think
just
to
give
you
to
give
you
an
overview
of
google?
Think,
oh
okay!
So
this
is
this
is
not
code.
We
can
change
this,
the
only
code
we
can
consume.
Yes
exactly
this
is
this
is
why
I
said,
depending
on
on
how
how
much
flexibility
we
want.
It
might
be
a
d
breaker
for
us
right
and
and
the
new
handle
basically
says
it-
gives
you
the
methodology
to
read
the
keck
so
it
for
us.
B
B
Question
where
was
it
yeah?
I
had
the
key
templates
so
let's
see
as
gcm
key
template
yeah.
So
basically
they
choose
the
key
size,
a
prefix,
to
identify
the
key.
I
would
say
and
underneath
that
when
we
go
down,
we
see
that
here
we
have
the
proto
the
muscles
in
it
in
the
protobuf
yeah.
So
it's
basically
just
predefining
a
couple
of
things.
But
when
you
go
down
to
the
subtle
thing,
where
actually
encryption
happens,
you
see
that
they
use
the
native
libraries.
B
A
B
B
So
when
you
write
you,
you
give
the
the
from
the
upstream
kms
you
would
give.
You
also
need
to
give
some
kind
of
key
set.
So
we
would
need
to
bridge
this
somehow,
but
this
should
be
trivial
because
they
have
the
kms
implementation
already,
at
least
for
google
right,
and
I
think,
for
aws
and
for
microsoft
they
were
missing.
So
this
is
somewhere
in
the
code
already
how
to
do
this,
how
to
bridge
this
and
then
basically
they've
write
it
right.
B
Where,
where
they
marshal
is
so
for
us,
it
would
be
more
or
less
opaque
binary
and
would
completely
delegate
the
the
cryptographic
logic
more
or
less
to
the
think
library-
and
this
is
like
the
question:
if
this
is
sufficient-
or
I
said
no-
we
want
to
have
more
fine-grained
control.
Then
we
would
need
to
look
in
how
we
can
break
it
up.
A
Yeah,
I
guess
in
my
head.
What
I
had
imagined
is
what
we
were
this
is
you
know
none
of
these
opinions
are
strongly
held.
This
is
just
like
how
I'd
imagined
it
is.
What
we
could
do
is
in
this
v2
alpha
1
api
right
that
we
would
we
would
basically,
you
know,
still
have
encryption
and
decryption,
but
basically
have
dedicated
sections
in
both
of
them
for
effectively
arbitrary
metadata,
of
which
one
of
them
is
the
key.
A
It
doesn't
need
any
of
this
fancy
key
hierarchy
or
any
of
that
inspection
or
even
any
concept
of
rotation,
because
you
can't
it's
in
hardware,
it's
literally
sitting
right
there.
So
in
that
sense
that
kms
plug-in
implementation
would
simply
just
return
the
encrypted
cipher
text
back
to
the
api
server
and
its
metadata
would
just
be
empty.
It
was
like,
I
don't
need
any
metadata.
I
am.
A
A
I
don't
think
we
need
anything
like
prefixing
and
stuff,
then
right,
because
we
like
the
reason
for
using
prefixing,
is
when
you're
like.
I
have
like
effectively
a
flat
set
of
bytes
and
I
need
prefixes
to
like
do
that
right.
I'm
saying
I
don't
want
to
keep
doing
that.
I
won't
I
want
to.
I
want
to
have
a
proper
structure
thing
that
has
fields
for
me
to
use,
so
I
use
the
fields.
B
A
Yeah,
I
guess
in
I
don't
know.
If
I
I
guess
I
don't
have
an
opinion
necessarily
on
how
the
rotation
is
done
as
much
as
that
we
do
it.
But
in
my
head
I'd
imagined
that
if
we
give
the
kms
plug-in
of
space
to
store
its
state,
that
is
persisted
by
the
aps
server,
I
think
most
of
the
complexity
necessary
for
the
prefix
and
all
that
kind
of
dissolves
away,
because
it
doesn't
have
to
remember
everything
in
like
one
slice
of
bytes.
A
You
can
say
cool
like
I
know
the
name
of
like.
I
know
that
I
have
the
concept
of
a
name
of
another
stream
key,
and
I
put
that
here
and
I
know
that
I
asked
it
to
encrypt
my
local
keck
using
some
proprietary
protocol,
and
this
is
the
slice
of
bytes.
It
gave
me
I'm
just
going
to
stick
them
right
here
right
and
then,
if
you
have
all
that,
then
like
yes,
we
want
rotation.
After
you
know
some
n
number
of
writes
from
the
local
keck.
A
We
don't
have
to
actually
remember
any
old
kecks
or
any
old
local
kecks
or
any
future
local
kex,
because
we
just
it's
a
point
in
time,
storage
right
and
whenever
we
get
it
back.
If
we
don't
happen
to
know
at
that
instant
how
to
do
it,
we
just
ask
the
upstream:
like
hey,
you
said
that
if
I
get,
if
I
told
you
that
I
was
using,
you
know
key
vault
77
key.
A
B
But
we
have
several
kicks
like.
First
of
all,
we
have
several
plugins
right,
so
we
will
have
several
of
those
local
kegs
encrypted
somewhere
on
the
on
the
disk
and
how
what
we
associate,
for
example,
the
id
or
something
like
how
do
we
know
that
this
local
keg
is
used
to
decrypt?
This
stack
right
so
when.
A
When
an
encryption
response
comes
in
from
the
api
server
right,
it
will
give
you
like:
hey
here's,
the
plain
text
I
need
you
to
encrypt,
we
will
encrypt
it
using
the
local
keck,
but
in
the
response,
as
part
of
the
metadata,
we
will
include
the
encrypted
local
tech
and
other
metadata.
We
need
to
later
redo
this
right.
So
we
did
that
and
let's
say
we
crash
immediately
after
that,
and
we
start
so.
We've
lost
all
of
our
local
memory.
The
api
server
immediately
turns
around
like
hey.
I
need
you
to
decrypt
this
data.
C
A
I
you
had
helped
me
previously
encrypt,
so
it
would
just
pass
us
back
that
metadata
and
be
like
cool.
We
have
no
idea
what
that
encrypted
kick
is
or
really
how
to
do
anything.
So
we
need
to
ask
the
upstream
key
vault
to
help
us
basically
re-cache
the
correct
key
right,
which
is,
I
think,
what
initiated
just
you
like
re-using
a
lot
of
the
existing
kubernetes
code
base
so
they'll
some,
some
mixture
of
cellular
plus
kubernetes
glued
together
in
some
way.
B
I
would
guess
right
so
so,
when
the
api
server
has
a
decryption
request,
it
send
us
the
encrypted
look:
okay,
we
see
the
encrypted
local
keck
and
we
would
would
then
look
up
if
the
we
would
always.
We
would
not
like
to
always
decrypt
it
right.
So
we
would
check
if
the
encrypted
local
keck
is
with
somewhere
within
our
cache.
B
But
then,
but
then
the
question
is
that
when
you
encrypt
one,
I
don't
know
exactly
how
the
upstream
cameras
works,
but
when
I
would
say
to
the
upstream
kms
look,
I
have
key
a
and,
as
could
you
please
encrypt
key
a
then
encrypt
the
encrypt
key
a
for
me
and
when
I
would
do
the
same,
I
would
ask
again:
could
you
again
encrypt
key?
A
both.
Both
ciphertext
should
look
differently
right,
because
when
you
create
equip
the
same
plain
text
twice
it
should.
B
It
should
be
different
because
you
add
a
different
initialization
vector
and
so
the
encrypted
sci-fi.
Even
when
you
have
the
same
plain
text
looks
differently,
so
you
can
not
make
any
statistical
attacks
on
it
or
stuff
like
that.
So
it
would
be
really
hard
for
us
to
say
that,
even
though
it's
the
exact
same
look
at
keck,
it
would
always
look
different
for
us.
This
is
why
it
might
be
beneficial
to
have
some
kind
of
an
id
for
for
the
key.
A
When
it's
as
it's
used,
it
will
only
have
one
representation.
It'll
have
one
set
of
random
bytes,
which
is
it's
plain
text
and
one
set
of
random
bytes,
which
are
it's
ciphertext
right
and
the
site
that
same
ciphertext
will
be
shuffled
around
right
like
at
no
point
will
a
different
instance
of
the
kms
plugin
try
to
reuse
that
key
as
a
write
key
it
will
so
there
will
be
never
more
than
one
call
to
azure
key
vault
or
whatever
to
encrypt
that
plain
text.
A
C
C
So
this
encrypted
deck
comes
from
the
kms
plugin
and
then
the
way
I
did
that
in
the
poc
was
there
is
an
lru
cache
where
we
have
the
encrypted
local
cache
and
then
the
keck
and
plain
text
has
the
value.
So
whenever
encrypt
call
comes
in,
we
just
check
in
the
cache
that
if
we
already
have
the
get
in
the
cache,
if
it
is
available
in
the
cache,
we
use
that
and
then
just
encrypt
it
and
send
it
back.
C
So
this
is
just
for
us
to
avoid
making
an
external
api
called
the
upstream
kms
keyword.
But
if
it's
not
in
the
cache,
then
we
generate
a
new
kick
right.
Like
I
mean
if
the
tech
has
already
been
used
for
a
certain
number
of
times,
so
that's
one
scenario,
but
in
the
decrypt
scenario
the
api
server
will
give
us
the
encrypted
deck
ciphertext,
and
then
it
will
also
give
us
this
additional
metadata
that
we
shared,
which
is
stored
in
hcd.
So
the
kms
plugin
will
look
at
this
metadata.
C
This
particular
key,
which
is
the
encrypted
if
it
is
not
in
the
cache.
It
says:
okay,
it's
not
in
the
cache,
so
it
in
in
the
metadata.
There
is
the
encrypted
kick
and
the
key
id
which
was
used
from
keyword
to
encrypt,
so
it
will
go
to
key
vault
and
say:
hey
look!
This
is
this
encrypted
data
that
I
have
and
I
had
encrypted
using
this
particular
key
id.
Can
you
decrypt
it
for
me
and
give
it
back
to
me
and
once
it
gets
it
back,
it
will
add
to
the
cache.
C
C
And
more
said,
the
key
is
only
generated
once
right,
like
it's
generated
at
start
and
then,
if
it's
used
for
thousand
operations,
your
cash
value
is
the
same
like
key
encrypted
check,
and
then
the
key
is
just
going
to
stay
the
same.
So
it
does
not
change
in
any
way
for
so,
even
for,
if
you
get
calls
for
a
thousand
encryptions
you're,
always
just
getting
it
from
the
cache
encrypting
it
and
sending
it
back.
B
A
B
No,
actually,
I
don't
think
that
they
have
a
counter,
so
when
you
create
a
new
handle
for
a
key
set,
so
we
give
that
key
template.
So
we
want
to
say
it's
asgcm
with
128
bits
and
basically
it
does
on
on
the
very
first
thing
it
creates.
A
manager
makes
the
rotation
and
then
uses
the
the
rotated
key
set
and
gives
it
to
the
handle.
So
it
it's
basically
from
the
start
using
a
rotation.
B
B
So
it
it
does
it
not
do
it
on
its
own.
So
so
what
I
did?
I
added
a
counter,
an
atomic
counter
that
that,
on
every
encryption
it
comes
up
and
once
it
reaches
a
certain
threshold,
we
initiate
to
think
a
rotation.
But
again
it's
not
super
complex
right.
So
if
we
say
okay,
that
we
need
to
work
too
hard
against
think
we
could
just
do
rotation
on
ourselves.
I
thought
it's
just
quite
nice
to
to
to
do
it
on
on
behalf
of
us.
B
B
A
B
A
A
C
A
Of
the
api
server
didn't
you
so,
though,
and
that
code's
not
exactly
fun
in
any
way,
though
I
I
suspect,
because
of
the
the
prefixing
stuff
we
couldn't.
Actually,
we
can't
move
the
api
server
to
use
this
library
right
because
it
would
actually
try
to
change
what's
on
disk
right,
which
is
unfortunate.
A
B
A
B
A
B
I'm
fine
using
the
the
native
stuff,
I'm
I'm
fine,
I
just
hoped
it
would
give
us
some
benefit,
but
again
it
quite
frequently
happens
and
we
have
a
strong
open
intake
framework
that
it's
too
hard
to
to
to
use
it,
because
you
need
to
just
I
know
like
java
spring
right.
So
I
don't
know
when
you
look
into
it,
it's
quite
opinionated
and
you
need
to
live
with
it
and
adjust
to
it
and
not
the
other
way
around.
A
A
A
If
we
have,
if
we
have
basically
a
dedicated
field
for
metadata
in
the
in
the
proto
that
we're
gonna
send
back
and
forth
between
the
api
server
and
the
kms
plugin,
I
I'd
wanna
see
like
what
does
that
look
like
when
you're
using
hardware
local
hardware
versus
like
key
vault
versus
like
gke
secret
manager-
gke,
I
guess
maybe
whatever
like.
If
we
we
had
those.
I
I'd
be
curious
to
see
what
those
end
up
looking
like
to
see.
A
C
A
A
C
Yeah
yeah,
but
in
terms
of
like,
I
think,
immediate
next
steps.
So
what
do
you
think
so?
Whatever
I
have
in
the
kms
plugin
now
like
whatever
I
did
for
the
poc,
I
can
extract
that
to
a
library,
so
basically
it'll
be
a
new
key
generator
which
borrows
the
generate
key
and
all
this
code
from
the
kubernetes
repo
and
then
the
a
is
cbc
part.
C
C
A
Yeah,
I
think
the
parts
that
are
not
fully
clear
in
my
head
regarding
a
kep
is
what
is
the
on
disk
storage
format?
What
does
that
look
like
for?
Basically
for
storage
ncd?
What
is
the
v2
alpha?
One
proto
format,
so
the
communication
channel
between
the
plugin
and
the
api
server
that
part
needs
to
be
really
solid
and
specified.
So
that
way,
it's
kind
of
clear.
A
Within
that
api
right,
what
what
are
the
other
extensions?
We
need
for
the
the
rotation
bits?
Basically,
I
don't
know
if
we're
at
the
kept
stage
or
if
it
would
just
be
easier
to
like,
like
as
as
a
for
example,
we
could
have
a
have
a
shared
fork
of
the
kubernetes
kubernetes
repo.
Just
you
know
public
for
not
private
one
or
anything
like
that
where
we
just
add
the
v2
alpha
one
api
together,
you
know
just
so
that
way,
it's
just
in
a
shared
spot.
A
A
A
Basically,
the
rotation
around
like
like
the
true
canvas
right
like
when
azure
keyword,
does
a
rotation.
How
do
you?
How
do
you
funnel
that
through
the
stack
so
that
way,
guy
server
knows
that
it
needs
to
do
something,
because
I
don't
I
the
local
keck
being
located.
I
don't
think
actually
meaningfully
matters.
I
don't
think
anyone
actually
is
concerned,
because
the
upstream
key
hasn't
changed,
so
it
doesn't
doesn't
change
anything.
A
Yeah-
and
it's
also
like
like,
depending
on
you
know
like
which
kms
plug-in
an
api
server
talks
to
right,
it's
going
to
have
a
different
local
tech
right
key
right,
so
it
doesn't
doesn't
conceptually
mean
anything
you're,
not
achieving
a
particular
version,
because
it's
every
api
server
has
its
own
kms
plugin,
which
has
its
own
in
memory.
Local
track
right.
So
that's
not
the
rotation
you're
trying
to
achieve
that.
That
hierarchy
is
simply
there
for
performance
reasons.
It's
not
there
for
a
security
boundary.
A
I
think
in
the
library
I
think
another
thing
that
would
be
nice
to
see
is
some
kind
of
like
interface,
like
go
interface,
definition
of
like
how
we
want
to
express
some
of
this
stuff,
because
presumably
we
would
have
an
interface
that
is
able
to
handle
the
local
hardware
key
based
encryption
as
well
as
this
like
delegating
key
hierarchy
encryption,
so
you
would
have
it'd
be
like
a
double
abstraction
rate.
You
would
have
this
interface
implementation,
that's
like
yeah!
A
C
B
Sure,
but
this
is
but
this
is
the
question
right,
because
my
repository
had
some
assumptions
like
around
think
and
now
it's
very
strongly
from
what
we
came
up
with.
So
the
question
is,
if
it
wouldn't
not
make
sense
to
maybe
work
from
manage
point
proof
of
concept,
because
it's
closer
to
I
mean
basically,
and
it
would
need
to
remove
nearly
everything
and
put
his
proof
of
concept
on
top
of
that
which
would
be
kind
of
silly
right.
So
maybe.
A
A
It
starts
from
nothing
because
the
we
want
to
separate
it
from
azure
key
vault
right,
because
that's
that's
just
one
upstream
implementation
right
like
one
that
we
want
to
support
along
with
the
other
two
major
cloud
providers,
because
everyone
wants
their
fanciness
and
yeah.
I
think
we're.
I
agree
that
if,
if
the
whole
library
is
right
on
tape,
then
it
probably
doesn't
help
out
too
much
to
coordinate
on
it,
which
is
fine
yeah.
A
I
think
actually,
now
that
I'm
thinking
about
it,
we
can
pretend
for
the
first.
You
know
bit:
let's
just
assume
the
api
server
has
been
updated
and
can
handle
the
new
api.
Let's
just
assume
that
for
a
second,
you
can
put
the
full
v2
alpha
one
further
definition
in
this
reaper
right,
because
it
has
to
have
the
server
implementation
in
this
repo.
The
client
is
inside
the
api
server.
We're
just
going
to
pretend
the
client
is
already
done
right.
So
then
we
we
can.
C
A
A
A
Yeah,
I
I
think
I
think
the
hardest
part
from
the
library
implementation
bit
is
giving
the
right
extension
points.
So
that
way,
if
you
wanted,
if
you
wanted
to
implement
your
own,
you
know
you
could
get
the
benefit
of
most
of
the
code
and
plug
in
the
bits
that
you
want
to
change
and
to
be
fair,
we
would
be
able
to
exercise
that
extension
point
pretty
well
by
literally
saying
well,
you
have
to
support
this
this
and
this
other
thing
that
have
well-known
implementations
for
it.
A
D
No,
I
was
trying
to
catch
up
musky,
but
I
saw
they
could
tell
you.
You
are
trying
to
iterate
over
the
couple
of
fractional
items
that
we
found
over
the
last
couple
of
months.
It's
great
that
it's
finally
taking
some
place
and
yeah
yeah.
I
don't
have
much
comment,
because
I
feel
that
the
discussion
that
happened
today
are
kind
of
like
things
that
we
already
figured
out
in
the
past.
It's
more
like
how
do
we
iterate
about
it?
B
A
I
I
think
I
I
would
air
towards
the
side
of
if
you
think
something
needs
an
issue,
just
go
ahead
and
make
one
and
then
we,
if,
if
we
think
it's
invalid,
then
we
can
just
say
here's
the
reason
I
think
there's
invalid
or
more
likely
what's
gonna
happen
is
like,
oh,
by
the
way,
I
think,
there's
five
other
issues
that
are
similar
to
this.
Let's
add
more
issues
but
yeah.
I
think
it's
fine.
I
don't.
I
wouldn't.