Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)
On Sat, Apr 6, 2019 at 5:59 PM, Jonas Schäfer wrote: I agree with Florian fully. This is rather non-idiomatic to implement on the client side, due to how XMPP works otherwise. The flow suggested by Florian is more idiomatic and implementable with less brain-hurt. I don’t see any advantage (only disadvantages) on the client side with the message based flow (also, the horrors of carbons and archives), and I’m not sure which advantages there would be for servers. No problem, I will re-design the flow, this is absolutely not a subject for debates for me. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)
On Donnerstag, 4. April 2019 12:52:15 CEST Florian Schmaus wrote: > On 02.04.19 10:07, Evgeny wrote: > > On Mon, Apr 1, 2019 at 9:40 PM, Florian Schmaus wrote: > >> I am a little bit worried that this will take a few detours to implement > >> cleanly and elegant in clients and client libraries. Especially since > >> this pattern never occurred before. > >> > >> Instead I suggest the following control flow, which should be straight > > > >> forward to implement with the facilities libraries currently provide: > > Hi, Florian, thanks for your feedback. > > Interestingly, in my very rough version I had exactly this scheme, and I > > found no real advantage. > > Is it possible that you looked at it with your XMPP server developer > googles on? :) > > > Instead, I made it possible to just resend the > > request (with the same CertificateRequest structure) if a client > > believes the challenge is resolved. > > So XEP-0417 specifies that upon solving the challenge I have to resend > the IQ request? I could not tell that this is the case, as you can see > from how I modelled the anticipated current protocol flow in my previous > message and below. Nevertheless I still would favour my suggested > protocol flow. > > > What "detours" do you see possible > > from a client developer perspective? > > Assume that most client libraries provide a facility to send a IQ > request, gather the response, or bail out on a timeout, and ensures that > no resources leak. The following should be considered pseudocode but > roughly reassembles Smack's API and thus may remember you of Java. I agree with Florian fully. This is rather non-idiomatic to implement on the client side, due to how XMPP works otherwise. The flow suggested by Florian is more idiomatic and implementable with less brain-hurt. I don’t see any advantage (only disadvantages) on the client side with the message based flow (also, the horrors of carbons and archives), and I’m not sure which advantages there would be for servers. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)
On 02.04.19 10:07, Evgeny wrote:
> On Mon, Apr 1, 2019 at 9:40 PM, Florian Schmaus wrote:
>> I am a little bit worried that this will take a few detours to implement
>> cleanly and elegant in clients and client libraries. Especially since
>> this pattern never occurred before.
>>
>> Instead I suggest the following control flow, which should be straight
>> forward to implement with the facilities libraries currently provide:
>
> Hi, Florian, thanks for your feedback.
> Interestingly, in my very rough version I had exactly this scheme, and I
> found no real advantage.
Is it possible that you looked at it with your XMPP server developer
googles on? :)
> Instead, I made it possible to just resend the
> request (with the same CertificateRequest structure) if a client
> believes the challenge is resolved.
So XEP-0417 specifies that upon solving the challenge I have to resend
the IQ request? I could not tell that this is the case, as you can see
from how I modelled the anticipated current protocol flow in my previous
message and below. Nevertheless I still would favour my suggested
protocol flow.
> What "detours" do you see possible
> from a client developer perspective?
Assume that most client libraries provide a facility to send a IQ
request, gather the response, or bail out on a timeout, and ensures that
no resources leak. The following should be considered pseudocode but
roughly reassembles Smack's API and thus may remember you of Java.
IQ request = …
IQ result = sendIqA(request).getResult();
Now with the current protocol flow, the client-side logic would look
like this:
// Open a try block to ensure we do not leak resources at the end.
try {
// Setup a listener for the optional challenge message.
Listener optionalChallengeMessageListener = () -> {
// Signal that a challenge is required.
};
connection.addListener(optionalChallengeMessageListener);
// Send the IQ request with the cert to sign
PendingIQ pendingIq = sendIq(request);
// Some rather complex and error prone logic to wait either on
// pendingIq.getResult() or on the optional message arriving.
somehowBlockUntilEitherTheMessageOrTheIqArrives();
if (messageHasArrvied) {
asyncSolveChallenge();
while (solvingChallenge) pendingIq.resetTimeout();
}
IQ result = pendingIq.getResult();
} finally {
connection.removeListener(optionalChallangeMessageListener);
}
Whereas with my suggestion it would be straight forward to implement
which the typical facilities for IQ handling that exists likely in every
XMPP client implementation:
IQ request = …
IQ result = sendIq(request).getResult();
if (result.needsChallenge) {
// Solve challange
…
}
IQ request2 = …
IQ certificateResult = sendIq(request2).getResult();
return ceritifcateResult.certificate;
- Florian
signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)
On Mon, Apr 1, 2019 at 9:40 PM, Florian Schmaus wrote: I am a little bit worried that this will take a few detours to implement cleanly and elegant in clients and client libraries. Especially since this pattern never occurred before. Instead I suggest the following control flow, which should be straight forward to implement with the facilities libraries currently provide: Hi, Florian, thanks for your feedback. Interestingly, in my very rough version I had exactly this scheme, and I found no real advantage. Instead, I made it possible to just resend the request (with the same CertificateRequest structure) if a client believes the challenge is resolved. What "detours" do you see possible from a client developer perspective? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)
On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote: > Version 0.1.0 of XEP-0417 (E2E Authentication in XMPP: Certificate > Issuance and Revocation) has been released. > > Abstract: > This specification defines a way for a certificate authority to serve > certificate signing requests via XMPP in order to issue X.509 > certificates for the use in end-to-end and c2s SASL EXTERNAL > authentication. > > Changelog: > Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc)) > > URL: https://xmpp.org/extensions/xep-0417.html Thanks for submitting this zinid. I am especially interested [1] in the client certificate issuance (§ 6. of this XEP). I even wrote a straw-man [2] so that zinid and I are able to compare our ideas and vision. Also please note that with XEP-0257 we have prior-art. What immediately got my attention reading this XEP-0417 was the "optional message response as result of a request IQ pattern" used in § 6. To my knowledge this is a new unique pattern in XEP land. To illustrate, the XEP currently uses a protocol flow as follows: CSR: Certificate Signing Requester (typically an XMPP Client) CS: Certificate Signer (typically an XMPP server) CSR CS --- -- IQ request w/ certificate to sign---> (Example 8) - Begin optional protocol flow - Message <---w/ challenge (Example 9) CSR solves challenge - End optional protocol flow IQ result <--- w/ signed certificate (Example 10) At first glance, this looks similar to what we do in MAM: Deferring the IQ result until the last intermediate message has arrived. But there is an important difference here: The final IQ result is triggered as result of the IQ result *receiving* entity. I am a little bit worried that this will take a few detours to implement cleanly and elegant in clients and client libraries. Especially since this pattern never occurred before. Instead I suggest the following control flow, which should be straight forward to implement with the facilities libraries currently provide: CSR CS --- -- IQ request w/ certificate to sign---> (Example 8) IQ result <--- either w/ optional challenge *or* signed certificate - Begin optional protocol flow - CSR solves challenge IQ request indicating that CSR believes challenge---> to be solved IQ result <---w/ signed certificate - End optional protocol flow - Florian 1: https://mail.jabber.org/pipermail/standards/2019-February/035805.html 2: http://geekplace.eu/xeps/xep-ccm2/xep-ccm2.html signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)
Version 0.1.0 of XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation) has been released. Abstract: This specification defines a way for a certificate authority to serve certificate signing requests via XMPP in order to issue X.509 certificates for the use in end-to-end and c2s SASL EXTERNAL authentication. Changelog: Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0417.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
