Could you, or anyone else, clarify what is meant with that rfc822name
"to use in the overlay" ? Why is it there ?
AFAIK the username is a human readable name for a given RELOAD peer or
client.
Assume you have a central enrollment and a SIP usage, the client
(application) may want to know from this enrollment which AOR it
should use. I.e. you have a mobile device, within the enrollment
process, the AOR should be provided by enrollment since the Client
(user) does not want to configure it's AOR manually in the phone (you
never did that with you "old" mobile, right ?).
Hmm. My understanding is that a SIP usage of RELOAD stores and fetches
AORs on its own. This has nothing to do with the information provided in
a certificate used at RELOAD transport level (hence nothing to do with
the rfc822name and/or node_ids, used to manage the RELOAD
functionality). But this is only my understanding.
The SIP AOR is for me nothing special than a datum, stored in the DHT of
the overlay, able to be retrieved from that.
But I might be wrong. And because all experts prefer to not comment, we
might stay stupid for a certain time :(
Regards
Currently, it's not quite clear for me. Can you help there ?
Cheers,
Frederic
On Tue, Feb 23, 2010 at 7:59 AM, neil.young <[email protected]> wrote:
Hi Frederic,
thanks for your answer, but I tend to disagree. Your proposal does neither
match 13.12 (RELOAD URI) nor matches the node_id format, which might be
derived from 10.1 (element <kind-signer>). As for the node_id I'm pretty
sure it has to be a 32 hex digit ASCII hex string (16 byte, 128 bits).
I don't know, how they encode a "destination _list_", this is rather unclear
in 13.12, but I would expect to see something like this:
"reload://[email protected]/"
But this is just my interpretation, without having other references and
indications.
Regards
Frederic-Philippe Metz schrieb:
Hi,
I thought it could look like this (see below).
The node ID is placed in the URI field.
There's also a name (rfc822name) placed in the SubjectAltName under
the "email" Attibute.
Any comments on that ?
Cheers,
Frederic
// -----------------------
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=DE, ST=Hessen, L=Darmstadt, O=P2P SIP, CN=P2P SIP
Root CA/[email protected]
Validity
Not Before: Feb 17 13:10:43 2010 GMT
Not After : Feb 17 13:10:43 2011 GMT
Subject: C=DE, ST=Hessen, O=P2P SIP, OU=R&D, CN=Somewhat
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:c6:5b:0f:24:ea:08:3e:73:db:97:d6:d0:cb:e1:
5c:6a:ca:fa:9a:06:9f:a6:6e:14:f6:aa:1a:dd:36:
65:c1:32:42:26:3f:28:21:e6:da:d3:c2:c4:ce:a2:
34:d1:76:04:96:f6:9f:10:8c:e1:d6:75:37:90:2c:
22:07:c2:3a:fd:e6:f6:82:37:3d:c8:b4:95:5e:63:
2b:45:0a:07:30:f0:e3:41:68:2b:44:01:ac:76:3c:
d8:89:bf:f8:bb:70:f7:ef:00:85:aa:77:4a:9b:5e:
49:a3:1a:2e:de:5f:4a:7e:0e:ce:ee:b9:59:96:3b:
f8:3d:ba:de:9b:f3:9c:ec:10:46:50:db:40:7f:46:
ad:50:96:b0:f3:e3:7a:90:6e:88:b9:16:45:73:da:
78:63:e5:14:d8:3a:60:da:f4:58:32:15:2f:30:b1:
ed:89:59:36:49:e4:03:fe:4c:c7:7a:d2:6a:f8:09:
5c:c6:64:9f:be:60:c2:14:7a:34:70:75:27:ec:d5:
90:f0:ab:e0:00:74:2e:87:44:ef:41:e8:0d:31:d9:
ca:dc:f9:33:b3:ae:1c:3b:2a:89:39:ca:88:94:ca:
90:6d:41:06:b2:b0:8c:9d:42:f9:32:0c:e5:ad:4d:
1d:08:b2:ce:8c:78:6b:a0:8b:eb:6b:8f:82:95:ae:
a1:43
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
99:C0:70:B7:EE:9E:93:B4:5E:DC:AF:69:1C:88:72:E9:EC:68:DF:B8
X509v3 Authority Key Identifier:
keyid:BB:7F:34:F1:85:9E:EE:31:9F:C6:40:62:73:D3:E7:E4:35:58:FE:68
DirName:/C=DE/ST=Hessen/L=Darmstadt/O=P2P SIP/CN=P2P
SIP Root CA/[email protected]
serial:87:8B:21:B0:5B:B7:1D:4D
Netscape CA Revocation Url:
https://1.2.3.4/example-ca-crl.pem
X509v3 Subject Alternative Name:
email:[email protected], URI:42
Signature Algorithm: sha1WithRSAEncryption
4d:39:28:f2:aa:4b:12:e1:b3:bc:6f:ae:48:77:80:b6:5c:ab:
d3:17:dc:85:f9:eb:02:b2:33:89:60:e3:1a:68:5d:28:f3:e8:
a3:3a:b5:60:fe:83:ef:44:c7:e4:45:c9:37:50:ea:ce:fa:70:
91:af:62:2f:5f:1e:49:29:28:da:48:2d:41:fe:24:a9:f4:94:
77:5a:35:a7:41:99:a8:84:d2:38:fb:f8:dc:a8:44:fe:34:96:
9c:47:1f:2d:3d:e3:d8:73:af:81:3c:a1:3b:59:db:5d:af:68:
15:82:39:c1:2a:a2:0a:40:3f:1f:de:b5:d7:10:c8:be:80:44:
84:3f
On Tue, Feb 23, 2010 at 12:05 AM, neil.young <[email protected]>
wrote:
Sorry, may I raise this question again?
TIA
Regards
RELOAD BASE 07,
10.3.
One or more Node-IDs which MUST be cryptographically random
[RFC4086]. Each MUST be chosen by the enrollment server in such a
way that they are unpredictable to the requesting user. Each is
placed in the subjectAltName using the uniformResourceIdentifier
type and MUST contain RELOAD URIs as described in Section 13.12
and MUST contain a Destination list with a single entry of type
"node_id".
Could anybody please give me a pointer, how such a record may look like?
A
sample would be of help.
Thanks
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
