Subject: [P2PSIP] 10.3. NodeId in certificate

From: "neil.young" <[email-masked]>
Date: Fri, 19 Feb 2010 14:28:24 +0100

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

---

From: "neil.young" <[email-masked]>
Date: Tue, 23 Feb 2010 00:05:13 +0100

Sorry, may I raise this question again?
TIA
Regards

> Could anybody please give me a pointer, how such a record may look 
> like? A sample would be of help.
> Thanks

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Tue, 23 Feb 2010 06:19:29 +0100

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/emailAddress=[email-masked]
        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/emailAddress=[email-masked]
                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-masked], 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-masked]> wrote:
> 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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: "neil.young" <[email-masked]>
Date: Tue, 23 Feb 2010 07:59:21 +0100

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-masked]/"

But this is just my interpretation, without having other references and indications.

Regards

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Tue, 23 Feb 2010 12:55:44 +0100

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-masked]> 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:
>

---

From: "neil.young" <[email-masked]>
Date: Tue, 23 Feb 2010 13:37:33 +0100

> "to use in the overlay" ? Why is it there ?
AFAIK the username is a human readable name for a given RELOAD peer or 
client.

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Feb 2010 17:18:31 -0800

On Tue, Feb 23, 2010 at 4:37 AM, neil.young <[email-masked]> wrote:
> 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.
>

My intention was always that the name in the certificate was the AOR. obviously
the documents aren't clear on this point. Can you suggest some text that
would help?

-Ekr

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Wed, 24 Feb 2010 06:18:06 +0100

Hi Eric,

For clarification:
The "name" is the AOR (e.g. for the SIP usage "[email-masked]").
Additionally, there's a node id in form of a URI following the syntax
of 13.12..

Correct ?

So coming back to the roots and the question of Neil:
In 10.3., what is meant with the destination list in
'... and MUST contain a Destination list with a single entry of type
"node_id". '

Cheers,
  fpm

---

From: "neil.young" <[email-masked]>
Date: Wed, 24 Feb 2010 08:48:54 +0100

> the documents aren't clear on this point. Can you suggest some text that
A lookup for "user name" in the draft gives several hits, some of it 
give a tendency for an AOR:

The most natural rule is that a certificate authorizes a user to
   store data keyed with their user name X. This rule is used for all
   the kinds defined in this specification.  Thus, only a user with a
   certificate for "[email-masked]" could write to that location in
   the overlay.

10.3.1

 o  A single name this user is allowed to use in the overlay, using
      type rfc822Name.

12.3

When a user enrolls in the Overlay Instance, they request or are
   assigned a unique name, such as "[email-masked]". 

 Each certificate enables an entity to act in two sorts of roles:
   o  As a user, storing data at specific Resource-IDs in the Overlay
      Instance corresponding to the user name.

and many more.

So for the user name is sort of AOR, but not especially meant to be used 
for a SIP usage only. It is basically a RELOAD user name. It entitles a 
user to store data in the overlay using the given user name. If 
perpended with "sip:" it forms an AOR, ready to be used by a SIP usage.

Am I correct?