About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting

  • From: Andrei Robachevsky <
    >
  • Date: Thu, 01 Mar 2007 08:13:52 +0100

Vasily, others,

Vasily Dolmatov wrote:
[...]

> In brief: There is no way to _ensure_ that certificate was taken by proper
> person.
> There is crucial difference between "Leo Vegoda with valid passport in hand"
> and "someone who connected to the Portal using two text strings, which some
> time ago were sent by e-mail to someone who wrote he was Leo Vegoda".
> So, certificate generated in the first case can legally represent Leo Vegoda
> (provided another lot of conditions were met), certificate generated in the
> second case can represent _nothing_ and _noone_. It will be issued and
> transferred to _unknown_person_ who happened to posess knowlegde of pair of
> text strings in given moment of time. No claims concerning following actions
> using this certificate can be considered either legally or logically.
>

I understand that you probably used an identity certificate an an
example only, but perhaps we need to ensure we are on the same page WRT
what the resource certificates are certifying.

Current thinking is that those certificates only state that
- resources listed in the extension have been allocated (and that can be
validated)
- the holder of the private key corresponding to the public key in the
certificate has right to use the resources.

This is explained in more detail in the Certificate Policy that is being
discussed in the IETF:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-01.txt

In particular this document states:

"1.4.1. Appropriate certificate uses

   The certificates issued under this hierarchy are for authorization
   in support of validation of claims of current holdings of address
   space and/or AS numbers, e.g., for routing security. With regard to
   routing security, an initial goal of this PKI is to allow the holder
   of a set of address blocks to be able to declare, in a secure
   fashion, the AS number of each entity that is authorized to
   originate a route to these addresses, including the context of ISP
   proxy aggregation.  Additional uses of the PKI, consistent with the
   basic goal cited above, are also permitted under this policy.

   Some of the certificates that may be issued under this hierarchy
   could be used to support operation of this infrastructure, e.g.,
   access control for the repository system. Such uses also are
   permitted under this policy. "

Does this help in defining the goals?

Regards,

Andrei
[...]



 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community