Subject: [saag] A URI for cryptographic keys

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Feb 2015 12:03:58 -0500

This has come up a few times in the past. This time though I would really
like us to get something done.

In a nutshell, it would be really useful if there was a type of URI that
could be simply cut and pasted that would specify either:

* A user account and a means of authenticating a credential that
authenticates the user of that account.

* An Internet service and means of authenticating a credential that
authenticates that service.

So let us say that we are working on ACME or DPRIV and we are looking for a
way to tell the client or device (or whatever) that it should use service X
and authenticate it with key Y.

Forget for a minute the user interface details of how we arrive at this
point. At some point we are going to come down to a DNS name and some means
of authenticating the server key on the client side and a user account and
a means of authenticating the user on the server side.

What I would like is a URI form that would allow this type of relationship
to be described:

user:[email-masked]:AwRhsxbsSU8qI-1vqfVavrKQ
service:example.com:acme.tcp:Ae_9fezf3UABuCE6llMYdDwA

Think of these as the 'thin waist' for authentication mechanisms. No matter
what the actual authentication mechanism is or how these credentials were
established, I can provide a description of the authentication credential
in this form and then use it to verify the actual credential against. SAML,
PKIX, OpenID, OAUTH, Kerberos, everything can be expressed in one form.

user:<account>@<dns-name>:<authenticator>
service:<dns-name>:<service-prefix>:<authenticator>

These URI forms are the sort of thing we might put in a configuration file
or the windows registry or any other configuration file. They are not
something I think we would want to thrust in front of the user's face. But
having the ability to handle them as text strings will be very useful on
occasion. Particularly if we are configuring an embedded device via a USB
cable or such.

The authenticator part can be either direct or indirect. A direct
authenticator being the cryptographic key itself and an indirect
authenticator being a means to authenticate the key.

The cryptographic keys themselves may be either a public key or a kerberos
like ticket.

Which type of authenticator we wanted to make use of would depend on what
layer we are in the crypto-stack.

At the very top layer the authenticator would probably be a SHA512-256 or
SHA512-128 digest of the root of trust in a PKI. If I am configuring an
ACME client to connect to the Comodo CA for certificate issue, I probably
want the authenticator to be the root of trust for the Comodo CA, i.e. a
digest of the keyinfo block of some Comodo root cert.

At the very bottom crypto layer we only use symmetric keys. So the
authenticator might be a Kerberos ticket or the like. Obviously this is not
the type of credential you would usually want to have lying around in a
static config file.

In between we would probably have use for using a public key as the
authenticator. Or at least will do once we get a ~256 bit ECC algorithm
agreed. I would not want to cut and paste raw RSA keys but lots of people
are already doing just that for Curve25519.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 19 Feb 2015 17:17:13 +0000

Are these not YURLs? http://www.waterken.com/dev/YURL/.

On 19 February 2015 at 17:03, Phillip Hallam-Baker
<[email-masked]> wrote:
> of authenticating the server key on the client side and a user account and a
> means of authenticating the user on the server side.
>
>
> established, I can provide a description of the authentication credential in
> this form and then use it to verify the actual credential against. SAML,
> SHA512-128 digest of the root of trust in a PKI. If I am configuring an ACME
> client to connect to the Comodo CA for certificate issue, I probably want
> the authenticator to be the root of trust for the Comodo CA, i.e. a digest
> of the keyinfo block of some Comodo root cert.
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: "Scott R. Corzine" <[email-masked]>
Date: Thu, 19 Feb 2015 13:13:57 -0500

> service:<dns-name>:<service-prefix>:<authenticator>

If successful there are going to be users who have multiple keys with
the same <account>@<dns-name> or <dns-name>:<service-prefix>. These
will have been created for different purposes, need user-designated
tags for special needs (e.g. designate destination or for
prod/dev/test), dates or numbers for users to be able to
rotate/regenerate their keys, etc.

In many cases users will primarily depend on the information in the
URI for selection.. So adding a simple field that can contain what's
important to the user should work.

We should not depend on the users (either creators or consumers)
maintaining this information external to the keys (filenames,
formatted documents, databases). Many people will have them scattered
around in various files and mail messages. Existing URIs in flat
configuration files usually won't have anything beyond the URI.

I'm just suggesting a simple external field, tag or label. It doesn't
have to be signed. There is utility in letting this tag information be
changed by the user of the URI. If each person can only distinguish to
the account@dns-name level then they will tend to only use one key for
all purposes and as long as they can. Anything else will cause too
much headache.

For example, I do this with my ssh keys to distinguish between
different keys for different destinations/purposes and track when the
key was generated. Encoding as an email address I can use something
like this "[email-masked]". It's kludgy but my ssh
keys are maintainable, identifiable, and updatable. I can use
different keys for appropriate purposes and know where they're
generated/stored.

I'm not necessarily saying we should use the + syntax for such
purposes. Just a simple user field which can be separated into
different uses and have new information added to it.

These URIs will get separated from metadata, jumbled around and need
to be self-identifying.

-Scott-

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Feb 2015 13:46:43 -0500

>>>>> "Phillip" == Phillip Hallam-Baker <[email-masked]> writes:
Hi.
I spent a few minutes trying to understand what you're proposing, and
completely failed.
I'd consider myself fairly versed in authentication and if I can't
follow it at all, I'm probably not the only one.
So, I'd appreciate it if you would be willing to try and explain this a
bit better.
Also, I'm not really sure that the authentication technologies I'm
familiar with work the way you claim they do.
Please consider the following:

    Phillip> Forget for a minute the user interface details of how we
    Phillip> arrive at this point. At some point we are going to come
    Phillip> down to a DNS name and some means of authenticating the
    Phillip> server key on the client side and a user account and a
    Phillip> means of authenticating the user on the server side.  What
    Phillip> I would like is a URI form that would allow this type of
    Phillip> relationship to be described:

Fundamentally it's not obvious to me that the above paragraph applies to
Kerberos, SAML and I'm unclear about OAUTH.
I understand you claimed that it does apply to those technologies, but I
consider myself rather familiar with Kerberos and fairly familiar with
SAML, and I just don't see it.

take Kerberos for example:

* the server and client don't have separate keys

* The assumptions you're making about DNS don't apply to Kerberos.

For SAML:

* Depending on the profile SAML may not have a lot to say about
  validating the server.

* SAML naming has very little to do with DNS especially for the names of
  subjects.

So, please take a step back--a lot of steps back and explain what you're
trying to do at least well enough that those of us who have spent a fair
bit of time working with the technologies you're  discussing can:

1) understand

2) agree that for technologies we're familiar with you're capturing the
aspects of our technology we consider important.

Thanks,

--Sam

---

From: "Scott R. Corzine" <[email-masked]>
Date: Thu, 19 Feb 2015 14:49:15 -0500

>From a quick read of the YURL site and my understanding of this
proposal I would say they are very different things:

This proposal simply appears to define URIs which can pair an user
account or a service with an authenticator, a complete key or an
authenticator/id for an external key.  There's a lot of discussion of
protocols and different authentication methods but I read that as
discussion of how they could interact not a proposal to replace of
change any of them.

YURL is complex. It appears to purportedly simultaneously eliminate or
reduce reliance on the PKI and DNS (both of which are strongly
criticized along with the "global namespace"). It involves URLs
containing: *mandatory pre-shared* SHA-1 hash of a X.509 public key as
the primary resource id, multiple network connections, a list of
"hints" - IP addresses ("not discouraged")/DNS names at least one of
which must exist, intentional use of HTTP redirects as a location
service, TLS/1.0 (required) with reduced PKI use, all of the preceding
repeated until success is achieved or the hints run out. Then,
finally, a normal HTTP dialogue for /url-path. That's a single
request.

-Scott-

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Feb 2015 13:57:20 -0600

Have you seen PKCS#11 URIs?  (Not that that's the right answer for
you, but if the credentials needed to use are buried in a token that
must be accessed via PKCS#11, then PKCS#11 URIs become part of the
answer.  Particularly since PKCS#11 URIs allow you to specify a
provider, in case that a platform default doesn't know how to access
the credentials, and so on.)

Nico
--

---

From: Paul Lambert <[email-masked]>
Date: Mon, 23 Feb 2015 17:30:33 -0800

I’m interested in cryptography in URIs or YURLs, but am very confused by  the proposal below.

Perhaps a more succinct use case would help.

I’m working now on trying to bind a ‘service’, ‘communication channel’ and a ephemeral public key as a YURL-ish introduction.  This would be in QR codes to securely connect to a related wireless P2P service.  The character encoding in a QR-Code might benefit from the use of a URI.

Paul

From: saag [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, February 19, 2015 9:04 AM
To: [email-masked]
Subject: [saag] A URI for cryptographic keys

This has come up a few times in the past. This time though I would really like us to get something done.

In a nutshell, it would be really useful if there was a type of URI that could be simply cut and pasted that would specify either:

* A user account and a means of authenticating a credential that authenticates the user of that account.

* An Internet service and means of authenticating a credential that authenticates that service.

So let us say that we are working on ACME or DPRIV and we are looking for a way to tell the client or device (or whatever) that it should use service X and authenticate it with key Y.

Forget for a minute the user interface details of how we arrive at this point. At some point we are going to come down to a DNS name and some means of authenticating the server key on the client side and a user account and a means of authenticating the user on the server side.

What I would like is a URI form that would allow this type of relationship to be described:

Think of these as the 'thin waist' for authentication mechanisms. No matter what the actual authentication mechanism is or how these credentials were established, I can provide a description of the authentication credential in this form and then use it to verify the actual credential against. SAML, PKIX, OpenID, OAUTH, Kerberos, everything can be expressed in one form.

These URI forms are the sort of thing we might put in a configuration file or the windows registry or any other configuration file. They are not something I think we would want to thrust in front of the user's face. But having the ability to handle them as text strings will be very useful on occasion. Particularly if we are configuring an embedded device via a USB cable or such.

The authenticator part can be either direct or indirect. A direct authenticator being the cryptographic key itself and an indirect authenticator being a means to authenticate the key.

The cryptographic keys themselves may be either a public key or a kerberos like ticket.

Which type of authenticator we wanted to make use of would depend on what layer we are in the crypto-stack.

At the very top layer the authenticator would probably be a SHA512-256 or SHA512-128 digest of the root of trust in a PKI. If I am configuring an ACME client to connect to the Comodo CA for certificate issue, I probably want the authenticator to be the root of trust for the Comodo CA, i.e. a digest of the keyinfo block of some Comodo root cert.

At the very bottom crypto layer we only use symmetric keys. So the authenticator might be a Kerberos ticket or the like. Obviously this is not the type of credential you would usually want to have lying around in a static config file.

In between we would probably have use for using a public key as the authenticator. Or at least will do once we get a ~256 bit ECC algorithm agreed. I would not want to cut and paste raw RSA keys but lots of people are already doing just that for Curve25519.