►
From YouTube: IETF95-COSE-20160404-1550
Description
COSE meeting session at IETF95
2016/04/04 1550
A
Hello
testing,
testing
testing:
this
is
the
coos.
A
working
group.
I
am
NOT,
kept
paying
or
Justin
I'm
pinch-hitting
for
them
they
should
be
remote
in
the
session
in
the
Java
room,
yeah
he's
in
an
airport
and
his
city's
got
crappy
Wi-Fi.
So
hopefully
this
will
work.
That's
not
gonna
work,
because
that's
too
big
well
I,
don't
know
why
it's
doing
that
I'm
not
gonna
mess
with
it
yeah
fair
enough!
So
it's
the
IHF!
There's
no
well
I
have
no
idea
what
it's
like
is
doing
that
it's
like
you,
think
I!
A
All
right,
it's
the
screen
size
whatever.
So
it's
that
this
is
the
no
well.
Basically.
The
brief
summary
is
that
you
agree
to
our
hockey
are
rules.
You
also
understand
if
you
speak
at
the
microphone,
things
are
being
recorded.
There's
a
there's,
a
link
there
at
the
bottom
or
a
bunch
of
formation
of
LPC
peas
that
you
should
note
requests
to
start
the
meeting
session
off
I
need
a
jabber
scribe.
I
need
a
minute
taker.
Oh
got
a
diverse
crab.
C
A
A
You
get
a
star
if
you
actually
take
notes.
I
have
plenty
on
my
laptop
because
I
often
volunteer
to
do
that.
Most
of
the
people
I
know,
are
people
that
are
going
to
be
at
the
microphone
a
lot.
So
you
don't
have
a
laptop.
Do
you
like
you,
you
you
Dave?
Do
you
want
to
do
us
a
service
and
just
take
some
bullet
notes?
Thank
you
very
much,
sir
appreciate
that
the
blue
sheets
are
circulating
now
or
the
blue
sheet.
Please
make
sure
to
sign
it.
A
Here's
our
agenda,
I,
actually
don't
have
access
to
upload
slides.
So
this
is
a
an
agenda
that
we're
going
to
bash.
The
first
thing
that
we're
taking
out
I
got
slides
from
Goran
on
the
ephemeral
diffie-hellman
overview,
/
co
giay
the
a
subject:
security
got
fixed,
apparently
on
the
list,
so
that
item
is
going
to
be
dropped.
A
So
that's
definitely
means
that
we're
going
to
have
time
to
go
all
through
the
Seaboard
encoded
message:
syntax
for
40
minutes,
which
I
think
is
pretty
long
based
on
the
number
of
slides
we
have
and
the
additional
algorithms
20
minutes
if
we
have
time
and
I
think
we're
going
to
get
at
least
half
of
that
back.
So
without
further
ado,
let's
see
if
these
slides
have
been
uploaded.
A
E
Okay,
so
I'm
your
surrender
and
together
with
my
colleagues
francesca
and
John,
we
have
try
to
start
with
the
component,
which
we
think
our
is
missing
from
from
cosi
yeah.
It's
like
this,
so
basically
because
it
does
a
very
good
job
in
making
a
compact
representational
of
elliptic
curve,
diffie-hellman
static,
static
and
ephemeral
static,
and
we
would
like
for
the
application
security
work,
application
security
in
terms
of
and
using
cozy
in
co-op.
E
We
would
like
to
have
an
nfa
and
FML
FML
version
of
defilement,
so
that
would
be
to
pass
protocol
and
we
made
a
first
attempt.
It's
actually
a
second
attempt.
First
attempt
ilari
shut
down
very
quickly,
so
we
don't
make
any
more
experiments.
Now
we
like
to
have
a
good
good
feedback
on
on
on
this.
So
so
what
we
basically
are
using
cozy
for
is
for
transporting
ephemeral,
public
keys,
and
there
are
two
cases.
E
So
that's
basically
what
we've
done,
and
there
is
the
01
version
uploaded
today,
which
is
doing
something
else
from
the
00
version,
and
we
are
really
interested
in
getting
comments
on
that
I.
Suppose
you
can.
You
can
do
this,
even
if
we
didn't
do
it
right.
The
first
time
I
suppose
it's
possible
to
do
this
right
somehow
so
we're
we're
longing
for
feedback
and
and
and
interested
people
to
give
give
comments.
So
not
some
questions
for
four.
That's
next
slide,
please
for
the
group.
E
So
we
assume
this
is
out
of
scope,
for
cozy
will
happily
leave
it
to
cause
you're
deleting
coffee
or
whatever,
but
we
suppose
this
is
not
in
scope.
That's
that's
a
question
and
I
can
take
all
the
questions
and
get
the
answers
later.
Is
there
any
other
activity
on
or
need
for
embedding
security
protocols
in
cosi?
We
think
it
was
really
nifty
to
have
a
compact
format
for
for
exchanging
for
as
a
carrier
for
protocol
messages.
Maybe
there
is
some
other
activity
also
interested
in
that.
A
third
question
is
specifically
on
the
protocol.
E
We
designed
all
the
cosy
objects
we
use
well
formed
in
the
sense,
for
example,
in
the
scientific
ailment
one
of
the
messages
we
need
to,
but
it's
what
is
important
is
to
identify
the
receiver,
for
example,
in
in
in
the
diffie-hellman
exchange.
You
also
include
the
identity
of
the
sender
and
the
receiver,
and
the
question
is
which
field
we
should
we
put
the
receiver
in.
So
in
our
case,
we
have
pre-identified
receiver,
so
we
put
it
in
the
external
aad,
but
maybe
there's
another
field
and
Jim
is
not
in
here.
E
F
Is
this
otoscope
I
think
it
is
out
of
scope,
because
this
is
going
to
be
very
protocol
based,
so
is
going
to
be
for
a
specific
situation,
so
it
may
not
actually,
for
example,
if
the
same
thing
may
not
apply
and
if
they're
in
it
in
I
or
something
else.
So
it's
not
clear
that
this
is.
It
would
be
the
right
working
group
for
it.
F
I
think
if
it
in
point
of
fact,
ace
is
probably
a
more
appropriate
one,
either
that
the
court
I'm
not
too
sure
which
depends
on
whether
you
think
it's
authorization,
key
distribution,
which
would
be
ace
at
the
side.
That
was
well
of
my
first
impression,
or
it.
E
F
Right,
the
one
immediate
feedback
that
I
have
for
these
is:
why
are
using
the.
E
Yes-
and
that
brings
us
to
the
next
slide-
please
so
cozy
doesn't
really
reference
a
specification
for
deriving
the
DHT
shared
secret.
That's
it
okay,
James
Naughton
again,
so
I
didn't
find
that
so
I
didn't
find,
for
example,
but
which
specification
is
referenced
and
I
suggest
we
should
add
it
to
the
cosi
draft
or
provide
reference,
and
are
you
saying
it's
exists
and
I?
I
must
say
I
missed
that
point.
Okay,
so
will
I
have
to
discuss
that
offline
and
on
and
on
the
question
of
a
specific
field
for
the
receiver?
E
A
B
F
We
have
in
cosi,
a
partial
IV
and
one
of
the
things
that
I
thought
might
be
useful
to
go
with.
This
is
the
ability
to
send
a
base
IV
as
part
of
a
cozy
key
structure,
so
basically
I
defined
this
arm.
It
gives
you
a
chance
to
distribute
to
the
base
IV.
You
can
do
your
ex
of
your
of
your
partial
IV
with
your
base.
Iv
and
everything
is
happy
and
after
I
finished
it
and
sent
it
off.
I
came
up
and
started
thinking.
F
Oh,
this
may
not
be
as
secure
as
I
would
like
it
to
be,
because
we
may
be
in
the
situation
where,
if
you
distribute
the
same
psk
for
bi-directional
traffic
in
both
directions,.
F
The
either
need
to
have
two
different
base
IVs,
if
they're
both
going
to
count
starting
at
one
or
they
need
to
have
a
way
to
say
this
is
where
each
the
people
starts
counting
and
that's
not
in
the
document.
So
a
lot
of
this
depends
on
whether
we
think
people
are
going
to
if
we
think
people
are
going
to
distribute
the
same
psk
for
bi-directional
traffic
as
opposed
to
one
kid
one
psk
in
direction
a
in
one
psk
and
direction
be.
We
may
want
to
remove
this
from
this
back
and
not
have
it.
F
On
the
other
hand,
it
would
be
very
useful
for
a
lot
of
cases
to
have
a
standard
way
to
say,
if
you're
going
to
do
the
incremental
IVs,
along
with
the
base
IV,
here's
a
standard
way
of
sending
up-
and
this
is
something
that
I
can
see
being
used
in-
was
with
some
of
the
escape
work
in
ace
and
co-op
and
and
corn.
So
how
many
people
think
this
is
something
we
should
save
vs.
something
we
should
trash?
Do
we
think
that
anyone's
actually
going
to
use
this.
D
G
H
H
You're
having
a
separate
document
anyway,
you
get
as
well,
I
define
it.
The
effort
is
important
and
it
remains
to
be
seen.
What
really
comes
out
of
that
document
are
like
what
is
really
then
sort
of
their
greed
content,
because
at
the
moment
shows
because
there's
something
in
an
individual
document
doesn't
sort
of
create
the
dependency
on
what
you
really
need
to
go
into
the
working
group
document
as
such.
So
like
anything
that
helps
me
to
have
this
document
as
simple
as
possible.
It's
a
good
thing
for
me.
E
Your
answer
down
there
I
agree
that
simplicity
is
important,
though.
E
H
I
B
H
J
F
F
Padding
for
encryption,
one
of
the
things
that
we've
done
is
all
of
these
algorithms
are
counter
mode
encryption.
So
the
length
of
your
message
is
well
known.
Tls
has
gone
in
and
put
in
a
way
to
have
padding
on
messages
arm
they
get
lucky.
They
managed
to
not
have
to
actually
pay
any
penalty
in
size
for
it.
We
would
probably
actually
have
to
pay
a
penalty
in
size
of
if
we
provided
it.
On
the
other
hand,
I
didn't
hear
anyone
say
this
is
important
on
current
text
is
basically
we
don't
provide
this.
F
We
give
you
a
security
consideration
that
says
hey.
This
is
something
you
need
to
think
about
when
you're
creating
your
message
structure
arm.
If
the
length
of
the
messages
are
going
to
change
based
upon
values,
you
need
to
do
some
sort
of
padding
so
that
people
can't
just
look
at
the
length
of
the
encrypted
data
and
say
oh
yeah.
This
is
the
value.
I
can
tell
the
difference
between
yes
and
no
because
the
length
of
the
encrypted
data
is
different.
F
Is
there
anyone
who
thinks
that
we
really
need
to
deal
with
this
in
this
document?
At
this
time,.
F
F
Registry,
what
is
the
requirements
for
getting
things
into
the
registry
arm?
The
current
situation
is,
there
is
a
section,
the
registry
which
is
on
the
way
I
want
to
write.
It
is
it's
basically
first
come
first
serve,
but
you
do
have
to
pass
an
expert
review
to
actually
get
the
point
assigned
and
you
do
not
have
to
provide
a
specification
to
get
the
point
assigned
number
of
people
who
have
come
back
and
said.
No,
we
want
to
always
require
a
specification
to
exist
before
you
can
get
a
point.
Even
if
it's
company
proprietary
arm.
F
We
can't
really
let
people
just
squat
in
the
private
space
if
they're
doing
this
thing
for
outside
of
closed
environments,
because
you
may
end
up
with
two
different
companies:
squatting
on
the
same
private
space
point
and
start
interfering
with
each
other
once
they
actually
get
out
and
deployed.
So
that
is
a
potential
problem
with
people
just
using
private
space.
We
want
to
discourage
that
that's
what
this
extra
first
come.
First
serve
ace
was
designed
to
avoid.
F
Is
you
could
do
something
that
was
company
proprietary,
but
you
would
be
guaranteed
that
your
point
you,
what
point
was
not
going
to
collide
with
anybody
else's.
There
is
a
similar
feature
to
this
in
Jose,
where
they
have
private
namespace,
which
is
a
identified
by
a
URL
which
is
company
based.
We
don't
really
have
that
same
thing.
Instance
based
in
the
registry
arm,
I
know
that
in
the
past
both
honest
and
Mike
have
objected
to
not
having
us
best
vacation
required
in
this
section
arm
and
I
have
bought
in
equally
hard.
F
K
Giving
in
how
about
solving
the
problem
by
making
them
to
experts,
then
they
can,
you
know,
required
the
specification
if
they
want
to
which
expert
can
you
know
have
his.
You
know
he
will
select
it
based
on
some
rules.
He
sets.
It
is
okay
and
it's
okay
for
him
to
require
that
I
have
to
see
the
specification.
So,
if
analyst
wants
to
have
a
specification,
he
might
be
the
expert
to
you
me
look.
K
H
It's
the
issue
is
this
about
any
sort
of
fields
or
the
algorithms,
because
the
slide
doesn't
say
all.
H
K
As
I
matter
expert
for
the
I
person
to
specification
shall
register
starin,
I
can't
say
if
I
could
want
to
give
to
know
the
number
out
if
I
don't
see
what
it's
used,
for,
which
means
I
want
to.
I
want
to
see
some
kind
of
specification
right.
It
means
that
either
they
need
to
have
a.
You
know
point
me
reference
to
some
document
somewhere
that
gives
the
reference
or
they
need
to
explain
me
or
actually,
the
ionic
built
and
for
one
meal
request.
K
A
Process
interrupt
great
so
having
dealt
with
the
eye
on
registries,
a
lot
specification
required
actually
means
it's
like
publicly
available
in
on
stuff.
You
also
have
to
remember
that
if
you're
going
to
do
a
coolant
request
to
go
in
a
registry,
there's
no
proprietary
information
going
on
like
they're,
not
going
to
hide
that
that's
gonna
become
public.
You
could
also
split
the
registry
to
have
some
part
of
it
be
like
you
know,
specification
required
in
another
part,
be
private.
That's
kind
of
up
to
you
so.
F
Yeah
yeah
hanas,
I
kind
of
a
yacht
for
the
algorithm
set
registry
I
would
be
willing
to
basically
make
that
much
much
tighter
I,
don't
know
that
we
want
our
retiree
algorithms
to
show
up
in
space.
C
Yeah
rich
sauce,
yeah,
absolutely
algorithms
is
the
minimum.
There's
got
to
be
public,
otherwise
people
are
going
to
get
light
bulbs
that
are
controlling
phones
and
bad
things
like
that
right,
I,
think,
I'm
being
favored
and
suggest
everything
be
public
arm,
but
fallback
would
be
a
split
state
address
space
and
if
the
private
is
only
like
to
identify
errs,
that's
cool.
D
Mike
jones,
microsoft,
I
think
you
correctly
identified
the
difference
in
the
situation
from
jose.
That
made
me
think
you
needed
a
public
specification,
which
is
that
in
jose,
you
can
have
string
prefixes
that
our
URLs,
that
you
know,
okay,
this
subs
namespace,
is
controlled
by
this
entity
and
they
can
sub
allocate
in
that
to
their
heart's
content.
We're
in
co
giay.
The
good
identifiers
are
the
shared
space
of
numbers,
which
is
why,
given
it's
a
scare,
sir
space
I
would
rather
that
people
say
this
is
what
I'm
using
it
for
it
a
publicly
visible
way.
D
F
F
F
Operation
time
we
have
not
that's,
why
it's
an
open
issue
and
why
it's
discovering
it's
on
here
there
are
I,
have
put
in
a
operation
time
feel
arm.
Mike
has
objected
to
its
existence
at
on
several
occasions.
It
is
here
basically
to
say
this
is
what
time
I
created
this
security
object.
It
does
not
necessarily
say
this
is
what
time
I
created.
The
content
is
insecurity,
object.
They
may
or
may
not
be
the
same
time.
F
It
is
here,
at
least
in
part,
because
there
are
security
operations
which
do
not
have
their
own
content,
such
as
counter
signatures
and
content
types
such
as
just
a
plain
touch
thing
which
do
not
have
a
field
as
part
of
the
content
that
they
can
store
a
creation
time
in
if
they
want
one
things
such
as
the
the
cwt
structure,
have
the
ability
to
have
it
have
a
time
in
them
and
that
time
may
or
may
not
be
the
same
as
the
operation
time,
so
you
could
actually
potentially
have.
F
This
is
what
time
I
did
the
evaluation.
This
is
what
time
I
made
the
message,
and
this
is
what
time
the
evaluation
expires.
All
three
of
which
are
different,
so
the
question
is:
do
we
remove
contents
time
from
the
spec
or
do
we
keep
it
on
and
content
time
is
currently
a
standard
time
looking
things
so
it's
is,
it
is
a
time
and
date.
It
is
not
some
sort
of
non
Scouter
field,
which
was
suggested
at
one
point.
H
Is
it
would
that
be
similar
to
let's
say
a
time
stamp
in
a
classical
sense
like,
instead
of
having
so
for
the
men
to
be
used
as
a
replayed
protection
mechanism?.
F
Okay,
so
I've
got
two
problems
with
their
because
if
my
first
question
is
what
you
mean
by
time,
stamp
x,
10
time
stamp
in
terms
of
the
state
of
the
standard,
p,
cakes
time
stamp?
No,
yes,.
H
F
F
F
H
F
H
I,
wouldn't
think
that
this
is
a
cozy
layer
issue.
I,
think
that
would
be
something
that
I
would
put
in
a
in
a
document
that
the
building's
working
on
or
on
the
CW
d
or
somewhere
is,
depending
on
what
odd,
in
a
sentimental,
depending
on
what
you're
actually
trying
to
do.
I
think
it's
the
wrong
layer.
F
So
I
think
because
guetta
countersignature
can't
produce,
as
I
can
layer,
is
that
there's
no
data
layer
for
countersignature
it's
over
existing
data,
yeah.
H
So
what
I,
the
layering
that
I
think
would
be
useful
is
to
do
everything
that
deals
with
the
actual
security
mechanism,
just
in
a
cozy
layer
and
the
other
stuff
that
deals
with
the
application
layer
semantics
in
there
in
other
documents
and
I,
see
that
there's
a
little
bit
of
an
overlap
between
the
two
which
of
course,
I
create
some
challenges,
because
people
use
it
in
the
wrong
way
to
repurpose
things
and
so
on.
H
So
I'm
not
a
big
advocate
of
the
countersignature
to
begin
with
so
I
I
don't
have
that
problem,
but
a
design
so
so
yeah,
so
I
think
it
will
then
basically
boiled
down
to
explaining
very
clearly
on
what
this
is
useful
and
what
not
to
avoid
problems.
D
The
gist
of
my
argument
to
remove
it
is
similar
to
what
hanus
had
said.
I
have
no
doubt
that
this
field
will
get
created
and
used
by
some
applications,
and
it's
good
for
those
applications,
and
indeed,
we've
got
an
extensible
system
that
they
can
use
a
registry
to
create
such
a
field.
I
do
have
a
problem
with
sort
of
opportunistically,
including
non
cryptographic
fields
for
some
applications
that
we
think
are
common.
Let
the
apps
define
their
own
fields
and
keep
this
as
simple
as
possible.
B
L
D
D
But
my
point
is
that
even
using
the
extensibility
mechanisms,
an
application
could
define
that
an
operation
time
be
put
in
the
protected
header
and
then
the
counter
signature
does
have
an
operation
time.
That's
protected
so
again
to
achieve
the
semantic
intent
you
don't
have
to
have
the
syntax
in
this
spec.
J
F
Well,
that
doesn't
really
tell
you
I'll
tell
you,
is
evenly
split,
yeah
I'm
open
for
suggestions
on
how
to
resolve
this.
D
Mike
Jones,
given
the
answer
to
my
clarification
question
that
you
can
do
the
counter
signature
with
operation
time
without
pre,
defining
operation
time
in
this
specification,
I,
don't
see
a
compelling
reason
to
keep
it.
Applications
can
define
the
operation
time
value
that
they'd
like
to
have
included
in
the
protected
headers,
and
it.
A
What
I
want
to
know
if
I
was
trying
to
judge
the
consensus
here?
Is
you
know
the
people
who
want
this?
Is
this
something
that
you're
going
to
die
on
the
sword?
For
is
this
the
hill
on
which
you're
willing
to
die?
Are
you
just
sad
that
it's
not
there?
Did
you
get
my
point
it's
like?
Is
this
something
that
is
like
a
drop
dead?
You
got
to
have
this
thing
or
it's
like
if
we
could
define
him
elsewhere
and
put
it
in
our
spec.
Okay,
yes,
there's.
A
F
F
So
we
basically
said
we're
not
going
to
pick
up
the
new
diffie-hellman
and
signature
algorithms
from
CFR
G,
so
they
have
finished
the
diffie-hellman
one
and
the
east
and
and
the
signature
one
is
sitting
there
waiting
for
a
shepherd
to
show
up.
So
should
we
just
go
ahead
and
pull
these
four
algorithms
out
of
the
addition,
algorithms
back
and
put
them
into
this
algorithms
back.
My
expectation
is
that
the
the
core
people
and
the
ACE
people
would
really
rather
use
these
two
algorithms,
oh,
that
this
set
of
algorithms.
Then
the
current
missed
algorithms.
F
Although
I
don't
know
that,
that's
actually
a
true
statement.
Do
people
want
to
speak
in
favor
of
or
against
pulling
these
out
rhythms
and
now.
F
D
F
F
So
the
the
core
message-
security
document-
has
stated
that
they
really
do
want
to
have
to
make
the
algorithm
field
optional
in
the
protected
headers,
and
they
have
requested
that
we
provide
them
guidance
on
how
to
do
so
in
this
document.
F
B
H
I,
like
the
idea
of
making
the
field
optional,
as
I
stated
in
the
under
list
a
few
times,
and
the
reason
is
I
compare
this
with
the
dtls
record
layer
or
the
ipsec,
a
h,
/
ESP
header,
where
you
include
information
like
an
spi
that
allows
you
to
identify
together
with
some
other
things,
the
key
and
not
send
all
sorts
of
metadata.
That
relates
more
to
the
previous
establishment
of
those
keys
in
the
actual
message
itself,
and
we
have
some
of
those
use
cases.
H
D
My
chance
I
objected
to
this
on
the
list,
largely
just
wearing
my
ITF
crypto
agility.
Had
it
kind
of
scares
me
that
we
would
send
messages
without
algorithm
identifiers,
because
that
means
that
when
you
need
to
change
the
algorithms,
the
code
will
likely
not
be
prepared
to
have
a
different
algorithm.
M
Yeah
custom
omen
did
the
in
the
cases
that
honey
singh
cited
the
algorithm
would
be
in
the
security
Association
that
these
data
center
under
but
I
have
a
different
question.
If
you
delete
this
text,
is
it
going
to
turn
up
in
the
security
considerations
after
two
or
three
more
iterations
of
the
document
anyway,
I
mean?
Should
we
just
leave
it
there,
because
it's
in
the
end
security
considerations.
H
Hunt-
this
is
honest,
a
constant
summarized
issue,
quite
better.
I
was
about
to
respond
to
mike,
but
in
addition
to
say
that,
if
you
apply
that
same
line
of
thinking,
then
neither
daedelus
nor
I
be
sick.
If
I
question
to
has
tripped
agility,
which
is
obviously
not
wrong,
crypt
agility
does
not
require
that
every
message
that
you
send
carries
an
algorithm
around.
H
It
just
says
that
you
are
able
to
change
the
Iverson,
whether
you
do
that
in
the
setup
phase
or
in
each
message
itself
the
group
that
unity
requirements
don't
say
that
and
I'm
for
some
of
these
longer
live
connections
which
I
assume
will
be
there,
because
you
can
amortize
this
connection
setup
then,
over
the
the
the
longer
usage.
You
obviously
do
that
during
the
connection
setup
and
have
the
cryptic
actually
the
future
there
and
in.
F
G
So
Francesca
here
I
just
wanted
to
say
that
we
propose
this
for
size
reasons
and
for
our
scenario,
since
we
didn't
need
it,
and
it
was
also
discussed
a
lot
in
the
mailing
list
and
like
some
messages
about
some
mails
about
this,
where
and
from
September
last
year,
and
some
from
februari,
yeah
and
I
would
refer
to
those
Italy
reappointed.
Some
good
points
but
know
that
we're
just
taken
again
and
also
sunday
appended
big
mentioned,
is
so
maybe
yeah
mailing
list
to.
D
F
F
F
This
is
another
one
that
came
from
them,
which
is
they
want
to
be
able
to
serve
that
the
OS
cap
people
they
want
to
able
to
save
a
few
more
bites
in
some
of
the
cases
where
they
using
counter
signatures
where
they
can
derive
the
cryptographic
context
that
is
used
to
derive
titude
to
verify
the
signature
from
the
message
data
associated
with
the
encrypted
data,
which
is
being
countersigned.
So
basically,
the
key
identifier
in
the
encrypted
message
is
is
the
same
key
identifier.
F
That
you're
using
for
the
count
of
signature
on
the
context
on
information
will
also
identify
the
account
of
the
algorithm
being
used
with
the
counter
signature
on.
This
is
a
case
where
potentially
saying
that,
yes,
we
want
to
be
able
to
remove
the
operation.
Time
is,
is
the
right
answer,
because
you
obviously
wouldn't
have
an
operation
time
here
since
there's
no
protected
attributes
associated
with
the
counter
signature.
So
this
is
basically,
as
the
only
reason
for
doing
this
is
saving
some
bytes
in
the
message.
F
This
is
something
that
is
easy
for
us
to
define
it's
easier,
just
tell
people
how
to
do
is
this
is
not
a
hill
I'm
willing
to
die
on
so
if
it
is,
if
people
really
wanted
to
argue
that
we
should
remove
this
particular
section
of
Appendix,
A
I
would
be
less
worried
about
that
and
say
that
that
makes
sense
for
them
to
define
in
their
document,
because
I
think
this
is
far
more
specialized
than
what
that
rest
of
the
things
we've
been
talking
about
are
armed,
so
do
people
have
some
opinions
of
actors
best
sure.
E
So
the
use
case
here
is
we're
looking
at
the
publish-subscribe
type
of
scenario,
when
we
have
one
sender,
multiple
receivers
and
we
want
to
have
like
close
to
scriber
groups.
So
you
want
to
encrypt
with
a
symmetric
key
anyone
to
sign
with
a
private
key
and,
generally
speaking,
those
objects
are
far
too
large
because
of
the
size
of
the
signature
already.
So
you
could
ask
you,
can
I
argue
in
two
ways
saying
that
in
proportion
to
the
signature
itself,
what
what
does
this
bed
and
bites
matter?
E
F
And
just
just
to
be
clear
on
his
use
case,
the
signature
operation
is
used
because
you
basically
have
a
group
encryption
key,
so
there's
no
way
to
tell
which
of
the
owners
of
the
group.
Encryption
key
actually
sent
the
message.
It
also
allows
for
pub
scripts
that
for
the
publisher
subscriber
epoxy
to
validate
that
the
message
came
from
the
right
place
as
well,
even
without
being
able
to
decrypt
the
content.
You.
E
M
C
D
Mike
again,
it's
been
a
while,
since
I
read
the
draft
on
in
this
particular
point,
but
for
me
and
probably
for
some
of
the
room.
Is
it
right
that
this
is
defining
a
second
way
to
compute
counter
signatures,
or
is
this
just
adding
a
field
to
the
protected
headers
for
the
one
way
of
computing
counter
signatures.
F
It
is
a
second
way
of
doing
counter
signatures,
because
they,
you
don't
have
a
protected
headers
field.
For
this
countersignature,
however,
that
the
saint
is
is,
is
basically,
you
drop
one
field
from
the
the
structure
that
you
encode
inside,
so
it's
essentially
similar
is,
is
much
like
the
difference
between
signatures
for
multiple
signatures,
two
signatures
for
one
signature,
so
it
is
the
exact
same
set
of
changes.
G
Francesca
I
just
wanted
to
say
that
some
quick
calculations
showed
that
difference
is
around
five
to
nine.
Bytes
depends
on
what
you
have
in
in
the
header
of
the
counter
signature,
which
is
big,
considering
that
OC
overhead
is
nine
bytes
for
our
messages,
so
that
will
be
only
the
overhead
of
adding
the
this
header
for
for
the
counter
signature,
the
whole
countersignature
structure.
D
There's
a
bite
cost
which
is
very
quantifiable
and
there's
a
complexity
cost
which
is
less
so
and
the
more
options
you
put
in
the
spec
the
more.
If
statements
there
are
incomplete
implementations
and
the
less
likely
it
is
for
developers
to
build
the
whole
thing,
you'll
get
subsets
that
aren't
interoperable
and
that's
the
cost
that
I'm
concerned
about
here.
Having
two
ways
to
do.
The
same
thing
is
usually
a
recipe
for
problems.
F
G
G
F
My
sense
of
the
room
is
that
the
core
people,
with
the
possible
exception
of
honest
who
hasn't
actually
said
anything
our
for
it,
Mike's
against
it,
I'm
kind
of
agnostic
on
it.
Anyone
who
hasn't
spoken
yet
who
would
like
to
voice
an
opinion?
I.
H
Honest
the
reason
why
I
haven't
said
anything
about
any
of
the
topics
on
contesting
it
just
is
simply
because
we
didn't
hear
anyone
asking
us
for
any
of
this
so
which
is
the
like
I,
don't
have
an
opinion
about.
F
E
E
H
And
the
only
so
the
cases
where
we
had
sort
of
group
communication
where
from
the
Lightning
sector,
which
is
this
at
a
document
in
there,
we
didn't
have
that
requirement.
So
they
are.
The
concern
is
about
any
sort
of
public
key
based
operation
regarding
what
at
signature
encryption
also
and
in
those
environments
the
guys
who
care
about
this
commercial
indoor
lighting,
they
just
don't
want
to
use
asymmetric
cryptography
for
the
reasons
stated
in
that
document,
and
so
that
stuff
does
apply.
C
E
C
H
Ok
so
mean
maybe
maybe
I
sort
of
you
could
convince
the
lighting
guys
that
this
is.
This
is
the
solution,
and
maybe
it
is
I,
don't
think
so,
but
and
I
think
from
my
assessment
of
the
threat
model,
which
was
heavily
debated
in
the
dice
working
group,
and
I
think
the
symmetric
key
solution
is
ok,
it
so
I'm
not
trying
to
sort
of
reinterpret
the
solution
that
people
sort
of
come
up
with
their
another
case.
H
Where
we
worked
on
singing
sender,
multiple
receiver
cases
was
the
software
update
mechanism,
but
they
are
we
the
solution
day.
I
think
the
current
document,
the
current
cozy
document
without
counter
signatures,
is,
is
walk
over
there.
I
should
look
look
at
the
details,
but
my
understanding
is
that
I
can
use
an
asymmetric
mechanism
to
as
a
key
wrapping
mechanism
to
protect
the
symmetric
key
off
of
let's
say
a
firmware
image
and
then
ship
that
and
get
and
do
the
signature
macaroons
day.
I
don't
need
to
have
the
counter
signature
for
that
purpose.
E
F
H
Software
update
server
I
create
to
generate
a
symmetric
key
then
encrypt
the
whole
image,
then,
and
then
what
do
I
then
want
I
have
to
look
at
what
I
really
want.
There
I
mean,
but
I
think.
H
H
E
That's
the
clarification
I,
don't
tell
me
about
this
lightning
scenario:
I
think
they
have
good
reasons
for
using
symmetric
keys,
but
there
are
other
use
cases
like
weather,
where
these
type
of
weight,
where
you
actually
would
need
the
type
of
asymmetry
between,
because
because
there
are,
there
are
different
parties
that
that
that
they
are
not
trusted
in
a
symmetric
way.
So
so
I'm
not
saying
that
lightning
use
case
should
use
calculus
ignitors.
F
A
F
Okay,
really
fast
I,
updated
additional
algorithms
document
and
basically
the
thing
I
did
in
it
was
I,
updated
the
text
dealing
with
the
new
CF
RG
algorithms.
So
people
want
to
look
at
that,
that's
more
or
less
what
I'm
going
to
pull
into
the
new
document
on
at
the
beginning
of
March,
I
pinged
the
chairs
about
saying:
hey,
we've
got
this
document
on
our
list
and
you
haven't
assigned
an
editor
for
it.
Can
you
do
that
and
obviously
they
have
not
asked
for
someone
to
come
back
and
edit
that
document
yet?
F
So,
if
people
want
to
bombard
the
chairs
to
say
that
they
should
assign
an
editor
for
this
additional
algorithm
document,
I'd
be
all
in
favor
of
you
doing.
That
makes
him
do
the
job
other
than
that
I.
Just
I
just
basically
cut
some
stuff
that
was
due.
It
was
still
duplicate
information
from
the
village
nice
pipes.
I
D
A
Okay,
okay,
thanks
everybody
signed
the
blue
sheets.
I'm,
not,
however,
letting
you
go.
Justin
has
requested
that
we
go
through
the
issues
on
the
github,
so
you're
not
going
to
get
20
minutes
back
of
your
life.
You're
gonna,
25
minutes,
you're
gonna
have
to
go
through
this
with
me
to
make
sure
there's
anybody
that
has
any
comments
on
these
I
haven't
looked
at
this
in
forever.
So
hopefully
we
can
all
have
a
group
discussion,
August.
F
61
we
just
discussed
okay,
great
60,
yes,
I
know,
okay,
54
is
fit,
is
in
the
current
version
of
document.
Okay
53.
We
just
discussed
okay
just
discuss
52
52.
We
just
discussed
51.
C
F
F
F
That
one
was
is,
is
is
I
need.
Is
it
it
that
one
actually
has
a
small
edit?
That
now
needs
to
be
done
because
we're
moving
create.
We
are
removing
creation
time
so
you're
you're
committing
to
make
this
change.
Yes,
okay,
great
13.
We
just
discussed
right
nine.
We
just
discussed
five
I
hate
this
yeah
well,.
B
H
Sean
of
its
I
was
wondering
like
it
seems
like
most
of
the
things
of
course,
spending
the
update
of
the
document
look,
look
like
they
have
finished
now,
which
is
good
and
I
one
hour
like
what
what
is
sort
of
the
precondition
to
get
this
done
and
I'm
curious,
like
we
have
this
at
the
next
IDF
meeting
before
the
meeting.
We
have
this
workshop
and
I
wonder
what
we
could
add
a
day
to
do
an
interoperability
test
on
this
I'm.
H
A
A
H
F
F
I
should
probably
get
a
schedule.
My
expectation
is
I
will
have
an
update
of
all
of
this
published
by
the
time
I
get
back
from
back
to
the
United
States,
which
is
the
twentieth
of
April.
Okay,
so
so
put
that
down
in
the
minutes
arm,
and
at
that
point
my
expectation
is
20.
The
chairs
should
issue
a
last
call.
Working
group
last
call
I
encourage
people
to
do
implementations.
F
F
F
I
C
J
N
Frankly,
because
it's
tiring
to
have
the
same
conversation
over
over
again
I
understand,
there's
resistance
to
it,
but
on
platforms,
where
you
don't
write
the
cryptographic,
algorithms,
where
you're
given
what's
provided
to
you
from
underneath,
there
is
not
much
support
at
all
for
PSS,
at
least
on
the
ones
that
I'm
used
to
I'm
a
Java
developer
on
the
server
few
people.
Do
you
java
in
the
world
like
a
lot
and
in
order
to
get
PSS,
you
have
to
install
different
security
providers,
pull
it
from
different
places
like
it's,
not
a
trivial
thing.
N
So
the
the
reason
for
asking
for
RSA
115
was
to
have
some
base
level
amount
of
support
from
the
other
line
platform,
and
there's
been
a
lot
of
pushback
on
it.
I
get
to
push
back.
Pss
is
better,
but
it's
not
like
there's
no
actual
vulnerability
in
15,
so
I.
So
it's
the
yeah,
yeah,
okay,
all
right
Joe,
but
I'm
not
going
to
die
on
I
like
we've,
had
the
conversation
over
and
over
again,
and
so
that
that's
why
it
that's?
Why
I'm
not
up
here
as
usual,
like
it's.
O
O
So
I
mean
I'm
on
Santa's.
Let's
just
tap
make
sure
that
we've
captured.
You
know
the
way
that
it's
hard
in
a
way
that
we
don't
have
to
keep
asking.
If
it's
in.
If
it's
in
this,
then
that's
fine,
it
doesn't
look
like
there's.
For
example,
there
doesn't
look
like
there's
a
link
off
to
the
javadocs
hear
of
it
not
working
in
the
base
stuff,
just
suggesting
away
to
and.
A
A
Dave,
if
you
can
just
make
sure
that
that's
in
the
minutes
that
we're
gonna
try
to
make
sure
we
capture
that
p
for
the
RSA
version,
1.5
stuff,
that
the
point
to
the
java
specs
and
the
issues
with
implementing
it
all
right
folks.
So
that
is
like
raging
agreement
at
this
point.
So
I'm
really
happy,
and
thank
you
very
much
for
not
being
too
mean
to
me
and
you
get
some
time
back
your
life.
Thank
you
very
much.