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

Frederick Hirsch wrote:
> 
> 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)?

I think we should replace/move the best practice #5 about RM (RetrievalMethod) 
and the following paragraph from section 2.1 to section 2.1.3. The RM best 
practices can then be combined because they are both essentially the same (be 
careful or avoid RetrievalMethod).

We could also then replace the paragraph with a sentence in section 2.1 that 
refers to the RetrievalMethod best practice, for ex:

 >>>> 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 best practice #X for more information).

--Sean


> (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 Tuesday, 23 September 2008 13:04:43 UTC