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

Sean Mullan wrote:
> 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 
                                      ^^^^^^^^^^^^^^^^
s/best practice #5/best practice #2

> (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 14:22:13 UTC