David,
It all started way way back in late 2007 with this section of the draft:
http://www.p2psip.org/drafts/draft-bryan-p2psip-reload-02.html#sec-cert-security
The contents of the certificate include:
* A public key provided by the user.
* Zero, one, or more user names that the DHT is allowing this user
to use. For example, "[email protected]". Typically a certificate
will have one name. In the SIP usage, this name corresponds to the
AOR.
Nothing explicit about which part of the X509 certificate should hold
the AOR, just "name".
As a convenient, we used JDK program keytool to generate self-signed
certs instead of the more confusing openssl. It just so happens that JDK
keytool encodes only DN (common name, etc), no X509 v3 extensions fields
like subjectAltName and emailAddress (it is still this way with JDK 6).
We simply put the AOR in the "least inappropriate" field, Common Name.
Then we moved on and never thought about it much.
I believe it will remove a great deal of confusion if you guys create a
sample self-signed cert and put the output of the following OpenSSL
command in the appendix:
openssl x509 -text -in my_sip_cert.pem
I also want to point out that even with the most simple encoding (JDK
keytool), a 1024 bit RSA public key certificate takes up 619 bytes. A
production strength 2048 bit RSA cert is 880 bytes. If a peer can only
be reached via UDP, the overhead of DTLS + Reload Signature on message
leaves very little room for the relevant data fragment (e.g. 1500 packet
size), which means UDP transport may be very inefficient. Transport
overhead should be a separate discussion thread.
Thanks
--Michael
David A. Bryan wrote:
Michael,
I haven't had a chance to go back and reread the section in RELOAD or
fully think about this particular issue too much yet (so I certainly
have no opinions about the "right" way), but since this decision is
coming from an actual implementation, can you share a bit why you made
the decision you did? Was it motivated by a problem with the proposal
in the draft? An optimization to improve the current draft after
trying the other way? Or was it just that you did it that way before
the draft, etc.?
Obviously since we are still working on getting things right with the
draft, nothing is set in stone quite yet, and it's always good to hear
from implementors about why they made the decisions they did when they
differ from the draft, so that we make sure we really are getting the
best ideas. (especially here, where it seems, unfortunately, that
there are only a few folks trying to implement RELOAD, or at least
willing to talk about their implementation experience)
Also, anything else you have done differently/found awkward/etc. in
the current draft? It's not really so much a question of "compliance"
with the current draft right now -- now is the time to discuss
differences and find and address as many shortcomings in the current
draft proposal as possible, so we get as many ideas as possible and
the best protocol, then move it forward...
My 2 cents
David (as individual)
On Thu, Sep 24, 2009 at 11:07 AM, ekr <[email protected]> wrote:
On Thu, Sep 24, 2009 at 7:31 AM, Michael Chen <[email protected]> wrote:
Julian,
In our implementation, we search for rfc822Name format in all X509 fields in
the following order:
CN
This seems like it is not compliant with the current draft.
emailAddress
This is definitely not compliant and I don't see why it would be OK under
any circumstances.
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
