Re: [VIPR] Identity certificate segregation for VIPR

[Eric Rescorla <[e-mail]>]

On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/07/2012 09:51 AM, Eric Rescorla wrote:
>> On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin <[e-mail]>
>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> The current version of RELOAD requires that the certificates used contain
>>> one or more Node-IDs and one username.  This username plays no role in
>>> VIPR, so it is not only useless, but can also be a source of privacy
>>> leak.
>>>
>>> A proposal was made in the p2psip WG some time ago for Identity
>>> certificate segregation[1] (see also [2]), but the author is waiting for
>>> the final version of RELOAD to publish a draft about this.
>>>
>>> My proposal is to say in the RELOAD usage document that VIPR must not
>>> use certificates with username, and to put a placeholder for the
>>> reference to the upcoming draft about Identity certificate segregation.
>>
>> Or, you could just use a dummy (random) username, e.g., a hash of the
>> node-id.
>>
>
> Yes, although that would still require an enrollment server that slightly
> deviates from what is described in section 10.3 of RELOAD...
>
> ...or more precisely from what I understand from section 10.3, which is that
> the user name stored in the certificate returned is the concatenation of 1)
> the username passed as parameter of the HTTP POST, 2) the '@' character and 3)
> the overlay name (there is at least one implementation I know of that assumes
> that the username parameter is already in RCF822 form, thus permitting a
> domain name different from the overlay name).

I don't read 10.3 as restricting the user name to be what is in the POST. The
requirement is:

   o  A single name this user is allowed to use in the overlay, using
      type rfc822Name.  Enrollment servers SHOULD take care to only
      allow legal characters in the name (e.g., no embedded NULs),
      rather than simply accepting any name provided by the user.

As authentication may not be required at all, I don't see how there
can be a requirement that these two usernames be the same.

   o  If authentication is required, there is an form parameter of
      "password" and "username" containing the user's name and password
      in the clear (hence the need for HTTPS)

-Ekr



> - --
> Marc Petit-Huguenin
> Personal email: [e-mail]
> Professional email: [e-mail]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBCAAGBQJPMWtuAAoJECnERZXWan7E5iMP/i8USAqHFD8yhxAE8w2PKgyl
> CqWALShBV36pfMWojjQnNXDrLRPj0hnBoz9mQmBne03GQPof9x/uqDNdbc0BGm5+
> xmEWpQr4ZHqPm1L0pZRmg2o/7X3M+61Byc1x+WjOda0weZX8qg6xEgOyRgpFPlsa
> GowkfMgFj69xk5bvH+wXI27a1cWBeR5ocrICkWwHCwrVmmysQzixD4bGmb8+wmLX
> QZ9CiL77cGxRzvGSULl0smqIyGR2WkrIzErpdVoqvFIXAV12AMEKZAGjMjReCX2B
> OOsxtfpz2xLKpqgHdLCcV65Gvd4dEM8jChZAIRPG1WhanpM/rYlrUt0gF9SFX5cC
> DRcM5II8vKqgwPQ2yb42tNekYpWicxcK09T5U7ghMsJttMbfEpK3vb8lAmAfpt6h
> /n/VmgxqocMgRSIYHWPOFiJ69fbMml4Hn31DKUc9IrVYN5IlTT/zg4ILEww0sLdI
> KqDDboDS9FZB1pBrEiAeCDcGIz0rKKheGH95iedAdkcp0lFP6p3SrzaFzIKtjq/r
> ME+PBUjMjXPROz5m/w/BL8TAtwGfbbv3GDlkIXtM0aSybHCjhZSEtK8ng457sd3u
> 6Lv/WV8i2hlMj5guYV8rI1J+S3r7mm+31O4NxyVXVBpy1DDRnMNyfV8xJJt6dqfM
> h7UHwT2A5OoNOtdZgsn7
> =XWUE
> -----END PGP SIGNATURE-----