W3C

List of comments on “XML Signature Syntax and Processing Version 1.1” (dated 3 March 2011)

Quick access to

There are 3 comments (sorted by their types, and the section they are about).

general comment comments

Comment LC-2503
Commenter: Marcos Caceres <marcosscaceres@gmail.com> (archived message)
Context: 4.5.4 The X509Data Element Identifier Type="http://www.w3....
Not assigned
Resolution status:

On Mon, Jun 20, 2011 at 3:21 PM, Cantor, Scott E. <cantor.2@osu.edu> wrote:
> On 6/20/11 8:37 AM, "Marcos Caceres" <marcosscaceres@gmail.com> wrote:
>>Is there some means to explicitly indicate the order in which
>>certificates in an xml dig sig file should be processed? The problem
>>is that if you screw up the certificate order in the xml file, the
>>validator (e.g,. xmlsec) does not know which cert is the end-entity.
>
> BP is EE first, the rest after (and technically the order of the rest
> isn't supposed to matter).

Can I get an assurance from the XML Sec working group that a
non-normative note will be added to the XML Dig Sig specification wrt
to this best practice? Please consider this comment implementer
feedback on the CR.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2504
Commenter: Marcos Caceres <marcosscaceres@gmail.com> (archived message)
Context: in (Introduction and References)
assigned to Frederick Hirsch
Resolution status:

Add link and informative reference to XML SIgnature Best Practices document to XML Signature 1.1 introduction.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2502
Commenter: Sean Mullan <sean.mullan@oracle.com> (archived message)
Context: 4.5 The KeyInfo Element KeyInfo is an optional element that...
assigned to Frederick Hirsch
Resolution status:

Section 4.5, paragraph 2:

"If KeyInfo is omitted, the recipient is expected to be able to identify the key
based on application context. Multiple declarations within KeyInfo refer to the
same key. While applications may define and use any mechanism they choose
through inclusion of elements from a different namespace, compliant versions
must implement KeyValue (section 4.5.2 The KeyValue Element) and should
implement RetrievalMethod (section 4.5.3 The RetrievalMethod Element)."

These requirements seem like they should be revisited, especially since a later
section says to avoid RetrievalMethod because of potential security concerns
(see Note in section 4.5.10). Also, does this imply that all KeyValues must be
supported? I would think it should only be supported if there is a required
signature algorithm for the corresponding key type. Had there ever been any
discussion about updating the list of required KeyInfo types?

Thanks,
Sean
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org