On Fri, Mar 22, 2019 at 2:18 PM, Dave Cridland <d...@cridland.net>
wrote:
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."
Sounds good. Except I don't like the idea of a resource. I think it's
something volatile and is attached to a session or a device, but not to
a long living thing such as a CA certificate. Well, I cannot imagine
any benefits from hardcoding the resource, only drawbacks (e.g. a
server can easily change it, and an operator may only detect this after
software upgrade). This also will not make it possible to run several
bots on the same JID (for load balancing for example).
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.
Fine by me.
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.
I think current protocol supports all these. CSR itself already plays a
role of the id: a client may resend a request and the server will
respond with a certificate if it has already issued it for this exact
CertificateRequest structure (without even challenging a client). And
the structure is required to be retained until successful completion of
a transaciton. See "Mobile OS Considerations" section [1] as an example
of how this can be used.
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.
Hehe, too late, I already removed it and made other changes :)
Also, this is a very general advice that doesn't belong solely to this
particular specification.
[1] http://upload.zinid.ru/xep-eax-cir.html#mobile-os-cons
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
