Skip to Content.
Sympa Menu

cacert-policy - Re: [CAcert-Policy] Why is identity needed to authenticate domains?

Subject: Policy-Discussion

List archive

Re: [CAcert-Policy] Why is identity needed to authenticate domains?


Chronological Thread 
  • From: "Greg Stark" <gstark AT electrorent.com>
  • To: "'Policy-Discussion'" <cacert-policy AT druantia.cacert.org>
  • Subject: Re: [CAcert-Policy] Why is identity needed to authenticate domains?
  • Date: Thu, 10 May 2007 12:53:23 -0700
  • List-archive: <http://lists.cacert.org/cgi-bin/mailman/private/cacert-policy>
  • List-id: Policy-Discussion <cacert-policy.lists.cacert.org>

Mondior,
I think cryptographic strength misses the point.  You don't need CAcert to
create certificates to secure your internet activities.  YOU do not need US.

So why do you want to use our certificate service for?  So you or visitors
to your website don't get the annoying SSL popup window?

You wish to be anonymous!  A 6 month certificate is what CAcert offers.  6
months, no user name  Frankly, I think it should be a 30 day certificate.

Look, What CAcert offers its users, for free is, trusted identity on the
internet.  To do this we look at one another's official identity documents
to confirm who we, and if that is not posible we ask you to provide us with
documentation (TTP Form).  Having done that I can feel confident that when I
get a signed document from you.  It is you.  For you to have your name on
the certificate you have met the requirements of our community.  You are
established in our Web-Of-Trust.  A member of the Club.

Anonymous identity just does not exist here.  Privacy does.  No address is
asked for.

Greg

> -----Original Message-----
> From: 
> cacert-policy-bounces AT druantia.cacert.org
>  
> [mailto:cacert-policy-bounces AT druantia.cacert.org]
>  On Behalf 
> Of 
> mfolimun AT elitemail.org
> Sent: Thursday, May 10, 2007 11:19 AM
> To: Policy-Discussion
> Subject: Re: [CAcert-Policy] Why is identity needed to 
> authenticate domains?
> 
> 
> On Thu, 10 May 2007 08:25:35 -0700, "Peter Williams" 
> <home_pw AT msn.com>
> said:
> > An auditor would normally accept two risk-based rationales, 
> supporting 
> > the policy of CA management concerning periods.
> >  
> > 1. lack of cryptographic strength is mitigated by limiting the 
> > exposure of the key, by limiting the period during which it can be 
> > used
> >  
> > 2. naturally diminishing strength of the binding of a 
> confirmed name 
> > to the public key over time is mitigated by setting a 
> threshold date 
> > after which the strength must be re-established in order to 
> convey the 
> > appropriate amount of identity assurance. Obviously, either further 
> > professionalize or simplify the language, to suit the audience.
> 
> Well 1 doesn't apply (since I intend on requesting at least a 
> 2048bit key), so I will address 2. Ultimately, a signed TLS 
> cert is a certification of a domain name, not an individual 
> person. For my domain, no individual is listed on the whois 
> information, so there is no identity to assure.
> 
> However, I can conclusively demonstrate, via a number of 
> different technical mechanisms, that the request for the 
> certificate is actually coming from the entity that owns the 
> domain. Therefore, I don't understand why I am to be given 
> such an low threshhold of trust.
> A reasonable level, in my opinion, would be the lesser of 1 
> year and domain expiration date. 6 months is too rapid to be 
> practical.
> 
> The ability to create subdomains, answer postmaster's mail, 
> and post requested web content demonstrates 3 independent 
> mechanisms for verifying domain ownership. Reverse DNS 
> represents yet a fourth.
> Since seeing an ID in my case adds no additional assurance of 
> domain ownership (it could be anyone's ID: whois displays no 
> one), I really don't see any reason why a full length cert 
> shouldn't be granted using these mechanisms.
> -- 
>   
>   
> mfolimun AT elitemail.org
> 
> --
> http://www.fastmail.fm - Accessible with your email software
>                           or over the web
> 
> _______________________________________________
> Have you subscribed to our RSS News Feed yet?
> 
> CAcert-Policy mailing list
> CAcert-Policy AT lists.cacert.org
> http://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.16.

Top of Page