Re: [db-wg] X.509 authentication in the RIPE Database, take II

[Joao Luis Silva Damas <]

Shane,

adding a new strong authentication method to the Database, is in my own 
personal opinion, a good thing(tm), particularly if the same credential 
can be used for other interactions with the RIPE NCC, make user's life 
easier.

I wonder however about a few questions:

- will this auth method be available only to RIPE NCC members? Is it 
not seen as a valuable general addition for non-member users of the IRR 
part of the RIPE DB?

- Why the choice of not publishing the pulic part of the certificated 
in the DB? The choice to have a key-cert for the PGP method was not to 
do with issues of web of trust but rather for purposes of helping the 
users with their data maintenance. As a matter of fact the 
recommendation regarding the use of PGP in the RIPE DB, as described in 
the RFC and the minutes of the DBSEC TF, was to use a PGP key for this 
purpose that was not used elsewhere.

- will the RIPE NCC make avaiable, at the time of implementation, 
documentation to guide use of this feature by users with a couple of 
the most popular clients?

Thanks for the good work,
Joao Damas

On Thursday, August 14, 2003, at 06:24 PM, Shane Kerr wrote:

> All,
>
> [Apologies for duplicate e-mails]
>
> Attached please find a proposal for X.509 authentication in the RIPE 
> Database.  From the Database point of view (that is, syntax and 
> semantics), it is the same as the one sent 3 July 2003.  The 
> difference is that it contains only the specific details of the 
> change, in a straightforward fashion.
>
> I hope that we have addressed questions about the use of X.509 that 
> arose in earlier discussions.
>
> --
> Shane Kerr
> RIPE NCC
> Addition of X.509 authentication to the Database
>
>
> Proposal:
>
> To add an X509 authentication type to the "auth:" attribute.
> Attributes with this type will use the Distinguished Name (DN) of the
> certificate to identify it.
>
>
> Motivation:
>
> X.509 allows a single authentication method to work for both e-mail
> and the web.  LIRs can receive an X.509 certificate through the LIR
> Portal, and should be able to use this to update records they control
> in the Database.  X.509 is "strong", like PGP, although a different
> trust model is used.
>
>
> Details:
>
> The "auth:" attribute of the mntner class will have a new
> authentication scheme, X509.  The DN, as defined in RFC 2253, will be
> used to identify the specific certificate used.
>
> Note that there is no key-cert object for the X509 scheme.  Instead,
> the certificate must be signed by a trusted authority.  The trusted
> authority will be the RIPE NCC Certificate Authority (CA) that is
> currently only available to LIRs.  It is possible to configure
> additional CAs in future, should this become desirable.  For instance,
> existing commercial CAs could be allowed, or the RIPE NCC could create
> a CA to issue certificates to non-LIRs for this purpose only.
>
> Below is an example of a maintainer with X.509 authentication:
>
> mntner:       EXAMPLE-MNT
> descr:        Sample maintainer for example.
> admin-c:      SWK1-RIPE
> tech-c:       RD132-RIPE
> tech-c:       HOHO-RIPE
> upd-to:       ripe-dbm@localhost
> mnt-nfy:      ripe-dbm@localhost
> auth:         X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1
> auth:         X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2
> notify:       ripe-dbm@localhost
> mnt-by:       EXAMPLE-MNT
> referral-by:  RIPE-DBM-MNT
> changed:      ripe-dbm@localhost 20030813
> source:       RIPE
>
>
> Usage:
>
> E-mail updates for objects maintained by a maintainer with X509
> authentication must be sent in S/MIME format and signed (not
> encrypted) using the private key associated with the issued
> certificate.
>
> Synchronous updates for objects maintained by a maintainer with X509
> authentication must use an SSL connection using the private key from
> the issued certificate on the client side.
>
> Web updates for objects maintained by a maintainer with X509
> authentication can use a browser with the certificate loaded.  The web
> updates screens will allow users to specify that they want to identify
> themselves using the client-side private key, over an SSL connection.