Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

["John R Levine" <[e-mail]>]

On Wed, 2 Jan 2019, Gould, James wrote:
> To remove any concerns related to the inclusion of VSP policy in draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof of verification and the generated verification code; and MAY store the verified data." can be removed.  If there are no objections to the removal of this sentence, it will be removed in the next version of the draft.

That's OK with me.  I'm not totally opposed to it but without some hint 
about what an interoperating system would do with the object the token 
points to, I think it's confusing.  As you can see, it confused me.

>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 1/2/19, 3:56 PM, "regext on behalf of John R Levine" <[e-mail] on behalf of [e-mail]> wrote:
>
>    On Wed, 2 Jan 2019, Adam Roach wrote:
>    >>  I don't understand why.  The code is a signed token.  Imagine the registry
>    >>  goes back to the signer asks about token 123-foo666 and the answer is
>    >>  "We're the Ministry, we signed it, of course it's valid.  The details are
>    >>  secret."
>    >>
>    >>  While that would not be my favorite way to work, and I can easily imagine
>    >>  other scenarios with auditing and transparency business requirements, why
>    >>  wouldn't that interoperate?
>    >
>    > If we're concerned merely with interoperation, the same is true of most --
>    > if not all -- normative keywords used in "Security Considerations" sections.
>    > Your position might (or might not) be correct, but the logic of "2119
>    > language is only used for interoperabilty reasons" simply isn't true.
>
>    I think there's a difference -- in security sections the goal is usually
>    to prevent leakage or spoofing or something else that would allow a
>    malicious party to interoperate with a victim.  One part of good interop
>    is not to interoperate with attackers.  But that's not what's going on
>    here.  The signature shows that the token is valid, and unless I'm missing
>    something, whatever you might learn from the thing the token represents is
>    outside the scope of EPP.
>
>    Regards,
>    John Levine, [e-mail], Taughannock Networks, Trumansburg NY
>    Please consider the environment before reading this e-mail. https://jl.ly
>
>

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly