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


To: "Frank Thompson" <fot@ca.afilias.info>, "Francisco Obispo" <fobispo@nic.ve>
Cc: "Alexander Mayrhofer" <axelm@nic.at>, <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Thu, 7 Dec 2006 10:47:45 -0500
Content-class: urn:content-classes:message
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AccaFawRLOJ91RMeRByzDaYpDdlPVAAAPGug
Thread-Topic: [ietf-provreg] Re: Certificate Validation and Subject Analysis
Subject: RE: [ietf-provreg] Re: Certificate Validation and Subject Analysis

> -----Original Message-----
> From: Frank Thompson [mailto:fot@ca.afilias.info] 
> Sent: Thursday, December 07, 2006 10:37 AM
> To: Francisco Obispo
> Cc: Alexander Mayrhofer; ietf-provreg@cafax.se; Hollenbeck, Scott
> Subject: Re: [ietf-provreg] Re: Certificate Validation and 
> Subject Analysis
> 
> 
> Hello,
> 
> Afilias does not employ CN idenity ACL checking either for the same 
> reasons as NIC.VE, but use other hardware/software solutions 
> for client 
> idenity and IP ACL validation.
> 
> Therefore we also believe that this does not belong in the 
> EPP protocol.

Well, you guys will need to take that up with the IESG after reviewing
RFC 3280.  In the mean time, what do you do if the certificate presented
from a client has valid certification path signatures, but the names
have nothing to do with that client?

-Scott-


Home | Date list | Subject list