W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2003

Re: X509 data element

From: Joseph Swaminathan <jswamina@cisco.com>
Date: Wed, 05 Feb 2003 10:13:21 -0800
Message-ID: <3E415441.A23187F8@cisco.com>
To: Tom Gindin <tgindin@us.ibm.com>
CC: Rich Salz <rsalz@datapower.com>, w3c-ietf-xmldsig@w3.org

Tom, Rich,

        My question is, if there is a content in the XML document we
cannot trust, then shouldnt we, not use it for any purpose. What
situation a data which can't be trusted be useful.

        Even if we don't use that for validation, I feel it still couldn't
understand where it could be useful.

        Rich in your mail you mentioned, the x509 elements are used
as a lookup information. Supposing the end entity validates the
certificate using XKMS, and the key management server says
everything is in order. Now supposing  the entity uses the x509 subject
name element as lookup info to store the received document in the
appropriate folder. If the subject name in the ceritificate and the
subject name element does not match (hacked), the documents will
end up in the wrong place, and will be as good as not receiving the
document. So even if we don't use the extra information to validate
the contents, a hacker could still disrupt the normal operation of the
end organization isn't it.


Tom Gindin wrote:

>       Joseph:
>       Some responses below.  I think you've uncovered an actual attack
> against some possible RP software - not mainly by substituting X509yyy
> parameter values, but by adding KeyValue to them.  The attack I see
> (against RP software in which KeyValue's are accepted) is that an attacker
> will extract the key from a certificate (probably in X509Certificate, but
> possibly retrieved elsewhere given some of the other parameters), create a
> KeyValue from it, and add a phony X509SubjectName.
>       IMHO, you should be suspicious of a KeyInfo containing KeyValue and
> either X509IssuerSerial or X509SubjectName.  Is there anybody on the list
> who creates such constructs in their software, and if so, why?
>             Tom Gindin
> Joseph Swaminathan <jswamina@cisco.com>@w3.org on 02/04/2003 09:42:38 AM
> Sent by:    w3c-ietf-xmldsig-request@w3.org
> To:    Rich Salz <rsalz@datapower.com>
> cc:    w3c-ietf-xmldsig@w3.org
> Subject:    Re: X509 data element
> Rich Salz wrote:
> > >    1. When X509 certificate element is present, is there any need
> > >       for X509IssuerSerial, X509SubjectName, X509SKI, elements. Is
> > >       it possible for all of these to be present. If so, what is
> > >       the significance of the later three, as the first one contains
> > >       all of them.
> >
> > Many implementations actually provide more than one of the differnet
> > forms in the same signature.  Yes, the certificate includes all the
> > other data, but it requires a fairly heavy-duty ASN1/DER parser.
> > Breaking out the alternate "lookup keys" is just "friendly," as it were.
>      Since the signature value on the signature node only covers the
> signed info element, the individual x.509 elements present in the
> key info is not signed at all. In that case, how can these values be
> trusted, unless it is cross verified with x.509 certificate.
> [Tom] You can't verify the signature on the document without getting the
> public key info.  This would have to be gotten either from the certificate
> (in which case you've got all the individual values to check) or KeyValue.
>        Wont it be possible for a hacker to intercept the XML document
> and add these individual x.509 elements which is not consistent with
> x.509 certicate and change the signed info as he pleases.
> [Tom] The danger you are talking about would occur only if somebody were to
> specify KeyValue with one of those elements, and you were to take their
> word for it.
> thanks
> Joseph
> > >    2. Also, how is a certificate validated. Is it by
> >
> > That's a local trust issue, and depends on your implementation and
> > business requirements.  A common 80/20 technique is to verify that the
> > certificate *or it's issuer* came from a locally-configured trusted list.
> >
> >         /r$
Received on Wednesday, 5 February 2003 13:14:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:38 UTC