Hi Neil, I totally agree with what you meant with the node id. I just inserted a fake ID.
The second topic is very interesting. I wasn't already at the point to have a look in more detail with that. Could you, or anyone else, clarify what is meant with that rfc822name "to use in the overlay" ? Why is it there ? 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 ?). 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
