[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006

Hi Francis,

El 21/07/2006, a las 17:54, Francis Dupont escribió:


 In your previous mail you wrote:
yes but the pki for issuing client certificates that bind IP addresses with public keys may be significatly different from the one available 
   for TLS server certificates.
=> one real world difference is for public TLS servers one is ready to pay... 

   In particular, the type of verification
that is needed is different since in one case you must verify that the 
   fqdn contained in the certificate actually belongs to the server,
=> in fact this is not a TLS property but something asks by the application 
(perhaps through an abstract "secure connection setup").
i think there is a misunderstanding here... by verification i am not talking about the protocol to perform the verification, but the actual process carried on by the Registration authority to verify that the one that is requesting the certificate actually owns the ip address that it wants to include in the certificate. It is not the protocol perspective that i am refering to but the logistic perspective. What is the administrative procedure to perform such verification. My point is that you need to build a different administrative setup to verify the information included in this type of certificates... 


   while
   in the other case you need to verify that the particular IP address
   belongs to a given person, which imho may be harder (since today
addresses are not assigned as a unit but prefixes are allocated to lirs 
   and lirs assign prefixes to end sites and then end sites assign
   addresses to hosts, so the verification of the trust chain may be
   harder imho

=> if you want to stick the prefix delegation with the trust chain
I suggest the RFC 3779 (I can share some code implementing it I did
for a SEND prototype) but it works only for static assignments and
perhaps does not well suit to this particular problem (a reverse
DNSSEC seems better, RFC 3779 was designed for routing protocols).
again, i am not talking about certificate formats but the actual administrative provedure and agreements that need to be in place to issue this type of certificates and that they are needed to validate the information included in them 


makes sense now?

regards, marcelo



Regards

Francis.Dupont@point6.net