Re: Crypto ontology?

On 3/25/21 12:04 PM, Henry Story wrote:
> I am implementing ”Signing HTTP Messages” [1] which have moved since 
> draft-cavage to a new signature algorithm hs2019 which essentially states 
> that the information about the key and hashing must be given by the keyId.
> 
> As I am taking keyIds to be URLs that I can dereference

Ah! They are not. :)

keyIds are opaque values that may have other semantics layered on top of them
by other specifications. For example, Authorization Capabilities interpret
keyId as a URI (typically, a DID), but other applications may have other ways
of getting to the key material. Per the current spec:

"""
1.5.  Application of HTTP Message Signatures

   HTTP Message Signatures are designed to be a general-purpose security
   mechanism applicable in a wide variety of circumstances and
   applications.  In order to properly and safely apply HTTP Message
   Signatures, an application or profile of this specification MUST
   specify all of the following items:

...


   *  A means of retrieving the key material used to verify the
      signature.  An application will usually use the "keyid" field of
      the "Signature-Input" header value and define rules for resolving
      a key from there.

   *  A means of determining the signature algorithm used to verify the
      signature content is appropriate for the key material.

   *  A means of determining that a given key and algorithm presented in
      the request are appropriate for the request being made.  For
      example, a server expecting only ECDSA signatures should know to
      reject any RSA signatures; or a server expecting asymmetric
      cryptography should know to reject any symmetric cryptography.
"""

So, be careful to not assume this is done at the HTTP Signatures layer; it's
done at a layer above.

> If there were a agreed on crypto ontology that would be easy to put
> together. Is there one yet?

There is a Security ontology that this community uses and maintains here:

https://w3id.org/security

> Otherwise how could I encode this info in a way that would be somewhat
> acceptable? Is there a name for such a pair?

Looking a key up by hash is a curious choice when you could just use a URL?
Why aren't you just doing Linked Data and using a URL to the key information
instead? Why go at it from the other direction?

Answering that question might provide more insight into potential solutions.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Thursday, 25 March 2021 17:34:42 UTC