- Sep 2024
-
matrix.org matrix.org
-
it feels we’re creeping ever closer to that goal of providing the missing communication layer for the open Web. The European Union’s Digital Markets Act (DMA) is a huge step in that direction - regulation that mandates that if the large centralised messaging providers are to operate in the EU, they must interoperate. We’ve been busy working away to make this a reality, including participating in the IETF for the first time as part of the MIMI working group - demonstrating concretely how (for instance) Android Messages could natively speak Matrix in order to interoperate with other services, while preserving end-to-end encryption.
Matrix seeing DMA as supportive towards their goal of open web's communication layer. Actively demo'ng Android interoperability while preserving E2EE, and participating in IETF / MIMI ( https://datatracker.ietf.org/group/mimi/about/ )
Tags
Annotators
URL
-
- Oct 2023
-
buildkite.com buildkite.com
-
UUID Version 7 (UUIDv7) is a time-ordered UUID which encodes a Unix timestamp with millisecond precision in the most significant 48 bits. As with all UUID formats, 6 bits are used to indicate the UUID version and variant. The remaining 74 bits are randomly generated. As UUIDv7 is time-ordered, values generated are practically sequential and therefore eliminates the index locality problem.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unix_ts_ms | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unix_ts_ms | ver | rand_a | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |var| rand_b | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rand_b | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
datatracker.ietf.org datatracker.ietf.org
- Sep 2023
-
blog.cloudflare.com blog.cloudflare.com
-
datatracker.ietf.org datatracker.ietf.org
- Jul 2023
-
datatracker.ietf.org datatracker.ietf.org
-
blog.mozilla.org blog.mozilla.org
-
datatracker.ietf.org datatracker.ietf.org
- Jun 2023
-
www.bortzmeyer.org www.bortzmeyer.org
-
datatracker.ietf.org datatracker.ietf.org
- May 2023
-
httptoolkit.com httptoolkit.com
-
softwareengineering.stackexchange.com softwareengineering.stackexchange.com
-
a SHOULD is always trumped in RFCs by a MUST. The fact that hosts SHOULD do something means that they might not and I just wanted reassurance that, in reality, the SHOULD is a bit more widely adopted than its definition implies.
-
-
blog.teknkl.com blog.teknkl.com
-
When an IETF RFC uses the keyword “MUST” it means business
-
-
datatracker.ietf.org datatracker.ietf.org
-
Proposal for internet wall . By Pradeep kumar Xplorer ex sun .com engineer currently victim of cybercrime using dhyanayoga.info california resident unable to return there and his mother murdered. If you like this proposal or design please email pradeepan88@hotmail.com and request some financial aid to expand the design and have the project rolling. I propose the internet wall . Wall is old unix command line utility where a user can message all users logged in with some wall message. Like the system administrator in the evening giving half an hour more time to finish work and log off, or informing of some meeting to discuss some projects.The internet wall is where you see the internet as a giant computer. Once you are online you are one user of the internet which can have several million to billion users online at the same time. The internet wall is a suite of applications cross platform cross domain that would be in your desktop or smart fone screen that you can invoke and wall everyone online or some subset of those who are online. I propose a website internetwall .com or or any other domain extensions
😂🤣😭
This draft is a rogue submission with author impersonation, isn't it ? 🤔
-
-
datatracker.ietf.org datatracker.ietf.org
- Apr 2023
-
-
If you'd like to make your own: Go to https://chat.openai.com/chat "Give me another title and abstract for a funny April 1 RFC about AI" Ask it to shorten the abstract if it's too long Ask it to write the introduction "Now write a terminology section. Make sure to include the RFC 8174 boilerplate." "Now write a section describing how the protocol works. Be detailed, and make sure to refer to some RFCs." "Now write a Security Considerations section and an IANA considerations section"
-
-
mstdn.social mstdn.social
-
Today's crop of April 1 RFCs contains what is to my knowledge the first RFC generated by an LLM, or indeed any type of AI.
-
- Mar 2023
-
gitlab.com gitlab.com
-
developer.mozilla.org developer.mozilla.org
- Feb 2023
- Jan 2023
-
blog.cloudflare.com blog.cloudflare.com
-
datatracker.ietf.org datatracker.ietf.org
-
justinsecurity.medium.com justinsecurity.medium.com
-
blog.joinmastodon.org blog.joinmastodon.org
-
We need to read the Signature header, split it into its parts (keyId, headers and signature), fetch the public key linked from keyId, create a comparison string from the plaintext headers we got in the same order as was given in the signature header, and then verify that string using the public key and the original signature.
```ruby require 'json' require 'http'
post '/inbox' do signature_header = request.headers['Signature'].split(',').map do |pair| pair.split('=').map do |value| value.gsub(/\A"/, '').gsub(/"\z/, '') # "foo" -> foo end end.to_h
key_id = signature_header['keyId'] headers = signature_header['headers'] signature = Base64.decode64(signature_header['signature'])
actor = JSON.parse(HTTP.get(key_id).to_s) key = OpenSSL::PKey::RSA.new(actor['publicKey']['publicKeyPem'])
comparison_string = headers.split(' ').map do |signed_header_name| if signed_header_name == '(request-target)' '(request-target): post /inbox' else "#{signed_header_name}: #{request.headers[signed_header_name.capitalize]}" end end
if key.verify(OpenSSL::Digest::SHA256.new, signature, comparison_string) request.body.rewind INBOX << request.body.read [200, 'OK'] else [401, 'Request signature could not be verified'] end end ```
-
- Dec 2022
-
blog.cloudflare.com blog.cloudflare.com
-
Conceptually, OHTTP is a simple protocol: end-to-end encrypted requests and responses are forwarded between client and server through a relay, decoupling who from what was sent
-
-
datatracker.ietf.org datatracker.ietf.org
-
datatracker.ietf.org datatracker.ietf.org
-
The RFC Ontology extends the Bibliographic Ontology [BIBO] and reuse elements from the Friend of a friend [FOAF] and DCMI Metadata Terms [DCTERMS] ontologies.
-
-
github.com github.com
-
datatracker.ietf.org datatracker.ietf.org
- Nov 2022
-
datatracker.ietf.org datatracker.ietf.org
- Sep 2022
-
datatracker.ietf.org datatracker.ietf.org
-
The RFC Editor's DOI prefix is 10.17487
-
- Aug 2022
-
datatracker.ietf.org datatracker.ietf.org
-
www.arkko.com www.arkko.com
Tags
Annotators
URL
-
-
xml.coverpages.org xml.coverpages.org
Tags
Annotators
URL
-
- Jul 2022
-
datatracker.ietf.org datatracker.ietf.org
-
datatracker.ietf.org datatracker.ietf.org
- Jun 2022
-
datatracker.ietf.org datatracker.ietf.org
- Apr 2022
-
trac.ietf.org trac.ietf.org
-
The IETF provides an IMAP interface into the email list archives. This interface allows both anonymous and logged-in access.
``` Server: imap.ietf.org Port: 143 or 993
For authenticated access use your datatracker login and password.
For anonymous access use username="anonymous", and provide your email address as a password. ```
Tags
Annotators
URL
-
-
www.bortzmeyer.org www.bortzmeyer.org
Tags
Annotators
URL
-
-
www.ietf.org www.ietf.org
-
IMAP subscriptions: An IMAP server with all IETF email list archives is available for IMAP access at imap.ietf.org:993.
Tags
Annotators
URL
-
- Mar 2022
-
www.programmableweb.com www.programmableweb.com
- Dec 2020
-
-
Q_plain
Is the entropy from
Q_plain
really needed? A reason for it would be that the client provides randomness with the nonce contained inQ_plain
, in the sense of a contributive key exchange. However, the client already contributes the HPKE ephemeral key.If the Extract step should stay, I suggest changing the order of
Q_plain
andodoh_secret
. The valueodoh_secret
is of fixed size and uniformly random, and thus fits better assalt
to HKDF-Extract. If the first value is longer than a hash function block size, HMAC will do an additional hashing step: This seems easily possible for Q_plain. -
proxy and target indistinguishability
How is this defined?
-
of unique per-client keys
What kind of keys are meant here? Unique target public keys per client?
-
Q_encrypted
The function could receive only
ct
instead, as it does not useenc
, andsetup_query_context
already splitsQ_encrypted
. -
key_id
The function does not use this parameter.
-
context
The
context
is not returned by this function, but required as parameter todecrypt_response_body
. -
Expand(Extract("", config), "odoh key id", Nh)
config
contains kem_id, kdf_id, aead_id, and the public key. Why is entropy extraction needed here?
Tags
Annotators
URL
-
- Nov 2019
-
tools.ietf.org tools.ietf.org
-
- Oct 2018
-
www.ietfjournal.org www.ietfjournal.org
-
- Mar 2018
-
tools.ietf.org tools.ietf.org
-
Relation Name: cite-as
The registry with the listing for cite-as is here. https://www.iana.org/assignments/link-relations/link-relations.xhtml
-