Re: Crypto ontology?

> On 25 Mar 2021, at 18:34, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> 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. :)

Nothing stops us enhancing the protocol though.

That is what I suggest doing here:
https://github.com/solid/authentication-panel/blob/main/proposals/HttpSignature.md

There I propose a to add header to a request

Authorization: HttpSig …

But of course I could also use the following from draft-cavage

Authorization: Signature …

With perhaps a special attribute to indicate that the keyId is dereferenceable.
I am open for ideas here, and would love to find other interested folks to
develop this.

> 
> 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:

yes, in my HttpSig proposal I was suggesting that one could also use `did:key`
URLs, though per this issue I am not quite sure if those contain the hashing
algorithm to make them sufficient for use with ”Signing HTTP Messages"

https://github.com/solid/authentication-panel/issues/151

I opened an issue on the did:key repo on that too.
In any case at the stage at which I am now, it will be easier to implement
with simple HTTPs URLs to get going.

> 
> """
> 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.

Understood.

> 
>> 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

Ah thanks.
(It would be nice if there were a Turtle representation available. I need
to get banana-rdf and configure it to transform it to fully understand what
is being written there).

> 
>> 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?

(Not sure why you think I was suggesting to look it up by hash?)

Ah, perhaps you are thinking of <#k> and <#kh> ?
I meant of course that the following <#k> and <#kh> be relative
URLs to the base document in which they are placed. So if this
is located at <https://alice.name/keys>

<#kh> :uses <#k>;
     :with cert:Sha512 .

<#k>  a cert:RSAPublicKey;
    cert:modulus "00cb24ed85d64d794b..."^^xsd:hexBinary;
    cert:exponent 65537 .

( Can I express this with the security ontology? )

then the keyID of an HttpSig Message could contain either one of


1. if we allow relative URLs, (Alice accessing her own POD):

GET /comments/ HTTP/1.1
Authorization: HttpSig signed=”sig1"
Signature-Input: sig1=(); keyId="</keys#kh>"; created=1402170695
Signature: sig1=:cxieW5ZKV9R9A70+Ua1A/1FCvVayuE6Z77wDGNVFSiluSzR9TYFV
       vwUjeU6CTYUdbOByGMCee5q1eWWUOM8BIH04Si6VndEHjQVdHqshAtNJk2Quzs6WC
       2DkV0vysOhBSvFZuLZvtCmXRQfYGTGhZqGwq/AAmFbt5WNLQtDrEe0ErveEKBfaz+
       IJ35zhaj+dun71YZ82b/CRfO6fSSt8VXeJuvdqUuVPWqjgJD4n9mgZpZFGBaDdPiw
       pfbVZHzcHrumFJeFHWXH64a+c5GN+TWlP8NPg2zFdEc/joMymBiRelq236WGm5VvV
       9a22RW2/yLmaU/uwf9v40yGR/I1NRA==:


2. we can send a full URL, (perhaps if Alice goes to a different POD)

GET /comments/ HTTP/1.1
Authorization: HttpSig
Signature-Input: sig1=(); keyId="<https://alice.name/keys#kh>"; created=1402170695
Signature: sig1=:cxie...:


3. IDEALLY, if the P2P Extension to HTTP is used, the client could send
a relative URL pointing to itself, which the server could GET by
switching roles.

GET /comments/ HTTP/1.1
Authorization: HttpSig
Signature-Input: sig1=(); keyId=”>/keys#kh<"; created=1402170695
Signature: sig1=:.....:


> 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?

That is exactly what I want to do of course. See my HttpSig document.

I’d love to hear from people who want to pursue the LinkedData approach to
extending the IETF Signing Http Messages so that we can get Authentication
working with URIs explicitly. :-)



> 
> 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
> 
>