Re: ACTION-56: Suggested text for best practices draft

How about moving Retrieval Method 2.1.2 to end of denial of service  
section (after current 2.1.5)  and/or moving denial of service section  
2.1 to end (after current 2.5)?

(Note that comment on introduction now has separate email thread.)

regards, Frederick

Frederick Hirsch
Nokia



On Sep 19, 2008, at 11:14 AM, ext Hirsch Frederick (Nokia-OCTO/Boston)  
wrote:

>
> resend to public list, please follow-up on public list.
>
> Begin forwarded message:
>
>> Resent-From: member-xmlsec@w3.org
>> From: "ext Sean Mullan" <Sean.Mullan@Sun.COM>
>> Date: September 17, 2008 10:26:13 AM EDT
>> To: Scott Cantor <cantor.2@osu.edu>
>> Cc: "'XMLSec WG Member List'" <member-xmlsec@w3.org>
>> Subject: Re: ACTION-56: Suggested text for best practices draft
>>
>>
>> Looks good. One comment. It is not clear what is meant by "heavily  
>> profiling the transforms allowed". I think that best practice #2  
>> might be more clear if it was moved a bit later in the document,  
>> after discussing the malicious transforms. Then that sentence could  
>> be reworded to say that the transforms should abide by the best  
>> practices X-Y discussed earlier.
>>
>> Also, another comment not related to this action item. In the  
>> introduction, there are two paragraphs which say the same thing. I  
>> recommend removing the first paragraph.
>>
>> --Sean
>>
>> Scott Cantor wrote:
>>> My suggested changes are to section 2.1, under Best Practice 2. I  
>>> suggest
>>> replacing those two paragraphs with this text:
>>> ----
>>> In step 1, if the verification key is not known beforehand and  
>>> needs to be
>>> fetched from KeyInfo, the implementation should be careful in its
>>> processing. The KeyInfo can contain a RetrievalMethod child  
>>> element, and
>>> this could contain dangerous transforms, insecure external  
>>> references and
>>> infinite loops (See examples below).
>>> RetrievalMethod has legitimate uses; for example when there are  
>>> multiple
>>> signatures in the same document, these signatures can use a  
>>> RetrievalMethod
>>> to avoid duplicate KeyInfo certificate entries. However,  
>>> referencing a
>>> certificate (or most other KeyInfo child elements) requires at  
>>> least one
>>> transform, because the reference URI can only refer to the KeyInfo  
>>> element
>>> itself (only it carries an Id attribute). An implementation that  
>>> must handle
>>> potentially hostile messages should constrain the RetrievalMethod  
>>> elements
>>> that it processes - e.g. permitting only a same-document URI  
>>> reference, and
>>> heavily profiling the transforms allowed.
>>> Another potential security issue in step 1, is the handling of  
>>> untrusted
>>> public keys in KeyInfo. Just because an XML Signature validates
>>> mathematically with a public key in the KeyInfo does not mean that  
>>> the
>>> signature should be trusted. The implementation must first  
>>> validate that the
>>> public key is trusted with respect to the creator of the signature.
>>> For example, keys may be exchanged out of band, allowing the use  
>>> of a
>>> KeyValue or X509Certificate element directly. Alternatively,  
>>> certificate and
>>> path validation as described by RFC 5280 or some other  
>>> specification can be
>>> applied to information in an X509Data element to validate the key  
>>> bound to a
>>> certificate. This usually includes verifying information in the  
>>> certificate,
>>> such as  the expiration date, the purpose of the certificate,  
>>> checking that
>>> it is not revoked, etc.
>>> Key Validation is typically more than a library implementation  
>>> issue, and
>>> often involves the incorporation of application specific  
>>> information. While
>>> there are no specific processing rules required by the XML Signature
>>> specification, it is critical that applications include key  
>>> validation
>>> processing that is appropriate to their domain of use.
>>> ---
>>> Comments welcome.
>>> -- Scott
>>
>>
>
>

Received on Monday, 22 September 2008 22:02:40 UTC