[CAP] Then Again... (was Re: CAP Security UsingDigitalSignatures)

Art Botterell acb at incident.com
Thu Mar 12 15:22:43 PDT 2009


I look at it kind of the other way 'round, Brian.  If the digital  
signature is applied to the message as originally authored, there's no  
ambiguity and all a recipient needs is a clean copy of the original  
and the sender's public key.  Whereas if we attempt to canonicalize,  
every recipient (at least, any one that wants to be able to verify a  
signature) will need to become, and remain, fluent in one or more C14N  
schemes... and it doesn't look, from those W3C documents, as if that  
technology has fully stabilized yet.  Which to my mind raises even  
larger practical problems of interoperability.

The canonicalization kerfluffle does offer a good excuse to do nothing  
and wait a few more years for the dust to settle.  And under some  
circumstances that might be appropriate.  However, given the systems  
slated to roll out over the next couple of years, I think it could be  
a serious mistake that we'd be forced to live with for a long time.   
Thus my suggestion that we might want to get started by using one  
approach that everyone can understand in exactly the same way, using  
tools that are currently available.

Certainly I do understand that some programmers, particularly ones who  
are wholly dependent on off-the-rack frameworks, might find the null- 
canonicalization approach challenging.  And maybe in the long run  
it'll prove unnecessary, in which case everybody wins.

But if we don't start demonstrating some end-to-end authentication  
solutions soon, I'm concerned we'll find ourselves getting locked into  
one or more stovepipe authentication domains.  And that *would* be a  
betrayal of the purpose of CAP.

- Art

On Mar 12, 2009, at 3/12/09 2:52 PM, Russo CTR Brian T wrote:

> I think not performing C14n would be a mistake because then you open
> yourself up to a whole mess of bugs and interoperability issues  
> involving
> text encoding.. whitespace.. etc.. Not all of which would accurately  
> be
> characterized as bugs since many would involve legal serializations.
>
> If I can't load an infoset, then turn around and deserialize it  
> without
> changing anything - and have my implementation of XML "break" your
> signature, then I consider that a problem. I understand how many  
> wouldn't
> but in the long run you're just shooting yourself in the foot for some
> upfront convenience.
>
> And if you don't have an easily interoperable format.. Then what's the
> purpose of CAP?
>
> - bri
>



More information about the CAP-list mailing list