Subject: What ASN.1 got right

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 19:07:32 -0600

As an ASN.1 implementor, I can tell you things I, like many of you, hate
about ASN.1:

 - ugly syntax (made uglier by having tags as optional lexical elements)

 - ugly OIDs (should have been URNs or URN-like)

 - BER/DER/CER and all TLV encodings in the world (protocol buffers, I'm
   looking at you too) are awful

 - the fact that the specs were, for a long time, non-free, which led to
   a dearth of open source tooling that still persists somewhat (though
   not as bad as it used to be)

 - the fact that for years people hand-rolled their codecs due to the
   previous item, and so created many bugs

 - X.400/X.500, which are not part of ASN.1, of course, but closely
   related -- especially X.500 style naming!

Having recently implemented automatic open type decoding handling X.681/
X.682/X.683 (see RFCs 6025 for some insight, and 5912 for real examples
that I'm making use of), I can tell you that ASN.1 got some things
right:

 - rich formalisms ("constraints")

 - separation of syntax and encoding rules

The fact that there are many encoding rules for ASN.1, of almost every
kind (binary TLV, binaray non-TLV, and textual, including XML- and
JSON-based rules) proves the last point.  I can't help but see how XDR,
NDR, and flatbuffers, among many other encodings out there, could easily
be used with ASN.1.  (E.g., what XDR and NDR call "pointers" are just
optional fields in ASN.1.)

The fact that one can implement automatic open type decoding using ASN.1
formalisms and those already published in, e.g., RFC 5912[*] proves the
utility of those formalisms.  I now get to see certificates and many
other things in all their "glorious" detail as JSON, including all
extensions and what not, and that's made possible by these formalisms.

I beg the next person to re-invent this darned wheel to please educate
themselves as to what came before.  Among many lessons you should learn,
learn that some things can't be monetized well enough, or at all, or can
only be monetized in exchange for limiting their adoption, so figure out
what your goals are, then align pricing and licensing with those.

And since open types appear to be unavoidable, but also always a pain if
you don't have the metaschema to express the metadata needed to automate
their handling, don't forget to cover that.

XML, of course, with namespaces and references, has a reasonable
approach to open types as well.  It's not just ASN.1 that gets that
right well enough.

Nico

[*] A big thank you to RFC 5912's authors, though sadly one of them has
    passed.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Mar 2021 17:18:10 -0800

The combination of ASN.1 and X.509 has done irreparable harm to identity 
on the internet. X.509 provides exactly one benefit: the ability to 
verify offline that almost nobody cares about anymore. They have 
needlessly obfuscated the contents in the case of ASN.1, and the 
name/key binding in the case of X.509. Every security newbie immediately 
assumes that if you want to use an asymmetric key that you need X.509 
and hence ASN.1. That is not the case and that tail has wagged way too 
many dogs.

The best you can say is that X.509 bootstrapped TLS, but it would have 
been a way better world had it been bootstrapped by DNS.

Mike, yuck.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 1 Mar 2021 17:34:55 -0800

JSON-LD seems to fit modern needs from an extensibility / simplicity point
of view.
All the bit-packing goodness of various encodings are dreadful from an
interoperability point of view.
Rich formalisms and separation of syntax and "encoding rules" seem
counter-productive.
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: ietf <[email-masked]> On Behalf Of Nico Williams
> Sent: Monday, March 1, 2021 5:08 PM
> To: [email-masked]
> Subject: What ASN.1 got right
> 
about
> ASN.1:
that
> I'm making use of), I can tell you that ASN.1 got some things
> right:
> 
kind
> (binary TLV, binaray non-TLV, and textual, including XML- and JSON-based
> rules) proves the last point.  I can't help but see how XDR, NDR, and
> flatbuffers, among many other encodings out there, could easily be used
> with ASN.1.  (E.g., what XDR and NDR call "pointers" are just optional
fields in
> ASN.1.)
> utility of those formalisms.  I now get to see certificates and many other
> things in all their "glorious" detail as JSON, including all extensions
and what
> not, and that's made possible by these formalisms.
> 
only
> be monetized in exchange for limiting their adoption, so figure out what
your
> goals are, then align pricing and licensing with those.
> 
you
> don't have the metaschema to express the metadata needed to automate
> XML, of course, with namespaces and references, has a reasonable approach
> to open types as well.  It's not just ASN.1 that gets that right well
enough.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 20:17:32 -0600

> JSON-LD seems to fit modern needs from an extensibility / simplicity point

I know nothing about JSON-LD.

> Rich formalisms and separation of syntax and "encoding rules" seem

The nicest thing about XML is XSLT/XPath, and the nicest thing about
JSON is jq.  Such languages are probably only feasible when you have
loose typing, which XML and JSON do.  And loose typing does arguably
mean dispensing with the formalisms that force static typing.

That said, and as much as I love jq, for all the protocols I work on I
would much rather have static typing and rich formalisms.  Especially in
security protocols, I'd rather have rich formalisms.

As always, one should use the right tool for the job.  (FWIW, I used to
maintain jq and might again, and I maintain an ASN.1 implementation.)

I don't see how separation of syntax and encoding can be counter-
productive: alternative syntaxes are always possible, and transcoding is
generally possible, and people often have to do these things for some
reason.

As to "bit-packing"...  have you noticed that every textual encoding
eventually evolves a binary adaptation?  XML has FastInfoSet.  JSON has
a multitude of binary encodings (at least three).  Parsing textual
encodings isn't easy, and much less parsing them efficiently.  Parsing
dynamically typed data requires more overhead than parsing statically
typed data.

Parsing JSON efficiently is really hard.  Parsing anything without a
schema shifts a lot of burden onto the developer, unless the developer
is using something like jq.  People have devoted a lot of effort to
using SIMD to parse JSON more quickly than can be done on a traditional
CPU, but IIUC there are no online JSON parsers that use SIMD -- no one
would bother doing this for XDR because there is no need.

XDR was always simpler to compile or hand-roll codecs for than TLV
encodings, and definitely than textual encodings.  I've never heard a
bad thing uttered about XDR.

It turns out that once you've parsed the syntax into an AST it's pretty
trivial to generate codecs (possibly bytecoded) regardless of the
encoding rules' nature.

XDR being so much simpler than TLV types because of the absence of tags
and wasteful lengths, was always easy to handle, but what made it easy
was not having any crutches and so having to have parsed the syntax
defining the types one needed to encode.  There's a lot of hand-rolled
XDR out there as well, including some I look after, because it's much
easier to hand-roll XDR than TLV encodings, and certainly than textual
ones.

NDR's pointer dedup feature made it much harder to implement, but
otherwise it's really similar to XDR.  OER and PER are not too
dissimilar to XDR, so they're probably comparable to XDR in
implementaiton complexity.

Nico
--

---

From: Tim Bray <[email-masked]>
Date: Mon, 1 Mar 2021 18:40:35 -0800

ASN.1 always had data types, and then XML came along, which had no data
types but  a pretty good system for associating names with chunks of data,
and successfully invaded most of ASN.1's space. At which point I concluded
that it's more important to know something's name than its data type.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 20:44:01 -0600

> that it's more important to know something's name than its data type.

That's a good summary.  Though there's still a lot of input validation
to do, hence formalisms.

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Mar 2021 23:09:31 -0500

(wondering what brought up this subject... did someone decide that this 
is the week to rant about every past poor protocol design choice that we 
have to deal with?)

> Rich formalisms and separation of syntax and "encoding rules" seem
<soapbox>

There's something I used to call "ASN.1 disease", but it applies equally 
to XDR, some uses of XML, and a lot of other systems used to define data 
structures used in communications.

The basic problem is that if you give people the ability to generate and 
require arbitrarily complex type-checked data structures, protocol 
designers will use that ability to create overly complex structures.   
This in turn makes protocols and implementations much more brittle and 
less interoperable than they should be.   Every non-optional field must 
be specified and checked whether it is needed or not, it's more 
difficult to extend such protocols when needed, and implementation bugs 
that break things at a level which is hard to work around are far too 
common.

And because it's difficult to extend such protocols when needed, there's 
pressure to get things "right" the first time, which is often 
interpreted as "let's make sure specify every feature that could 
possibly be needed".

A related problem is setting up a tight binding between say an ASN.1 
structure and a C struct which imposes even more rigidity and subtle bugs.

There are some situations in which you need rigid type checking and a 
minimum of permitted variation, and probably X.509v3+DER is a good 
example of such a situation.   But this should not be the default.

And sure, you can use SEQUENCE or OPTIONAL or whatever to define ASN.1 
structures that aren't so rigid, but these tend to be used sparingly 
because people get enamored with their ability to define grandiose 
structures that solve all of the world's problems.

(Encodings are separate issues but I have yet to see an encoding of 
ASN.1 that is really efficient to either encode or decode. Not saying it 
cannot be done, but there's sort of an expectation that marshaling has 
to be done one datum at a time, in the sequence that they appear on the 
wire, and that slows things down by itself. )

Nico WIlliams wrote:

> I've never heard a bad thing uttered about XDR.
Besides being too rigid in the same way that ASN.1 is (for many 
applications), XDR is also grossly inefficient (in time more than space, 
though there's some space inefficiency) in both encoding and decoding, 
requiring extra memory copies and mallocs/frees to convert between 
on-the-wire and internal representations, and this slows things down 
tremendously.

(You're welcome.)

</soapbox>

Keith

---

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 1 Mar 2021 23:45:13 -0500

On Mon, Mar 01, 2021 at 11:09:31PM -0500, Keith Moore wrote:
> There's something I used to call "ASN.1 disease", but it applies equally to
> XDR, some uses of XML, and a lot of other systems used to define data
> require arbitrarily complex type-checked data structures, protocol designers
> will use that ability to create overly complex structures.   This in turn
> makes protocols and implementations much more brittle and less interoperable
> than they should be.   Every non-optional field must be specified and
> checked whether it is needed or not, it's more difficult to extend such
> protocols when needed, and implementation bugs that break things at a level
> which is hard to work around are far too common.

There's another side effect which this often enables (although
arguably this is the fault of the working group / standards committee)
which is that it becomes easier to settle disagreements by adding
large numbers of optional fields / substructures.  If you are using
fixed-length encodings, such as what is found in, say PPP, you can
still have extensibility, but since it's painful to create the
ASCII-art packet formats, I theorize this acts as a check against
unneceessary protocol complexity.

ASN.1-specified protocols tend to be far more complex, because it's
*easier* to create complexity, and this results in implementors having
to agree on profiles which are the subset of the protocol that
implementations _actually_ implement, and if there are different
profiles with different subset, there goes any hope of
interoperability.

						 - Ted

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 22:56:01 -0600

On Mon, Mar 01, 2021 at 11:09:31PM -0500, Keith Moore wrote:
> (wondering what brought up this subject... did someone decide that this is
> the week to rant about every past poor protocol design choice that we have
> to deal with?)

I had to deal with ugly things the TCG did, like creating non-string
directory attributes.  So I implemented automatic open type handling for
an ASN.1 compiler.  And now I can get beautiful JSON dumps of arbitrary
ASN.1 things.  And it wasn't very hard, and I wanted to thank Paul
Hoffman and Jim Schaad for RFC 5912.  And it made me think ASN.1 isn't
the awful think people make it out to be (but BER/DER/CER are).

> structures used in communications.

Yes, well, and JSON too.  I got into jq precisely because I needed to
deal with overwrought structures in JSON.

And look, that TCG stuff I mentioned above?  Similar disease.  Yes, that
one involves ASN.1.

> will use that ability to create overly complex structures.   [...]

They have that ability regardless.

> pressure to get things "right" the first time, which is often interpreted as
> "let's make sure specify every feature that could possibly be needed".

Typically we try to bake in extensibility only.

> structure and a C struct which imposes even more rigidity and subtle bugs.

Examples?  I don't think that's the case with any of the ASN.1-using
protocols I've ever had to implement any part of or which I'm familiar
with (e.g., PKIX, Kerberos, LDAP).  None of them are laid out with C in
mind, though all have C implementations, and all vary a fair bit in the
internal struct layouts.

I would think if you want nice alignment with C you'd want XDR, only
maybe an 8-octet alignment version nowadays.

> (Encodings are separate issues but I have yet to see an encoding of ASN.1
> that is really efficient to either encode or decode. Not saying it cannot be
> done, but there's sort of an expectation that marshaling has to be done one
> datum at a time, in the sequence that they appear on the wire, and that
> slows things down by itself. )

I've not implemented OER, but I suspect that OER is efficient in
run-time, and certainly in space needed.

> on-the-wire and internal representations, and this slows things down

Nah, that's just rpcgen -- one particular implementation.  Many JSON
implementations do that too.  You _can_ implement more flatbuffers-like
strategies for XDR.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 00:14:24 -0500

I agree ASN.1 got a lot of things right. And the problem is that if you are
baking a cake, its no longer a cake if there are too many rat droppings in
it.

I have written multiple serializers and deserializers for each of the
commonly used serialization formats, I have used a dozen schema languages
and written another dozen. I created another serialization scheme only last
week as it happens, needed something that works at the packet level that
worked really well with my crypto.

The problem I see with ASN.1 and XML is that the schema languages are
object description languages and thats a different thing from a
serialization format. I have stopped talking about 'objects' on the wire
and now refer to 'records' because I am not doing object broking, this is
message exchange on the wire but they are not events either as I use the
same format for stored data.

So the mistake I see in XML schema and also in most JSON schema proposals
is that they try to capture the full expressive power of the lexical syntax
and I am only interested in exchanging records and mapping them onto my
application data structures. I do not want to have the schema saying 'x is
an integer between 2 and 6'. I want 'x is an integer' and the only time I
want to have more information is if x won't fit into 64 bits. Similarly, I
don't want the schema to say '2 to 6 objects of type foo', the minimum
number of entries in a list is always either 0 or 1 and the maximum is
always 1 or infinity. Nothing else is needed at the schema layer. If you
have detailed data constraints you can always apply them later.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Mar 2021 06:20:11 +0100

On 2. Mar 2021, at 05:09, Keith Moore <[email-masked]> wrote:
> 
> There's something I used to call "ASN.1 disease", but it applies equally to XDR, some uses of XML, and a lot of other systems used to define data structures used in communications.

This is a complex subject.  Trying to do formal description techniques right has been keeping us busy for half a century, and will continue to do so.

The observation you make has been made by everyone watching the evolution of these techniques.
Once you have a tool that helps you manage complexity, you can use that to mitigate the bad effects of complexity, or (what you call ASN.1 disease) to help you create more complexity.  
The tool is neutral with respect to that choice!

Some real-world problems are complex, so a tool that helps manage that complexity is a good thing.

Some of the tools in this space generate their own complexity.
E.g., type systems in programming languages often require the addition of complexity to express the actual shape of the data being processed.

That brought us the differentiation between information models (which describe the natural complexity of the information at hand) and data models (which describe the complexity of that information mapped into specific data structures).

ASN.1 as the first major effort in describing the shape of data for interoperability of course didn’t have the benefit of things we have learned since 1983.

The most important difference between data modeling as used in programming languages’ type systems and as used for interoperability is the need to evolve protocols.  That need does occur in programming, too, but there is a big difference between evolving a system by a single actor and independently evolving parts of systems that are bound together by protocols.

The premier data modeling language that the IETF has is YANG.  YANG is still in the process of grappling with some of the issues arising in model evolution, and I’m sure that will be a major driving force for its own evolution.  But the fact that the tool helps designers to think about evolution issues may be one of its major contributions.

One of the interesting effects that I have seen over time is that experts for a specific modeling tool are often enthusiastic when they manage to express something in that tool that the tool wasn’t designed to support.  Even if that way of doing things creates additional complexity, instead of just managing it.  This is a bit of a Stockholm syndrome — if you have become the hostage of a description technique, and manage to negotiate a bit of freedom from your hostage takers, you may start to like what they are doing for you, forgetting that they are the hostage takers in the first place.  It can be hard to free hostages that have arranged themselves in their hostage situation that way.

So lamenting that more complex systems can be built now is like lamenting that society has become more complex because we now have transportation.
And something is to be said for arranging things in a way that many things can be done by walking.  But it is also important to understand what transportation issues are best solved by adding bicycles, cars, or tanks.  (You may now guess where ASN.1 fits into that parable…)

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 00:28:03 -0500

Thing about the WebPKI is that everyone seems to hate it just as much today
as when we originally proposed it 25 years ago. All the things people keep
saying were better were on the table then as well. We could have a
discussion about why DNSSEC is no better but that won't get us anywhere.

None of the systems on the table in 1995 is going to work and if you want
to understand why go get a machine that SHIPPED with Windows 95, boot it
and see what we had to work with.

PKIX and the WebPKI were built for 30MHz machines with 32 bit processors
and 4MB of memory.

If you want a decent PKI for user authentication you need to be willing to
do Internet2 for PKI and do some blue sky research.

There aren't many folk doing that at the moment as BitPonzi has sucked all
the air out of the room.

Its not ASN.1 that is the problem. Its actually Public Key crypto isn't
enough, you need threshold. But we are getting rid of the ASN.1 as well for
two reasons. First, nobody is going to use our stuff if we force them to do
ASN.1. Second, nobody is paying me to do my stuff right now but once I have
it working in JSON/JSON-B, I can probably find some ASN.1 aficionados to
give me a consulting gig to write an ASN.1 version.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 23:47:58 -0600

On Tue, Mar 02, 2021 at 12:14:24AM -0500, Phillip Hallam-Baker wrote:
>                       [...]. I want 'x is an integer' and the only time I

Yes, I agree with this.  Use [u]i[8|16|32|64] to indicate the expected
range of integers that aren't arbitrarily large, and make the name of
the large integer type denote as much so that it's not used accidentally
instead of machine word sized integer types.

If an integer really is expected to do something like express named
versions, then sure, name the valid values.

> have detailed data constraints you can always apply them later.

Indeed.

This is true for database schemas too.  Cardinality is always one of
zero-or-one, zero-one-or-many, one, or one-or-many.  Simpler that way.

ASN.1 is _too_ expressive in this regard, I agree, though one does not
have to use its full range of expressivity.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 23:50:33 -0600

On Tue, Mar 02, 2021 at 06:20:11AM +0100, Carsten Bormann wrote:
> ASN.1 as the first major effort in describing the shape of data for
> interoperability of course didn’t have the benefit of things we have
> learned since 1983.

Hmm, but it has type variables -- a pretty advanced concept that did not
exist in 1983.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 00:06:23 -0600

> discussion about why DNSSEC is no better but that won't get us anywhere.

We hate WebPKI because it isn't really a PKI and because x.509 meant
x.500 naming and because it's ugly and old and creaky.

OTOH, PKIX at least has evolved almost enough over the years.  We now
have better naming, and we understand that short-lived credentials are
the only way to do revocation (Kerberos knew that long ago).

I like OpenSSH's simpler certificates, but in some ways they're too
simple.  I really do want a hint as to the "type" of a "principal" name
because the corporate world I inhabit has multiple types of principal
names.  Etc.

> PKIX and the WebPKI were built for 30MHz machines with 32 bit processors

I don't follow.  Given all the CPU, RAM, and storage available now, what
would you do differently?  Mesh, yes, I know, but, remind me how Mesh
uses all that extra HW that PKIX leaves on the table?

> do Internet2 for PKI and do some blue sky research.

No please.  That's how we got X.500 naming to begin with.  Subject Alt
Names exist because X.500 failed.

SMTP and RFCx822-style email address naming killed X.400 because X.400
inherently meant an awful UX.  X.500 naming needs to die.

> There aren't many folk doing that at the moment as BitPonzi has sucked all

Sadly this is too true.

> give me a consulting gig to write an ASN.1 version.

Eh, to be sure I don't anyone to have to use ASN.1.  And I agree any
replacement for PKIX should use JSON, like JWT does.  As I said, the
biggest problem with ASN.1 is the dearth of open source tooling, and
that is caused by bad pricing decisions made in 1984 [by people doing
blue sky research].

Though sometimes I think simpler is bad because it makes it too easy to
end up with ton of half-baked simple implementations and can lead to an
interoperability nightmare.

[And again, you can do JSON with ASN.1, but whatever.]

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 01:45:59 -0500

> uses all that extra HW that PKIX leaves on the table?

The original goal of the Mesh was to make computers easier to use by making
them more secure.

WebPKI is really limited to authenticating organizations. Private key
management considerations are pretty much out of scope. The assumption is
that Alice has a public key pair which is stretched to separate keys for
encryption and decryption.

The Mesh has a separate key for every function and for every device and
application. So if Alice has a dozen machines connected to her Mesh, they
each have separate encryption, authentication and signature keys. And they
are all used for threshold operations which really don't fit into the RSA
scheme of things.

Introducing more keys allows me to deal with all the real world use cases
that get ignored like what to do if Alice loses her phone, if she is
planning to go through an airport in a hostile police state, etc. etc.

Sure, now I have the architecture, we could go back and spend ten years
working out how to retrofit to PKIX. Or we could write some end to end
secure applications that are exactly as easy to use as the applications
people use today. I am talking about zero user impact security, zero trust
models, etc.

Social media where the service cannot read any of the posts.

> inherently meant an awful UX.  X.500 naming needs to die.

I come to bury X.500 naming, not to praise it.

People don't have DNS names and a majority of people on the planet can't
afford $10/yr to rent one. And that tomato has sailed.

We need names that cost $0.10 for life. If we can get the price that low,
we can get to universal coverage some day. We can find someone to pay even
if the end user can't afford it.

$10/yr is a thousand bucks over a lifetime. Won't be able to find someone
to sign that check for the planet.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 01:08:01 -0600

> are all used for threshold operations which really don't fit into the RSA

But do you need to store a huge mesh on every device?  Where is all the
power of modern HW being used here?

> people use today. I am talking about zero user impact security, zero trust

I mean, Alice can have a private CA for her devices, with secret
splitting / threshold crypto used to spread that around, and/or secure
elements storing the keys or key shares, and yet all the devices might
not need to know all the other devices' keys because they might always
present EE certs chaining to her private CA.  The naming on the
certificates would be all pseudonymous perhaps, or real names encrypted
to a key specifically for that purpose that all of Alice's devices have,
so that she can identify them.

PKIX certificates are just bags of "extensions", so you can fit any of
that into it.  There's even an extension for encrypted naming, though I
forget right now what it's called, and it might not fit your needs.

(And yes, if a bad of random extensions + a signature is all one needs,
then ASN.1 is overwrought for it.  Just if you use JSON, please don't
make the schema for that overwrought either.)

> Social media where the service cannot read any of the posts.

But they give you the software you need to use it, right?

All these apps that claim to have end-to-end crypto, but where you have
to run an implementation you didn't write, so you don't really know if
there's a MITA or backdoor or whatever.

> > > If you want a decent PKI for user authentication you need to be
> > > willing to do Internet2 for PKI and do some blue sky research.
> >

+1

> afford $10/yr to rent one. And that tomato has sailed.

Well, certainly DNS naming is 1e6 times better than X.500.  But I agree
that for individuals it doesn't work.

> if the end user can't afford it.

+1.

> to sign that check for the planet.

Well, most households pay for utilities, but I agree.

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Tue, 2 Mar 2021 09:33:01 +0100

On 2 Mar 2021, at 02:18, Michael Thomas <[email-masked]> wrote:

> The combination of ASN.1 and X.509 has done irreparable harm to identity on the internet. X.509 provides exactly one benefit: the ability to verify offline that almost nobody cares about anymore.

Actually - to provide a counter point - with the current Covid-19 response effort - the fact that we have X.509 (and CMS, pkcs7/10) and can do off-line verification is proving to be a great asset.  As it allows for verification of signatures without the need for the verifier to instantly disclose to world+dog what they are doing. And this is in addition to the ability of any app to set up trusted connections based on cached/offline data. So I would not discount this aspect too quickly. 

Dw

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 10:19:53 -0800

> Actually - to provide a counter point - with the current Covid-19 response effort - the fact that we have X.509 (and CMS, pkcs7/10) and can do off-line verification is proving to be a great asset.…
Er, how so? And what does it have to do with the covids? And once you 
rely on online crl's, it's all the same.

Mike

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Tue, 2 Mar 2021 19:24:13 +0100

> Er, how so? And what does it have to do with the covids? And once you rely on online crl's, it's all the same.

Purely as an example - that, even in this time of the internet - the `ability to verify offline' is something one may care about - in this particular case --  to verify a X.509 in the field, entirely off-line and without any communication.  If you need to do OCSP or CRL's - then obviously a CRL may be a better idea if you are trying to minimise the surveillance options. 

Dw

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 10:38:15 -0800

On 3/1/21 9:28 PM, Phillip Hallam-Baker wrote:
> Thing about the WebPKI is that everyone seems to hate it just as much 
> today as when we originally proposed it 25 years ago. All the things 
> people keep saying were better were on the table then as well. We 
> could have a discussion about why DNSSEC is no better but that won't 
> get us anywhere.
>
> None of the systems on the table in 1995 is going to work and if you 
> want to understand why go get a machine that SHIPPED with Windows 95, 
> boot it and see what we had to work with.
>
> PKIX and the WebPKI were built for 30MHz machines with 32 bit 
> processors and 4MB of memory.
>
>
> There aren't many folk doing that at the moment as BitPonzi has sucked 
> all the air out of the room.
>
> Its not ASN.1 that is the problem. Its actually Public Key crypto 
> isn't enough, you need threshold. But we are getting rid of the ASN.1 
> as well for two reasons. First, nobody is going to use our stuff if we 
> force them to do ASN.1. Second, nobody is paying me to do my stuff 
> right now but once I have it working in JSON/JSON-B, I can probably 
> find some ASN.1 aficionados to give me a consulting gig to write an 
> ASN.1 version.

TLS is water under the bridge. We got the mess of disjoint trust anchors 
and who should be trustworthy or not, but somehow it mostly works. My 
beef is with the collateral damage of that choice. ASN.1 instantly makes 
figuring out what's going on much harder. Instead of more(1) I have to 
do some arcane openssl incantation to view the contents of a 
certificate. And instead of just directly using a public key to bind to 
an identity, I have to figure out how and what CA to issue a 
certificate, blah blah blah, instantly making a simple concept far, far 
harder. And don't even get me started on business models.

Look at the complexity difference between DKIM vs. STIR which are doing 
approximately the same thing (or at least should be). I would say that 
part of STIR's failing is that they got sucked down the X.509 rathole 
requiring special root CA's so they could assert things about e.164 
addresses instead of doing the far more obvious thing that DKIM did 
which was to assign responsibility for messages to the domains sending 
them. It's not directly X.509's fault they solved the wrong problem, but 
it absolutely didn't help because it set up the mindset where solving 
the wrong problem seemed like a tractable problem when in fact it is not.

Mike

>
>
> On Mon, Mar 1, 2021 at 8:18 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 12:39:02 -0600

On Tue, Mar 02, 2021 at 10:19:53AM -0800, Michael Thomas wrote:
>                                                    [...] And once you rely
> on online crl's, it's all the same.

Yes, well, wherever possible we should be using short-lived credentials
and dispense with revocation.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 12:55:17 -0600

On Tue, Mar 02, 2021 at 10:38:15AM -0800, Michael Thomas wrote:
> TLS is water under the bridge. We got the mess of disjoint trust anchors and
> who should be trustworthy or not, but somehow it mostly works. My beef is
> with the collateral damage of that choice. ASN.1 instantly makes figuring
> out what's going on much harder. Instead of more(1) I have to do some arcane
> openssl incantation to view the contents of a certificate. And instead of
> just directly using a public key to bind to an identity, I have to figure
> out how and what CA to issue a certificate, blah blah blah, instantly making
> a simple concept far, far harder. And don't even get me started on business
> models.

Yes, which is why I put some effort into automatic open type handling.
I can now get a pretty JSON view of a certificate, with all Extensions,
all Attributes, all RDNs, all GeneralName alternatives (well, ok, I've
not implemented X.400 naming, and I won't), all SANs, everything decoded
nicely.

> approximately the same thing (or at least should be). I would say that part
> of STIR's failing is that they got sucked down the X.509 rathole requiring
> special root CA's so they could assert things about e.164 addresses instead
> of doing the far more obvious thing that DKIM did which was to assign
> responsibility for messages to the domains sending them. It's not directly
> X.509's fault they solved the wrong problem, but it absolutely didn't help
> because it set up the mindset where solving the wrong problem seemed like a
> tractable problem when in fact it is not.

It's possible, yes, but this is why it's important to understand the
technology one picks.  TCG, for example, picked PKIX then they created
non-string-valued attributes (%^&@!).  Tools are just that, and you can
always misuse the right tools, or pick the wrong tools to begin with.

That's why my post ended with an imploration to know what came before
before one goes around reinventing the darned thing.

Since this sub-thread is devolving into what went wrong with x.509,
maybe we should also look at what went right, and about the only things
I can think went right was:

 - that it got extended to support arbitrary naming forms,
 - EKUs,
 - and that PKIX usage is evolving towards short-lived certificates to
   avoid dealing with revocation.

Also, having end entities send their certificate chain.  RPs simply
can't construct validation chains from just EE certs, and it was always
pure fantasy that they could, just as public X.500 DAP / LDAP
directories full of private information made public was always a 1980s
naive fantasy.  Ah, the naive 80s, before the Morris worm, before spam,
back when the only people on the Internet were professors, grad
students, and the military.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 15:44:19 -0500

On Tue, Mar 2, 2021 at 1:39 PM Nico Williams <[email-masked]> wrote:

> >                                                    [...] And once you

Getting back to the constraints of 30MHz Windows 95 PCs. Has anyone here
tried to create a 2048 bit RSA key on a BBN safekeyper box?

The notary videographer did not expect to be spending eight hours filming
absolutely nothing happening.

Back in 1995, signing a new cert for each subscriber every day was
impossible. Now it is completely feasible.

With threshold techniques, we don't even need the subscriber to make a new
cert request and we can still roll the key:

* Alice creates public/private key pair {a.P, a}, sens a.P to Carol

t=0) Carol validates the request generates a new keypair {c0.P, c0} and
sends back a certificate for { (a+c0).P, a+c}. and the value c0 Carol
doesn't know a of course but she can calculate a.P + c0.P which is the same
thing. This cert is valid for 48 hours.

t=1) The next day, Carol sends a certificate for { (a+c1).P, a+c}. and the
value c1

t=2) The next day, Carol sends a certificate for { (a+c2).P, a+c}. and the
value c3

t=3) 'Alice' turns out to have never been Alice, it was Mallet. Carol stops
sending her new certificates.

I could write a spec for this in PKIX if anyone was interested. Of course,
you would end up listening to me yacking on about the Mesh while I did it.

This approach would completely eliminate the need for CRLs except for
purposes of recording the fact an issue arose for purposes of interpreting
signatures.

Of course, we would have to modify TRANS to make this work or else those
logs are gonna BLOW! Basically, you would have to log a template for the
cert rather than the cert itself. And there would need to be an extension
in the cert so things were all tickety boo. But it is all doable.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 12:49:54 -0800

> and dispense with revocation.

Or just directly query the domain for the public key and turn it into a 
caching problem instead of a revocation problem. Caching has appeal 
because the TTL can be zero as needed.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 12:55:53 -0800

On 3/2/21 12:44 PM, Phillip Hallam-Baker wrote:
> On Tue, Mar 2, 2021 at 1:39 PM Nico Williams <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Getting back to the constraints of 30MHz Windows 95 PCs. Has anyone 
> here tried to create a 2048 bit RSA key on a BBN safekeyper box?
>
> The notary videographer did not expect to be spending eight hours 
> filming absolutely nothing happening.
>
> With threshold techniques, we don't even need the subscriber to make a 
> new cert request and we can still roll the key:
>
> t=0) Carol validates the request generates a new keypair {c0.P, c0} 
> and sends back a certificate for { (a+c0).P, a+c}. and the value c0 
> Carol doesn't know a of course but she can calculate a.P + c0.P which 
> is the same thing. This cert is valid for 48 hours.
>
> t=1) The next day, Carol sends a certificate for { (a+c1).P, a+c}. and 
> the value c1
>
> t=2) The next day, Carol sends a certificate for { (a+c2).P, a+c}. and 
> the value c3
>
> t=3) 'Alice' turns out to have never been Alice, it was Mallet. Carol 
> stops sending her new certificates.
>
>
Or skip all of this complexity and just enroll the naked public key 
bound to whatever name you like (if any) and having the side benefit of 
not having to deal with a dinosauric encoding scheme.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 16:38:58 -0500

On Tue, Mar 2, 2021 at 3:56 PM Michael Thomas <[email-masked]> wrote:

> Or skip all of this complexity and just enroll the naked public key bound
> to whatever name you like (if any) and having the side benefit of not
> having to deal with a dinosauric encoding scheme.
>
https is not the same as TLS. You don't need the TLS name to be bound to
the domain but the https name does. And you also have to provide backwards
compatibility for 30 years of https browsers.

We looked at this approach in 1995. Really we did. And the problem is that
you aren't avoiding a central point of control, you are pretending ICANN is
that point of control. And it isn't up to that role institutionally, nor is
DNS suited for that purpose.

The Mesh callsign registry is designed to support exactly that.

Henry's Hosting registers the callsign @henry as follows

Callsign: @henry
Profile fingerprint : MD4R-HO4D-AZY3-MZ3A-K7KP-N67I-LSUT
DNS: {10.0.0.1,  10.0.0.2}

Alice uses Henry's hosting:

Callsign: @alice
Profile fingerprint : MCQB-GS7P-HBSV-TKWW-WSD5-NSID-VU4L
Service: @henry

Both are enrolled in the notorized, append only callsign log. Think of it
as a blockchain that doesn't require more electricity than Argentina uses
to function. So the binding from the callsigns to the keys is solid. It
cannot be unrolled without relying parties being aware it has been unrolled.

The Mesh foundation is a wafer thin registry that does not provide query
functions. All it supports is incremental zone transfer of the entire log
to parties who do provide that function. The $0.10 fee to create a new
callsign is principally there to keep the log size bounded so that an
incumbent doesn't try to spam the log to raise the cost to service
providers.

Alice can now create a web site https://alice.mesh/ which can be found by
any Mesh aware browser as follows:

.mesh is a reserved TLD that I don't feel the need to pay $250,000 in ICANN
rent to get. Flood the zone worked for .onion and it will work for this.

Bob's mesh aware browser interprets the domain as follows:

1) Query Bob's MSP to resolve the callsign @alice, this causes both records
to be returned.

2) Query Henry's DNS at 10.0.0.1/10.0.02 which publishes the authoritative
zone for alice.mesh. This zone MUST be DNSSEC secured under a key that has
a validation path up to Henry's profile MD4R-...

3) Start TLS, get the cert back, this MUST include a valid chain to Alice's
cert root under her profile MCQB-... It MAY include a valid chain up to a
CABForum DV or EV root. A Mesh aware browser will trust it either way.

Carol's non mesh browser can only resolve this web site if there is some
registry out there providing a shadow service of the .mesh pseudo domain
using the callsign registry to populate it. That may happen of course. In
fact it is likely to happen but Carol's non mesh aware browser will only
consider the cert valid if there is a valid cross cert to one of the
browser roots.

So did people notice what I did there? This trust chain costs only a few
pennies to set up if Alice and Henry chose callsigns of 9 characters or
more. It provides the functionality of a DNS name AND the functionality of
a TLS DV cert. And there are no renewal fees for either.
This trust chain can be validated by Bob and the only thing he is trusting
is that nobody have futzed with the Merkle Tree authenticated append only
callsign log. And I can make the work factor on that practically infinite.
Oh and BTW, I didn't write a single line of description or code for this
project until after I left Comodo and after my non compete clauses had
expired (not that they would have been enforceable).

The trust path for validating the name of the site does not involve either
ICANN or any CA. [There are some issues to do with IPR in the names I am
eliding but these are considered in the detailed specs]

So what does this mean for CAs? Well they still have two important WebPKI
roles. First, they are the only parties that can provide certs that work
with legacy browsers and that will be a profitable number of users for at
least a decade. Second, they will still have an important function for
providing the accountability that the WebPKI is there to provide.

But more importantly for them, Threshold Key Infrastructure provides vastly
more functionality than legacy PKI. The Mesh will cannibalize their legacy
business over time but the opportunities that will replace that are orders
of magnitude greater. The Mesh protocols make use of Lototypes for
communicating trust to the end users. Also, the CAs are the parties best
positioned to run MSPs.

What does this mean for the wider industry? Well it is simple: This is how
all the IoT devices you are wanting to sell to Alice can use TLS to secure
the connection to their local web server console. You give each customer a
voucher that is redeemable for registering one callsign and that will cost
you $0.10 if they need to use it.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 14:19:12 -0800

On 3/2/21 1:38 PM, Phillip Hallam-Baker wrote:
>
>     Or skip all of this complexity and just enroll the naked public
>     key bound to whatever name you like (if any) and having the side
>     benefit of not having to deal with a dinosauric encoding scheme.
>
> https is not the same as TLS. You don't need the TLS name to be bound 
> to the domain but the https name does. And you also have to provide 
> backwards compatibility for 30 years of https browsers.

As I said, x.509 with TLS for https is water under the bridge. My point 
is that we don't need to keep thinking that they are the only way or 
even the preferred way to implement identity with asymmetric keys across 
trust boundaries, and most especially not when they are within trust 
boundaries. I've seen people get completely wrapped around the axle 
trying to shoehorn enterprise level certs and just shake my head of what 
on earth they are thinking.

>
> We looked at this approach in 1995. Really we did. And the problem is 
> that you aren't avoiding a central point of control, you are 
> pretending ICANN is that point of control. And it isn't up to that 
> role institutionally, nor is DNS suited for that purpose.

So instead we got a whole bunch of trust anchors basically by fiat. And 
business models. Lots of business models.

> The Mesh callsign registry is designed to support exactly that.
[]

Is this supposed to make me feel better about induced complexity?

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 17:27:37 -0500

> Is this supposed to make me feel better about induced complexity?
It is much simpler than what we have today and one person has written all
the specifications and 90% of the code in 26 months, and I was recovering
from whatever I picked up in Singapore for six of those.

Things should be as simple as possible but it is absolutely critical that
they not be made simpler. I have 30 years experience with this technology
and its application to the real world. The Mesh PKI side is much simpler
than PKIX, OpenPGP or SAML but it is not simple. I know what I missed by
trying for too much simplicity in XKMS.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 15:23:24 -0800

On 3/2/21 2:27 PM, Phillip Hallam-Baker wrote:
> On Tue, Mar 2, 2021 at 5:19 PM Michael Thomas <[email-masked] 
> It is much simpler than what we have today and one person has written 
> all the specifications and 90% of the code in 26 months, and I was 
> recovering from whatever I picked up in Singapore for six of those.
>
> Things should be as simple as possible but it is absolutely critical 
> that they not be made simpler. I have 30 years experience with this 
> technology and its application to the real world. The Mesh PKI side is 
> much simpler than PKIX, OpenPGP or SAML but it is not simple. I know 
> what I missed by trying for too much simplicity in XKMS.
>

So I just looked up ssh certificates which I think somebody mentioned. 
This is a prime example of throwing needless complexity at a problem. If 
you just added the user's public keys to, say, an LDAP repo, you get the 
scaling they claim to be solving for, and avoid all of the needless 
complexity of issuing certs and installing them on the client. The 
client ssh doesn't need to do anything different as bonus. With LDAP you 
get the added bonus that it can dish out attributes for things like 
roles and permissions, which would be a giant headache if it had to be 
done with reissued certs every time your role or permission changed.

I'm trying to think of major things that use public key authentication. 
There's TLS with certs, DKIM using raw public keys, and SSH mainly using 
raw public keys. Am I missing anything else that is widely deployed? 
DNSsec and BGP are still pretty skimpy from what I can tell.

Mike

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 17:49:29 -0600

On Tue, Mar 02, 2021 at 03:23:24PM -0800, Michael Thomas wrote:
> So I just looked up ssh certificates which I think somebody mentioned. This
> is a prime example of throwing needless complexity at a problem. If you just
> added the user's public keys to, say, an LDAP repo, you get the scaling they

In the 80s the naive assumption was made that we'd have "white pages" --
directories -- where we could do such lookups.  I think that's what you
have in mind since you refer to an "LDAP repo".

That did not work, and cannot work because it has privacy issues, at
least when you do lookups _by name_.

Now, maybe you have something different in mind.

The authenticating party presents a directory name, a public key, and a
signature, and the RP looks up the key in the directory to get a name?

That might not have privacy issues, but it still requires online infra
that someone has to pay for, and that RPs need to contact (so they need
to do async I/O, naturally).  More things to break.

And, of course, LDAP is insanely complex and brings X.500 naming right
back into the picture completely unnecessarily (along with ASN.1,
naturally).

> claim to be solving for, and avoid all of the needless complexity of issuing
> certs and installing them on the client. The client ssh doesn't need to do
> anything different as bonus. With LDAP you get the added bonus that it can

The client is also a relying party though, since it has to authenticate
the server.

> dish out attributes for things like roles and permissions, which would be a
> giant headache if it had to be done with reissued certs every time your role
> or permission changed.

Certificates are infinitely easier.  Now, you mention "the needless
complexity of issuing certs and installing them on the [authenticating
party]".  But that's not so complex.  You can run an online CA that
issues short-lived client certificates based on a longer-lived
credential, and that and "installing" the certificates (and private
keys) are purely internal details that users shouldn't need to know.
That works for corporate networks, but it should work for a home network
too.  For a Mesh-like scheme you're really going to need long-lived
(forever) device public keys and revoke them only in the sense of
removing the public keys from Alice's other devices, and there is a
directory in Mesh case, but it's purely local (just Alice's devices,
which should be few enough that the whole thing scales fine).

> There's TLS with certs, DKIM using raw public keys, and SSH mainly using raw
> public keys. Am I missing anything else that is widely deployed? DNSsec and
> BGP are still pretty skimpy from what I can tell.

Kerberos, with PKINIT.  Mosh?  But note that SSH, TLS, and Kerberos (or,
rather, GSS-API) covers... a lot of protocols -- practically all
Internet protocols.

Nico
--

---

From: George Michaelson <[email-masked]>
Date: Wed, 3 Mar 2021 10:00:35 +1000

I "worked" (some might dispute it was work, or even helped) on X.500
in UCL-CS under Steve Kille, and at CSIRO, in this time. (on Quipu)
and at UQ in a national X500 project we ran in AARNet.

The X.500 nameforms are complex because human names are complex. I
have friends with one name, who are forced to enter their names twice,
to pass input field validity checks, and who have problems at borders
with their passport and data matching.

Some people change names as a function of gender re-assignment (when
the titular element of the name is baked into the name) or because of
ritual or because of status changes. Names are not static

Name order is cultural. Japan, with the change of Emperor, semi-hemi
formally changed the expected display order of Surname and given name.
Some Japanese like it and some don't. Chinese and Korean and
Vietnamese might share this, or not, "it depends"

I think there is a version of "7 bit ascii was good enough for me" in
names. People love to simplify from their own cultural norms. This
rarely scales.

I worked on this, in an economy (Australia) with 40% of the population
of migrant extraction or actually migrants themselves. I can tell you,
Names are not simple.

X.500 is complicated because names are complicated.

-G

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 16:17:28 -0800

> Now, maybe you have something different in mind.

I'm talking about the server side sshd just fetching the associated ssh 
keys with the user trying to log in, maybe with some authz sprinkled in 
for finer granularity. It could be LDAP, it could whatever you want. I 
don't know how configurable sshd is, so that might limit your choices.

> back into the picture completely unnecessarily (along with ASN.1,

I'm just using LDAP as an example of a well known corpro directory. It 
could be anything. It just needs to be something online that can store 
the name public key(s) binding so that the sshd can see if they should 
allow that user/key to log in.

> The client is also a relying party though, since it has to authenticate
If you care about that, I suppose. I think most people do the leap of 
faith and known_hosts ignores the problem.
> which should be few enough that the whole thing scales fine).

I don't see how doing nothing at all on the client can be "infinitely 
easier" than doing a lot of something else. Every company large enough 
to care about scaling authorized_keys is going to have some sort of 
employee directory system, so that complexity is baked in. And a 
directory based system doesn't suffer from the revocation problem 
either: if I lose my phone, I can just go and delete it as one of my 
devices.  On the server side it's six of one, half dozen of the other: 
it's just configuration that is baked with chef or puppet when it's 
brought up.

> rather, GSS-API) covers... a lot of protocols -- practically all

Is anybody using PKINIT?

Mike

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 18:18:25 -0600

> with their passport and data matching.

And yet name@domain has succeeded where X.500 failed.  That's because
people like nicknames, and name@domain is a nickname.

> X.500 is complicated because names are complicated.

Also, X.500 for naming humans isn't very complicated.  In PKIX it's
givenName, initial, surname, generation qualifier, and title.  It could
have been more complicated.  My mother had 3 middle names, for example.

It's true that somewhere one has to put complex name information, but
it's not true that one must use complex name information everywhere and
all the time.  Nor is it true that one must parse complex names into
complex data structures when simple strings might suffice.

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Mar 2021 16:19:57 -0800

> X.500 is complicated because names are complicated.

Well, no. George, I worked on X.500 at the same time you did, and my 
conclusions are different. X.500 names main source of gratuitous 
complexity what that they embedded an arbitrary hierarchy. If I remember 
correctly, the name hierarchy in X.500 embedded things like country 
name, telecom company name, city, street, company (aka, organization), 
department (a.k.a., organization unit), maybe several levels of those, 
and then common name. Some attributes did not identify the person at 
all, but where there to route the query to relevant database. Many of 
these attributes are useful when searching for "Jane in Marketing", but 
the fact is that pretty much each of those attributes have different 
possible values like short or long versions, and that they are probably 
not all required to identify the person. In order to manage the system, 
users were expected to pick a specific subset of "distinguished" 
attributes, which would have enough routing information in them to find 
the relevant database and then uniquely identify an entry in that 
database -- that's why the X.500 names in certificates are called 
"distinguished names". Suffice to say that people found it way easier to 
refer to "[email-masked]".

-- Christian Huitema

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 18:23:31 -0600

On Tue, Mar 02, 2021 at 04:17:28PM -0800, Michael Thomas wrote:
> I'm talking about the server side sshd just fetching the associated ssh keys
> with the user trying to log in, maybe with some authz sprinkled in for finer
> granularity. It could be LDAP, it could whatever you want. I don't know how
> configurable sshd is, so that might limit your choices.

I wouldn't want to do this.  It's much more complex than the client
sending a certificate.

And getting their public key(s) (they will almost certainly have more
than one, and many ephemeral) into the directory is the equivalent of
getting a certificate issued.  So you're not saving anything, and you're
adding complexity, and if you're using LDAP you're not even getting rid
of x.500 or ASN.1.

> I'm just using LDAP as an example of a well known corpro directory. It could
> be anything. It just needs to be something online that can store the name
> public key(s) binding so that the sshd can see if they should allow that
> user/key to log in.

It can't be anything.  It has to be standard-enough.

> If you care about that, I suppose. I think most people do the leap of faith
> and known_hosts ignores the problem.

I very much care about that.  Certainly in a corporate network.

> easier" than doing a lot of something else. [...]

It's not nothing.  New keys?  Update the directory.  Same complexity as
getting keys certified, only worse because the online CA only needs to
be online when you want new keys / certs, but the directory has to be
online any time you want to use those keys.

> Is anybody using PKINIT?

Yes.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 16:43:10 -0800

> I wouldn't want to do this.  It's much more complex than the client

Huh? It's a bit of configuration on the server side that is probably 
captured in provisioning systems. And client provisioning -- which is 
what certs imply -- is extremely problematic. How do I get a client ssh 
cert onto my phone's ssh app, for example? Not having to change client 
behavior or provisioning significantly simplifies the problem.

> adding complexity, and if you're using LDAP you're not even getting rid
Not having to do anything at all on the client is a significant savings. 
I would much rather the help desk cost of nothing different than taking 
calls on how to install the ssh certs on exotic and not so exotic clients.
> I very much care about that.  Certainly in a corporate network.

It's orthogonal to the client side authentication problem though.

> online any time you want to use those keys.

Uploading a new public keys is the ~same for both. Downloading a client 
cert is a whole lot of something. And if your corpro directory is down, 
you are already in a world of hurt. The advantage of offline 
verification in the age of 24/7 internet is very niche.

> Yes.

Where? In any volume?

Mike

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 18:51:36 -0600

On Tue, Mar 02, 2021 at 04:43:10PM -0800, Michael Thomas wrote:
> captured in provisioning systems. And client provisioning -- which is what
> certs imply -- is extremely problematic. How do I get a client ssh cert onto
> my phone's ssh app, for example? Not having to change client behavior or
> provisioning significantly simplifies the problem.

It's the same problem as getting the keys into the directory.

> Not having to do anything at all on the client is a significant savings. I
> would much rather the help desk cost of nothing different than taking calls
> on how to install the ssh certs on exotic and not so exotic clients.

Yes, if you ignore the part about having to get the keys into the
directory.

> It's orthogonal to the client side authentication problem though.

It's a similar problem, and you can't ignore it.

> Uploading a new public keys is the ~same for both. Downloading a client cert
> is a whole lot of something. And if your corpro directory is down, you are
> already in a world of hurt. The advantage of offline verification in the age
> of 24/7 internet is very niche.

We have an online CA with an HTTP API.  You POST a CSR authenticating
with whatever credentials you've got, and you get back a short-live
certificate for your authenticated name(s) or for the requested name(s)
if you're authorized to them.  Using this is trivial.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 18:57:47 -0600

> Where? In any volume?

Corporate networks.  The only place where Kerberos is used.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 17:06:47 -0800

> It's the same problem as getting the keys into the directory.

But it's not the same problem as getting a cert (chain) out of the CA 
and installing it on the client. In the one case it is nothing at all to 
do, in the cert case it's a whole lot of things to do and go wrong. 
Client provisioning is a minefield and it speaks miles that there is 
little to no client cert deployment for anything. Even with ssh where 
clue is probably higher than average, I wouldn't want to think about the 
support desk implications.

> Yes, if you ignore the part about having to get the keys into the
They both have to do that, so it cancels that out.

> if you're authorized to them.  Using this is trivial.

That doesn't alter that needing offline authentication is niche. A Mars 
rover might need that. My phone connected to the internet, not so much.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 17:09:06 -0800

> Corporate networks.  The only place where Kerberos is used.

Really? What is the use case? I'm under the impression that Kerberos has 
mostly been relegated to Active Directory and that's about it. I like 
Kerberos, fwiw.

Mike

---

From: George Michaelson <[email-masked]>
Date: Wed, 3 Mar 2021 12:10:13 +1000

I think you worked on this far more than me, and I think your work on
this was far more important than mine. Mainly, I recall you hosting
the collaborative workshop in INRIA and my pleasure at red wine and
fresh fruit for lunch, from the refectory. Happy days!

I don't  disagree with anything you say Christian. Your point is (to
me at least) people want simpler forms to use in everyday life.

If however, you drive X.500 into use for structural naming against
government process, documents, your legal status against other people,
rank (in the military) then these complexities surface very rapidly.
Lying underneath, is the problem in the US where some people never
completely recover from identity theft because these structural forms
were not properly respected, and simpler use of names and identity
were overwritten. When you fill in paperwork, which is going to mint a
digital identity, there is what CN and SN have become. When you want
to find the correct instance of somebody against the 1000 other people
with "the same name" it becomes important which field was used for
which element.

X.500's complexity reflects goal-seeking to "but what is the
functionally correct attribute in a model, for this data" when names
tend more towards "what do you call yourself, and how unique is this
in context"

cheers

-George

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 20:17:33 -0600

> mostly been relegated to Active Directory and that's about it. I like

Use cases:

 - smartcards

 - anonymous Kerberos (requires PKINIT)

 - batch jobs

   You can have a trust anchor where a CA issues certificates with a
   Kerberos SAN and the PKINIT EKU and then that can be used to get
   tickets on behalf of that user for their batch jobs.

I don't like Kerberos, not Kerberos V, but I do like Needham-Schroeder,
and I suspect we may want to sprinkle a bit of Needham-Schroeder onto
a post-quantum future as an optimization for PQ crypto.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 21:17:55 -0500

On Tue, Mar 2, 2021 at 7:20 PM Christian Huitema <[email-masked]>
wrote:

> and then common name.

X.500 was designed to support X.400 email which was designed to replace
mail. So of course you would write out the postal address to send an email.
Email is mail right? Skendomorphism rulz.

DNS also suffers from gratuitous hierarchy but it is only one layer of
bogosity most of the time. There was never any logic to .com/.net/.edu it
was a naive taxonomy which has only worked for extracting rents. It worked
because it was only four redundant characters.

Names are simple, it is when people try to encode unnecessary assumptions
into them that it all collapses.

On Tue, Mar 2, 2021 at 6:23 PM Michael Thomas <[email-masked]> wrote:

> complexity of issuing certs and installing them on the client. The client
> ssh doesn't need to do anything different as bonus. With LDAP you get the
> added bonus that it can dish out attributes for things like roles and
> permissions, which would be a giant headache if it had to be done with
> reissued certs every time your role or permission changed.
>
> raw public keys. Am I missing anything else that is widely deployed? DNSsec
> and BGP are still pretty skimpy from what I can tell.
>

Or you could use XKMS which is a W3C spec that does exactly that.

The peculiar thing about SSH certs is that they only exist for servers, not
for users. At least as far as I could see.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 20:22:35 -0600

On Tue, Mar 02, 2021 at 05:06:47PM -0800, Michael Thomas wrote:
> But it's not the same problem as getting a cert (chain) out of the CA and
> installing it on the client. [...]

The latter is strictly simpler for the reasons I gave.

> They both have to do that, so it cancels that out.

But the directory case requires things that don't exist (e.g., schema,
tools) and also online infrastructure.  Certificates don't.

> rover might need that. My phone connected to the internet, not so much.

You say niche, but it's not at all.  And before anyone mentions CRLs
and/or OCSP, the real answer to revocation os short-lived credentials
(with fast, unforgiving rotation schedules).

We issue 5 day server certs, for example.  We also have a Kerberos KDC
extension that uses virtual service principals keyed on a clock, with
services having to fetch "keytabs" frequently via an HTTP API.

This is strictly simpler than having to modify a bunch of applications
and libraries to do directory lookups.  And there is no online
infrastructure at the point of authentication in the PKIX case.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 20:24:32 -0600

> for users. At least as far as I could see.

No, they exist for users.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Mar 2021 19:00:35 -0800

> The latter is strictly simpler for the reasons I gave.

It is literally nothing different in use, rather than having to figure 
out how to install certs. It is ridiculously harder to use client certs. 
If it weren't we'd see client side certs all over the place. We don't. 
That is for a reason.

> tools) and also online infrastructure.  Certificates don't.
NRE vs constant help desk. I'll take that. And of course there is 
considerable NRE for certs too.
> (with fast, unforgiving rotation schedules).

Where are all of these use cases that need offline verification? I asked 
somebody else and didn't get an answer.

All of this tells me that there is a witching hour with certs that 
hasn't been broken in almost 40 years.

Mike

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 21:35:56 -0600

On Tue, Mar 02, 2021 at 07:00:35PM -0800, Michael Thomas wrote:
> NRE vs constant help desk. [...]

I can't parse "NRE".

> somebody else and didn't get an answer.

Admins *really* like to be able to get into their servers when bad
things happen on their networks and necessary infrastructure is down.
SSH generally gives you that.

> All of this tells me that there is a witching hour with certs that hasn't
> been broken in almost 40 years.

Short-lived certs == no one ever forgets to automate the fetching of new
ones.

When you have two-year certs you need CRLs and OCSP and you always
forget to renew.

When you have five-day certs you cannot forget to renew more than twice
because you won't like the constant outages, so you'll automate.

Heck, you could dial that down to eight-hour certs.  After all, with JWT
we use JWKs that last only a few hours, so you *really* have to fetch
them on a schedule.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Mar 2021 00:34:19 -0500

The practical limit on certificate lifespan is 48 hours renewed every 24
unless you have a means of reliably getting trusted time into the client.

I have been trying to find info on SSH user certs on and off for quite a
while. Seems like an under-documented feature... They solve a big problem
for me :-)

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Mar 2021 09:26:33 -0600

> unless you have a means of reliably getting trusted time into the client.

For server certificates five days is fine.  For clients you want
something akin to Kerberos.  Typical Kerberos installations issue 10
hour TGTs that are renewable (note: Kerberos sense of renewal) for a few
days, and after that the user has to type in their password or do
whatever MFA dance.

> while. Seems like an under-documented feature... They solve a big problem

Honestly, they're not that interesting to me because of the limited
hierarchy they have.  I'd rather it were PKIX certs.  But at least they
got something right: subject naming, which they call principal names,
and which are just strings, freeform strings.  That means that if you
are migrating from some other system, you can keep that other system's
naming.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Mar 2021 12:43:08 -0500

> are migrating from some other system, you can keep that other system's

Thats all I need. Consider the case where Alice is using the Mesh to manage
her SSH credentials. She has 5 devices she uses as a client and accesses 24
different servers.

Cryptographic hygiene requires each device have separate SSH credentials.
Doing that with raw keys is beyond tedious because the admin tool has to
log into every one of those 24 servers to update Alice's authorized
keys file.

If the certificates are actually supported by GitHub etc, and can be used
in the same spot that regular keys are, everything is tickety boo. If this
is a theoretical feature supported by a fraction of the installed base...
not so much.

And it looks like Github supports user certs but only in the paid
enterprise version. Which doesn't work for my objective of getting the open
source development ecosystem fixed...

Part of the plan here is that I want to get to a place where ALL code is
signed. Especially code that is in development. Every build should be
signed, every item in every assembly. Which is yet another reason why my
Merkle Tree based DARE is vastly superior to WPACK.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Mar 2021 09:50:30 -0800

>> NRE vs constant help desk. [...]

Non-recurring engineering, ie upfront cost.

> we use JWKs that last only a few hours, so you *really* have to fetch

Or you just expect online and not worry about any of this.

I'm not even sure why you'd want to use certs in your use case. You're 
just reinventing Kerberos.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Mar 2021 13:32:08 -0500

> just reinventing Kerberos.

It really isn't useful to discuss how PKIX makes use of client certs, it
failed to achieve ubiquitous use, the management of private keys is
horrible and revocation doesn't do what you want.

Something I learned in the past few days is that revocation is not part of
authentication at all. It is exclusively a part of authorization. The
device has been authenticated to the key even if the certificate was
revoked.

What enterprises want for revocation of user credentials is a scheme that
allows all use of the credential to be disabled within 30 minutes. The
objective being that during the time Mallet is getting his termination
interview in Alice's office, every open session Mallet has established is
disconnected and he is prevented from creating any new ones.

I just don't see OCSP or any other PKIX technology doing that. And neither
does the Mesh currently.

And it isn't just Mallet that is the issue here, it's also Alice's phone
which Mallet swipes during the termination interview, that has to be
disabled the minute Alice realizes it is gone.

Coincidentally, I am just working on that exact bit of the Mesh
architecture. I think we can reuse the 'heartbeat' capability required in
any presence protocol. If Alice can get messages on a device, it has to be
telling the service where it can be reached.

So Alice's cell phone is going to be pinging Alice's MSP with a UDP packet
once a minute or so. And that allows the device to send out updates
whenever one of the catalogs that device is subscribed to is updated. It
also allows Alice to be told of an incoming call, etc. etc.

We can do the exact same thing when Alice uses her credential to connect to
a service. The relying service takes out a subscription to the credential
source and gets a notification when it is revoked.

The exact same code path can be used when there is a change in Alice's
authorization status while a device is connected. And that can go up as
well as down.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Mar 2021 12:38:24 -0600

> Or you just expect online and not worry about any of this.

No, sorry.  I've explained.  We'll have to disagree.

> I'm not even sure why you'd want to use certs in your use case. You're just
> reinventing Kerberos.

Because we have a principal for a user, and also a trusted thing that
wants to impersonate them (in order to run the user's batch jobs) but
without the user having to delegate a credential to them.  So we issue
that thing a client certificate (that the user never sees) that can be
used to acquire a TGT on behalf of the user.  This isn't remotely like
reinventing Kerberos.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Mar 2021 14:05:33 -0500

When I was writing my intro to crypto course, I covered Kerberos and then
moved on to PKI, I was astonished at just how close the Kohnfelder model
hews to Kerberos (maybe not so surprising, it was an MIT undergrad thesis).

But here is the thing, nobody should ever be ashamed of 're-inventing'
systems of the past. If old techniques work, then use them.

Since adding PKI to Kerberos wasn't exactly successful, one is going to
have to add PKI to Kerberos or Kerberos to PKI and the complexity of either
is likely to be rather greater than designing something from scratch using
the experience of the past 40 years.

There were dozens of AAA products on the market when I started work on
SAML. And SAML is merely PKIX attribute certificates done right encoded in
XML.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Mar 2021 13:56:28 -0600

> Since adding PKI to Kerberos wasn't exactly successful, one is going to

I wouldn't say that PKINIT has failed.  It works, and it is used.  It's
not used widely as intended (i.e., with smartcards) because what failed
is smartcards.

If you use PKINIT as a bridge, and you have online CAs, and online JWT
issuers, and... you can have whatever kind of credential you want as a
root credential.  One might use KSATs or GSATs as root credentials, or
Kerberos, or smartcards, or whatever.

I've been building authentication bridges because it turns out that
getting the whole world to support the one authentication system, or
some minimal set of authentication systems, is impossible.

(Aside: one design for PKCROSS is basically online CAs + PKINIT.)

> the experience of the past 40 years.

I'd rather start from scratch when it comes to Kerberos.  Too many
mistakes were made in Kerberos V's design (listing them should require a
separate thread).

Also, Kerberos as a competitor to TLS failed, leaving it mostly only a
role as a token system akin to JWT with symmetrically encrypted tokens
(a mostly unused option of JWT's).  GSS-API as a pluggable system has
also failed except in so far as it could be an API for TLS (as GSS-API's
Windows cousin, SSPI, is).

Note that failure in this context doesn't mean "and we can obsolete and
remove the failed thing".  Even failed things tend to last forever :(

The great thing about Needham-Schroeder is that it depends only on
symmetric crypto, which is good news in a PQ world, and in a post-RSA
world (if we're there).  Even better is that combining PK and Needham-
Schroeder is an optimization for slow PK, which is what you want in a PQ
world.

The bad thing about Needham-Schroeder is that setting up trusts is a
very manual process and needs PK in order to automate it (or better, in
order to not need to setup trusts at all).  But again, that just leads
one to want to combine Needham-Schroeder with PK.

Nico
--

---

From: Jared Mauch <[email-masked]>
Date: Thu, 4 Mar 2021 04:35:05 -0500

On Mon, Mar 01, 2021 at 05:18:10PM -0800, Michael Thomas wrote:
> The combination of ASN.1 and X.509 has done irreparable harm to identity on
> the internet. X.509 provides exactly one benefit: the ability to verify
> offline that almost nobody cares about anymore. They have needlessly

	As someone who had to build my own fiber/internet access in
a developed country, I believe the community often misses the mark in
assuming everyone is as well connected as they are.

	I encourage you to review this assumption.

	- Jared

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 05:42:34 -0500

+1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Mar 2021 09:57:47 -0500

On Thu, Mar 4, 2021 at 4:35 AM Jared Mauch <[email-masked]> wrote:

> on

It is really rare that people try to use TLS without Internet connectivity.
And the deployed base really isn't good at working in that mode.

Kohnfelder was originally writing for email messaging. But even then, how
do you send a mail without some connectivity?

X.509 is really optimized around the totally offline case. And that is a
bad choice for many applications. But it does work for some.

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Thu, 4 Mar 2021 16:11:18 +0100

On 4 Mar 2021, at 15:57, Phillip Hallam-Baker <[email-masked]> wrote:

> Kohnfelder was originally writing for email messaging. But even then, how do you send a mail without some connectivity?
> 
> X.509 is really optimized around the totally offline case. And that is a bad choice for many applications. But it does work for some.

Though increasingly (in Europe at least) - that off-line also is becoming increasingly useful in the on-line world; and playing a role in DPIA's and similar privacy assessment  (GDPR mandated or just as good practice).

As it allows key management, verification, etc without necessarily telling world+dog what you are doing (but for the occasional bulk down load of some CRLs).

Dw.

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Mar 2021 09:52:23 -0600

> bad choice for many applications. But it does work for some.

No, that's not it.

X.509 tries to minimize online infrastructure, but not to zero.

In particular, it minimizes *state*.

Kerberos too tries to minimize online infrastructure, but does much less
well than X.509, and, crucially, as-implemented, Kerberos does NOT
minimize STATE.

When we started using elastic clouds and hosts coming and going we
started having trouble scaling Kerberos even with very nice self-service
tooling for it because creating and key-rotating and deleting service
principals requires mutating and replicating state.  What we ended up
doing is implementing a notion of namespace wherein all host-based
service principals have their keys derived from base keys, the
principals' names, and the _clock_, leading to an unforgiving key
rotation schedule and needing host-based roots of trust other than
long-term keys for host-based services (since, after all, hosts/apps
need credentials to fetch these fast-changing Kerberos keys).

To make Kerberos scale we had to remove its dependence on state
mutation.  Fortunately the state mutation aspect of Kerberos is not
inherent in its specification, just in all KDC implementations to date
(except Heimdal, which has the feature described above).

Now, if you start binding public keys to users via a directory, you'll
be unhappy because you'll have all the problems directories have, and
because you might get the schema wrong and allow only one key per-user,
and even if you don't get the schema wrong you'll have a garbage
collection problem, and even if you manage to solve that with
expirations then the act of registering new keys is still more complex
than the act of signing new certificates.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Mar 2021 09:54:18 -0600

On Thu, Mar 04, 2021 at 04:11:18PM +0100, Dirk-Willem van Gulik wrote:
> As it allows key management, verification, etc without necessarily
> telling world+dog what you are doing (but for the occasional bulk down
> load of some CRLs).

You can dispense with CRLs/OCSP if you use sufficiently short-lived
certificates.

That requires an online CA to certify those short-lived certificates,
but it's online infrastructure that is required only once or twice per
rotation period for any one end entity.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 09:04:27 -0800

> In particular, it minimizes *state*.
Um, why should we care about that? Nothing else cares about holding state.
> than the act of signing new certificates.
Oh brother. When you start arguing that people might get implementations 
wrong, you're grasping at straws. All of the sites that I've used that 
allow public key authentication have groked that there might be more 
than one key like, oh say, github. This is complete nonsense. People 
might issue certs for a 150 years too.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 09:07:51 -0800

> rotation period for any one end entity.

"requires an online" being the key phrase. If you require online, you 
can reduce the revocation linger time to zero, and you don't need to 
onerous infrastructure of X.509 at all. Naked public keys are our friends.

Mike

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Mar 2021 11:11:22 -0600

> Um, why should we care about that? Nothing else cares about holding state.

I explained in the text you didn't quote.  Did you somehow miss it?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 09:14:54 -0800

On 3/4/21 6:57 AM, Phillip Hallam-Baker wrote:
>
>
> On Thu, Mar 4, 2021 at 4:35 AM Jared Mauch <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> It is really rare that people try to use TLS without Internet 
> connectivity. And the deployed base really isn't good at working in 
> that mode.
>
> Kohnfelder was originally writing for email messaging. But even then, 
> how do you send a mail without some connectivity?
>
> X.509 is really optimized around the totally offline case. And that is 
> a bad choice for many applications. But it does work for some.
>
>
That's the thing: the only thing that X.509 is used for at any scale is 
TLS and that is definitionally online. Everything else is niche in 
comparison. If you need offline capability, fine, but almost nothing 
does anymore if it's associated with the internet in any way.

Mike

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Mar 2021 11:15:30 -0600

On Thu, Mar 04, 2021 at 09:07:51AM -0800, Michael Thomas wrote:
> "requires an online" being the key phrase. If you require online, you can
> reduce the revocation linger time to zero, and you don't need to onerous
> infrastructure of X.509 at all. Naked public keys are our friends.

The "... that is required only once or twice per rotation period for any
one end entity" part is an essential modifier to "requires an online".
You can't focus on the "requires an online" without addressing the other
part.

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 09:15:36 -0800

> I explained in the text you didn't quote.  Did you somehow miss it?

You asserted it, yes.

Mike

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Mar 2021 11:19:03 -0600

> > I explained in the text you didn't quote.  Did you somehow miss it?

And then you asked me to.. what, assert it again?  Or did you want more
details?  Was your question an implied dismissal of my earlier
explanation?  That's just rude.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 09:19:32 -0800

> You can't focus on the "requires an online" without addressing the other

Your online requirements cherry picks that the online requirements will 
neatly line up in times of need and ignores other online requirements. 
Authentication is one small part of a larger system. That larger system 
almost always needs to be online 24/7. X.509 is a relic from the past.

Mike

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Mar 2021 11:33:55 -0600

> almost always needs to be online 24/7. X.509 is a relic from the past.

I've explained about online requirements on every transaction vs. once
in a while.  It's not cherry-picking.  It's trade-offs.  I've tried
explaining, and you can disagree with good technical arguments about
cases where there's better trade-offs or whatever, but instead you've
just been unnecessarily rude.  Have a nice day.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 10:07:38 -0800

> just been unnecessarily rude.  Have a nice day.

This entire subthread started from the observation that just putting a 
ssh public key in an employee directory would be a lot simpler than 
issuing certificates since it doesn't change anything on the client at 
all. You said that doing something -- installing certificates -- is 
easier than doing nothing at all. It's hard to take that sort of 
statement seriously because it's flat out wrong and contradictory.

But with respect to state and being able to do things offline, if your 
employee directory is down in you average company you have a 5 alarm 
fire that needs to be put out just as much as if your website went down. 
The need for offline verification is niche these days. Since that's the 
only advantage that X.509 brings, that tells me that there is a lot of 
tail wagging dogs going on. As it ever were.

Thankfully beyond the vast confusion factor that x.509 brings it mostly 
doesn't matter these days. Nobody uses client side certs because they 
don't scale. Manifestly.

Mike

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 13:44:18 -0500

On 3/4/21 9:57 AM, Phillip Hallam-Baker wrote:

> connectivity.

That might be due in part to the association, in practice, of TLS with 
verification of DNS names in server certificates.

There are lots of applications (including but not limited to ordinary 
web browsers and servers) running on disconnected and 
intermittently-connected networks out there that need encryption, and 
which can't practically use TLS, because they don't use DNS or even host 
files.   But it's not a limitation of the TLS protocol so much as of the 
APIs and the code that does certificate verification.

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 13:48:38 -0500

On 3/4/21 12:14 PM, Michael Thomas wrote:

> That's the thing: the only thing that X.509 is used for at any scale 
> is TLS and that is definitionally online. Everything else is niche in 

I don't think that's true at all.   There are a vast number of networks 
that are mostly disconnected from the Internet (but probably do connect 
occasionally), but which still use Internet protocols and applications.

It's silly to dismiss those as if they didn't exist or weren't 
important.  They're quite often parts of critical infrastructure.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 10:56:39 -0800

On 3/4/21 10:48 AM, Keith Moore wrote:
> I don't think that's true at all.   There are a vast number of 
> networks that are mostly disconnected from the Internet (but probably 
> do connect occasionally), but which still use Internet protocols and 
> applications.
>

Online != Internet connected. If you're using TLS you are online 
definitionally. You may be on a stub air-gapped network but you're still 
using internet protocols to communicate. That stub network can have all 
it needs to support its infrastructure. It's just as online as anything 
else. X.509 comes from a time where you couldn't even make that 
assumption. Applications that require that assumption are pretty far and 
few between these days.

Mike

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 14:03:06 -0500

On 3/4/21 1:56 PM, Michael Thomas wrote:
> definitionally. You may be on a stub air-gapped network but you're 
> still using internet protocols to communicate. That stub network can 
> have all it needs to support its infrastructure. It's just as online 
> as anything else.

Usually, "all it needs to support its infrastructure" is an Ethernet 
switch or WiFi access point.   DNS is often considered an operational 
hazard in such environments, sometimes DHCP is also, as is firmware update.

> X.509 comes from a time where you couldn't even make that assumption. 
> Applications that require that assumption are pretty far and few 
> between these days.

I don't think it makes sense to waste otherwise good protocol 
engineering just because it doesn't fit someone's idea of "how the 
network works".   TLS can be profiled to work well in such environments 
(without change to the TLS stack), and so can X.509. Why re-invent the 
wheels?

Keith

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 11:17:39 -0800

On 3/4/21 11:03 AM, Keith Moore wrote:
> network works".   TLS can be profiled to work well in such 
> environments (without change to the TLS stack), and so can X.509.  Why 
> re-invent the wheels?
>
>
My point here isn't to defend how TLS works, it's to say that almost 
nothing requires the truly offline verification aspect that x.509 brings 
to the table. I can (and have) built a asymmetric key login mechanism 
that just puts naked public keys into a user table of a database, for 
example. The x.509-first view of the asymmetric keys world has confused 
a lot of thinking and had I introduced it to that mechanism it would 
have worlds more complex and much harder to understand. Designers 
should, dare I say it, be looking at the actual requirements of the 
system before settling on a particular solution.

Mike

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 14:24:29 -0500

On 3/4/21 2:17 PM, Michael Thomas wrote:

> nothing requires the truly offline verification aspect that x.509 
> brings to the table.
>
Emphatically disagree.   There are lots of situations requiring "truly 
offline" certificate verification.

> I can (and have) built a asymmetric key login mechanism that just puts 
> naked public keys into a user table of a database, for example. The 
> x.509-first view of the asymmetric keys world has confused a lot of 
> thinking and had I introduced it to that mechanism it would have 
> worlds more complex and much harder to understand. Designers should, 
> dare I say it, be looking at the actual requirements of the system 
> before settling on a particular solution.
>
Perhaps you should take your own advice.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 11:32:04 -0800

> offline" certificate verification.
What? Seriously what? A Mars rover, maybe? And if they truly need 
offline verification, fine use X.509. For all the rest it is just so 
much more unneeded baggage and confusion.
>
>
>> I can (and have) built a asymmetric key login mechanism that just 
>> puts naked public keys into a user table of a database, for example. 
>> The x.509-first view of the asymmetric keys world has confused a lot 
>> of thinking and had I introduced it to that mechanism it would have 
I did take my own advice. The result was DKIM. So did the SSH folks 
which works just fine on a disconnected network.

Mike

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Mar 2021 17:46:16 -0200

> On Mar 4, 2021, at 4:44 PM, Keith Moore <[email-masked]> wrote:
> 
> There are lots of applications (including but not limited to ordinary web browsers and servers) running on disconnected and intermittently-connected networks out there that need encryption, and which can't practically use TLS, because they don't use DNS or even host files.   But it's not a limitation of the TLS protocol so much as of the APIs and the code that does certificate verification.

TLS without DNS name checks and/or without any hierarchical PKI
is directly supported by OpenSSL.

For example, Postfix (via OpenSSL) supports "fingerprint"
verification of the peer certificate, where a digest of the
server's public key or certificate is matched against the
expected value.  The peer certificate is matched directly,
without any reliance on DNS or trusted CAs.

Postfix supports isolated deployments without DNS (don't
use either setting on MTAs delivering email to the public
Internet):

    # No MX lookups for the nexthop domain
    disable_dns_lookups = yes
   
    # No DNS when mapping hosts to IP addresses
    smtp_host_lookup = native

You can still use TLS, in any of the supported verification
modes:

    http://www.postfix.org/TLS_README.html#client_tls_levels

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 14:59:47 -0500

On 3/4/21 2:46 PM, Viktor Dukhovni wrote:

>> On Mar 4, 2021, at 4:44 PM, Keith Moore<[email-masked]>  wrote:
>>

Yes I know.  But people need web browsers that can do this.  And there's 
still a need to thwart active attacks in such environments.

IOW it's not only TLS and X.509 that are needed, but a stack (including 
browser) that can use these without needing DNS or external connectivity.

Keith

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Mar 2021 15:52:38 -0500

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith>    IOW it's not only TLS and X.509 that are needed, but a
    Keith> stack (including browser) that can use these without needing
    Keith> DNS or external connectivity.

I've been doing this a fair bit for isolated networks for cyber training
and for other things in that space.
We end up providing a DNS and a PKI etc.

At this point it's going to be simpler to provide some good devops'd dns
and PKI than to go develop a custom browser.

I gave a talk on our work at
https://debconf20.debconf.org/talks/32-when-we-virtualize-the-whole-internet/

last year.  It's focused more on the software packaging  aspects of
setting up the more complex aspects of the infrastructure, but does give
an architectural overview for this sort of approach.
If all you need is DNS and PKI and the like, it's much simpler than the
problems I focus on in the talk.

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 16:05:21 -0500

> and PKI than to go develop a custom browser.

I've written code for a variety of environments like these for the last 
13 years or so: gas pipeline monitoring, broadcast television 
operations, traffic signal monitoring/control, factory 
monitoring/automation, avionics, cryogenic dewar monitoring for various 
kinds of environments, and some others that don't come to mind 
immediately.   For the environments I've worked with, any of that kind 
of stuff would be a non-starter.     DNS is rightly seen as yet another 
reason for things to fail, and factories, gas pipelines, etc. are 
intolerant of lines being shut down because some IT guy wanted to use a 
name rather than an IP address. Static IPs work just fine for these 
situations.   External connections are also regarded as security threats 
and generally forbidden, which is not to say that the rules are never 
bent or that nobody every plugs in a nomadic laptop.

So they do need better protection against threats and sometimes they'll 
even admit it (the customers more than the equipment manufacturers), but 
the Big Internet assumptions don't work for them.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Mar 2021 17:01:51 -0500

> browser) that can use these without needing DNS or external connectivity.

Since unlike various sorts of industrial equipment, ... browsers
presumably run on a mainstream OS (BSD, Linux, MacOS, Windows, ...), you
can always MiTM the browser with "stunnel" or fancier proxy, making all
connections to names that resolve to "127.0.0.1", and the proxy making
a connection to a downstream server based on the SNI name.

The proxy can authenticate the target servers via some appropriate
mechanism, but present SNI-based certs acceptable to the browser.

    https://www.envoyproxy.io/docs/envoy/latest/intro/intro

-- 
    Viktor.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Mar 2021 17:02:45 -0500

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> I've written code for a variety of environments like these
    Keith> for the last 13 years or so: gas pipeline monitoring,
    Keith> broadcast television operations, traffic signal
    Keith> monitoring/control, factory monitoring/automation, avionics,
    Keith> cryogenic dewar monitoring for various kinds of environments,
    Keith> and some others that don't come to mind immediately.   For
    Keith> the environments I've worked with, any of that kind of stuff
    Keith> would be a non-starter.     DNS is rightly seen as yet
    Keith> another reason for things to fail, and factories, gas
    Keith> pipelines, etc. are intolerant of lines being shut down
    Keith> because some IT guy wanted to use a name rather than an IP
    Keith> address. Static IPs work just fine for these situations.  

We're not really in agreement here.
I suspect that was true 20 years ago.
I suspect that was believed to be true 10 years ago, and was possibly
true in important cases.

But over time we've gotten better at providing redundant automated
infrastructure for things like naming etc.

I think we've reached a point now where the advantages of having naming
outweigh the disadvantages.

If for some reason that's still not true, the same infrastructure
advances that make it plausible to provide infrastructure like naming in
these environments also give you the mechanisms to go distribute a hosts
file everywhere or to issue certs with a IP SAN if that's really how you
want to go.
I don't think there's much point in the two of us talking past this
point: we are both appealing to our experience and the set of situations
we've studied and we have reached conflicting conclusions.
We've given our input; it's now time for others to chime in.

    Keith>     Keith> External connections are also regarded as security
    Keith>     Keith> threats

I'm disappointed to see  you bringing a red herring like this into the
conversation.
We were both explicitly talking about disconnected/intermittantly
connected networks.
Appealing to external connections would clearly not be the answer there.

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 19:37:24 -0500

> I suspect that was believed to be true 10 years ago, and was possibly
I can only report what I've seen in my own experience, from circa 2007 
up to and including 2020.
> outweigh the disadvantages.

I'd love to hear you make that argument to some of the customers I've 
talked to and see what their responses are.   Maybe they'll eventually 
come around, but different communities have developed different ideas of 
what makes for good operational practice, based on their own 
requirements and experiences.   Meanwhile, trying to tell customers that 
they should do things differently than they "know", that your experience 
from a different environment trumps their experience with their own 
environment, seems like a pretty ineffective way to sell product and a 
pretty good way to market for your competitors.

> conversation. We were both explicitly talking about disconnected/intermittantly
> connected networks.  Appealing to external connections would clearly not be the answer there.

Glad we agree on that.  I only wrote it because lots of IETF people who 
might respond to this thread seem to insist that part of the right 
solution is for all of these networks to connect to the public Internet, 
perhaps through a firewall, so that they can query the public DNS, and 
get firmware updates and root cert updates along with those, perhaps 
CRLs also.

I do get your point that we're better at providing reliable 
infrastructure than we used to be, and maybe someone will figure out how 
to package this really cleanly so that it doesn't require a lot of 
expensive hardware to support in the field.   But I'm not sure how much 
that would address these customers' concerns.   It's pretty hard for IP 
address lookup to fail if you start with the IP address.   And they're 
not renumbering their hosts so they don't need DNS or similar service to 
have stable endpoint names.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Mar 2021 16:51:26 -0800

On 3/4/21 4:37 PM, Keith Moore wrote:
>
> Glad we agree on that.  I only wrote it because lots of IETF people 
> who might respond to this thread seem to insist that part of the right 
> solution is for all of these networks to connect to the public 
> Internet, perhaps through a firewall, so that they can query the 
> public DNS, and get firmware updates and root cert updates along with 
> those, perhaps CRLs also.

Not sure who this strawman is aimed at, but if it's me you're way off 
the mark. Having services inside an air-gapped network is not the same 
as requiring public internet connectivity. That is a completely separate 
argument. And has nothing to do with anything I've been saying either.

Mike

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Mar 2021 19:53:51 -0500

[private reply]

On 3/4/21 7:51 PM, Michael Thomas wrote:
>> who might respond to this thread seem to insist that part of the 
>> right solution is for all of these networks to connect to the public 
> the mark.

Nope, not you.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Mar 2021 11:01:05 -0500

I don't want to wade into this thread much, as I think it's mostly an
irrelevant conversation.

The ANIMA WG has a document, draft-ietf-anima-brski-async-enroll-00 where we
are trying to adapt an online use of TLS (with RFC7030 + RFC8366), to be an
an offline mode with CMP rather than EST for enrollment.

This is a variation of delay tolerant networking (and we currently lack a
deep understanding of what DTNRG has done), where round trips are implemented
by an installer walking up/down (basement) stairs.

Freshness and proof-of-possession of provite key, and proximity are the
challenges.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide