santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heiner Westphal <Heiner.Westp...@verit.de>
Subject Re: Enveloped suggestions
Date Tue, 05 Jul 2005 07:49:30 GMT
Hi Martin!

See my comments inline.

Martin Ravell wrote:
> Hi Heiner,
> 
> Thanks for the response.
> 
> I've been giving this a little thought as I get up to speed with the whole
> xmldsig thing and pretty much reached the same conclusion. 
> 
> Fortunately my specific application pretty much has control over the xml
> creation and modification processes so I will be able to handle the use of
> whitespace between element tags. Thinking about it further I am reasonably
> sure that the other libraries that I am using (JAX-P etc) should deal with
> whitespace in a consistent manner (fingers crossed).
AFAIK there is only one situation, where some parser might drop non- 
significant whitespace:
Parsing with validation.

If the parser knows the schema or DTD, it *does* know, if mixed content 
is possible, or not. In that case it may drop non-significant whitespace.
If you have to validate before signature verification *and* the 
signature check has to be done on the output of the validating parser, 
then you have to make sure there is no non-significant whitespace
on the signed document (if you can control the signer, that is).

> 
> I've looked at the Apache samples a little closer and they seem to be more
> 'real world' than the reference versions from Sun since they do things like
> access keystores rather than generate once off keys etc. The only downside I
> see is a scarcity of documentation or tutorials. What have you experiences
> been with the Apache libraries?
The examples combined with this list proved pretty helpful.
The code is not overly documented, but clean enough to sort things out,
if in doubt.
I don't like code with too many comments. Many comments tend to be 
superflous or outdated, if not both. And code that *has* to be commented
is too complicated. Javadocs are very useful though.

I've done enveloping signatures only, which was straight forward 
starting with the right example, adding some code to handle DSA/RSA 
based pubkeys differently (ever tried to RSA-sign with an DSA-pubkey?).

Regards,

Heiner

> 
> 
> 
> Regards
> Marty
> 
> 
> -----Original Message-----
> From: Heiner Westphal [mailto:Heiner.Westphal@verit.de] 
> Sent: Monday, 4 July 2005 5:55 PM
> To: security-dev@xml.apache.org
> Subject: Re: Enveloped suggestions
> 
> Martin,
> 
> the canonicalizer cannot know, if the <element></element> may
> contain other elements only, or if mixed content is allowed.
> So there is no way to tell the difference between significant
> and non significant whitespace.
> Else the canonicalization would remove non significant whitespace,
> I would guess.
> 
> Just my 2 cent,
> 
> Heiner
> 
> Martin Ravell wrote:
> 
>>Hmmmm, it may well be a misunderstanding on my part then.
>>
>>I had assumed (yep I know that I should never assume anything) that the
>>following would be handled by the canonicalisation process:
>>
>><element>
>>  <child>Whatever</child>
>></element>
>>
>>Would be equivalent to 
>>
>><element><child>Whatever</child></element>
>>
>>
>>I was guessing that since the xml could go through various parsers and
>>modification processes that it would be possible for this sort of change
> 
> to
> 
>>be made but that the logical content of the two fragments above is the
> 
> same.
> 
>>Following your email and other replies to my post I have tested the
>>whitespace inside element tags ('<' and '>') and the canonicalisation does
>>seem to work under the Sun reference sample code. (From the JWSDP 1.5)
>>
>>
>>
>>Regards
>>Marty
>>
>>-----Original Message-----
>>From: Jesse Pelton [mailto:jsp@PKC.com] 
>>Sent: Friday, 1 July 2005 10:14 PM
>>To: security-dev@xml.apache.org
>>Subject: RE: Enveloped suggestions
>>
>>Canonicalization leaves whitespace in document content alone (though any
>>whitespace in element tags - that is, between the '<' and '>' that start
>>and end a tag - is normalized).  See
>>http://www.w3.org/TR/2001/REC-xml-c14n-20010315#Example-WhitespaceInCont
>>ent.  What behavior are you seeing that seems inconsistent with the
>>specification?
>>
>>
>>
>>>-----Original Message-----
>>>From: Martin Ravell [mailto:xml@rave-tech.com.au] 
>>>Sent: Thursday, June 30, 2005 7:36 PM
>>>To: security-dev@xml.apache.org
>>>Subject: RE: Enveloped suggestions
>>>
>>>Just had a crack at using the id and it seems to work. Given 
>>>that my app is
>>>building the XML to begin with I think I can live with the 
>>>limitations you
>>>mentioned.
>>>
>>>I notice that the reference samples (JWSDP 1.5) seem to ignore the
>>>canonicalization process on both the signing and verification 
>>>processes. (I
>>>tested removing some whitespace and wondered why it would not 
>>>verify until I
>>>took a closer look at the code).
>>>
>>>So I guess I'm still interested in which of the Apache 
>>>samples fits best
>>>(and does canonicalization properly).
>>>
>>>
>>>
>>>Regards
>>>Marty
>>>
>>>-----Original Message-----
>>>From: Martin Ravell [mailto:xml@rave-tech.com.au] 
>>>Sent: Friday, 1 July 2005 8:28 AM
>>>To: security-dev@xml.apache.org
>>>Subject: RE: Enveloped suggestions
>>>
>>>Thanks for the pointer Scott. I'll take another look at the reference
>>>implementation.
>>>
>>>I'm kind of interested in the Apache security stuff now and 
>>>my question on
>>>which of the samples to focus on still stands. Can you (or 
>>>anyone out there
>>>on the list) suggest a tutorial or even just which of the samples best
>>>covers the process of creating an enveloped signature and 
>>>then validates it?
>>>
>>>
>>>Thanks
>>>Marty
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Scott Cantor [mailto:cantor.2@osu.edu] 
>>>Sent: Friday, 1 July 2005 12:58 AM
>>>To: security-dev@xml.apache.org
>>>Subject: RE: Enveloped suggestions
>>>
>>>
>>>
>>>>I had also looked at the reference implementation that 
>>>
>>>ships with the
>>>JWSDP
>>>
>>>
>>>>1.5 but had problems in being able to specify a particular 
>>>
>>>element via
>>>URI.
>>>
>>>
>>>>The sample given seems to specify the whole document with a "" blank
>>>
>>>String
>>>
>>>
>>>>but when I try a relative URI (#elementname) it falls on it's arse.
>>>
>>>You can't specify an element in a fragment by name, only by 
>>>ID. Which has
>>>its own set of endless problems since IDs are technically 
>>>only legal in the
>>>presence of a DTD, so there are endless hacks to try and 
>>>establish what
>>>attributes are IDs and they all require knowing ahead of time 
>>>what's been
>>>signed.
>>>
>>>-- Scott
>>>
>>>
>>>
>>>
>>
>>
> 


Mime
View raw message