W3C home > Mailing lists > Public > xml-encryption@w3.org > October 2003

XML Encryption Reference Toolkit(NEC)

From: Takahiro SUGIYAMA <t-sugiyama@da.jp.nec.com>
Date: Wed, 01 Oct 2003 19:26:23 +0900
To: xml-encryption@w3.org
Message-Id: <20031001184100.A2C6.T-SUGIYAMA@da.jp.nec.com>

Hi All,

The following URL is a download page of NEC's reference toolkit for the
XML Encryption.

http://www.sw.nec.co.jp/soft/xml_e/main_e.html

Thanks,
Takahiro SUGIYAMA

> 
> Hi Joseph,
> 
> The following is NEC's interop result for the XML Encryption.
> Could you add our record to the matrix?
> 
> Thanks in advance,
> Takuya Mori
> 
> ----
>     Takuya Mori
>     moritaku@bx.jp.nec.com / tk-mori@isd.nec.co.jp
>     Internet Solution Platform Development Div.,
>     NEC Solutions, Tokyo Japan
> 
> 
> [Application Features]						NEC	
> Laxly valid schema generation of EncryptedData/EncryptedKey:	Y	
>   * Normalized Form C generations.:				N (*1)
> Type, MimeType, and Encoding:					Y	
> CipherReference URI derefencing:				Y	
>   * Transforms:							Y	
> ds:KeyInfo:							Y	
>   * enc:DHKeyValue:						Y	
>   * ds:KeyName:							Y	
>   * ds:RetrievalMethod:						Y	
> ReferenceList:							Y	
> EncryptionProperties:						Y	
> Satisfactory Performance:					Y	
> [Processing Features]
> Required Type support Element and Content.:			Y	
> Encryption:							Y	
>   * Serialization of XML Element and Content.:			Y	
>     1.NFC conversion from non-Unicode encodings(dchanged
>       such that the application MUST provide data in NFC form)	N (*1)
>   * Encryptor returns EncryptedData structure.:			Y	
>   * Encryptor replaces EncryptedData source document(when Type
>     is Element or Content).:					Y	
> Decryption:							Y	
>   * The decryptor returns the data and its Type to
>     the application(be it an octet sequence or key value).:	Y	
>   * If data is Element or Content the decryptor return
>     the UTF-8 encoding XML character data.:			Y	
>   * If data is Element or Content the decryptor replaces
>     the EncryptedData in the source document with the decrypted
>     data.:							Y	
> [Algorithm]
> TRIPLEDES:							Y1 Y2	
> AES-128:							Y1 Y2	
> AES-256:							Y1 Y2	
> AES-192:							Y1 Y2	
> RSA-v1.5(192 bit keys for AES or DES):				Y1 Y2
> RSA-OAEP(128 and 256 bit keys for AES):				Y1 Y2
> Diffie-Helman Key Agreement:					Y1 Y2
> TRIPLEDES Key Wrap:						Y1 Y2
> AES-128 Key Wrap (128 bit keys):				Y1 Y2
> AES-256 Key Wrap (256 bit keys):				Y1 Y2
> AES-192 KeyWrap:						Y1 Y2
> SHA1:								Y1 Y2
> SHA256:								Y1 Y2
> SHA512:								Y1 Y2
> RIPEMD-160:							Y1
> XML Digital Signature:						Y
> Decryption Transform for XML Signature:				Y3
>   * XML Mode:							Y3
>   * Binary Mode:						Y3
>   * Profiled X Pointer support in Except URI:			Y3
>   * Profiled X Pointer support in Except URI into replacement
>     node-sets(I.e. super-decryption).:				Y3 (*2)
>   * Full X Pointer support in Except URIs.:			N
> Canonical XML (with and without coments):			Y
> Exclusive Canonicalization (with and without comments):		Y
> base64 Encoding:						Y1 Y2
> 
> Some Comments:
>   *1:  Our not supporing these features is intentional.
>   *2:  If the meaning of "Profiled X Pointer support" is "support
>        for the same-document XPointers '#xpointer(/),
>        #xpointer(id('ID'))' as described in 4.3.3.2 The Reference
>        Processing Model", we think we support the feature.
> 
> 
> ==== End of our interop report ====
> 

Takahiro SUGIYAMA
NEC Corporation
Internet Sokution Platform Deveopment Division
Received on Wednesday, 1 October 2003 06:34:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:04 UTC