Ontology for the KeyId document

[bblfish]

Research space to find ontologies that could be used for the Http Signatures proposal.

There is the 13 year old Cert Ontology from 2008 that has enough info to encode RSA keys. It could be developed further.

There is the security vocabulary by @msporny, @OR13 and @mattcollier.

We will need an ontology to express keys + extra data for the keyId Document. See the thread on the Credentials Mailing List. The keyId URL could be its own document but it could also be a pointer into a larger RDF document, e.g. a WebID profile, a document containing any number of keys, etc... It could have extra information about expiry dates, encryption functions, etc...

The minimum required by the "Signing Http Messages" IETF HttpBis spec hs2019 protocol is that the keyId point not just to a cryptographic key, but to a key + metadata info. Something like this:

<#kh> a :Sha512SigningKey;
      :with [  a cert:RSAPublicKey;
         cert:modulus "00cb24ed85d64d794b..."^^xsd:hexBinary;
        cert:exponent 65537 
        ] .

This could then be referred to in an HTTP request like this:

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

[OR13]

Is this essentially a request for new vocabulary? I would be happy to review any changes to the security vocab that would make it useful for solid. Let me know how I can help.

[bblfish]

Hi @OR13. I can't quite tell if I need a new vocabulary item, as i am having trouble parsing the examples from the spec. (see issue 93 in the security-vocab).

All I need for the moment is to express something along the lines of what I expressed above for RSA keys, to say that I have a signing key that links to an RSA cryptographic key, to be used with SHA512. Is there a way to express that using the security vocabulary? That would allow me to try out HttpSig authentication on my server and start adding WAC authorization built around that.

[bblfish]

Ok @OR13. I found that the Titanium JSON-LD parser works with the security vocabulary (see issue 93 above). I think the following JSON should do for the hs2019 algorithm in Signing HTTP Messages.

{
"@context": [
    "https://w3id.org/security/v1",
    { "ex": "http://example.org/vocab#" }
  ],
  "id": "#hs",
  "controller": "/people/henry#i",
  "publicKeyJwk": {
    "kty": "RSA",
    "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
    "e":"AQAB",
    "alg":"PS512",
    "kid":"2011-04-29"
  }
}

The algorithm PS512 is defined in RFC 7518 and I think is the same as the RSASSA-PSS referred to in Signing HTTP Messages with SHA512 hash. (which seems to be confirmed by the registry entry at the end of RFC7518).

The above JSON-LD converts to the following Turtle when fetched from </keys>

@prefix security <https://w3id.org/security#> .

</keys#hs> 
     security:controller </people/henry#i> ;
     security:publicKeyJwk """{
                "alg":"PS512",
                "e":"AQAB",
                "kid":"2011-04-29",
                "kty":"RSA",
                "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78L..."
      }"""^^rdfs:JSON .

(it looks like the Titanium parser reordered the json fields).

The JSON comes from Appendix A of RFC7517 after replacing the alg from RS256 with PS512.

I don't know if I need to describe the type of </keys#hs>. It seems that the security:publicKeyJwk is a owl:FunctionalProperty, so that it can have only 1 public key.

Perhaps this is all we need for RSA keys to work with HttpSig? (Of course one would later go through the other key types suggested by signing Http Messages.)

The algorithm for the Http Signature Verifier Agent would then be for a keyId="</keys#hs>" located on the same server on which the resource being fetched is located would then be:

1. GET /keys on the server
2. transform that to an RDF DataSet
3. place the pointer on the #hs node of the dataset
4. follow the security:publicKeyJwk relation
5. parse the json and retrieve the key and alg to know what SHA to use.
6. verify the signature with that information

[David-Chadwick]

@bblfish In the did:jwt draft I wrote, I use the alg id to tell the recipient what the remaining public key parameters are. Together these become the jwt kid (they are the public key). As new crypto algorithms are invented, then the JWT group will define new alg identifiers. So an example encoding for RS256 is:

     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSocBJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-GxBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
    "e":"AQAB",
    "alg":"RS256"
and for EC256 is:
    "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
    "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
    "alg":"ES256"

these are simply base64 encoded and follow did:jwt. No canonicalisation is needed.

[OR13]

No canonicalisation is needed.

thats because you are using base64 of json as canonicalization... I imagine the costs of this approach will become untenable for very large credentials... as we have already seen for JWT elsewhere... https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens#size

Regarding the other points regarding OWL, I am sure @dmitrizagidulin will be happy to comment on this... I have lost the will to continue to advocate for a coherent approach to the security vocab and owl after these mega threads:

• https://github.com/w3c-ccg/security-vocab/pull/45
• https://github.com/w3c-ccg/security-vocab/pull/59

[bblfish]

Thanks for those pointers. Interesting conversation on OWL. I can feel and urge to commenting on those, but I have some deadlines... :-/ Note, I did spend quite a lot of time on the subject a while back with the cert ontology.

I think I am going to get going with the dereferenceable keyID returning a graph in whatever serialization that MUST contain a security:publicKeyJWK triple.

</keys#hs> 
     security:publicKeyJwk """{
                "alg":"PS512",
                "e":"AQAB",
                "kid":"2011-04-29",
                "kty":"RSA",
                "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78L..."
      }"""^^rdfs:JSON

[OR13]

another related link for future readers... https://docs.joinmastodon.org/spec/security/

security:publicKeyJWK -> security:publicKeyJwk -> http://w3id.org/security#publicKeyJwk

[bblfish]

I have gathered all the definitions for the security vocabulary that I could help to work this out in this issue https://github.com/solid/authorization-panel/discussions/225