[ppml] Policy Proposal 2007-1 - Staff Assessment

[Kevin Kargel]

If it is just authentication we are worrying about why  are we talking
about limiting it to one method?  I like the idea of having access to a
method such as 'smtp from' as a fallback.  If you want to make that
stricter you could enforce SPF requirements on the SMTP for that to
work. I am not sure about the SPF as that would place requirements on
the email provider that may be beyond the end users control.

The pgp (or other certificate method) would be simpler for the user once
implemented, and would probably be the method of choice, but there are
times that I am caught away from my normal resources and need to do
"stuff" , where alternate methods come in handy. 

I do much like the Thawte Web of Trust (WoT) personal email signatures,
which are easily implemented in current email clients (like the
microsoft variants) and allow authenticated/encrypted email without
needing to add a plugin or run a separate program.  These signatures are
also available for free.  The biggest probem I see with using them is
that they are not USA based and the US centric folks will go zenophobic.

Kevin

$s/worry/happy,g 





> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Stephen Sprunk
> Sent: Friday, April 13, 2007 5:01 PM
> To: Randy Bush; Member Services
> Cc: ARIN PPML
> Subject: Re: [ppml] Policy Proposal 2007-1 - Staff Assessment
> 
> Thus spake "Randy Bush" <randy at psg.com>
> >>      4. In the section "KEY USE IN COMMUNICATION", the proposal 
> >> requires validation of "a chain of trust not longer than 
> five steps" 
> >> between the signing key and ARIN's hostmaster role key, without 
> >> regard to whether such intermediary signers are ARIN POCs, or are 
> >> even known to ARIN.  Without direct binding of the PGP key 
> to an ARIN 
> >> POC record, such anonymity in the chain of trust raises serious 
> >> questions about how ARIN staff will know and evaluate that 
> an e-mail 
> >> from a signer is authentically from the ARIN POC that the sender 
> >> claims to be.
> >
> > this is critical!
> 
> I think folks are confusing authentication with authorization 
> here (which is common).  The number of steps through the web 
> of trust indicates how much confidence one has when 
> authenticating a sender.  It has nothing to do with 
> authorizing the sender to perform a given action.
> 
> For instance, if bob at foo.com signs a key for john at bar.com, 
> ARIN could legitimately consider mail from john at bar.com to be 
> authentic if ARIN trusts bob at foo.com.  Still, ARIN would only 
> allow john at bar.com to update FooCorp's records if he was a 
> POC for FooCorp.  Or is my understanding of the proposal 
> wrong?  I doubt that, if someone at AT&T signs a key of 
> someone at Verizon, the authors intended to let Verizon 
> modify all of AT&T's resources...
> 
> I happen to think five steps is excessive, and would like 
> that revised lower, but by itself that's not enough reason 
> for me to be against this proposal.  Still, counsel's 
> reasonable concerns about liability may require us to 
> eliminate the chain of trust entirely.
> 
> >> Although ARIN could proceed by generating a new PGP-key, we would 
> >> need to use a limited distribution mechanism that excludes 
> well-known 
> >> servers, since more than one key for the same e-mail 
> address cannot 
> >> exist in the key servers.
> >
> > i believe that last assertion to be incorrect
> 
> I know for a fact it's incorrect; the same thing happened to 
> me years ago and the keyserver network now has several 
> different keys for me (only one of which I still possess).
> 
> Still, I'd expect that the keyserver operators would 
> cooperate with removing ARIN's old key if contacted by 
> non-electronic means.  They might not (er,
> won't) do this for individuals, but ARIN does have standing 
> in the community that warrants an exception...
> 
> Also, it's possible to have multiple email addresses attached 
> to the same key, allowing hostmaser@, reassign@, and any 
> other role addresses to use the same key.  However, non-role 
> addresses should not be added since they effectively cannot 
> be removed.
> 
> S
> 
> Stephen Sprunk      "Those people who think they know everything
> CCIE #3723         are a great annoyance to those of us who do."
> K5SSS                                             --Isaac Asimov 
> 
> 
> _______________________________________________
> This message sent to you through the ARIN Public Policy 
> Mailing List (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>