On Fri, 22 Mar 2019 at 09:05, Evgeny <xramt...@gmail.com> wrote: > > > On Fri, Mar 22, 2019 at 11:29 AM, Georg Lukas <ge...@op-co.de> wrote: > > * Tedd Sterr <teddst...@outlook.com> [2019-03-17 21:53]: > >> Proposed XMPP Extension: E2E Authentication in XMPP: Certificate > >> Issuance and Revocation - > >> https://xmpp.org/extensions/inbox/eax-cir.html > > > > +1 > > Thank you very much for the thorough review. > > > > > - A CA doesn't _need to_ be a server entity. It's well possible for a > > CA > > to be a bot@domain/resource or a component.domain, as long as it's > > ensured that the respective server is configured to enforce s2s (and > > c2s) TLS and to check server certificates. > > I was thinking about this. The terminology in the XEP becomes more > complex. How to name this stuff? CA XMPP entity? But this is a cosmetic > issue of course. > > You can just have a note somewhere that says "All examples, and much the the terminology, assumes that a CA is hosted on a XMPP server entity addressed by a domain-style Jid; this is not a requirement of the protocol, and a CA MAY be addressed by any valid Jid, including local@domain or even local@domain/resource."
> > > > - I'm not sure what is gained by stripping the PEM BEGIN/END headers. > > IMO It's not worth optimizing for two lines at the cost of increased > > client and server complexity. > > Without PEM encapsulation boundaries it's just a Base64 encoded DER > stuff. So you can use Base64 codec for this, not full blown PEM codec > which should parse and understand the boundaries and which can run into > compatibility problems (due to historic reasons outlined in RFC7468). > Also, in other places, such as the signature element, it's just base64 > encoded binary, so we will run into consistency problems, although > cosmetic, but still. > > I can probably just to reform the phrase and say that it's Base64 > encoded DER ASN.1 stuff. Note also, that understanding full PEM > encoding is not required by the document (all those places are SHOULD > or RECOMMENDED or some such). > > Yes, I hadn't actually noticed you'd said "PEM without headers". I'd prefer specifying just base64 DER. While these are the same thing in principle, I think it clarifies things enormously. (I actually just glanced at the base64, saw the opening, and recognised certificates in base64-encoded DER - I've obviously spent too long on this stuff before). > > > > - Signing Request: I'm not very happy with using IQs for the request > > and > > response, because there is an optional message-based manual > > challenge > > step in between, essentially meaning that the IQ request must be > > sent > > with an infinite timeout. OTOH, replacing this flow with something > > like data forms / ad-hoc commands might make things even more > > complex. > > Timeouts during a challenge procedure is indeed a problem. However, I > don't see how this can be overcome by using data forms or other > stanzas. I think a client should render "Cancel" button when it has run > an URL handler and wait indefinitely. And yes, the complexity. > > I did wonder, actually, about seperating the CSR submission from the processing. The spec as written more or less assumes a short, online interaction - if you assume lots of manual intervention and an offline CA, I think this becomes rapidly impractical. What about an IQ which creates the signing request with a CSR, and returns an id which can be queried about status? The query could trigger resending any pending challenges, too, as well as delivering the certificate. > > > > - Is there a specific reason for mandating the @by in the error > > response, in addition to the IQ @from? > > Probably it's not, I can remove it. It has left from the previous > version of the document. > > I'd drop it to a SHOULD rather than removing it. It's always useful to know whose error it is. > > > > - §8.1: it should be explicitly stated that this part replaces the > > XEP-0077 IBR workflow and not extends it. Also that by using this > > mechanism, the account does not have a password and that the only > > way > > to register another device is to copy over the private key. > > In recent version of the document [1] (which is only a local copy that > I'm going to submit later) I address this problem and X.509 IBR can be > used to recover access to the account without copying keys. > And yes, I can add the statement. > > > > > - §9: 'id' attribute of the <item/> element MUST contain first 16 > > octets > > from a signatureValue" - if this is required for interop, it should > > be > > "MUST equal to", otherwise it might as well allow shorter @ids, eg. > > urls-safe-base64. > > Okay, whatever. I don't oppose, I'll change it. Although I personally > don't see the difference, probably it's lost in translation. > > [1] http://upload.zinid.ru/xep-eax-cir.html#acc-recovery > > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
