Subject: [Curdle] should we include xmldsig and xmlenc?

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2015 12:48:54 +0000

Hiya,

I was at a thing with some w3c folks yesterday and mentioned
curdle. It is conceivable that W3C may want to add codepoints
to xmldsig and xmlenc for the new curves, just like we do. So
far though, I've not seen anyone ask specifically for that.

xmldsig was a joint bit of work between the IETF and W3C but
that was a bit of a process-pain, so xmlenc was just done as
a W3C thing. OTOH, Don Eastlake did write up an RFC for some
additional algorithms for those as RFC6931 as well. [1] I
guess that amicable divorce wasn't ever fully finalised:-)

So, questions:

1. is there interest to define how to use the new curves for
   xmldsig and xmlenc?
2. if 1==yes, do we have volunteers to do the editing work?
3. if 1==yes and 2==yes, is curdle the right place to do that
   or should we just leave that to W3C to handle as and when
   they want?

FWIW, I've no strong opinions on this, but if this group
felt that the answers to all 3 questions are yes, then we
should probably sort that out with W3C (one way or another)
while we're chartering curdle. If any of the answers is no,
then we're good as-is and there's nothing else we need do
for now.

Cheers,
S.

PS: mnot and Wendy are cc'd as they're the relevant liaison
folks between the IETF and W3C.

[1] https://tools.ietf.org/html/rfc6931

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Dec 2015 14:14:06 +0100

XML Digital Signatures is mentioned in the curdle charter text.  I
suggest to add XML Encryption too.

Incidentally, I approached Wendy and Frederick Hirsch about this last
month, and their recommendation (IIUC) was that since the W3C group is
in maintenance mode it would be preferrable to announce work on this to
their list and then go from there.

I have an Ed25519/Ed448-for-XMLDigSig document sitting on my disk, but
it is pending feedback from implementers.  I don't believe it would be
useful to approach this as a prescriptive work.  I can post the document
as an I-D if that would help get implementations going, but I don't
think we should adopt this if nobody is interested in implementing it.
I'm hesitant about burning energy on corner-cases since it will delay
publishing the documents that implementers deployed years ago.

Another option may be for the IETF to recognize reality and recommend
against further use of XMLDigSig/XMLEnc completely.  I.e., "XML Security
Considered Harmful".  A compromise would be to say that it is OK to use
for existing use-cases, but don't use it in new protocols.  I believe
that reflect the general thinking among implementers about XML Security
in general.

/Simon

Stephen Farrell <[email-masked]> writes:

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 2 Dec 2015 15:19:39 +0100

> I have an Ed25519/Ed448-for-XMLDigSig document sitting on my disk

No need to keep it there, I have pushed it, and include it below.

https://gitlab.com/jas/ietf-xmldsig-curves/blob/master/draft-josefsson-xmldigsig-curves.md

/Simon

EdDSA Ed25519/Ed448 for XML Digital Signatures
==============================================

We describe how EdDSA digital signatures (Ed25519 and Ed448) [EDDSA]
can be used in XML Digital Signatures [XMLDSIG].

Approach
========

EdDSA is used in XML Digital Signatures through the Elliptic Curve
Digital Signature Algorithm (ECDSA) framework described in [XMLECDSA].

While EdDSA is different from ECDSA, we have chosen to re-use existing
elements and specify semantic conventions specific to EdDSA, rather
than to describe a new mechanism.

The remaining sections describe how use of EdDSA differs from use of
other ECDSA schemes in the [XMLECDSA] framework.

Namespace and Identifiers
=========================

The XML namespace URI that MUST be used by implementations of this
specification is:

    http://josefsson.org/2015/12/xmldsig-eddsa#

Elements in the namespace of the [XMLDSIG] specification are marked by
using the namespace prefix "dsig" in the remaining sections of this
document.

The URI Identifiers used to identify the algorithms we describe are
for Ed25519 and Ed448 respectively:

    http://josefsson.org/2015/12/xmldsig-eddsa#ed25519
    http://josefsson.org/2015/12/xmldsig-eddsa#ed448

EdDSA Key Values
================

EdDSA public keys are encoded using the new element EdDSAKeyValue.
Include the element inside dsig:KeyValue similar to dsig:RSAKeyValue,
dsig:ECDSAKeyValue.  The EdDSA public keys are binary strings as
described in [EDDSA], here encoded as base64.

DTD Replacement
---------------

The following definition amends the entity Key.ANY

    <!ENTITY % KeyValue.ANY '| ecdsa:EdDSAKeyValue'>

Schema definition
-----------------

The element consists of the base64 encoded public key.

      <xs:element name="EdDSAKeyValue" type="eddsa:EdDSAKeyValueType"/>
      <xs:simpleType name="EdDSAKeyValueType">
           <restriction base="base64Binary"/>
      </xs:simpleType>

DTD Definition:

      <!ELEMENT EdDSAKeyValue  (#PCDATA)  >
      <!-- base64 encoded digest value -->

EdDSA Signatures
----------------

Similar to RFC 4050, the input to the EdDSA algorithm is the
canonicalized representation of the dsig:SignedInfo element as
specified in Section 3 of [XMLDSIG].

The output of the EdDSA algorithm is a binary string.  The signature
value (text value of element dsig:SignatureValue - see section 4.2 of
[XMLDSIG]) consists of the base64 encoding of the binary EdDSA output.

Security Considerations
=======================

See [EDDSA], [XMLDSIG], and [XMLECDSA]

XML is by design prone to implementation flaws.

References
==========

[EDDSA] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa

[XMLDSIG] RFC 3275

[XMLECDSA] RFC 4050

Appendix
========

Aggregate XML Schema
--------------------

    <?xml version="1.0" encoding="UTF-8"?>
    <xs:schema
     targetNamespace="http://josefsson.org/2015/12/xmldsig-eddsa#"
     xmlns:ecdsa="http://www.w3.org/2001/04/xmldsig-more#"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified"
     version="0.2">

     <!--ECDSA key value root element-->

     <xs:element name="EdDSAKeyValue" type="eddsa:EdDSAKeyValueType"/>
     <xs:simpleType name="EdDSAKeyValueType">
          <restriction base="base64Binary"/>
     </xs:simpleType>

    </xs:schema>

Aggregate DTD
-------------

    <!ELEMENT EdDSAKeyValue  (#PCDATA)  >
    <!-- base64 encoded digest value -->