Subject: XML Digital Signatures for EPP.

From: Roger Castillo Cortazar <[email-masked]>
Date: Wed, 17 Apr 2002 13:30:44 -0500

Hi everybody.

We are working on an implementation of EPP for NIC-MX.

In our requirements we included a digital signature for all the
object transform commands.

This will provide the means to authenticate the sender,
verify the integrity of the information and to assure
the non-repudiation of the command.

There is a lot of work from IETF and W3C on XML Signatures,
we have some RFC's on signing models, canonical forms, etc.
There are also a few SDK's for XML digital signatures.

This seems to be quite interesting and useful, any comments ?
Is anyone working on something like this ?

Maybe this could be an interesting extension for EPP.
What do you think ?

Greetings.

Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx
Top Level Domain .MX

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Apr 2002 17:23:41 -0400

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 2:31 PM
> To: [email-masked]
> Subject: XML Digital Signatures for EPP.
> 
> 
> Hi everybody.
> 

Roger,

I've been thinking about this from the very beginning, but haven't really
wanted to get started until the EPP core documents were finished and the XML
DSIG stuff firmed up a bit.  Now that we're getting close to finishing the
core documents and RFC 3275 has been published I plan on looking at it much
more closely.

One other thought: digital signatures can also be applied via Open PGP or
S/MIME, and this might play into the whole email transport thing that we've
talked about but not yet crafted an I-D for.  Maybe there's two or three
documents to be written around email, including a core spec and one each
describing PGP and S/MIME security wrappers.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Apr 2002 12:06:17 -0400

Andy,

I don't think canonicalization (c14n) is really an issue since it's a just a
process that describes how to produce a consistent representation of a
well-formed instance.  Looking at the spec [1] right now I don't see any
real issues.

On the other hand, you're probably right about trying to provide integrity,
authentication, and non-repudiation services at some other layer.  The XML
DSIG specs allow multiple transforms (such as c14n and perhaps compression)
to be applied prior to signing, but XML signatures add a lot of "wrapper"
that add to bandwidth and processing horsepower requirements.

Just for yuks I worked up an example [2] of a host <create> command
contained with an XML signature wrapper.  Don't try to validate this
signature since all I did was steal data to make the XML parser happy, but
it's illustrative of the overhead required.

-Scott-

[1]
http://www.w3.org/TR/xml-c14n

[2]
(long lines are going to get wrapped; sorry)

<?xml version='1.0'?>
<Signature Id="EPPSig" xmlns="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
   xmldsig-core-schema.xsd">
   
  <SignedInfo>
    <CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710">
    </CanonicalizationMethod>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa">
    </SignatureMethod>
    <Reference URI="http://www.w3.org/TR/REC-xml-names/">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1">
      </DigestMethod>
      <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue>
    </Reference>
  </SignedInfo>

<SignatureValue>MC0CFFrVLtRlkMc3Daon4BqqnkhCOlEaAhUAk8pH1iRNK+q1I+sisDTz2TFE
ALE=</SignatureValue>
  
  <KeyInfo>
    <KeyValue>
      <DSAKeyValue>
 
<P>2iY3w062sDB3/DIlLWOeG9+4UpmDZ0dyqRk9dLlNQ6qaXI7tOrjdIhm6n/eOw45AQtuYSp6sp
Ct9cQcNBAj22KvygvfJIIXX9sSQrugfGqifeSvY3VX5Sd1j+z0MSZ/n5jNt88uh2C11SAqX6nrXT
Y/1RwkoWRN23SYhOlaG0hU=</P>
        <Q>9B5ypLY9pMOmtxCeTDHgwdNFeGs=</Q>
 
<G>MuGAlqeB1ax+vyO2+Osubjhl7pHxLu47RIH+/M52DjESA9KMSrwzsYx8yNR2WooByrE0t6fu0
VncK7UK8olO4t7wpv2z4AFQPRVCKFwo0qgn5aKIkICGMlrRy81avb27wGcWothx3iPPMtFXtoDqK
0JItaI9R8zc1msFhM1GKMY=</G>
 
<Y>ctA8YGxrtngg/zKVvqEOefnwmViFztcnPBYPlJsvh6yKI4iDm68fnp4Mi3RrJ6bZAygFrUIQL
xLjV+OJtgJAEto0xAs+Mehuq1DkSFEpP3oDzCTOsrOiS1DwQe4oIb7zVk/9l7aPtJMHW0LVlMdwZ
NFNNJoqMcT2ZfCPrfvYvQ0=</Y>
      </DSAKeyValue>
    </KeyValue>
  </KeyInfo>
  
  <Object>
    <SignatureProperties>
      <SignatureProperty Target="#EPPSig">
        <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
         epp-1.0.xsd">
          <command>
            <create>
              <host:create
               xmlns:host="urn:ietf:params:xml:ns:host-1.0"
               xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
               host-1.0.xsd">
                <host:name>ns1.example.tld</host:name>
                <host:addr ip="v4">192.1.2.3</host:addr>
                <host:addr ip="v4">198.1.2.3</host:addr>
                <host:addr
                 ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
              </host:create>
            </create>
            <clTRID>ABC-12345</clTRID>
          </command>
        </epp>
      </SignatureProperty>
    </SignatureProperties>
  </Object>
</Signature>

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 11:37 AM
> To: Hollenbeck, Scott
> Cc: 'Roger Castillo Cortazar'; [email-masked]
> Subject: RE: XML Digital Signatures for EPP.
> 
> 
> It has been a bit since I looked at this stuff, so forgive if 
> I get any
> of it wrong.  But it is my understanding that XML D-Sig uses XML
> Canonicalization which is DTD based.  This may pose a problem with EPP
> since its schema language is XML Schema.
> 
> I think doing this at the application transport level is a 
> better idea. 
> You also get the advantage of being able to run compression 
> against the
> XML instance before encryption.
> 
> -andy
>