►
From YouTube: IETF-SCITT-20230515-1500
Description
SCITT meeting session at IETF
2023/05/15 1500
https://datatracker.ietf.org/meeting//proceedings/
B
Okay,
hello,
does
your
presence
mean
you've
actually
made
it
or
might
you
might
you
fall
off
at
some
point.
A
No,
no
I'm
good
I
can
take
notes.
B
That'd
be
great,
you'll,
see,
I've,
opened
the
Hedge
dock
already
and
just
put
a
quick,
quick
header
up
with
the
agenda
excellent.
A
Few
minutes
for
folks
to
join
yeah
I
hope
that
I,
don't
think,
there's
anything
special
today,
but
I'm
not
entirely
sure.
Everyone
has
seen
the
update
to
the
meeting.
Invite.
D
E
D
Okay,
all
right
there
we
go,
did
what
changed,
because
it
seemed
about
the
same
to
me.
D
Maybe
it's
because
we're
on
daylight
savings
time
here
or
something
eight
o'clock
was
when
it
normally
I.
B
B
No
you're
right
Ray.
So
what
happened
was
it
was
always
eight
o'clock
and.
F
B
G
D
D
B
So
I
was
rather
hoping,
although
if
we
can
get
started
anyway,
it's
three
pass
now:
I
was
kind
of
hoping
that
we'd
have
Roy
and
Cedric
because
they
are
the
most
vocal
and
and
the
most
Keen
to
discuss
registration
policies
this
week
and
they're
currently
not
here,
but
we
can.
We
can
make
other
progress.
B
So
the
agenda
for
today
the
very
quick
recap
and
close
out
of
last
week
we
discussed
and
I
think
kind
of
agreed
the
hackathon
topic
for
117,
but
I
see
there's
been
some
discussion
on
the
mailing
list,
so
it'd
be
good
to
have
a
quick
chat
about
that
and
then
the
plan
was
to
move
on
to
registration
policies
which
I'm
so
happy
to
do
even
with
or
without
those
other
folks
does.
F
A
So
last
time
I
asked
who
is
interested
to
participate
at
the
hackathon
and
do
some
preparation.
Work
and
I
sent
out
an
email
to
those
who
expressed
interest.
So
if
you
like,
Eduardo
and
Dick
and
Ray,
but.
F
E
This
is
dick
Brooks,
so
John
and
I
met
last
Thursday
and
yeah.
He
he
did
a
demo
of
what
they've
done
on
the
hackathon,
the
previous
hackathon,
and
he
has
some
really
good
materials
in
there.
I'm
convinced
that
Rea
can
easily
Implement
what
what
John
showed
from
a
consumer
standpoint
where
we
would
query
a
transparency
service,
so
I
think
we're
in
a
pretty
good
shape
for
actually
contributing
to
that.
Thanks.
A
A
H
A
Think
we
are,
we
have
a
very
good
foundation,
but
there's
still
a
chance
to
do
a
little
bit
more
interrupt
testing.
This
kid
received
stuff
has
evolved.
If
we'll
now
look
at
the
sort
of
a
full
event
scenario,
I
think
that
also
requires
a
little
bit
of
work,
so
I
think
there's
room
for
everyone
to
contribute.
E
Yeah
one
one
potential
use
case
is
actually
in
line
with
something
that's
actually
happening
and
for
real
Ian
newberger
from
United
States
white
house.
E
Cyber
security
office
has
suggested
that
in
using
an
analogy,
a
restaurant
cleanliness
score
analogy
as
a
means
to
communicate
trustworthiness
for
software,
and
so
that
was
this
that
that's
a
use
case
that
we
could
easily
demonstrate
where
a
consumer
could
query
for
a
score
and
receive
the
results
back
and
John
basically
showed
that
that's
something
that
could
happen
today
using
a
shot,
256
hash
value
as
a
query,
so
I
I
think
we're
in
really
good
position
to
make
something
real,
but
to
show
something
real.
So
this
is
a
good
opportunity.
B
Yeah
thanks
dick,
so
I
really
ought
to
record
that
and
put
it
on
YouTube
make
it
easier
for
people
to
see,
as
well
as
just
having
the
code
hidden
away
on
GitHub,
but
yeah
thanks,
I
I,
agree,
I,
think
this
suggests
potentially
two
strands
in
the
or
three
strands
of
the
hackathon
and
I
hope
we're
not
too
thin
for
that.
B
But
it
seems
like
there's
a
hack,
spec
hacking,
obviously
some
some
folks
just
working
on
the
architecture,
and
there
was
also
some
discussion
on
the
the
mailing
list
about
use
case
expansion
which
probably
counts
into
there.
B
There's
the
topic
we
discussed
last
week.
I
think
it
is
still
the
most
pressing
topic
for
the
spec,
which
is
registration
policies
and
really
seeing
if
we
can
get
interoperable
registration
policies,
which
is
more
of
a
kind
of
Technology
layer
use
case.
And
then,
as
you
say,
it
will
be
very
compelling.
I
think
it
will
help
us
a
lot
if
we
can
also
have
one
of
these
user
level.
B
A
I
would
be
I
think
that
was
missing
last
time
at
least
I
started
here.
I
would
like
to
add
some
of
that
did
discussion
or
did
any
specific
aspects,
the
whole
setup
we
talked
about
it
at
the
call,
but
I
don't
think
you
guys
touched
on
that.
Didn't
you.
B
No
there's
a
big
so
interestingly,
so
there
was
a
discussion
on
the
mailing
list
about,
did
and
did
references
being
persistent
or
not
and
or
public
Keys
being
persistent
or
not,
which
is
all
very
all
very
important,
stuff
and
I
think
something
that
we
haven't
covered
very
well
yet
is
and
and
will
absolutely
come
out
with
the
registration
policies.
B
Topic
is
the
difference
between
evaluating
identity
right
now
for
the
purposes
of
authorizing
the
creation
of
a
claim
versus
the
evaluation
of
our
identity
at
some
unknown
point
in
the
future
to
work
out
who
made
that
claim
and
what
Authority
upon
which
they
did
so,
and
these
are
very
different
questions
in
some
cases
and
and
speak
to
why
intermediate
CA,
type
things
and
and
and
hosting
questions
are
all
very
asymmetrical,
so
yeah
I
would
hope
that
all
of
those
topics
will
come
out
and
be
covered,
but
you
never
you
never
know
so
it's
good
to
mark
them
explicitly.
A
E
C
The
video
you
mentioned
in
the
YouTube
is
it
part
of
the
ITF
presentations,
or
is
this
some
link
which
you
would
like
to
share
on
the
chat
so
that.
B
We
can
also
so
there's
if
you
look
at
last
week's
meeting.
The
Hedge
DOC
for
last
week's
meeting
has
a
link
to
a
YouTube
time
stamp,
which
is
the
start.
So
that's
the
entire
iot
skit
meeting
the
entire
two
hours
of
it,
but
the
timestamp
starts
you
at
the
hackathon
readout,
which
is
about
10
minutes.
B
Okay,
so
there's
that,
in
addition,
a
thing
that
I
show
dick
and
the
thing
that
I
presented
at
the
the
the
hackathon
has
a
I,
don't
know
if
you've
seen
them
before,
but
they
had
a
sort
of
meet
and
greet
evening
with
wine
and
demonstrations.
So
what
I
showed
Dick
and
what
I
showed
at
the
demonstration
evening
was
it
actually
working
in
real
commercial
product
with
other?
B
You
know
open
source
ITF
code
at
both
ends
and
a
commercial
service
in
the
middle
that
isn't
in
the
YouTube
on
the
meeting,
because
I
don't
think
it's
appropriate
for
me
to
be
showing
off
my
products
in
in
the
ITF
meeting,
but
I
could
I
could
also
I
think
it
would
be
useful
to
show
that,
especially
as
I'm,
not
the
only
one
anymore,
it
would
be
useful
to
also
post
that
somewhere,
so
I
might
get
on
to
that
this
week,.
C
B
Yeah
yeah
and
the
client
API
just
to
be
clear
for
anyone
who's,
not
clear
the
the
client
API
is
all
derived
from
the
skit
architecture.
So
there's
nothing
specific,
there's
no
like
using
my
proprietary
apis
or
anything
like
that.
It
just
happens
to
be.
You
need
to
have
a
service
and
a
database
in
the
cloud
somewhere
to
make
it
work
and
that's
mine.
B
Well,
that
has
yet
to
be
done,
so
we
actually
have
in
my
product.
We
have
extremely
complex
registration
policies,
but
they're
not
standardized
yet
so
standardizing
those
and
getting
an
idea
of
how
those
work
is.
What
we
agreed
last
week
should
be
the
the
next
sort
of
big
topic
to
get
our
teeth
into.
A
I,
just
posted
the
link
to
the
meeting
minutes
from
last
week,
so
just
in
case
you
guys,
you
want
to
to
look
at
that
video.
Just
a
video
from
the
idea
still
still
very
useful.
D
Well,
it
looks
like
I
can
answer
my
own
hand,
the
I
I
think
we
can
make
good
progress
on
on
the
public
key
question
like
we're
going
on
now
on
the
list,
so
we
can
continue
that
there
I
just
had
a
question
about,
did
and
does
any
to
me.
It
seemed
like
it
was
a
cheeseless
rat
hole,
in
other
words,
I.
D
Don't
think
that
that
standard
will
become
followed,
but
that's
my
initial
very
cursory
review
it
does
anyone
have
more
information
in
terms
of,
is
it
being
embraced
at
all
and
it
because
it
seems
like
it.
It
sort
of
attacks
the
problem,
the
wrong
way
and
and
I
thought
that
the
the
package
URL
the
Pearl
things
were
much
more
along
the
lines
of
what
we
would
need
for
identifying
things
that,
along
those
lines
versus
versus
the
did,
which
seems
to
lump
way
too
much
into
into
the
ID.
C
So
yes
to
answer
this
question,
I
think
didweb
is
a
evolving
specification,
but
it
is
being
adopted
by
w3c,
I
suppose
for
verified
credentials.
C
Working
group
in
w3c
and
I
think
few
more
standard
bodies
do
used
it
so
I
think
Ori
is
not
here,
but
he
is
the
best
person
because
he's
actually
very
active
in
w3c
working
group
on
this
subject.
So
he
would
shed
more
light,
but
I
can
certainly
tell
that
it
has
been
adopted
in
other
standard
bodies.
Yeah.
That's
all
I
wanted
to.
A
D
F
A
D
Well,
I'll
tell
you
what
I
will
we
can
put
that
question
aside
since
there's
no
quick
answer
and-
and
then
you
know,
attack
it
later,
but
sometimes
I
see
this.
You
know
where,
where
there'll
be,
some
really
good
work
done
a
whole
lot
of
infrastructure
planned
around
it
and
so
forth,
and
then
it
doesn't
get
adopted
because
it
doesn't
quite
fit
what
the
needs
are
and
whereas.
A
D
A
Think
it's
a
very
important
Point
I
believe
it
would
be.
It
would
be
good
to
identify
like
what
are
some
of
the
most
important
sort
of
information
elements
we
need
to
have
in
in
our
systems
and
then
finding
out
what
technology
sort
of
fits
the
the
needs
best
would
be
appropriate.
I
guess:
I,
don't
have
a
strong
opinion
about
this.
This
and
so.
C
D
Yeah
well
well,
the
reason
I
say
what
I
said
is
because
I
thought
that
that
in
my
scanning
of
it
the
the
dead
thing
goes
much
further
than
what
we
would
need,
because
it
it
lumps
in
a
whole
lot
of
things
such
as
signatures
and
so
forth,
and
also
I
had
some
problem
with
how
they
had
arranged
it
with
their
thinking
that
everything
was
going
to
be
available
on
the
internet
to
anyone
at
all
times,
maybe
not
but
I
mean
so
so
I
I,
I'm,
still
sort
of
cautiously
making
these
statements
I
could
be
wrong
and
I
may
reverse
myself,
but
that
I
just
wanted
to
tell
you
that
that
was
my
and
a
lot
of.
D
So
I
I
I
thought
that
the
the
P
URL
stuff
was
was
going
to
be
very
handy
and
easy
to
use
and
deploy
and
looks
like
it
already
has
traction,
whereas
the
did
stuff
I
just
don't
think
it's
going
to
have
that
same
level
of
deployment
and
traction
because
it
doesn't
leverage
stuff.
That's
already
there.
The
P
URLs,
the
Pearl
stuff
is,
is
leveraging
the
package
name
spaces
that
already
exist,
and
so
nothing
has
to
be.
You
know.
D
All
they
have
to
do
is
just
use
those
namespaces
done
and
it
can
also
be
maybe
maybe
turn
toward
some
proprietary
name
spaces.
I,
don't
know
if
they
have
that
in
there,
but
a
manufacturer
has
their
own
name
spaces
that
they
want
to
Define
and
that
whole
thing
can
work.
Fine
it
doesn't
have
to
because
we
don't
need
them
to
be
as
secured,
because
that's
what
skid
is
providing.
So
we
don't
need
that
level
of
of
mechanisms
of
the
dead.
But
okay,
thank
you
for
the
answer
and
I'll
continue
to
research.
B
Well,
yes,
it
may
be
a
question
also
to
well
anybody
actually
on
the
call,
but
particularly
Bob
Martin
as
well,
who
will
have
seen
this
a
couple
of
questions
so
P
URL
for
software
packages
and
identifying
you
know
who,
if
we're
just
doing
s-bombs
and
vexes
and
things
I,
see
that,
but
we're
also
trying
to
identify
people
and
organizations
and
potentially
machine
actors
as
well,
because
this
all
ties
into
who
is
making
these
claims
not
just
what
the
claims
are
about.
B
So
question
question.
The
first
is:
have
I
missed
some
development
in
Purl.
B
That
makes
it
suitable
for
identifying
arbitrary
actors
and
a
second
and
possibly
related
question
is
I
used
to
spend
quite
a
lot
of
time
hanging
out
in
the
s-bomb
meetings,
particularly
the
Cesar
working
groups,
but
in
also
the
pre-cisa
working
groups
when
14028
was
new
and
also
some
of
the
various
Community
groups
around
that
and
the
topic
of
naming
and
identifying
software
and
using
Purl
was
very
quickly
seized
upon,
but
then
seemed
to
go
round
in
Long
circles
about
whether
it
was
actually
useful
and
how
to
use
it,
because
you
know
semantics
and
syntax
are
different
and
globally
versus
locally
uniqueness
are
different,
so
I,
don't
know
Ray
or
anybody
else.
B
If
you've
observed
those
conversations
and
they
actually
made
some
breakthroughs-
that
we
can
rely
on
or
whether
my
my
concerns
are
founded
or
not,.
D
No
I
think
your
observations
are
correct
in
that
that
I
didn't
notice
them
extending
the
the
PRL
Paradigm
to
to
allow
for
proprietary
name.
You
know
namespaces,
but
it
would
be
easy
to
do
so
and
then
then
we
would
have
something
that
would
work
for
everything.
D
E
You
harness
so
I'm
going
to
go
in
the
same
direction
that
John
went.
I
know
when
I
worked
on
the
ntia
s-bomb
work.
You
know,
there's
a
lot
of
discussion
about
naming
and
so
forth
and
it.
F
E
Down
to
it
really
takes
three
data
elements
to
identify
unique
pieces
of
software
software
product
and
it's
a
supplier
name.
They
are
signed
a
product
named
by
that
supplier
and
the
version
and
those
three
components
represent
sort
of
a
primary
key
Pearl.
E
E
Look
for
maybe
some
guidance
on
this
sisa
has
announced
their
self
attestation
form.
This
is
what
software
suppliers
will
need
to
communicate
to
the
federal
government
to
indicate
that
they
are
following
this
guidance
standards,
and
there
is
no
requirement
for
pearl
in
that
document.
But
information
about
identifying
the
supplier
and
products
and
versions
are
indeed
the
elements
that
are
expected
to
be
present.
Thanks.
G
G
So
first
one
is
that
ntia
provided
for
this
sort
of
loose
agglomeration
of
fields
as
dick
described.
They
also
provided
for
a
field
called
software
identifier,
which
was
one
of
three
things:
a
guid
or
uuid,
a
pearl
or
I
can't
remember
the
the
third
thing,
but
so
those
there
are
some
possible
unique
values.
However,
there
is
no
guidance
on
which
to
use,
and
there
is
no
guidance
on
the
source
of
Authority
for
any
of
those
Etc.
G
Now
other
groups
have
basically
declared
Pearl
to
be
the
winner
in
that
and
I
believe
they've
done
that
prematurely
and
without
considering
some
of
the
implications
of
it.
Pearl
in
particular
will
really
not
work
for
proprietary
software,
so
I,
don't
think
that
problem
is
solved
at
all
and
I
think
that
solving
it
is
a
big
deal.
So
we
can
attempt
to
move
further
down
the
road
on
that,
or
we
can
just
say
okay
we'll
take
whatever
identifier
is.
G
A
H
Yeah,
the
the
follow-up
to
that
Charlie
is
the
same
thing,
which
is
you
can
rebuild
the
product
in
times
the
s-bomb
will
probably
be
the
same.
The
Pearl
will
potentially
be
the
same
point
of
the
source
code,
but
the
evidence
that
we
do
for
monitoring
how
to
build
is
happening
and
file.
That
would
be
a
per
instance
that
you
spin
the
build
and
the
machines
it
runs
on
and
everything
else,
which
is
why
the
greater
uuid
approach
for
a
unique
identifier,
kind
of
resonated
with
with
me.
H
G
And
so
the
actually
I
thought
of
the
third,
which
is
CPE,
which
has
many
of
the
same
issues,
so
the
yeah,
the
build
so
I
mean
you
know
spawn,
is
going
to
change
every
time.
You
have
a
timestamp
added
to
it,
but
there
could
be
no
content
change
whatsoever,
including
the
identifier
just
as
Roy
points.
E
Thank
you
harness
yeah.
My
findings,
I
find
I,
find
that
Charlie's
findings
are
match.
What
I
found
as
well.
That
Pearl
has
some
issues
with
regard
to
proprietary
software.
He
also
brought
up
the
CPE
is
another
one.
Of
course
CPE
is
ambiguous.
You
can
use
multiple
CPE
identifiers
to
refer
to
the
same
piece
of
software.
So
as
far
as
the
ntia
minimum
elements
go,
the
software
ID
is
not
one
of
the
required
minimum
elements,
but
the
supplier
name,
the
product
name,
and
the
version
are
indeed
required.
H
The
question
there
is
that,
just
because
of
the
way
they
think
they're
tracking
software-
or
they
just
haven't,
got
to
the
trying
to
get
them
into
information.
I
can
understand
a
grid,
doesn't
get
you
anywhere,
where
the
other
three
get
you
at
least
to
a
a
producer
and
a
a
set
of
responsible
parties.
But
it's
not
unique
enough
when
you
start
looking
at
evidence
and
CVS
and
so
forth,.
G
Yeah
they
they
basically
decided
to
punt,
threw
up
their
hands
and
made
it
optional.
E
Yeah
and
and
just
to
your
point,
Roy
I,
think
what
you'll
find
is
that
you
know
vendors
want
to
be
in
charge
of
the
wrong
name
space
when
it
comes
to
naming
products
and
versions.
Some
like
the
use,
semantic
versioning,
some,
don't
some
use
hash
values,
so
you
know
there's
no
guarantee
it
was.
The
name
will
be
unique
or
an
identifier
will
be
unique
without
having
a
central
authority
to
ensure
uniqueness.
So
by
by
using
the
three
elements
and
letting
the
supplier
be
the
authority
and
naming
what
they
want
up
signing
words.
E
D
I'm
sorry
I've
got
some
background
noise,
but
you
know
normally
that's
the
way
it's
done.
I
wouldn't
expect
any.
You
know
the
the
vendors
to
change
their
names
or
something
or
go
through
an
authority,
but
the
only
thing
you'd
have
to
do,
and
it's
typically
done
is
you
have
to
have
the
vendor
name
be
the
thing.
That
is
the
only
thing
that
is,
you
know
past.
That
has
to
be
unique
and
then,
after
that
you
can
do
anything.
You
want
almost
anything.
D
You
want
Plus,
the
the
you
know
we're
not
really
constrained
to
use
a
single
line
of
a
single
string.
You
know
we
can.
We
can
use
a
Json
block
and
and
have
whatever
we
want
in
there
similar
to
what
you
would
have
in
a
a
descriptor
of
a
container,
so
so
anyway,
I
I.
My
question,
though,
is:
is
there
anything
written
up
about
or
is
there?
What
is
the
status
of
of
considering
these
things?
G
Anybody
else
who
wants
to
jump
in
yeah
they're,
the
Pearl
folks,
are
a
large
contingent
of
OSS
suppliers
and
and
related
folks
like
the
Linux
foundation,
and
they
have
sort
of
declared
victory
that
that
Pearl
is
the
unique
identifier.
It
really
isn't,
and
there's
no
they're
stating
so
hasn't
made
it
so
and
hasn't
increased
adoption
as
far
as
I
can
tell
so,
it
is
not
written
up.
It's
all
optional
and
ciso
is
aware
of
this.
G
Nist
is
aware
of
this
and
everybody's
trying
to
scratch
their
heads
and
figure
out
how
to
get
out
of
it.
I
do
believe
at
some
point.
There
will
be
USG
sponsored
project
to
better
identify
software,
and
it
may
very
well
proceed
with
the
attestation
stuff
that
dick
was
talking
about
because
right
now
it's
a
mess
and
that's
not
a
good
way
for
regulations
to
be
promulgated.
A
A
But
also,
and
so
I
think
it
at
right
now,
I
I
would
find
it
important
to
just
like
we
have
the
discussion
on
the
mailing
list
to
find
out
like
what
are
some
of
the
informational
elements.
We
need
in
all
the
different
requests
and
responses
and
then
to
find
out
like
what
would
be
the
best
tool
to
do
to
stick
in
there.
A
And
and
at
least
so
far,
we
have
sort
of
been
working
with
the
dits
and
they're
highly
customizable
like
like
just
some
some
structures
and
so
I
think,
particularly
given
the
hackathon
I
think
we
can
prepare.
A
And
then
gain
some
experience
and
see
how
it's
going.
But
Ori
also
said
last
time
that
the
whole
process
in
the
w3c
is
a
little
bit
convoluted
and
and
long
and
so
on,
and
so
it's
not
entirely
clear
on
when
they
will
be
able
to
finish
and
the
work
on
on
some
of
the
deep
methods
which,
which
is
a
chat
which
is
a
challenge
for
us.
I.
Think,
okay,.
C
G
I
think
there
is
no
real
solution
that
we
can
get
to
realistically,
and
we
just
have
to
work
with
the
imperfect
possibilities
we
have
and
I
think
the
fully
qualified
vendor
software
name,
software
version
build
version.
Etc
is
probably
the
best
information
we
could
use
right
now.
H
So
there's
a
slightly
different
thought
here
right
so
for
the
did
we
have
to
potentially
think
of
which
method
we
want
to
to
focus
on
is
a
did
web.
Is
it
DNA
d-I
and
is
it
did
some
other
new
new
protocol
and
even
producing,
limiting
and
reducing?
That
section
is
highly
valuable
and
we
can
make
progress
with
did
web?
It's
it's
much
separate
starting
point.
I
wouldn't
pick
ion
or
or
some.
H
Ones
like
DN
did
set
I,
don't
think
works
in
the
in
our
scenario,
but
that
said,
the
the
cases
for
pearl
I
think
are
disconnected
from
the
did
discussion.
H
If
I
have
an
s-bomb
forget
a
what's
in
it
and
I
have
evidence.
The
fact
that
I,
don't
want
to
put
the
evidence
in
the
public
domain
means
I
may
need
something
like
a
pearl
to
say,
hey.
If
you
ask
for
this
at
a
fiduciary
level,
you
can
now
retrieve
it
because
some
of
the
information
that
they're
asking
to
retrieve
is
potentially
a
map
to
how
to
compromise
a
product
right.
A
F
F
Yeah
so
I
mean
in
the
context
of
identifiers
for
things.
I
was
implementing
RFC
9162
over
the
weekend
and
and
they
have
a
urine
registry
for
transparent
parameters
and
I
wondered
whether
there
had
been
any
discussion
about
building
on
that
registry
and
skit.
Yet
like
have,
we
talked
about
you
know,
because
ietf
has
urns
for
all
kinds
of
things.
F
You
know
some
of
my
favorites
are
identifiers
for
Keys,
like
the
jwk
thumbprint
urine
RFC,
so
it's
possible
that
we
could
use
these
year-ends
to
identify
artifacts
that
buy
content
right.
So
you
can
say,
here's
the
sha-256
of
this
particular
content
and
here's
the
ietf
you're
in
for
Content
that
matches
that
hash,
so
I
just
wanted
to
ask
like.
Has
anyone
been
thinking
about
extending
the
transparency
urine
registry?
Because,
right
now
it
has
like
basically
just
error
codes
for
certificate
transparency
in
it.
As
far
as
I
can
tell
that's,.
A
It
already
have
you,
you
said
RSC
9162,
which
is
the
the
certificate
transparency.
Is
that
correct.
B
You
yeah
I'll,
put
in
a
small
vote
for
looking
at
ways
of
incorporating
9162
if
for
no
better
reason
than
that,
it
is
also
based
on
Merkle
tree
inclusion,
proofs
and
just
gives
us
a
bigger
community
of
people
using
that
proof
method.
B
Beyond
that,
what
I
was
wanting
to
say,
and
thanks
Ari
for
for
the
joining
and
and
everyone
else
who
came
later
on
I
think
what
we're
trying
to
get
to
in
terms
of
work
item
progress
here
is
I'm
picking
all
of
the
issues
that
are
in
the
way
of
defining
our
registration
policies,
work
and
all
of
these
various
different
ways
of
identifying
things
is
just
one
of
those
core
items
and
I
wonder.
B
I
think
it's
very
important
that
we
have
hard
rules
on
the
fact
that
things
are
identified,
but
it
may
well
turn
out
that
the
technology
used
is
more
a
side
effect
of
what
forgive
me.
I,
forget,
I,
think
it
was
Ray.
Forgive
me
if
I'm
wrong
was
was
mentioning
last
week,
but
actually
the
important
thing
for
us
to
specify
is
that
Audits
and
checks
and
identity
verification
have
been
done
to
some
level
as
opposed
to
exactly
how
they
were
done,
and
we
might
be
able
to
just
avoid
some
of
these
really
hard
technical
questions.
A
A
Policy
is
at
least
so,
whether
there's
some
commonality
between
what
you
John
have
been
doing
in
implementing
and
what
already
has
been
working
on
to
find
out
whether
there's
a
sort
of
like
an
intersection
that
we
could
potentially
document
somewhere
in
the
whatever
document
architecture
document
or
another
document.
A
F
Sorry
finishing
typing
and
and
yeah
so
I.
F
My
primary
interest
in
in
skit
is
to
understand
the
envelope
format
and
how
you
verify
an
envelope
has
been
signed
by
a
particular
entity
and
so
for
the
systems
that
I've
been
working
on
in
relationship
to
skit
I've
been
using
the
ISS
field
and
the
kid
field
and
I've
been
using
dids
for
the
ISS
field,
and
that
causes
you
to
need
to
resolve
key
material
as
part
of
the
registration
policy,
because
you
have
a
signed
statement
coming
in
it's
signed
by
something.
How
do
you
know
that
you
trust
the
signature
from
that
something?
F
So
you
need
a
policy
file
that
looks
at
the
issuer
and
kid
gets
to
key
material
and
can
make
a
decision
on
whether
the
signature
is
originating
from
that
issuer
or
not,
and
so
I've
been
implementing
that
with
with
Rego
and
and
sort
of
looking
at.
F
How
might
we
ship
a
sort
of
standard
registration
policy
for
ecosystem
components
that
build
on
top
of
did
and
I
think
I
think
it's?
It's
not
that
hard
to
do
it
with
Rego
today,
as
long
as
you
use
Json
web
keys
and
use
Json
and
you
use
Jose,
but
there
are
also
there's
also
support
in
Rego
for
certificates,
and
so
it's
it's
not
totally
unreasonable
that
you
might
have
regular
policies
for
registration
and
one
transparency
service
that
rely
on
certificates
and
policies
in
another
transparency
service
that
rely
on
did
but
only
support.
F
You
know
some
dids
and
then
a
different
one
that
maybe
supports
a
different
set
of
dids
and
so
I
I
think
the
relationship
between
the
registration
policy
policy,
engine
languages
and
the
envelope
formats
like
for
the
most
part.
It's
not
really
our
business
to
say
what
policy
language
you
use,
but
every
policy
language
will
look
at
the
envelope
formats
to
make
decisions,
and
so
we
we
do
have
a
responsibility
to
document.
You
know
the
most
popular
ways
of
identifying.
You
know
issuers
for
sign
statements
and
then
I
think
on
the
outbound
side
as
well.
F
When
you
have
a
transparency
service
and
it's
making
you
know
assigned
statements
transparent
it
has.
It
would
be
really
smart
for
us
to
make
that
identity
system
kind
of
compatible
with
the
same
inbound
identity
system.
So
if
you
were
in
the
did
web
ecosystem
transparency
service
would
sign
with
did
web
and
issuers
would
submit
with
did
web.
F
Like
that's
that's
one
sort
of
simple
case
you
could
mix,
you
could
have
the
transparency
service
sign
with
certificates
and
the
issuers
all
kind
of
come
in
with
vids
I
think
you
know
that's
fine
to
support,
but
it
would
be
nice
to
have
some
parity
and
a
single
sort
of
recommended
way
of
doing
things
for
skit.
F
You
know
the
RFC
9162
covers
a
massive
amount
of
space
and
it
also
covers
signing
and
rest
apis
and
Merkle
tree
proofs
and
so
I
think
there
is
a
sort
of
minimum
set
of
things.
You
need
to
bundle
together
to
get
to
the
point
where
you
you've
made
the
experience
easy
for
developers.
That's
it.
H
F
So
I
think
it's.
It
can
be
a
way
to
move
forward.
I
I'm,
not
from
I'm,
not
sure
how
mature
that
particular
did
method
is
I.
Think
you
know
if
you're,
if
you're
using
x509
today
and
you
don't
want
to
upgrade
to
dids-
you
should
not
have
to
to
use
skit
like
things
should
work,
but
then
someone
needs
to
sit
down
and
explain.
How
does
that
work
and
make
it
really
easy?
F
I'm,
not
volunteering,
to
do
that
for
x509,
but
I'm
totally
volunteering
to
do
that
for
dids.
So
that's
sort.
F
Yeah
I
mean
I
have
a
meeting
with
her
later
today,
possibly
in
a
few
minutes,
can
you
ask
her
to
do
that
to
ask
Curtin
to
normalize
their
didx
509
method
into
a
generic
DED
structure.
F
F
H
I
think,
when
we're
documenting
how
we
expect
x509,
whether
you
have
to
have
the
intermediate
certificate
chains
in
the
signature
in
how
that's
represented
in,
why
going
to
did,
would
be
a
strategic
thing
going
forward.
I
think
somebody
has
already
says
has
to
document
how
we
expect
to
be
used.
H
I
have
to
go
look
at
what
we
did
for
notary,
but
I
can't
answer
that
until
I.
F
Mean
if
they
are,
then
the
process
of
sort
of
verifying
the
x509
path
is
sort
of
the
same
as
it
is
for
dids.
It's
just
with
a
different
set
of
header
parameters.
You
use
to
make
the
evaluation
instead
of
looking
at
ISS
and
kid.
You
look
at
the
certificate
chain
and
you
have
some
way
of
trusting
that
this
particular
you
know,
roots
are,
is
is
worthy
and
therefore
all
of
the
intermediates
and
the
signature
on
the
final
object
are
acceptable
to
you.
Yeah
I
think
that
verification
process
is
usually
like.
F
A
A
It
or
deployed
it
very
different
things
I
think
it's
easy
to
do
technically,
but
I
haven't
seen
it
being
implemented
in.
H
G
E
Thank
you
harness
no
problem.
Oh
it's
good
good
conversation,
I
I.
Think
one
of
the
things
what
I
heard
already
saying
I
agree
with.
Is
you
want
to
verify
the
Integrity
of
the
party
that
you
know
that
is
shining,
but
but
the
other
Factor
too,
in
the
cab
forum
is
actually
coming
around
to
this,
and
voting
on
this
recently
is
the
notion
that
even
a
valid
party
can
end
up
becoming
an
invalid
signature.
E
So
it's
it's
not
enough
to
just
validate
that
the
party
is
legitimate.
We
also
have
to
validate
that
the
key
and
the
certificate
that
was
used
to
sign
is
still
valid,
and
the
scenario
they
give
is
that
you
know
someone
has
signed.
E
Some
software
turns
out
that
there's
some
malware
in
the
software
AKA
solo
wins,
and
it
turns
out
that
you
really
shouldn't
be
trusting
the
certificate
that
was
used
to
sign
that
piece
of
software,
so
that
that's
the
other
factor
that
needs
to
be
considered
here
is:
is
the
party
legitimate
and
is
the
key
still
valid
in
a
certificate
still
valid
that
signed
it?
H
So
dick
the
solar
winds
attack
wasn't
that
the
key
was
compromised,
the
they
just
injected
into
the
build
Pipeline
and
the
whole
premise
of
what
they're
trying
to
do
with
secure
supply
chain
moves
it
away
from
the
certificate
needs
to
be
revoked
versus.
You
can
now
make
a
negative
endorsement
or
a
claim
against
an
existing
product
to
Target
one
or
end
products.
Revoke
can
have
a
key
means
that
every
product
that
was
ever
signed
with
it
is
now
suspect,
and
that's
not
necessarily
the
granularity.
We
want
going
forward.
E
Yeah
I
agree
with
you,
Roy
I
think
right
now
it's
a
hammer
and
you
need
something.
That's
much
more
much
closer
to.
You
know
a
sewing
needle
to
get
this
right
right
because
you
need
to
be
more
granular,
but
unfortunately,
right
now
what
we
have
in
the
public
key
infrastructure
space
is
what
we
have
and
that's
you
know
it's
a
hammer.
H
H
Endorsement
they
basically
want
third-party
endorsements
as
a
way
to
solve
that
problem,
and
that's
where
they're
moving
with
supply
chain,
I
I'm,
not
arguing
that
there
has
to
be
the
hammer
capabilities
somewhere
right.
You
still
need
to
be
able
to
revoke
these
things,
but
the
90
99
case
should
be
a
negative
endorsement,
not
a
revocation
of
a
certificate.
E
Yeah
I
think
we're
in
agreement
Roy,
because
you
know
these
things,
they
can
be
ephemeral
right,
I
mean
you
can
one
day
it's
good
the
next
day.
It's
bad
so
recognizing
that
that
that
reality
is
what
we
deal
with.
However,
you
don't
want
to
implement
the
methods
that
say
today,
it's
good
tomorrow,
it's
bad.
However,
we
want
to
do
that.
Is
okay,
I,
just
making
you
aware
that
you
know
the
guys
over
on
the
cab.
H
I
have
no
problem
with
the
scenario
yesterday.
It
was
good
today
it
was
bad.
The
one
I
don't
like
is
yesterday.
It
was
good.
Today
we
have
no
clue
because
the
certificate
expired,
and
we
can't
tell
you
whether
it
was
ever
revoked.
That's
the
one
that
that's
really
a
fly
in
the
ointment
here
right,
the
the
fact
that
something
got
in
and
we
didn't
detect.
It
means
that
allowing
it
to
be
bad
later
on
is
perfectly
viable
way
to
move
forward.
E
Yeah
I
think
we're
in
agreement
again,
I
think
what
you're
saying
is
that
you
know
if
a
certificate
is
allowed
to
expire,
that
you
should
really
shouldn't
be
trusting
it
if
it's
used
to
sign
material
after
the
expiration
date,
I
agree,
but
while
it
was
valid,
it's
still
valid.
So
all.
E
That's
why
you
just
can't
rely
on
on
the
duration.
You
know
the
start
and
end
date
of
the
certificate
you
really
have
to
see.
Has
this
thing
been
revoked
because
someone
has
discovered
something
that
shouldn't
be,
that
has
challenged
its
trustworthiness
so
that
both
are
very
important.
As
you
know,
thanks.
D
A
quick
question
about
you
guys
conversation:
the
hammer
is
the
is
the
revocation
and
that
that
is
too
big
of
a
hammer.
D
I
assume
that
that's
what
you're
saying
then-
and
you
know
what
this
is
very
much
like
the
voter
database
situation
and
and
and
most
people
think
the
voters
are
deleted
from
them,
but
they're
not
allowed
to
be
they're,
they're
forced
to
be
maintained,
and
you
can
mark
them
as
as
not
active,
but
you
don't
get
to
delete
it
so
same
thing
with
these
certificates
there
should
be
like
there
should
not
just
be
a
revoke
and
and
no
Trail.
D
There
should
be
a
if
there
is
a
some
sort
of
a
hammer
that's
applied.
It
should
be
documented,
along
with
that
their
certificate
and
if
right
button,
if
that
mechanism
doesn't
exist,
then
then
that's
a
big
problem.
H
H
There's
two
extremes
here:
array
there's
the
very
short-lived
one-use
signing
certificates
and
then
you
end
up
with
whole
Haystack
of
signatures
that
you're
trying
to
assume
that
are
the
same
or
slightly
different
and
spotting
an
outlier
can
be
really
problematic
versus
the
other
one.
Is
we
use
the
same
same
key
for
the
next
50
years?
H
D
A
Before
we
run
completely
out
of
time
already,
you
posted
a
link
to
a
tutorial
you
gave
or
you
it's
some
some
write-up
in
what
context
or
which
context
is
this
fit
in
terms
of
the
meeting
minutes
discussion
so.
F
The
the
question
was
sort
of
like
how
do
you
verify
certificates
if
you
have
did
web
and
you
also
want
to
check
certificate
chains?
How
do
you
do
that,
and
so
we
put
together
this
tutorial
using
openssl?
That
showed
one
way
to
do
it,
but
you
know
again
like
it's
like
how
to
use
dids
with
certificates
is
not
super
well
defined,
and
if
you
just
most
of
what's
in
that
tutorial,
is
just
like
using
libraries
that
exist
around.
F
A
G
Keep
I
forget
very
quickly:
identity
is
different
from
the
certificate
or
the
key
or
the
representation
of
it
right.
There's
a
verifiable
identity
at
the
root
of
all
these
things,
and
we
have
to
be
able
to
figure
out
a
way
to
reflect
that
certificates
are
inadequate
right
now,
the
way
they're
you
know
revoked
and
and
managed
and
expired
and
so
forth.
G
But
the
bottom
line
is
that
we
need
a
way
to
establish
the
identity
of
that
underlying
entity,
and
there
are
ways
that
individuals
like
fingerprints
and
retina
scans
and
face
scans
and
so
forth.
For
companies
there
are
probably
similar
methods.
You
know
that
involve
going
to
the
registrars
in
various
countries
whatever
so
we
should
be
thinking
about,
in
my
view,
how
to
kind
of
get
back
to
that
verifiable
identity
and
making
sure
that
the
certificate
reflects
the
owner
of
that
identity.
A
I
I
months
ago,
I
distributed
a
link
to
in
this
document
that
was
written
or
co-authored
by
some
IDF
people
and
and
of
course,
folk
and
I.
Think
that
provided
a
lot
of
good
terminology
and
background
and
architecture
and
I
think
that's
something
we
should
probably
reread
again,
because
it
will
help
us
to
see
that,
regardless
of
what
what
name
of
technology
and
encoding
of
the
formats
we
use,
there
are
some
underlying
challenges:
don't
go
away
and
I
think
that's
just
we
have
to
live.
A
That
I
think
would
be
very
important.
I
will
try
to
dig
out
that
link
again
and
put
it
into
post
it
to
the
middle
list.
G
Yeah
I'll
take
a
look
too
Ray's.
Voter
analogy,
I
think
is
excellent.
You
know
the
voter
didn't
go
away,
voter's
still
there
or
the
identity
of
the
voter
at
least.
Is
they
just
you
know
their
certificate's
not
valid
anymore,
so
they
have
to
re-up
it,
but
they
still
exist.
So
that's
that's
going
to
be
important,
especially
if
you
look
at
software,
that
is
long-lived
and
successor
companies
and
all
that
crap.
So.
H
Just
one
thing
I
wanted
to
answer:
Charlie
is
I,
truly
believe
products
have
their
own
signature,
it
isn't
a
human,
basically,
the
maintainers
control
the
repo
and
hit
the
button,
but
the
the
product
actually
has
a
dad
document
and
signs
there.
Therefore,
there
is
no
biometric
if
we
want
to
say:
hey,
there's
a
an
audit
Trail
back
to
who
the
maintainers
at
the
time
of
hitting
the
button.
That's
an
interesting
discussion
forum.
G
Yeah
well,
software's
got
a
you
know:
a
genealogy
and
a
set
of
DNA
as
well,
so
I
think
that's
yeah
I
think
it's
useful
to
think
of
a
piece
of
software
as
an
entity
that
cannot
be
corrupted
if
we
give
it
verifiable
credentials.
D
D
I
put
in
the
chat
the
what
I
thought
might
be.
The
link
that
you're,
referring
to
honest,
which
is
the
nist
SP
800-63-3
document,
is
that
the
one
you're
thinking
of
yes
so
yeah.
D
It's
an
interesting
document:
okay,
yeah
yeah!
Just
just
extending
that
conversation
about
the
voter
yeah,
the
the
thing
there
is
that
you
can
never
delete
a
record
in
the
voter
database.
It
can
be
canceled,
it
can
be
amended
and
so
forth,
but
you
no
one
gets
to
delete
those,
and
so
when
they
say
you
know,
you
have
sometimes
too
many
records
or
too
many
voters
and
and
so
forth.
It's,
usually
I
misunderstanding
of
what
what
happens
with
that.
Thank
you.
H
I
just
wanted
to
mention
one
thing
before
we
go
is
that
with
K
leaving
Microsoft
I've
asked
Christina
you
shoulda
to
step
in
as
program
manager,
Microsoft's
efforts
in
skit
and
help
me
and
Cedric
and
Antoine
I
do
believe
her
expertise
in
identity
and
what's
happening
on
the
ietf
in
those
areas,
is
worthwhile
having
her
in
these
discussions,
which
is
why
I've
asked
already
to
reach
out
to
her.
B
C
A
Yeah
thanks
a
lot
right,
I
have
to
bail
out
so
and
we
actually
already
running
overtime.
So
I
suggest
you
stop
here
and
I
will
send
down
the
meeting
minutes
to
the
mailing
list
and
we
see
each
other
we'll
hear
each
other
next
week
on
Monday.