Copyright
(削除) ゥ
2002
(削除ここまで)
(追記) ツゥ
2013
(追記ここまで)
W3C
(削除) ョ
(削除ここまで)
(追記) ツョ
(追記ここまで)
(
MIT
,
(削除) INRIA
(削除ここまで)
(追記) ERCIM
(追記ここまで)
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
(削除) ,
document
use
(削除ここまで)
and
(削除) software
licensing
(削除ここまで)
(追記) document
use
(追記ここまで)
rules
apply.
This
document
specifies
a
process
for
encrypting
data
and
representing
the
result
in
XML.
The
data
may
be
(削除) arbitrary
(削除ここまで)
(追記) in
a
variety
of
formats,
including
octet
streams
and
other
unstructured
data,
or
structured
(追記ここまで)
data
(削除) (including
an
(削除ここまで)
(追記) formats
such
as
(追記ここまで)
XML
(削除) document),
(削除ここまで)
(追記) documents,
(追記ここまで)
an
XML
element,
or
XML
element
content.
The
result
of
encrypting
data
is
an
XML
Encryption
element
(削除) which
(削除ここまで)
(追記) that
(追記ここまで)
contains
or
references
the
cipher
data.
This
(追記) section
describes
the
status
of
this
(追記ここまで)
document
(削除) is
(削除ここまで)
(追記) at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
(追記ここまで)(追記)
W3C
(追記ここまで)(追記)
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
(追記ここまで)(追記)
W3C
(追記ここまで)(追記)
technical
reports
index
(追記ここまで) (追記)
at
http://www.w3.org/TR/.
(追記ここまで)
(追記)
At
(追記ここまで)
the
(追記) time
of
this
publication,
the
most
recent
(追記ここまで)
W3C
(追記) Recommendation
of
XML
Encryption
1
is
the
(追記ここまで)(追記)
10
December
2002
(追記ここまで)
XML
Encryption
Recommendation
(削除) (REC)
(削除ここまで)
.
(削除) This
document
has
been
reviewed
by
W3C
Members
and
other
interested
parties
and
has
been
endorsed
by
the
Director
as
a
W3C
Recommendation.
It
(削除ここまで)
(追記) The
most
recent
publication
of
this
draft
(追記ここまで)
is
(追記) the
(追記ここまで)(追記)
Last
Call
draft
of
18
October
2012
(追記ここまで),
a
(削除) stable
document
and
may
be
used
as
reference
material
or
cited
as
a
normative
reference
(削除ここまで)
(追記) return
to
Last
Call
(追記ここまで)
from
(削除) another
document.
W3C's
role
(削除ここまで)
(追記) Candidate
Recommendation
to
allow
review
and
comment
on
specific
changes
noted
(追記ここまで)
in
(削除) making
(削除ここまで)
(追記) that
draft.
As
noted
in
that
draft,
(追記ここまで)
the
(追記) Working
Group
planned
to
progress
to
Proposed
(追記ここまで)
Recommendation
(削除) is
(削除ここまで)
(追記) upon
completion
of
the
Last
Call.
(追記ここまで)
(追記)
Last
Call
was
completed
without
formal
comment,
however
the
group
received
subsequent
notice
of
a
potential
security
threat
(追記ここまで)
to
(削除) draw
attention
(削除ここまで)
(追記) implementations,
so
the
group
agreed
to
add
an
additional
security
consideration
(追記ここまで)
to
the
(削除) specification
and
(削除ここまで)
(追記) informative
security
considerations
section.
Thus
changes
(追記ここまで)
to
(削除) promote
its
widespread
deployment.
This
enhances
(削除ここまで)
the
(削除) functionality
and
interoperability
of
(削除ここまで)
(追記) document
since
(追記ここまで)
the
(削除) Web.
(削除ここまで)
(追記) last
publication
include
the
following:
(追記ここまで)
(削除) This
specification
was
produced
by
(削除ここまで)
(追記) Please
review
(追記ここまで)
the
(削除) W3C
(削除ここまで)
(追記) differences
between
the
previous
Last
Call
Working
Draft
and
this
Proposed
Recommendation
Working
Draft
(追記ここまで),(追記)
and
the
(追記ここまで)(追記)
differences
between
the
previous
(追記ここまで)
XML
Encryption
(追記) Recommendation
and
this
Proposed
Recommendation
(追記ここまで)
Working
(削除) Group
(削除ここまで)
(追記) Draft
(追記ここまで)
(削除) (
Activity
(削除ここまで)
(追記) ;
a
detailed
explanation
of
changes
is
also
available
[
(追記ここまで)(追記)
XMLENC-CORE1-CHGS
(追記ここまで)
(削除) )
which
believes
(削除ここまで)
(追記) ].
(追記ここまで)
(追記)
The
previous
Last
Call
working
draft
followed
Candidate
Recommendation
since
an
at-risk
feature
was
moved
to
an
informative
appendix
due
to
lack
of
implementation,
(追記ここまで)
the
(削除) specification
is
sufficient
(削除ここまで)
(追記) requirement
(追記ここまで)
for
(削除) the
creation
of
independent
interoperable
implementations
as
demonstrated
(削除ここまで)
(追記) an
algorithm
implementation
was
changed
due
to
security
concerns,
an
additional
algorithm
identifier
was
added
and
additional
clarifications
made
based
on
review
during
implementation.
This
Last
Call
resulted
(追記ここまで)
in
(追記) an
adding
a
security
consideration
to
address
new
research
related
to
security
threats
but
with
no
objection
to
(追記ここまで)
the
(削除) Interoperability
Report.
(削除ここまで)
(追記) changes
resulting
in
Last
Call.
(追記ここまで)
(削除) Patent
disclosures
relevant
(削除ここまで)
(追記) Conformance-affecting
changes
against
the
previous
recommendation
mainly
affect
the
set
of
mandatory
(追記ここまで)
to
(削除) this
specification
may
be
found
on
(削除ここまで)
(追記) implement
cryptographic
algorithms,
by
adding
Elliptic
Curve
Diffie-Hellman
Key
Agreement,
making
AES-128
GCM
mandatory,
changing
RSA
v1.5
to
optional,
adding
optional
AES192-GCM
and
adding
optional
RSA-OEAP
algorithm
variants.
(追記ここまで)
(追記)
This
document
was
published
by
(追記ここまで)
the
(追記) XML
Security
(追記ここまで)
Working
(削除) Group's
patent
disclosure
page
(削除ここまで)
(追記) Group
(追記ここまで)
(削除) in
conformance
with
(削除ここまで)
(追記) as
a
Proposed
Recommendation.
This
document
is
intended
to
become
a
(追記ここまで)
W3C
(削除) policy.
Please
report
errors
in
this
(削除ここまで)
(追記) Recommendation.
The
(追記ここまで)(追記)
W3C
(追記ここまで)(追記)
Membership
and
other
interested
parties
are
invited
to
review
the
(追記ここまで)
document
(追記) and
send
comments
(追記ここまで)
to
(削除) xml-encryption@w3.org
(削除ここまで)
(追記) public-xmlsec@w3.org
(追記ここまで)
(
(削除) public
archive
(削除ここまで)
(追記) subscribe
(追記ここまで),(追記)
archives
(追記ここまで)
(削除) ).
(削除ここまで)
(追記) )
through
25
February
2013.
Advisory
Committee
Representatives
should
consult
their
(追記ここまで)(追記)
WBS
questionnaires
(追記ここまで).(追記)
Note
that
substantive
technical
comments
were
expected
during
the
Last
Call
review
period
that
ended
13
March
2012.
(追記ここまで)
(削除) The
list
of
known
errors
in
this
specification
is
available
at
http://www.w3.org/Encryption/2002/12-xmlenc-errata
(削除ここまで)
(追記) Please
see
the
Working
Group's
(追記ここまで)(追記)
implementation
report
(追記ここまで)
.
(削除) The
English
version
of
this
specification
is
(削除ここまで)
(追記) Publication
as
a
Proposed
Recommendation
does
not
imply
endorsement
by
(追記ここまで)
the
(削除) only
normative
version.
Information
about
translations
of
this
(削除ここまで)
(追記) W3C
(追記ここまで)(追記)
Membership.
This
is
a
draft
(追記ここまで)
document
(削除) (if
any)
(削除ここまで)
(追記) and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
(追記ここまで)
is
(削除) available
http://www.w3.org/Encryption/2002/12-xmlenc-translations
.
(削除ここまで)
(追記) inappropriate
to
cite
this
document
as
other
than
work
in
progress.
(追記ここまで)
(削除) A
(削除ここまで)
(追記) This
document
was
produced
by
a
group
operating
under
the
(追記ここまで)(追記)
5
February
2004
(追記ここまで)(追記)
W3C
(追記ここまで)(追記)
Patent
Policy
(追記ここまで).(追記)
W3C
(追記ここまで)(追記)
maintains
a
(追記ここまで)(追記)
public
(追記ここまで)
list
of
(削除) current
(削除ここまで)
(追記) any
patent
disclosures
(追記ここまで) (追記)
made
in
connection
with
the
deliverables
of
the
group;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
(追記ここまで)(追記)
Essential
Claim(s)
(追記ここまで) (追記)
must
disclose
the
information
in
accordance
with
(追記ここまで)(追記)
section
6
of
the
(追記ここまで)
W3C
(削除) Recommendations
and
other
technical
documents
can
be
found
at
http://www.w3.org/TR/
(削除ここまで)
(追記) Patent
Policy
(追記ここまで)
.
(削除) Table
(削除ここまで)
(追記) Additional
information
related
to
the
IPR
status
(追記ここまで)
of
(削除) Contents
(削除ここまで)
(追記) XML
Encryption
1.1
(追記ここまで)
(追記) is
also
available.
(追記ここまで)
EncryptedData
and
EncryptedKey
Usage
EncryptedType
Element
EncryptionMethod
Element
CipherData
Element
EncryptedData
Element
ds:KeyInfo
Element
ReferenceList
Element
EncryptionProperties
Element
(追記)
Type
(追記ここまで)(追記)
parameter
values
(追記ここまで) (追記)
<EncryptedData>
(追記ここまで)(追記)
part)
(追記ここまで)
This
document
specifies
a
process
for
encrypting
data
and
representing
the
result
in
XML.
The
data
may
be
arbitrary
data
(including
an
XML
document),
an
XML
element,
or
XML
element
content.
The
result
of
encrypting
data
is
an
XML
Encryption
EncryptedData
element
(削除) which
(削除ここまで)
(追記) that
(追記ここまで)
contains
(via
one
of
its
children's
content)
or
identifies
(via
a
URI
reference)
the
cipher
data.
When
encrypting
an
XML
element
or
element
content
the
EncryptedData
element
replaces
the
element
or
content
(respectively)
in
the
encrypted
version
of
the
XML
document.
When
encrypting
arbitrary
data
(including
entire
XML
documents),
the
EncryptedData
element
may
become
the
root
of
a
new
XML
document
or
become
a
child
element
in
an
application-chosen
XML
document.
This
specification
uses
XML
schemas
[
(削除) XML-schema
(削除ここまで)
(追記) XMLSCHEMA-1
(追記ここまで)
(追記) ],
[
(追記ここまで)(追記)
XMLSCHEMA-2
(追記ここまで)
]
to
describe
the
content
model.
(追記) The
full
normative
grammar
is
defined
by
the
XSD
schema
and
the
normative
text
in
this
specification.
The
standalone
XSD
schema
file
is
authoritative
in
case
there
is
any
disagreement
between
it
and
the
XSD
schema
portions.
(追記ここまで)
The
key
words
(削除) "MUST",
"MUST
NOT",
"REQUIRED",
"SHALL",
"SHALL
NOT",
"SHOULD",
"SHOULD
NOT",
"RECOMMENDED",
"MAY",
(削除ここまで)
(追記) "
(追記ここまで)(追記)
must
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
must
not
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
required
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
shall
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
shall
not
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
should
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
should
not
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
recommended
(追記ここまで)(追記)
",
"
(追記ここまで)(追記)
may
(追記ここまで)(追記)
",
(追記ここまで)
and
(削除) "OPTIONAL"
(削除ここまで)
(追記) "
(追記ここまで)(追記)
optional
(追記ここまで)(追記)
"
(追記ここまで)
in
this
specification
are
to
be
interpreted
as
described
in
(削除) RFC2119
(削除ここまで)
[
(削除) KEYWORDS
(削除ここまで)
(追記) RFC2119
(追記ここまで)
]:
(削除) "they MUST (削除ここまで)(追記) "They (追記ここまで)(追記) must (追記ここまで) only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
Consequently,
we
use
these
capitalized
keywords
to
unambiguously
specify
requirements
over
protocol
and
application
features
and
behavior
that
affect
the
interoperability
and
security
of
implementations.
These
key
words
are
not
used
(capitalized)
to
describe
XML
grammar;
schema
definitions
unambiguously
describe
such
requirements
and
we
wish
to
reserve
the
prominence
of
these
terms
for
the
natural
language
descriptions
of
protocols
and
features.
For
instance,
an
XML
attribute
might
be
described
as
being
(削除) "optional."
(削除ここまで)
(追記) "optional".
(追記ここまで)
Compliance
with
the
XML-namespace
specification
[
(削除) XML-NS
(削除ここまで)
(追記) XML-NAMES
(追記ここまで)
]
is
described
as
(削除) "REQUIRED."
(削除ここまで)
(追記) "
(追記ここまで)(追記)
required
(追記ここまで)(追記)
".
(追記ここまで)
The
design
philosophy
and
requirements
of
this
specification
(including
the
limitations
related
to
instance
validity)
are
addressed
in
the
(追記) original
(追記ここまで)
XML
Encryption
Requirements
[
(削除) EncReq
(削除ここまで)
(追記) XML-ENCRYPTION-REQ
(追記ここまで) (追記)
]
and
the
XML
Security
1.1
Requirements
document
[
(追記ここまで)(追記)
XMLSEC11-REQS
(追記ここまで)
].
(削除) No
provision
is
made
for
an
explicit
version
number
in
this
syntax.
If
a
future
version
is
needed,
it
will
(削除ここまで)
(追記) This
specification
makes
(追記ここまで)
use
(削除) a
different
namespace.
The
experimental
(削除ここまで)
(追記) of
(追記ここまで)
XML
(削除) namespace
(削除ここまで)
(追記) namespaces,
and
uses
Uniform
Resource
Identifiers
(追記ここまで)
[
(削除) XML-NS
(削除ここまで)
(追記) URI
(追記ここまで)
]
(削除) URI
that
MUST
be
used
by
implementations
(削除ここまで)
(追記) to
identify
resources,
algorithms,
and
semantics.
(追記ここまで)
(追記)
Implementations
(追記ここまで)
of
this
(削除) (dated)
(削除ここまで)
specification
(削除) is:
(削除ここまで)
(追記) must
(追記ここまで)(追記)
use
the
following
XML
namespace
URIs:
(追記ここまで)
| (追記) URI (追記ここまで) |
namespace
|
XML
|
|---|---|---|
|
(追記) default
(追記ここまで)
namespace
|
(追記) <!ENTITY
xenc
"http://www.w3.org/2001/04/xmlenc#">
(追記ここまで) |
(追記)
http://www.w3.org/2009/xmlenc11#
(追記ここまで) | (追記)
xenc11:
(追記ここまで) | (追記)
<!ENTITY
xenc11
"http://www.w3.org/2009/xmlenc11#">
(追記ここまで) |
(追記)
The
(追記ここまで)(追記)
http://www.w3.org/2001/04/xmlenc#
(追記ここまで)(追記)
(
(追記ここまで)(追記)
xenc:
(追記ここまで)(追記)
)
namespace
was
introduced
(追記ここまで)
in
(追記) version
1.0
of
(追記ここまで)
this
specification.
(削除) For
example
"
(削除ここまで)
(追記) The
present
version
does
not
coin
any
new
elements
or
algorithm
identifiers
in
that
namespace;
instead,
the
(追記ここまで)
(削除) &xenc;Element"
(削除ここまで)
(追記) http://www.w3.org/2009/xmlenc11#
(追記ここまで)
(削除) corresponds
to
"http://www.w3.org/2001/04/xmlenc#Element".
(削除ここまで)
(追記) (
(追記ここまで)(追記)
xenc11:
(追記ここまで)(追記)
)
namespace
is
used.
(追記ここまで)
(削除) This
(削除ここまで)
(追記) No
provision
is
made
for
an
explicit
version
number
in
this
syntax.
If
a
future
version
of
this
(追記ここまで)
specification
(削除) makes
use
(削除ここまで)
(追記) requires
explicit
versioning
(追記ここまで)
of
the
(削除) XML
Signature
[
XML-DSIG
]
(削除ここまで)
(追記) document
format,
a
different
(追記ここまで)
namespace
(削除) and
schema
definitions
(削除ここまで)
(追記) will
be
used.
(追記ここまで)
(削除) URIs
[
URI
]
MUST
abide
by
the
[
XML-Schema
]
anyURI
type
definition
(削除ここまで)
(追記) Additionally,
this
specification
uses
elements
(追記ここまで)
and
(追記) algorithm
identifiers
from
(追記ここまで)
the
(追記) XML
Signature
name
spaces
(追記ここまで)
[
(削除) XML-DSIG
,
4.3.3.1
The
URI
Attribute
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
(削除) ]
specification
(i.e.,
permitted
characters,
character
escaping,
scheme
support,
etc.).
(削除ここまで)
(追記) ]:
(追記ここまで)
| (追記) URI (追記ここまで) | (追記) namespace prefix (追記ここまで) | (追記) XML internal entity (追記ここまで) |
|---|---|---|
(追記)
http://www.w3.org/2000/09/xmldsig#
(追記ここまで) | (追記)
default
namespace
(追記ここまで),(追記)
ds:
(追記ここまで),(追記)
dsig:
(追記ここまで) | (追記)
<!ENTITY
dsig
"http://www.w3.org/2000/09/xmldsig#">
(追記ここまで) |
(追記)
http://www.w3.org/2009/xmldsig11#
(追記ここまで) | (追記)
dsig11:
(追記ここまで) | (追記)
<!ENTITY
dsig11
"http://www.w3.org/2009/xmldsig11#">
(追記ここまで) |
The
contributions
of
the
following
Working
Group
members
to
this
specification
are
gratefully
acknowledged
in
accordance
with
the
contributor
policies
and
the
active
WG
roster
(削除) .
(削除ここまで)
:
Joseph
(削除) Ashwood
(削除ここまで)
(追記) Ashwood,
(追記ここまで)
Simon
Blake-Wilson,
(削除) Certicom
(削除ここまで)
(追記) Certicom,
(追記ここまで)
Frank
D.
Cavallito,
BEA
(削除) Systems
(削除ここまで)
(追記) Systems,
(追記ここまで)
Eric
Cohen,
(削除) PricewaterhouseCoopers
(削除ここまで)
(追記) PricewaterhouseCoopers,
(追記ここまで)
Blair
Dillaway,
Microsoft
(削除) (Author)
(削除ここまで)
(追記) (Author),
(追記ここまで)
Blake
Dournaee,
RSA
(削除) Security
(削除ここまで)
(追記) Security,
(追記ここまで)
Donald
Eastlake,
Motorola
(削除) (Editor)
(削除ここまで)
(追記) (Editor),
(追記ここまで)
Barb
Fox,
(削除) Microsoft
(削除ここまで)
(追記) Microsoft,
(追記ここまで)
Christian
Geuer-Pollmann,
University
of
(削除) Siegen
(削除ここまで)
(追記) Siegen,
(追記ここまで)
Tom
Gindin,
(削除) IBM
(削除ここまで)
(追記) IBM,
(追記ここまで)
Jiandong
Guo,
(削除) Phaos
(削除ここまで)
(追記) Phaos,
(追記ここまで)
Phillip
Hallam-Baker,
(削除) Verisign
(削除ここまで)
(追記) Verisign,
(追記ここまで)
Amir
Herzberg,
(削除) NewGenPay
(削除ここまで)
(追記) NewGenPay,
(追記ここまで)
Merlin
Hughes,
(削除) Baltimore
(削除ここまで)
(追記) Baltimore,
(追記ここまで)
Frederick
(削除) Hirsch
(削除ここまで)
(追記) Hirsch,
(追記ここまで)
Maryann
Hondo,
(削除) IBM
(削除ここまで)
(追記) IBM,
(追記ここまで)
Takeshi
Imamura,
IBM
(削除) (Author)
(削除ここまで)
(追記) (Author),
(追記ここまで)
Mike
Just,
Entrust,
(削除) Inc.
(削除ここまで)
(追記) Inc.,
(追記ここまで)
Brian
LaMacchia,
(削除) Microsoft
(削除ここまで)
(追記) Microsoft,
(追記ここまで)
Hiroshi
Maruyama,
(削除) IBM
(削除ここまで)
(追記) IBM,
(追記ここまで)
John
Messing,
(削除) Law-on-Line
(削除ここまで)
(追記) Law-on-Line,
(追記ここまで)
Shivaram
Mysore,
Sun
(削除) Microsystems
(削除ここまで)
(追記) Microsystems,
(追記ここまで)
Thane
Plambeck,
(削除) Verisign
(削除ここまで)
(追記) Verisign,
(追記ここまで)
Joseph
Reagle,
W3C
(Chair,
(削除) Editor)
(削除ここまで)
(追記) Editor),
(追記ここまで)
Aleksey
(削除) Sanin
(削除ここまで)
(追記) Sanin,
(追記ここまで)
Jim
Schaad,
Soaring
Hawk
(削除) Consulting
(削除ここまで)
(追記) Consulting,
(追記ここまで)
Ed
Simon,
XMLsec
(削除) (Author)
(削除ここまで)
(追記) (Author),
(追記ここまで)
Daniel
Toth,
(削除) Ford
(削除ここまで)
(追記) Ford,
(追記ここまで)
Yongge
Wang,
(削除) Certicom
(削除ここまで)
(追記) Certicom,
(追記ここまで)
Steve
Wiley,
(削除) myProof
(削除ここまで)
(追記) myProof.
(追記ここまで)
Additionally,
we
thank
the
following
for
their
comments
during
and
subsequent
to
Last
Call:
Martin
(削除) D?rst,
(削除ここまで)
(追記) Dテシrst,
(追記ここまで)
W3C
,
Dan
Lanz,
(削除) Zolera
(削除ここまで)
(追記) Zolera,
(追記ここまで)
Susan
Lesch,
W3C
,
David
Orchard,
BEA
(削除) Systems
(削除ここまで)
(追記) Systems,
(追記ここまで)
Ronald
Rivest,
MIT
.
(追記) Contributions for version 1.1 were received from the members of the XML Security Working Group: Scott Cantor, Juan Carlos Cruellas, Pratik Datta, Gerald Edgar, Ken Graf, Phillip Hallam-Baker, Brad Hill, Frederick Hirsch, Brian LaMacchia, Konrad Lanz, Hal Lockhart, Cynthia Martin, Rob Miller, Sean Mullan, Shivaram Mysore, Magnus Nystrテカm, Bruce Rich, Thomas Roessler, Ed Simon, Chris Solc, John Wray, Kelvin Yiu. (追記ここまで)
(追記) The working group also acknowledges the contribution of Juraj Somorovsky raising the issue of the CBC chosen ciphertext attack and contributions to revising the security considerations of XML Encryption 1.1. (追記ここまで)
(追記) This section is non-normative. (追記ここまで)
This
section
provides
an
overview
and
examples
of
XML
Encryption
syntax.
The
formal
syntax
is
found
in
(追記) section
3.
(追記ここまで)
Encryption
Syntax
(削除) (section
3);
(削除ここまで)
(追記) ;
(追記ここまで)
the
specific
processing
is
given
in
Processing
Rules
(section
4).
Expressed
in
shorthand
form,
the
EncryptedData
element
has
the
following
structure
(where
"?"
denotes
zero
or
one
occurrence;
"+"
denotes
one
or
more
occurrences;
"*"
denotes
zero
or
more
occurrences;
(追記) "|"
denotes
a
choice;
(追記ここまで)
and
the
empty
element
tag
means
the
element
must
be
empty
):
The
CipherData
element
envelopes
or
references
the
raw
encrypted
data.
(追記) A
(追記ここまで)(追記)
CipherData
(追記ここまで)(追記)
element
must
have
either
a
(追記ここまで)(追記)
CipherValue
(追記ここまで)(追記)
or
(追記ここまで)(追記)
CipherReference
(追記ここまで)(追記)
child
element.
(追記ここまで)
If
enveloping,
the
raw
encrypted
data
is
the
CipherValue
element's
content;
if
referencing,
the
CipherReference
element's
URI
attribute
points
to
the
location
of
the
raw
encrypted
data
(追記) This section is non-normative. (追記ここまで)
(追記) Note: Examples in this document do not consider plaintext guessing attacks or other risks, and are only for illustrative purposes. (追記ここまで)
Consider the following fictitious payment information, which includes identification information and information appropriate to a payment method (e.g., credit card, money transfer, or electronic check):
This markup represents that John Smith is using his credit card with a limit of 5,000ドルUSD.
(追記) This section is non-normative. (追記ここまで)
Smith's
credit
card
number
is
sensitive
information!
If
the
application
wishes
to
keep
that
information
confidential,
it
can
encrypt
the
CreditCard
element:
By
encrypting
the
entire
CreditCard
element
from
its
start
to
end
tags,
the
identity
of
the
element
itself
is
hidden.
(An
eavesdropper
doesn't
know
whether
he
used
a
credit
card
or
money
transfer.)
The
CipherData
element
contains
the
encrypted
serialization
of
the
CreditCard
element.
As
an
alternative
scenario,
it
may
be
useful
for
intermediate
agents
to
know
that
John
used
a
credit
card
with
a
particular
limit,
but
not
the
card's
number,
issuer,
and
expiration
date.
In
this
case,
the
content
(character
data
or
children
elements)
of
the
CreditCard
element
(削除) is
(削除ここまで)
(追記) can
be
(追記ここまで)
encrypted:
(削除) Or,
(削除ここまで)
(追記) Alternatively,
(追記ここまで)
consider
the
scenario
in
which
all
the
information
except
the
actual
credit
card
number
can
be
in
the
clear,
including
the
fact
that
the
Number
element
exists:
Both
CreditCard
and
Number
are
in
the
clear,
but
the
character
data
content
of
Number
is
encrypted.
If the application scenario requires all of the information to be encrypted, the whole document is encrypted as an octet sequence. This applies to arbitrary data including XML documents.
(追記) Where appropriate, such as in the case of encrypting an entire EXI stream, the Type attribute (追記ここまで)(追記) should (追記ここまで)(追記) be provided and indicate the use of EXI. The optional MimeType (追記ここまで)(追記) may (追記ここまで)(追記) be used to record the actual (non-EXI-encoded) type, but is not necessary and may be omitted, as in the following EXI encryption example: (追記ここまで)
An
XML
document
may
contain
zero
or
more
EncryptedData
elements.
EncryptedData
cannot
be
the
parent
or
child
of
another
EncryptedData
element.
However,
the
actual
data
encrypted
can
be
anything,
including
EncryptedData
and
EncryptedKey
elements
(i.e.,
super-encryption).
During
super-encryption
of
an
EncryptedData
or
EncryptedKey
element,
one
must
encrypt
the
entire
element.
Encrypting
only
the
content
of
these
elements,
or
encrypting
selected
child
elements
is
an
invalid
instance
under
the
provided
schema.
For example, consider the following:
A
valid
super-encryption
of
"
//xenc:EncryptedData[@Id='ED1']
"
would
be:
where
the
CipherValue
content
of
'
newEncryptedData
'
is
the
base64
encoding
of
the
encrypted
octet
sequence
resulting
from
encrypting
the
EncryptedData
element
with
Id='ED1'
.
EncryptedData
and
EncryptedKey
Usage
EncryptedData
with
Symmetric
Key
KeyName
)
[s1]
The
type
of
data
encrypted
may
be
represented
as
an
attribute
value
to
aid
in
decryption
and
subsequent
processing.
In
this
case,
the
data
encrypted
was
an
'element'.
Other
alternatives
include
'content'
of
an
element,
or
an
external
octet
sequence
which
can
also
be
identified
via
the
MimeType
and
Encoding
attributes.
[s2]
This
(3DES
CBC)
is
a
symmetric
key
cipher.
[s4]
The
symmetric
key
has
an
associated
name
"John
Smith".
[s6]
CipherData
contains
a
CipherValue
,
which
is
a
base64
encoded
octet
sequence.
Alternately,
it
could
contain
a
CipherReference
,
which
is
a
URI
reference
along
with
transforms
necessary
to
obtain
the
encrypted
data
as
an
octet
sequence
EncryptedKey
(
ReferenceList
,
ds:RetrievalMethod
,
CarriedKeyName
)
The
following
EncryptedData
structure
is
very
similar
to
the
one
above,
except
this
time
the
key
is
referenced
using
a
ds:RetrievalMethod
:
[t02]
This
(AES-128-CBC)
is
a
symmetric
key
cipher.
[t04]
ds:RetrievalMethod
is
used
to
indicate
the
location
of
a
key
with
type
.
The
(AES)
key
is
located
at
'#EK'.
(削除) &xenc;EncryptedKey
(削除ここまで)
(追記) xenc:EncryptedKey
(追記ここまで)
[t05]
ds:KeyName
provides
an
alternative
method
of
identifying
the
key
needed
to
decrypt
the
CipherData
.
Either
or
both
the
ds:KeyName
and
ds:KeyRetrievalMethod
could
be
used
to
identify
the
same
key.
Within
the
same
XML
document,
there
existed
an
EncryptedKey
structure
that
was
referenced
within
[t04]
:
[t09]
The
EncryptedKey
element
is
similar
to
the
EncryptedData
element
except
that
the
data
encrypted
is
always
a
key
value.
[t10]
The
EncryptionMethod
is
the
RSA
public
key
algorithm.
[t12]
ds:KeyName
of
"John
Smith"
is
a
property
of
the
key
necessary
for
decrypting
(using
RSA)
the
CipherData
.
[t14]
The
CipherData
's
CipherValue
is
an
octet
sequence
that
is
processed
(serialized,
encrypted,
and
encoded)
by
a
referring
encrypted
object's
EncryptionMethod
.
(Note,
an
EncryptedKey's
EncryptionMethod
is
the
algorithm
used
to
encrypt
these
octets
and
does
not
speak
about
what
type
of
octets
they
are.)
[t15-17]
A
ReferenceList
identifies
the
encrypted
objects
(
DataReference
and
KeyReference
)
encrypted
with
this
key.
The
ReferenceList
contains
a
list
of
references
to
data
encrypted
by
the
symmetric
key
carried
within
this
structure.
[t18]
The
CarriedKeyName
element
is
used
to
identify
the
encrypted
key
value
which
may
be
referenced
by
the
KeyName
element
in
ds:KeyInfo
.
(Since
ID
attribute
values
must
be
unique
to
a
document,
CarriedKeyName
can
indicate
that
several
EncryptedKey
structures
contain
the
same
key
value
encrypted
for
different
recipients.)
This
section
provides
a
detailed
description
of
the
syntax
and
features
for
XML
Encryption.
Features
described
in
this
section
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
be
implemented
unless
otherwise
noted.
The
syntax
is
defined
via
[
(削除) XML-Schema
(削除ここまで)
(追記) XMLSCHEMA-1
(追記ここまで)
(追記) ],
[
(追記ここまで)(追記)
XMLSCHEMA-2
(追記ここまで)
]
with
the
following
XML
preamble,
declaration,
internal
entity,
and
import:
(追記)
Additional
markup
defined
in
this
specification
uses
the
(追記ここまで)(追記)
xenc11:
(追記ここまで)(追記)
namespace.
The
syntax
is
defined
in
an
XML
schema
with
the
following
preamble:
(追記ここまで)
EncryptedType
Element
EncryptedType
is
the
abstract
type
from
which
EncryptedData
and
EncryptedKey
are
derived.
While
these
two
latter
element
types
are
very
similar
with
respect
to
their
content
models,
a
syntactical
distinction
is
useful
to
processing.
(削除) Implementation
MUST
(削除ここまで)
(追記) Implementations
(追記ここまで)(追記)
must
(追記ここまで)
generate
laxly
schema
valid
[
(削除) XML-schema
(削除ここまで)
(追記) XMLSCHEMA-1
(追記ここまで)
(追記) ],
[
(追記ここまで)(追記)
XMLSCHEMA-2
(追記ここまで)
]
EncryptedData
or
EncryptedKey
(追記) elements
(追記ここまで)
as
specified
by
the
subsequent
schema
declarations.
(Note
the
laxly
schema
valid
generation
means
that
the
content
permitted
by
xsd:ANY
need
not
be
valid.)
Implementations
(削除) SHOULD
(削除ここまで)
(追記) should
(追記ここまで)
create
these
XML
structures
(
EncryptedType
elements
and
their
(削除) descendents/content)
(削除ここまで)
(追記) descendants/content)
(追記ここまで)
in
Normalization
Form
C
[
NFC
(削除) ,
NFC-Corrigendum
(削除ここまで)
].
EncryptionMethod
is
an
optional
element
that
describes
the
encryption
algorithm
applied
to
the
cipher
data.
If
the
element
is
absent,
the
encryption
algorithm
must
be
known
by
the
recipient
or
the
decryption
will
fail.
ds:KeyInfo
is
an
optional
element,
defined
by
[
(削除) XML-DSIG
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
],
that
carries
information
about
the
key
used
to
encrypt
the
data.
Subsequent
sections
of
this
specification
define
new
elements
that
may
appear
as
children
of
ds:KeyInfo
.
CipherData
is
a
mandatory
element
that
contains
the
CipherValue
or
CipherReference
with
the
encrypted
data.
EncryptionProperties
can
contain
additional
information
concerning
the
generation
of
the
EncryptedType
(e.g.,
date/time
stamp).
Id
is
an
optional
attribute
providing
for
the
standard
method
of
assigning
a
string
id
to
the
element
within
the
document
context.
Type
is
an
optional
attribute
identifying
type
information
about
the
plaintext
form
of
the
encrypted
content.
While
optional,
this
specification
takes
advantage
of
it
for
(削除) mandatory
(削除ここまで)
processing
described
in
(削除) Processing
Rules:
(削除ここまで)
(追記) section
4.4
(追記ここまで)
Decryption
(削除) (section
4.2).
(削除ここまで)
.
If
the
EncryptedData
element
contains
data
of
Type
'element'
or
element
'content',
and
replaces
that
data
in
an
XML
document
context,
(追記) or
contains
data
of
(追記ここまで)(追記)
Type
(追記ここまで)(追記)
'EXI',
(追記ここまで)
it
is
strongly
recommended
the
Type
attribute
be
provided.
Without
this
information,
the
decryptor
will
be
unable
to
automatically
restore
the
XML
document
to
its
original
cleartext
form.
MimeType
is
an
optional
(advisory)
attribute
which
describes
the
media
type
of
the
data
which
has
been
encrypted.
The
value
of
this
attribute
is
a
string
with
values
defined
by
[
(削除) MIME
(削除ここまで)
(追記) RFC2045
(追記ここまで)
].
For
example,
if
the
data
that
is
encrypted
is
a
base64
encoded
PNG,
the
transfer
Encoding
may
be
specified
as
'
http://www.w3.org/2000/09/xmldsig#base64
'
and
the
MimeType
as
'image/png'.
This
attribute
is
purely
advisory;
no
validation
of
the
MimeType
information
is
required
and
it
does
not
indicate
the
encryption
application
must
do
any
additional
processing.
Note,
this
information
may
not
be
necessary
if
it
is
already
bound
to
the
identifier
in
the
Type
attribute.
For
example,
the
Element
and
Content
types
defined
in
this
specification
are
always
UTF-8
encoded
text.
(追記) In
the
case
of
Type
EXI
the
MimeType
attribute
is
not
necessary,
but
if
used
should
reflect
the
underlying
type
and
not
"EXI".
(追記ここまで)
(追記) Encoding
(追記ここまで)(追記)
is
an
optional
(advisory)
attribute
which
describes
the
transfer
encoding
of
the
data
that
has
been
encrypted.
(追記ここまで)
EncryptionMethod
Element
EncryptionMethod
is
an
optional
element
that
describes
the
encryption
algorithm
applied
to
the
cipher
data.
If
the
element
is
absent,
the
encryption
algorithm
must
be
known
(削除) by
(削除ここまで)
(追記) to
(追記ここまで)
the
recipient
or
the
decryption
will
fail.
The
permitted
child
elements
of
the
EncryptionMethod
are
determined
by
the
specific
value
of
the
Algorithm
attribute
URI,
and
the
KeySize
child
element
is
always
permitted.
For
example,
the
RSA-OAEP
algorithm
(追記) (
(追記ここまで)(追記)
section
5.5.2
RSA-OAEP
(追記ここまで)
(削除) (section
5.4.2)
(削除ここまで)
(追記) )
(追記ここまで)
uses
the
ds:DigestMethod
and
OAEPparams
(削除) elements.
(削除ここまで)
(追記) elements,
and
may
use
the
(追記ここまで)(追記)
xenc11:MGF
(追記ここまで)(追記)
element
when
needed.
(追記ここまで)
(We
rely
upon
the
ANY
schema
construct
because
it
is
not
possible
to
specify
element
content
based
on
the
value
of
an
attribute.)
The
presence
of
any
child
element
under
EncryptionMethod
(削除) which
(削除ここまで)
(追記) that
(追記ここまで)
is
not
permitted
by
the
algorithm
or
the
presence
of
a
KeySize
child
inconsistent
with
the
algorithm
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
be
treated
as
an
error.
(All
algorithm
URIs
specified
in
this
document
imply
a
key
size
but
this
is
not
true
in
general.
Most
popular
stream
cipher
algorithms
take
variable
size
keys.)
CipherData
Element
The
CipherData
is
a
mandatory
element
that
provides
the
encrypted
data.
It
must
either
contain
the
encrypted
octet
sequence
as
base64
encoded
text
(追記) as
element
content
(追記ここまで)
of
the
CipherValue
element,
or
provide
a
reference
to
an
external
location
containing
the
encrypted
octet
sequence
via
the
CipherReference
element.
CipherReference
Element
If
CipherValue
is
not
supplied
directly,
the
CipherReference
identifies
a
source
which,
when
processed,
yields
the
encrypted
octet
sequence.
The
actual
value
is
obtained
as
follows.
The
CipherReference
URI
contains
an
identifier
that
is
dereferenced.
Should
the
CipherReference
element
contain
an
(削除) OPTIONAL
(削除ここまで)
(追記) optional
(追記ここまで)
sequence
of
Transform
s,
the
data
resulting
from
dereferencing
the
URI
is
transformed
as
specified
so
as
to
yield
the
intended
cipher
value.
For
example,
if
the
value
is
base64
encoded
within
an
XML
document;
the
transforms
could
specify
an
XPath
expression
followed
by
a
base64
decoding
so
as
to
extract
the
octets.
The
syntax
of
the
URI
and
Transforms
is
(削除) similar
to
that
of
(削除ここまで)
(追記) defined
in
XML
Signature
(追記ここまで)
[
(削除) XML-DSIG
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
(削除) ].
However,
there
(削除ここまで)
(追記) ],
however
XML
Encryption
places
the
(追記ここまで)(追記)
Transforms
(追記ここまで)(追記)
element
in
the
XML
Encryption
namespace
since
it
(追記ここまで)
is
(削除) a
difference
between
signature
and
encryption
processing.
(削除ここまで)
(追記) used
in
XML
Encryption
to
obtain
an
octet
stream
for
decryption.
(追記ここまで)
In
[
(削除) XML-DSIG
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
]
both
generation
and
validation
processing
start
with
the
same
source
data
and
perform
that
transform
in
the
same
order.
In
encryption,
the
decryptor
has
only
the
cipher
data
and
the
specified
transforms
are
enumerated
for
the
decryptor,
in
the
order
necessary
to
obtain
the
octets.
Consequently,
because
it
has
different
semantics
Transforms
is
in
the
namespace.
(削除) &xenc;
(削除ここまで)
(追記) xenc:
(追記ここまで)
For
example,
if
the
relevant
cipher
value
is
captured
within
a
CipherValue
element
within
a
different
XML
document,
the
CipherReference
might
look
as
follows:
Implementations
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
support
the
CipherReference
feature
and
the
same
URI
encoding,
dereferencing,
scheme,
and
HTTP
response
codes
as
that
of
[
(削除) XML-DSIG
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
].
The
Transform
feature
and
particular
transform
algorithms
are
(削除) OPTIONAL.
(削除ここまで)
(追記) optional
(追記ここまで).
EncryptedData
Element
The
EncryptedData
element
is
the
core
element
in
the
syntax.
Not
only
does
its
CipherData
child
contain
the
encrypted
data,
but
it's
also
the
element
that
replaces
the
encrypted
element,
or
(追記) element
content,
or
(追記ここまで)
serves
as
the
new
document
root.
ds:KeyInfo
Element
There
are
three
ways
that
the
keying
material
needed
to
decrypt
CipherData
can
be
provided:
EncryptedData
or
EncryptedKey
element
specify
the
associated
keying
material
via
a
child
of
ds:KeyInfo
.
All
of
the
child
elements
of
ds:
KeyInfo
specified
in
[
ds:KeyValue
is
ds:KeyName
to
refer
to
an
EncryptedKey
CarriedKeyName
is
ds:RetrievalMethod
is
In
addition,
we
provide
two
additional
child
elements:
applications
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
support
EncryptedKey
(削除) (section
3.5.1)
(削除ここまで)
(追記) (
(追記ここまで)(追記)
section
3.5.1
The
EncryptedKey
Element
(追記ここまで) (追記)
)
(追記ここまで)
and
(削除) MAY
(削除ここまで)
(追記) may
(追記ここまで)
support
AgreementMethod
(削除) (section
5.5).
(削除ここまで)
(追記) (
(追記ここまで)(追記)
section
5.6
Key
Agreement
(追記ここまで) (追記)
).
(追記ここまで)
ds:KeyInfo
)
EncryptedKey
element
can
specify
the
EncryptedData
or
EncryptedKey
to
which
its
decrypted
key
will
apply
via
a
DataReference
or
KeyReference
(追記) (
(追記ここまで)(追記)
section
3.6
The
ReferenceList
Element
(追記ここまで)
EncryptedKey
Element
Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"
(This
can
be
used
within
a
ds:RetrievalMethod
element
to
identify
the
referent's
type.)
The
EncryptedKey
element
is
used
to
transport
encryption
keys
from
the
originator
to
a
known
recipient(s).
It
may
be
used
as
a
stand-alone
XML
document,
be
placed
within
an
application
document,
or
appear
inside
an
EncryptedData
element
as
a
child
of
a
ds:KeyInfo
element.
The
key
value
is
always
encrypted
to
the
recipient(s).
When
EncryptedKey
is
decrypted
the
resulting
octets
are
made
available
to
the
EncryptionMethod
algorithm
without
any
additional
processing.
ReferenceList
is
an
optional
element
containing
pointers
to
data
and
keys
encrypted
using
this
key.
The
reference
list
may
contain
multiple
references
to
EncryptedKey
and
EncryptedData
elements.
This
is
done
using
KeyReference
and
DataReference
elements
respectively.
These
are
defined
below.
CarriedKeyName
is
an
optional
element
for
associating
a
user
readable
name
with
the
key
value.
This
may
then
be
used
to
reference
the
key
using
the
ds:KeyName
element
within
ds:KeyInfo
.
The
same
CarriedKeyName
label,
unlike
an
ID
type,
may
occur
multiple
times
within
a
single
document.
The
value
of
the
key
(削除) is
to
(削除ここまで)
(追記) must
(追記ここまで)
be
the
same
in
all
EncryptedKey
elements
identified
with
the
same
CarriedKeyName
label
within
a
single
XML
document.
Note
that
because
whitespace
is
significant
in
the
value
of
the
ds:KeyName
element,
whitespace
is
also
significant
in
the
value
of
the
CarriedKeyName
element.
Recipient
is
an
optional
attribute
that
contains
a
hint
as
to
which
recipient
this
encrypted
key
value
is
intended
for.
Its
contents
are
application
dependent.
The
Type
attribute
(削除) inheritted
(削除ここまで)
(追記) inherited
(追記ここまで)
from
EncryptedType
can
be
used
to
further
specify
the
type
of
the
encrypted
key
if
the
EncryptionMethod
Algorithm
does
not
define
a
unambiguous
encoding/representation.
(Note,
all
the
algorithms
in
this
specification
have
an
(削除) unambigous
(削除ここまで)
(追記) unambiguous
(追記ここまで)
representation
for
their
associated
key
structures.)
(追記) DerivedKey
(追記ここまで)(追記)
Element
(追記ここまで)
(追記) Type="http://www.w3.org/2009/xmlenc11#DerivedKey"
(追記ここまで) (追記)
(This
can
be
used
within
a
(追記ここまで)
ds:RetrievalMethod
(追記) element
to
identify
the
referent's
type.)
(追記ここまで)
(追記)
The
(追記ここまで)(追記)
DerivedKey
(追記ここまで)(追記)
element
is
used
to
transport
information
about
a
derived
key
from
the
originator
to
recipient(s).
It
may
be
used
as
a
stand-alone
XML
document,
be
placed
within
an
application
document,
or
appear
inside
an
(追記ここまで)(追記)
EncryptedData
(追記ここまで)(追記)
or
(追記ここまで)(追記)
Signature
(追記ここまで)(追記)
element
as
a
child
of
a
(追記ここまで)(追記)
ds:KeyInfo
(追記ここまで)(追記)
element.
The
key
value
itself
is
never
sent
by
the
originator.
Rather,
the
originator
provides
information
to
the
recipient(s)
by
which
the
recipient(s)
can
derive
the
same
key
value.
When
the
key
has
been
derived
the
resulting
octets
are
made
available
to
the
(追記ここまで)(追記)
EncryptionMethod
(追記ここまで)(追記)
or
(追記ここまで)(追記)
SignatureMethod
(追記ここまで)(追記)
algorithm
without
any
additional
processing.
(追記ここまで)
(追記) KeyDerivationMethod
(追記ここまで)(追記)
is
an
optional
element
that
describes
the
key
derivation
algorithm
applied
to
the
master
(underlying)
key
material.
If
the
element
is
absent,
the
key
derivation
algorithm
must
be
known
by
the
recipient
or
the
recipient's
key
derivation
will
fail.
(追記ここまで)
(追記)
ReferenceList
(追記ここまで)(追記)
is
an
optional
element
containing
pointers
to
data
and
keys
encrypted
using
this
key.
The
reference
list
may
contain
multiple
references
to
(追記ここまで)(追記)
EncryptedKey
(追記ここまで)(追記)
or
(追記ここまで)(追記)
EncryptedData
(追記ここまで)(追記)
elements.
This
is
done
using
(追記ここまで)(追記)
KeyReference
(追記ここまで)(追記)
and
(追記ここまで)(追記)
DataReference
(追記ここまで)(追記)
elements
from
XML
Encryption.
(追記ここまで)
(追記)
The
optional
(追記ここまで)(追記)
DerivedKeyName
(追記ここまで)(追記)
element
is
used
to
identify
the
derived
key
value.
This
element
may
then
be
referenced
by
the
(追記ここまで)(追記)
ds:KeyName
(追記ここまで)(追記)
element
in
(追記ここまで)(追記)
ds:KeyInfo
(追記ここまで).(追記)
The
same
(追記ここまで)(追記)
DerivedKeyName
(追記ここまで)(追記)
label,
unlike
an
ID
type,
may
occur
multiple
times
within
a
single
document.
Note
that
because
whitespace
is
significant
in
the
value
of
the
(追記ここまで)(追記)
ds:KeyName
(追記ここまで)(追記)
element,
whitespace
is
also
significant
in
the
value
of
the
(追記ここまで)(追記)
DerivedKeyName
(追記ここまで)(追記)
element.
(追記ここまで)
(追記)
MasterKeyName
(追記ここまで)(追記)
is
an
optional
element
for
associating
a
user
readable
name
with
the
master
key
(or
secret)
value.
The
same
(追記ここまで)(追記)
MasterKeyName
(追記ここまで)(追記)
label,
unlike
an
ID
type,
may
occur
multiple
times
within
a
single
document.
The
value
of
the
master
key
(追記ここまで)(追記)
must
(追記ここまで)(追記)
be
the
same
in
all
(追記ここまで)(追記)
DerivedKey
(追記ここまで)(追記)
elements
identified
with
the
same
(追記ここまで)(追記)
MasterKeyName
(追記ここまで)(追記)
label
within
a
single
XML
document.
If
no
(追記ここまで)(追記)
MasterKeyName
(追記ここまで)(追記)
is
provided,
the
master
key
material
must
be
known
by
the
recipient
or
key
derivation
will
fail.
(追記ここまで)
(追記)
Recipient
(追記ここまで)(追記)
is
an
optional
attribute
that
contains
a
hint
as
to
which
recipient
this
derived
key
value
is
intended
for.
Its
contents
are
application
dependent.
(追記ここまで)
(追記)
The
optional
(追記ここまで)(追記)
Id
(追記ここまで)(追記)
attribute
provides
for
the
standard
method
of
assigning
a
string
id
to
the
element
within
the
document
context.
(追記ここまで)
(追記)
The
(追記ここまで)(追記)
Type
(追記ここまで)(追記)
attribute
can
be
used
to
further
specify
the
type
of
the
derived
key
if
the
(追記ここまで)(追記)
KeyDerivationMethod
(追記ここまで)(追記)
algorithm
does
not
define
an
unambiguous
encoding/representation.
(追記ここまで)
(追記)
ds:RetrievalMethod
(追記ここまで)
Element
The
ds:RetrievalMethod
[
with
a
(削除) XML-DSIG
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
]
Type
of
'
http://www.w3.org/2001/04/xmlenc#EncryptedKey
'
provides
a
way
to
express
a
link
to
an
EncryptedKey
element
containing
the
key
needed
to
decrypt
the
CipherData
associated
with
an
EncryptedData
or
EncryptedKey
element.
The
ds:RetrievalMethod
(追記) [
(追記ここまで)(追記)
XMLDSIG-CORE1
(追記ここまで) (追記)
]
(追記ここまで)
with
(削除) this
type
(削除ここまで)
(追記) a
(追記ここまで)(追記)
Type
(追記ここまで)(追記)
of
'
(追記ここまで)(追記)
http://www.w3.org/2001/04/xmlenc#DerivedKey
(追記ここまで)(追記)
'
provides
a
way
to
express
a
link
to
a
(追記ここまで)(追記)
DerivedKey
(追記ここまで)(追記)
element
used
to
derive
the
key
needed
to
decrypt
the
(追記ここまで)(追記)
CipherData
(追記ここまで)(追記)
associated
with
an
(追記ここまで)(追記)
EncryptedData
(追記ここまで)(追記)
or
(追記ここまで)(追記)
EncryptedKey
(追記ここまで)(追記)
element.
The
(追記ここまで)(追記)
ds:RetrievalMethod
(追記ここまで)(追記)
with
one
of
these
types
(追記ここまで)
is
always
a
child
of
the
ds:KeyInfo
element
and
may
appear
multiple
times.
If
there
is
more
than
one
instance
of
a
ds:RetrievalMethod
in
a
ds:KeyInfo
of
this
type,
then
the
EncryptedKey
objects
referred
to
must
contain
the
same
key
value,
possibly
encrypted
in
different
ways
or
for
different
recipients.
ReferenceList
Element
ReferenceList
is
an
element
that
contains
pointers
from
a
key
value
of
an
EncryptedKey
(追記) or
(追記ここまで)(追記)
DerivedKey
(追記ここまで)
to
items
encrypted
by
that
key
value
(
EncryptedData
or
EncryptedKey
elements).
DataReference
elements
are
used
to
refer
to
EncryptedData
elements
that
were
encrypted
using
the
key
defined
in
the
enclosing
EncryptedKey
(追記) or
(追記ここまで)(追記)
DerivedKey
(追記ここまで)
element.
Multiple
DataReference
elements
can
occur
if
multiple
EncryptedData
elements
exist
that
are
encrypted
by
the
same
key.
KeyReference
elements
are
used
to
refer
to
EncryptedKey
elements
that
were
encrypted
using
the
key
defined
in
the
enclosing
EncryptedKey
(追記) or
(追記ここまで)(追記)
DerivedKey
(追記ここまで)
element.
Multiple
KeyReference
elements
can
occur
if
multiple
EncryptedKey
elements
exist
that
are
encrypted
by
the
same
key.
For
both
types
of
references
one
may
optionally
specify
child
elements
to
aid
the
recipient
in
retrieving
the
EncryptedKey
and/or
EncryptedData
elements.
These
could
include
information
such
as
XPath
transforms,
decompression
transforms,
or
information
on
how
to
retrieve
the
elements
from
a
document
storage
facility.
For
example:
EncryptionProperties
Element
Type="http://www.w3.org/2001/04/xmlenc#EncryptionProperties"
(This
can
be
used
within
a
ds:Reference
element
to
identify
the
referent's
type.)
Additional
information
items
concerning
the
generation
of
the
EncryptedData
or
EncryptedKey
can
be
placed
in
an
EncryptionProperty
element
(e.g.,
date/time
stamp
or
the
serial
number
of
cryptographic
hardware
used
during
encryption).
The
Target
attribute
identifies
the
EncryptedType
structure
being
described.
anyAttribute
permits
the
inclusion
of
attributes
from
the
XML
namespace
to
be
included
(i.e.,
xml:space
,
xml:lang
,
and
xml:base
).
This section describes the operations to be performed as part of encryption and decryption processing by implementations of this specification. The conformance requirements are specified over the following roles:
(追記) Encryptor and Decryptor are invoked by the (追記ここまで)(追記) Application (追記ここまで).(追記) This specification does not include normative definitions for application behavior. However, this specification does include conformance requirements on encrypted data that may only be achievable through appropriate behavior by all three parties. It is up to specific deployment contexts how this is achieved. (追記ここまで)
(追記) The processing rules for XML Encryption are designed around an intended application model that this version of the specification does not cover normatively. (追記ここまで)
(追記)
In
the
intended
processing
model,
XML
Encryption
is
used
to
encrypt
an
octet-stream,
an
EXI
stream,
or
a
fragment
of
an
XML
document
that
matches
either
the
(追記ここまで)(追記)
content
(追記ここまで)(追記)
or
(追記ここまで)(追記)
element
(追記ここまで)(追記)
production
from
[
(追記ここまで)(追記)
XML10
(追記ここまで) (追記)
].
(追記ここまで)
(追記)
If
XML
Encryption
is
used
with
some
octet-stream,
the
precise
encoding
and
meaning
of
that
octet-stream
is
up
to
the
application,
but
treated
as
opaque
by
the
Encryptor
or
Decryptor.
The
application
may
use
the
(追記ここまで)(追記)
Type
(追記ここまで),(追記)
Encoding
(追記ここまで)(追記)
and
(追記ここまで)(追記)
MimeType
(追記ここまで)(追記)
parameters
to
transport
further
information
about
the
nature
of
that
octet-stream.
Hence,
an
unknown
(追記ここまで)(追記)
Type
(追記ここまで)(追記)
parameter
is,
in
general,
not
treated
as
an
error
by
either
the
Encryptor
or
Decryptor,
but
instead
simply
passed
through,
along
with
the
other
relevant
parameters
and
the
cleartext
octet-stream.
(追記ここまで)
(追記)
If
XML
Encryption
is
used
with
an
XML
(追記ここまで)(追記)
element
(追記ここまで)(追記)
or
XML
(追記ここまで)(追記)
content
(追記ここまで),(追記)
then
Encryptors
and
Decryptors
commonly
perform
type-specific
processing:
(追記ここまで)
(追記)
element
(追記ここまで)(追記)
is
encrypted,
then
the
Encryptor
will
replace
the
element
in
question
with
an
appropriately
constructed
(追記ここまで)(追記)
EncryptedData
(追記ここまで)(追記)
element.
The
Decryptor
will,
conversely,
replace
the
(追記ここまで)(追記)
EncryptedData
(追記ここまで)(追記)
element
with
its
cleartext.
(追記ここまで)(追記)
content
(追記ここまで)(追記)
is
encrypted,
then
the
Encryptor
will
likewise
replace
this
content
with
an
appropriately
constructed
(追記ここまで)(追記)
EncryptedData
(追記ここまで)(追記)
element,
and
the
Decryptor
will
reverse
this
operation.
(追記ここまで)(追記) Note that the intended Encryptor behavior will often cause the document with encrypted parts to become invalid with respect to its schema for the hosting XML format, unless that format is specifically prepared to be used with XML Encryption. An Encryptor or Decryptor that implements the intended processing model is (追記ここまで)(追記) not required (追記ここまで)(追記) to ensure that the resulting XML is schema-valid for the hosting XML format. (追記ここまで)
(追記)
If
XML
processing
is
handled
inside
the
Encryptor
and
Decryptor,
and
the
(追記ここまで)(追記)
Type
(追記ここまで)(追記)
attribute
values
for
(追記ここまで)(追記)
element
(追記ここまで)(追記)
and
(追記ここまで)(追記)
content
(追記ここまで)(追記)
cleartext
are
used,
then
the
Encryptor
and
Decryptor
(追記ここまで)(追記)
must
(追記ここまで)(追記)
ensure
that
the
XML
cleartext
is
serialized
as
UTF-8
before
encryption,
and
--
if
needed
--
converted
back
to
whatever
other
encoding
might
be
used
by
the
surrounding
XML
context.
(追記ここまで)
(追記) If XML (追記ここまで) Encryption (追記) is used with an EXI stream [ (追記ここまで)(追記) EXI (追記ここまで) (追記) ], then Encryptors and Decryptors process content as for XML element or XML content processing, but taking into account EXI serialization. In particular, the encryptor will replace the XML element or XML fragment in question with an appropriately constructed EncryptedData element. The Decryptor will conversely replace the EncryptedData element with its cleartext XML element or XML fragment. Note that the XML document into which the EncryptedData element is embedded may be encoded using EXI and/or EXI may be used to encode the cleartext before encryption. (追記ここまで)
(追記)
Type
(追記ここまで)(追記)
parameter
values
(追記ここまで)
For (追記) interoperability purposes, the following types (追記ここまで)(追記) must (追記ここまで)(追記) be implemented such that an implementation will be able to take as input and yield as output data matching the production rules 39 and 43 from [ (追記ここまで)(追記) XML10 (追記ここまで) (追記) ]: (追記ここまで)
(追記)
EmptyElemTag
(追記ここまで) (追記)
|
(追記ここまで)(追記)
STag
(追記ここまで) (追記)
content
(追記ここまで) (追記)
ETag
(追記ここまで) (追記)
"
(追記ここまで)(追記)
CharData
(追記ここまで) (追記)
?
((
(追記ここまで)(追記)
element
(追記ここまで) (追記)
|
(追記ここまで)(追記)
Reference
(追記ここまで) (追記)
|
(追記ここまで)(追記)
CDSect
(追記ここまで) (追記)
|
(追記ここまで)(追記)
PI
(追記ここまで) (追記)
|
(追記ここまで)(追記)
Comment
(追記ここまで) (追記)
)
(追記ここまで)(追記)
CharData
(追記ここまで) (追記)
?)*"
(追記ここまで)(追記) Support for the following type is (追記ここまで)(追記) optional (追記ここまで)(追記) for Encryptors and Decryptors: (追記ここまで)
(追記)
Type
(追記ここまで)(追記)
indicates
that
the
cleartext
is
an
EXI
stream
[
(追記ここまで)(追記)
EXI
(追記ここまで) (追記)
].
Encryptors
and
Decryptors
that
support
this
type
(追記ここまで)(追記)
may
(追記ここまで)(追記)
operate
directly
on
(parts
of)
EXI
streams.
(追記ここまで)(追記)
Encryptors
and
Decryptors
(追記ここまで)(追記)
should
(追記ここまで)(追記)
handle
unknown
or
empty
(追記ここまで)(追記)
Type
(追記ここまで)(追記)
attribute
values
as
a
signal
that
the
cleartext
is
to
be
handled
as
an
opaque
octet-stream,
whose
specific
processing
is
up
to
the
invoking
application.
In
this
case,
the
(追記ここまで)(追記)
Type
(追記ここまで),(追記)
MimeType
(追記ここまで)(追記)
and
(追記ここまで)(追記)
Encoding
(追記ここまで)(追記)
parameters
(追記ここまで)(追記)
should
(追記ここまで)(追記)
be
treated
as
opaque
data
whose
appropriate
processing
is
up
to
the
application.
(追記ここまで)
(追記) The selection of the algorithm, parameters, and encryption keys is out of scope for this specification. (追記ここまで)
(追記)
The
cleartext
data
are
assumed
to
be
present
as
an
octet
stream.
If
the
cleartext
is
of
type
(追記ここまで)(追記)
element
(追記ここまで)(追記)
or
(追記ここまで)(追記)
content
(追記ここまで),(追記)
the
data
(追記ここまで)(追記)
must
(追記ここまで)(追記)
be
serialized
in
UTF-8
as
specified
in
[
(追記ここまで)(追記)
XML10
(追記ここまで) (追記)
],
using
Normal
Form
C
[
(追記ここまで)(追記)
NFC
(追記ここまで) (追記)
].
(追記ここまで)
(追記)
For
(追記ここまで)
each
data
item
to
be
encrypted
as
an
EncryptedData
or
EncryptedKey
(削除) (elements
derived
from
EncryptedType
),
(削除ここまで)
(追記) element,
(追記ここまで)
the
encryptor
(削除) must:
(削除ここまで)
(追記) must
(追記ここまで):
If
the
key
is
to
be
identified
(via
naming,
URI,
or
included
in
a
child
element),
construct
the
ds:KeyInfo
as
(削除) approriate
(削除ここまで)
(追記) appropriate
(追記ここまで)
(e.g.,
ds:KeyName
,
ds:KeyValue
,
ds:RetrievalMethod
,
etc.)
If
the
key
itself
is
to
be
encrypted,
construct
an
EncryptedKey
element
by
recursively
applying
this
encryption
process.
The
result
may
then
be
a
child
of
ds:KeyInfo
,
or
it
may
exist
elsewhere
and
may
be
identified
in
the
preceding
step.
If
the
(削除) data
is
an
'
element
'
[
XML
,
section
3]
or
(削除ここまで)
(追記) key
was
derived
from
a
master
key,
construct
a
(追記ここまで)(追記)
DerivedKey
(追記ここまで)
element
(削除) '
content
'
[
XML
,
section
3.1],
obtain
the
octets
by
serializing
the
data
in
UTF-8
(削除ここまで)
(追記) with
associated
child
elements.
The
result
may,
(追記ここまで)
as
(削除) specified
(削除ここまで)
in
(削除) [
XML
].
(The
application
MUST
provide
XML
data
in
[
NFC
].)
Serialization
MAY
be
done
by
the
encryptor
.
If
the
encryptor
does
not
serialize,
then
the
application
MUST
perform
(削除ここまで)
the
(削除) serialization.
If
the
data
is
(削除ここまで)
(追記) EncryptedKey
(追記ここまで)(追記)
case,
be
a
child
(追記ここまで)
of
(削除) any
other
type
that
is
not
already
octets,
the
application
MUST
serialize
(削除ここまで)
(追記) ds:KeyInfo
(追記ここまで),(追記)
or
(追記ここまで)
it
(削除) as
octets.
(削除ここまで)
(追記) may
exist
elsewhere.
(追記ここまで)
(追記) Encrypt the data: (追記ここまで)
Encrypt
the
octets
using
the
algorithm
and
(削除) key
from
steps
1
and
2.
(削除ここまで)
(追記) key.
(追記ここまで)
Unless
the
decryptor
will
implicitly
know
the
type
of
the
encrypted
data,
the
encryptor
(削除) SHOULD
provide
(削除ここまで)
(追記) should
(追記ここまで)(追記)
set
(追記ここまで)
the
(削除) type
for
representation.
The
definition
of
this
type
as
bound
to
an
identifier
specifies
how
(削除ここまで)
(追記) Type
(追記ここまで)
to
(削除) obtain
and
interpret
the
plaintext
octets
after
decryption.
For
example,
the
idenifier
could
(削除ここまで)
indicate
(削除) that
(削除ここまで)
the
(削除) data
is
an
instance
(削除ここまで)
(追記) intended
interpretation
(追記ここまで)
of
(削除) another
application
(e.g.,
some
XML
compression
application)
that
must
be
further
processed.
Or,
if
(削除ここまで)
(追記) the
cleartext
data.
See
(追記ここまで)(追記)
section
4.2
Well-known
Type
parameter
values
(追記ここまで) (追記)
for
known
parameter
values.
(追記ここまで)
(追記)
If
(追記ここまで)
the
data
is
a
simple
octet
sequence
it
(削除) MAY
(削除ここまで)
(追記) may
(追記ここまで)
be
described
with
the
MimeType
and
Encoding
attributes.
For
example,
the
data
might
be
an
XML
document
(
MimeType="text/xml"
),
sequence
of
characters
(
MimeType="text/plain"
),
or
binary
image
data
(
MimeType="image/png
").
(削除) EncryptedType
(
(削除ここまで)
EncryptedData
or
EncryptedKey
An
(追記)
or
(追記ここまで)(削除) EncryptedType
(削除ここまで)
(追記) EncryptedData
(追記ここまで)(追記)
EncryptedKey
(追記ここまで)
structure
represents
all
of
the
information
previously
discussed
including
the
type
of
the
encrypted
data,
encryption
algorithm,
parameters,
key,
type
of
the
encrypted
data,
etc.
CipherData
element
within
the
(削除) EncryptedType
,
(削除ここまで)
(追記) EncryptedData
(追記ここまで)(追記)
or
(追記ここまで)(追記)
EncryptedKey
(追記ここまで)(追記)
element,
(追記ここまで)
then
the
(追記) base64
representation
of
the
(追記ここまで)
encrypted
octet
sequence
is
CipherValue
element.
If
the
encrypted
octet
sequence
is
(削除) to
be
(削除ここまで)
stored
externally
to
the
(削除) EncryptedType
(削除ここまで)
(追記) EncryptedData
(追記ここまで)
(削除) structure,
then
store
(削除ここまで)
or
(削除) return
the
encrypted
octet
sequence,
and
represent
(削除ここまで)
(追記) EncryptedKey
(追記ここまで)(追記)
element,
then
(追記ここまで)
the
URI
and
transforms
(if
any)
required
for
the
(削除) decryptor
(削除ここまで)
(追記) Decryptor
(追記ここまで)
to
retrieve
the
encrypted
octet
sequence
(追記) are
described
(追記ここまで)
within
a
CipherReference
element.
(削除) Process
EncryptedData
If
the
Type
of
the
encrypted
data
is
'
element
'
or
element
'
content
',
then
the
encryptor
MUST
be
able
to
return
the
EncryptedData
element
to
the
application
.
The
application
MAY
use
this
as
the
top-level
element
in
a
new
XML
document
or
insert
it
into
another
XML
document,
which
may
require
a
re-encoding.
The
encryptor
SHOULD
be
able
to
replace
the
unencrypted
'element'
or
'content'
with
the
EncryptedData
element.
When
an
application
requires
an
XML
element
or
content
to
be
replaced,
it
supplies
the
XML
document
context
in
addition
to
identifying
the
element
or
content
to
be
replaced.
The
encryptor
removes
the
identified
element
or
content
and
inserts
the
EncryptedData
element
in
its
place.
(削除ここまで)
For
each
or
(削除) EncryptedType
derived
element,
(i.e.,
(削除ここまで)
EncryptedData
EncryptedKey
(削除) ),
(削除ここまで)
to
be
decrypted,
the
decryptor
(削除) must:
(削除ここまで)
(追記) must
(追記ここまで):
ds:KeyInfo
Decrypt
the
data
contained
in
the
CipherData
element.
If
a
CipherValue
child
element
is
present,
then
the
associated
text
value
is
retrieved
and
base64
decoded
so
as
to
obtain
the
encrypted
octet
sequence.
If
a
CipherReference
child
element
is
present,
the
URI
and
transforms
(if
any)
are
used
to
retrieve
the
encrypted
octet
sequence.
The
encrypted
octet
sequence
is
decrypted
using
the
(削除) algorithm/parameters
(削除ここまで)
(追記) algorithm,
parameters
(追記ここまで)
and
key
value
already
determined
from
(削除) steps
1
and
2.
Process
decrypted
data
of
Type
'
element
'
or
element
'
content
'.
The
cleartext
octet
sequence
obtained
in
(削除ここまで)
step
(削除) 3
is
interpreted
as
UTF-8
encoded
character
data.
The
decryptor
MUST
be
able
to
return
the
value
of
Type
and
the
UTF-8
encoded
XML
character
data.
The
decryptor
is
NOT
REQUIRED
to
perform
validation
on
the
serialized
XML.
The
decryptor
SHOULD
support
the
ability
to
replace
the
EncryptedData
element
with
the
decrypted
'
element
'
or
element
'
content
'
represented
by
the
UTF-8
encoded
characters.
The
decryptor
is
NOT
REQUIRED
to
perform
validation
on
the
result
of
this
replacement
operation.
The
application
supplies
the
XML
document
context
and
identifies
the
EncryptedData
element
being
replaced.
If
the
document
into
which
the
replacement
is
occurring
is
not
UTF-8,
the
decryptor
MUST
transcode
the
UTF-8
encoded
characters
into
the
target
encoding.
(削除ここまで)
(追記) 1.
(追記ここまで)
Encryption
and
decryption
operations
are
(削除) transforms
(削除ここまで)
(追記) operations
(追記ここまで)
on
octets.
The
application
is
responsible
for
the
marshalling
XML
such
that
it
can
be
serialized
into
an
octet
sequence,
encrypted,
decrypted,
and
be
of
use
to
the
recipient.
For
example,
if
the
application
wishes
to
canonicalize
its
data
or
encode/compress
the
data
in
an
XML
packaging
format,
the
application
needs
to
marshal
the
XML
accordingly
and
identify
the
resulting
type
via
the
EncryptedData
Type
attribute.
The
likelihood
of
successful
decryption
and
subsequent
processing
will
be
dependent
on
the
recipient's
support
for
the
given
type.
Also,
if
the
data
is
intended
to
be
processed
both
before
encryption
and
after
decryption
(e.g.,
XML
Signature
[
(削除) XML-DSIG
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
]
validation
or
an
XSLT
transform)
the
encrypting
application
must
be
careful
to
preserve
information
necessary
for
that
process's
success.
(削除) For
interoperability
purposes,
the
following
types
MUST
be
implemented
such
that
an
implementation
will
be
able
to
take
as
input
and
yield
as
output
data
matching
the
production
rules
39
and
43
from
[
XML
]:
element
'
http://www.w3.org/2001/04/xmlenc#Element
'
"[39]
element
::=
EmptyElemTag
|
STag
content
ETag
"
content
'
http://www.w3.org/2001/04/xmlenc#Content
'
"[43]
content
::=
CharData
?
((
element
|
Reference
|
CDSect
|
PI
|
Comment
)
CharData
?)*"
(削除ここまで)
The
following
sections
contain
specifications
for
decrypting,
replacing,
and
serializing
XML
content
(i.e.,
Type
'
element
'
or
element
'
content
')
using
the
[
(削除) XPath
(削除ここまで)
(追記) XPATH
(追記ここまで)
]
data
model.
These
sections
are
non-normative
and
(削除) OPTIONAL
(削除ここまで)
(追記) optional
(追記ここまで)
to
(削除) implementors
(削除ここまで)
(追記) implementers
(追記ここまで)
of
this
specification,
but
they
may
be
normatively
referenced
by
and
(削除) MANDATORY
to
(削除ここまで)
(追記) be
required
by
(追記ここまで)
other
specifications
that
require
a
consistent
processing
for
applications,
such
as
[
(削除) XML-DSIG-Decrypt
(削除ここまで)
(追記) XMLENC-DECRYPT
(追記ここまで)
].
Where
P
is
the
context
in
which
the
serialized
XML
should
be
parsed
(a
document
node
or
element
node)
and
O
is
the
octet
sequence
representing
UTF-8
encoded
characters
resulting
from
step
4.3
in
(削除) the
(削除ここまで)
(追記) section
4.4
(追記ここまで)
Decryption
(削除) Processing
(section
4.2).
(削除ここまで)
.
Y
is
node-set
representing
the
decrypted
content
obtained
by
the
following
steps:
Where
X
is
the
[
(削除) XPath
(削除ここまで)
(追記) XPATH
(追記ここまで)
]
node
set
corresponding
to
an
XML
document
and
e
is
an
EncryptedData
element
node
in
X
.
EncryptedData
element
type.
In
which
case:
In
(削除) Encrypting
XML
(削除ここまで)
(追記) section
4.3
Encryption
(追記ここまで)
(削除) (section
4.1,
step
(削除ここまで)
(追記) (step
(追記ここまで)
3.1),
when
serializing
an
XML
fragment
special
care
(削除) SHOULD
(削除ここまで)
(追記) should
(追記ここまで)
be
taken
with
respect
to
default
namespaces.
If
the
data
will
be
subsequently
decrypted
in
the
context
of
a
parent
XML
document
then
serialization
can
produce
elements
in
the
wrong
namespace.
Consider
the
following
fragment
of
XML:
Serialization
of
the
element
ToBeEncrypted
fragment
via
[
XML-C14N
]
would
result
in
the
characters
"
<ToBeEncrypted></ToBeEncrypted>
"
as
an
octet
stream.
The
resulting
encrypted
document
would
be:
Decrypting
and
replacing
the
EncryptedData
within
this
document
would
produce
the
following
incorrect
result:
This
problem
arises
because
most
XML
serializations
assume
that
the
serialized
data
will
be
parsed
directly
in
a
context
where
there
is
no
default
namespace
declaration.
Consequently,
they
do
not
redundantly
declare
the
empty
default
namespace
with
an
xmlns=""
.
If,
however,
the
serialized
data
is
parsed
in
a
context
where
a
default
namespace
declaration
is
in
scope
(e.g.,
the
parsing
context
(削除) of
a
(削除ここまで)
(追記) as
described
in
(追記ここまで)(追記)
section
4.5.1
(追記ここまで)
A
Decrypt
Implementation
(追記) (Non-normative)
(追記ここまで)
(削除) (section
4.3.1)),
(削除ここまで)
(追記) ),
(追記ここまで)
then
it
may
affect
the
interpretation
of
the
serialized
data.
To
solve
this
problem,
a
canonicalization
algorithm
(削除) MAY
(削除ここまで)
(追記) may
(追記ここまで)
be
augmented
as
follows
for
use
as
an
XML
encryption
serializer:
xmlns=""
)
While
the
result
may
not
be
in
proper
canonical
form,
this
is
harmless
as
the
resulting
octet
stream
will
not
be
used
directly
in
a
[
(削除) XML-Signature
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
]
signature
value
computation.
Returning
to
the
preceding
example
with
our
new
augmentation,
the
ToBeEncrypted
element
would
be
serialized
as
follows:
<ToBeEncrypted xmlns=""></ToBeEncrypted>
When processed in the context of the parent document, this serialized fragment will be parsed and interpreted correctly.
This
augmentation
can
be
retroactively
applied
to
an
existing
canonicalization
implementation
by
canonicalizing
each
apex
node
and
its
descendants
from
the
node
set,
inserting
xmlns=""
at
the
appropriate
points,
and
concatenating
the
resulting
octet
streams.
Similar
attention
between
the
relationship
of
a
fragment
and
the
context
into
which
it
is
being
inserted
should
be
given
to
the
xml:base
,
xml:lang
,
and
xml:space
attributes
as
mentioned
in
the
Security
Considerations
of
[
(削除) XML-exc-C14N
(削除ここまで)
(追記) XML-EXC-C14N
(追記ここまで)
].
For
example,
if
the
element:
is
taken
from
a
context
and
serialized
with
no
xml:base
[
(削除) XML-Base
(削除ここまで)
(追記) XMLBASE
(追記ここまで)
]
attribute
and
parsed
in
the
context
of
the
element:
the result will be:
Bongo
's
href
is
subsequently
interpreted
as
"
http://example.org/example.xml
".
If
this
is
not
the
correct
URI,
Bongo
should
have
been
serialized
with
its
own
xml:base
attribute.
Unfortunately,
the
recommendation
that
an
empty
value
be
emitted
to
divorce
the
default
namespace
of
the
fragment
from
the
context
into
which
it
is
being
inserted
(削除) can
not
(削除ここまで)
(追記) cannot
(追記ここまで)
be
made
for
the
attributes
xml:base
,
and
xml:space
.
(
Error
41
of
the
XML
1.0
Second
Edition
Specification
Errata
clarifies
that
an
empty
string
value
of
the
attribute
xml:lang
is
considered
as
if,
"there
is
no
language
information
available,
just
as
if
xml:lang
had
not
been
specified".)
The
interpretation
of
an
empty
value
for
the
xml:base
or
xml:space
attributes
is
undefined
or
maintains
the
contextual
value.
Consequently,
applications
(削除) SHOULD
(削除ここまで)
(追記) should
(追記ここまで)
ensure
(1)
fragments
that
are
to
be
encrypted
are
not
dependent
on
XML
attributes,
or
(2)
if
they
are
dependent
and
the
resulting
document
is
intended
to
be
valid
[
(削除) XML
(削除ここまで)
(追記) XML10
(追記ここまで)
],
the
fragment's
definition
permits
the
presence
of
the
attributes
and
that
the
attributes
have
non-empty
values.
This
section
specifies
the
process
for
wrapping
text
in
a
given
parsing
context.
The
process
is
based
on
the
proposal
by
Richard
Tobin
[
Tobin
]
for
constructing
the
infoset
[
(削除) XML-Infoset
(削除ここまで)
(追記) XML-INFOSET
(追記ここまで)
]
of
an
external
entity.
The process consists of the following steps:
If the parsing context contains any general entities, then emit a document type declaration that provides entity declarations.
Emit
a
dummy
element
start-tag
with
namespace
declaration
attributes
declaring
all
the
namespaces
in
the
parsing
context.
Emit the text.
Emit
a
dummy
element
end-tag.
In
the
above
steps,
the
document
type
declaration
and
dummy
element
tags
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
be
encoded
in
UTF-8.
Consider
the
following
document
containing
an
EncryptedData
element:
If
the
EncryptedData
element
is
(削除) fed
is
(削除ここまで)
decrypted
to
the
text
"
<One><foo:Two/></One>
",
then
the
wrapped
form
is
as
follows:
This
section
discusses
algorithms
used
with
the
XML
Encryption
specification.
Entries
contain
the
identifier
to
be
used
as
the
value
of
the
Algorithm
attribute
of
the
EncryptionMethod
element
or
other
element
representing
the
role
of
the
algorithm,
a
reference
to
the
formal
specification,
definitions
for
the
representation
of
keys
and
the
results
of
cryptographic
operations
where
applicable,
and
general
applicability
comments.
All
algorithms
listed
below
have
implicit
parameters
depending
on
their
role.
For
example,
the
data
to
be
encrypted
or
decrypted,
keying
material,
and
direction
of
operation
(encrypting
or
decrypting)
for
encryption
algorithms.
Any
explicit
additional
parameters
to
an
algorithm
appear
as
content
elements
within
the
element.
Such
parameter
child
elements
have
descriptive
element
names,
which
are
frequently
algorithm
specific,
and
(削除) SHOULD
(削除ここまで)
(追記) should
(追記ここまで)
be
in
the
same
namespace
as
this
XML
Encryption
specification,
the
XML
Signature
specification,
or
in
an
algorithm
specific
namespace.
An
example
of
such
an
explicit
parameter
could
be
a
nonce
(unique
quantity)
provided
to
a
key
agreement
algorithm.
This
specification
defines
a
set
of
algorithms,
their
URIs,
and
requirements
for
implementation.
Levels
of
requirement
specified,
such
as
(削除) "REQUIRED"
(削除ここまで)
(追記) "
(追記ここまで)(追記)
required
(追記ここまで)(追記)
"
(追記ここまで)
or
(削除) "OPTIONAL",
refere
(削除ここまで)
(追記) "
(追記ここまで)(追記)
optional
(追記ここまで)(追記)
",
refer
(追記ここまで)
to
implementation,
not
use.
Furthermore,
the
mechanism
is
extensible,
and
alternative
algorithms
may
be
used.
The table below lists the categories of algorithms. Within each category, a brief name, the level of implementation requirement, and an identifying URI are given for each algorithm.
(追記) Note: (追記ここまで)(追記) Use of AES GCM is strongly recommended over any CBC block encryption algorithms as recent advances in cryptanalysis [ (追記ここまで)(追記) XMLENC-CBC-ATTACK (追記ここまで) (追記) ][ (追記ここまで)(追記) XMLENC-CBC-ATTACK-COUNTERMEASURES (追記ここまで) (追記) ] have cast doubt on the ability of CBC block encryption algorithms to protect plain text when used with XML Encryption. Other mitigations should be considered when using CBC block encryption, such as conveying the encrypted data over a secure channel such as TLS. The CBC block encryption algorithms that are listed as required remain so for backward compatibility. (追記ここまで)
(追記) *note:
The
same
URI
is
used
to
identify
base64
both
in
"encoding"
context
(e.g.
when
used
with
the
(追記ここまで)(追記)
Encoding
(追記ここまで)(追記)
attribute
of
an
(追記ここまで)(追記)
EncryptedKey
(追記ここまで)(追記)
element,
see
(追記ここまで)(追記)
section
3.1
The
EncryptedType
Element
(追記ここまで) (追記)
)
as
well
as
in
"transform"
context
(when
identifying
a
base64
transform
for
a
(追記ここまで)(追記)
CipherReference
(追記ここまで),(追記)
see
(追記ここまで)(追記)
section
3.3.1
The
CipherReference
Element
(追記ここまで) (追記)
).
(追記ここまで)
Block
encryption
algorithms
are
designed
for
encrypting
and
decrypting
data
in
fixed
size,
multiple
octet
blocks.
Their
identifiers
appear
as
the
value
of
the
Algorithm
attributes
of
EncryptionMethod
elements
that
are
children
of
EncryptedData
.
(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).
Block encryption algorithms take, as implicit arguments, the data to be encrypted or decrypted, the keying material, and their direction of operation. For all of these algorithms specified below, an initialization vector (IV) is required that is encoded with the cipher text. For user specified block encryption algorithms, the IV, if any, could be specified as being with the cipher data, as an algorithm content element, or elsewhere.
The IV is encoded with and before the cipher text for the algorithms below for ease of availability to the decryption code and to emphasize its association with the cipher text. Good cryptographic practice requires that a different IV be used for every encryption.
Since
the
data
being
encrypted
is
an
arbitrary
number
of
octets,
it
may
not
be
a
multiple
of
the
block
size.
This
is
solved
by
padding
the
plain
text
up
to
the
block
size
before
encryption
and
unpadding
after
decryption.
The
padding
algorithm
is
to
calculate
the
smallest
non-zero
number
of
octets,
say
N
,
that
must
be
suffixed
to
the
plain
text
to
bring
it
up
to
a
multiple
of
the
block
size.
We
will
assume
the
block
size
is
B
octets
so
N
is
in
the
range
of
1
to
B
.
Pad
by
suffixing
the
plain
text
with
N-1
arbitrary
pad
bytes
and
a
final
byte
whose
value
is
N
.
On
decryption,
just
take
the
last
byte
and,
after
sanity
checking
it,
strip
that
many
bytes
from
the
end
of
the
decrypted
cipher
text.
For
example,
assume
an
8
byte
block
size
and
plain
text
of
0x616263
.
The
padded
plain
text
would
then
be
0x616263????????05
where
the
"??"
bytes
can
be
any
value.
Similarly,
plain
text
of
0x2122232425262728
would
be
padded
to
0x2122232425262728??????????????08
.
(削除) ANSI
X9.52
(削除ここまで)
(追記) NIST
SP800-67
(追記ここまで)
[
(削除) TRIPLEDES
(削除ここまで)
(追記) SP800-67
(追記ここまで)
]
specifies
three
sequential
FIPS
46-3
[
DES
]
operations.
The
XML
Encryption
TRIPLEDES
consists
of
a
DES
encrypt,
a
DES
decrypt,
and
a
DES
encrypt
used
in
the
Cipher
Block
Chaining
(CBC)
mode
with
192
bits
of
key
and
a
64
bit
Initialization
Vector
(IV).
Of
the
key
bits,
the
first
64
are
used
in
the
first
DES
operation,
the
second
64
bits
in
the
middle
DES
operation,
and
the
third
64
bits
in
the
last
DES
operation.
Note: Each of these 64 bits of key contain 56 effective bits and 8 parity bits. Thus there are only 168 operational bits out of the 192 being transported for a TRIPLEDES key. (Depending on the criterion used for analysis, the effective strength of the key may be thought to be 112 bits (due to meet in the middle attacks) or even less.)
The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example TRIPLEDES EncryptionMethod is as follows:
(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).
[ AES ] is used in the Cipher Block Chaining (CBC) mode with a 128 bit initialization vector (IV). The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example AES EncryptionMethod is as follows:
(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).
(追記) AES-GCM [ (追記ここまで)(追記) SP800-38D (追記ここまで) (追記) ] is an authenticated encryption mechanism. It is equivalent to doing these two operations in one step - AES encryption followed by HMAC signing. (追記ここまで)
(追記) AES-GCM is very attractive from a performance point of view because the cost of AES-GCM is similar to regular AES-CBC encryption, yet it achieves the same result as encryption and HMAC signing. Also AES-GCM can be pipelined so it is amenable to hardware acceleration. (追記ここまで)
(追記) For the purposes of this specification, AES-GCM shall be used with a 96 bit Initialization Vector (IV) and a 128 bit Authentication Tag (T). The cipher text contains the IV first, followed by the encrypted octets and finally the Authentication tag. No padding should be used during encryption. During decryption the implementation should compare the authentication tag computed during decryption with the specified Authentication Tag, and fail if they don't match. For details on the implementation of AES-GCM, see [ (追記ここまで)(追記) SP800-38D (追記ここまで) (追記) ]. (追記ここまで)
Simple
stream
encryption
algorithms
generate,
based
on
the
key,
a
stream
of
bytes
which
are
XORed
with
the
plain
text
data
bytes
to
produce
the
cipher
text
on
encryption
and
with
the
cipher
text
bytes
to
produce
plain
text
on
decryption.
They
are
normally
used
for
the
encryption
of
data
and
are
specified
by
the
value
of
the
Algorithm
attribute
of
the
EncryptionMethod
child
of
an
EncryptedData
element.
NOTE: It is critical that each simple stream encryption key (or key and initialization vector (IV) if an IV is also used) be used once only. If the same key (or key and IV) is ever used on two messages then, by XORing the two cipher texts, you can obtain the XOR of the two plain texts. This is usually very compromising.
No specific stream encryption algorithms are specified herein but this section is included to provide general guidelines.
Stream
algorithms
typically
use
the
optional
KeySize
explicit
parameter.
In
cases
where
the
key
size
is
not
apparent
from
the
algorithm
URI
or
key
source,
as
in
the
use
of
key
agreement
methods,
this
parameter
sets
the
key
size.
If
the
size
of
the
key
to
be
used
is
apparent
and
disagrees
with
the
KeySize
parameter,
an
error
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
be
returned.
Implementation
of
any
stream
algorithms
is
optional.
The
schema
for
the
KeySize
parameter
is
as
follows:
(追記) Key derivation is a well-established mechanism for generating new cryptographic key material from some existing, original ("master") key material and potentially other information. Derived keys are used for a variety of purposes including data encryption and message authentication. The reason for doing key derivation itself is typically a combination of a desire to expand a given, but limited, set of original key material and prudent security practices of limiting use (exposure) of such key material. Key separation (such as avoiding use of the same key material for multiple purposes) is an example of such practices. (追記ここまで)
(追記) The key derivation process may be based on passphrases agreed upon or remembered by users, or it can be based on some shared "master" cryptographic keys (and be intended to reduce exposure of such master keys), etc. Derived keys themselves may be used in XML Signature and XML Encryption as any other keys; in particular, they may be used to compute message authentication codes (e.g. digital signatures using symmetric keys) or for encryption/decryption purposes. (追記ここまで)
(追記)
The
ConcatKDF
key
derivation
algorithm,
defined
in
Section
5.8.1
of
NIST
SP
800-56A
[
(追記ここまで)(追記)
SP800-56A
(追記ここまで) (追記)
]
(and
equivalent
to
the
KDF3
function
defined
in
ANSI
X9.44-2007
[
(追記ここまで)(追記)
ANSI-X9-44-2007
(追記ここまで) (追記)
]
when
the
contents
of
the
(追記ここまで)(追記)
OtherInfo
(追記ここまで)(追記)
parameter
is
structured
as
in
NIST
SP
800-56A),
takes
several
parameters.
These
parameters
are
represented
in
the
(追記ここまで)(追記)
xenc11:ConcatKDFParamsType
(追記ここまで):
(追記)
The
(追記ここまで)(追記)
ds:DigestMethod
(追記ここまで)(追記)
element
identifies
the
digest
algorithm
used
by
the
KDF.
Compliant
implementations
(追記ここまで)(追記)
must
(追記ここまで)(追記)
support
SHA-256
and
SHA-1
(support
for
SHA-1
is
present
only
for
backwards-compatibility
reasons).
Support
for
SHA-384
and
SHA-512
is
(追記ここまで)(追記)
optional
(追記ここまで).
(追記)
The
(追記ここまで)(追記)
AlgorithmID
(追記ここまで),(追記)
PartyUInfo
(追記ここまで),(追記)
PartyVInfo
(追記ここまで),(追記)
SuppPubInfo
(追記ここまで)(追記)
and
(追記ここまで)(追記)
SuppPrivInfo
(追記ここまで)(追記)
attributes
are
as
defined
in
[
(追記ここまで)(追記)
SP800-56A
(追記ここまで) (追記)
].
Their
presence
is
optional
but
(追記ここまで)(追記)
AlgorithmID
(追記ここまで),(追記)
PartyVInfo
(追記ここまで)(追記)
and
(追記ここまで)(追記)
PartyUInfo
(追記ここまで)(追記)
must
(追記ここまで)(追記)
be
present
for
applications
that
need
to
comply
with
[
(追記ここまで)(追記)
SP800-56A
(追記ここまで) (追記)
].
Note:
The
(追記ここまで)(追記)
PartyUInfo
(追記ここまで)(追記)
component
shall
include
a
nonce
when
ConcatKDF
is
used
in
conjunction
with
a
static-static
Diffie-Hellman
(or
static-static
ECDH)
key
agreement
scheme;
see
further
[
(追記ここまで)(追記)
SP800-56A
(追記ここまで) (追記)
].
(追記ここまで)
(追記)
In
[
(追記ここまで)(追記)
SP800-56A
(追記ここまで) (追記)
],
(追記ここまで)(追記)
AlgorithmID
(追記ここまで),(追記)
PartyUInfo
(追記ここまで),(追記)
PartyVInfo
(追記ここまで),(追記)
SuppPubInfo
(追記ここまで)(追記)
and
(追記ここまで)(追記)
SuppPrivInfo
(追記ここまで)(追記)
attributes
are
all
defined
as
arbitrary-length
bitstrings,
thus
they
may
need
to
be
padded
in
order
to
be
encoded
into
hexBinary
for
XML
Encryption.
The
following
padding
and
encoding
method
(追記ここまで)(追記)
must
(追記ここまで)(追記)
be
used
when
encoding
bitstring
values
for
the
(追記ここまで)(追記)
AlgorithmID
(追記ここまで),(追記)
PartyUInfo
(追記ここまで),(追記)
PartyVInfo
(追記ここまで),(追記)
SuppPubInfo
(追記ここまで)(追記)
and
(追記ここまで)(追記)
SuppPrivInfo
(追記ここまで):
(追記) The bitstring is divided into octets using big-endian encoding. If the length of the bitstring is not a multiple of 8 then add padding bits (value 0) as necessary to the last octet to make it a multiple of 8. (追記ここまで)
(追記) Prepend one octet to the octets string from step 1. This octet shall identify (in a big-endian representation) the number of padding bits added to the last octet in step 1. (追記ここまで)
(追記) Encode the octet string resulting from step 2 as a hexBinary string. (追記ここまで)
(追記)
Example:
the
bitstring
(追記ここまで)(追記)
11011
(追記ここまで),(追記)
which
is
5
bits
long,
gets
3
additional
padding
bits
to
become
the
bitstring
(追記ここまで)(追記)
11011000
(追記ここまで)(追記)
(or
(追記ここまで)(追記)
D8
(追記ここまで)(追記)
in
hex).
This
bitstring
is
then
prepended
with
one
octet
identifying
the
number
of
padding
bits
to
become
the
octet
string
(in
hex)
(追記ここまで)(追記)
03D8
(追記ここまで),(追記)
which
then
finally
is
encoded
as
a
hexBinary
string
value
of
"03D8".
(追記ここまで)
(追記) Note that as specified in [ (追記ここまで)(追記) SP800-56A (追記ここまで) (追記) ], these attributes shall be concatenated to form a bit string 窶廾therInfo窶? that is used with the key derivation function. The concatenation (追記ここまで)(追記) shall (追記ここまで)(追記) be done using the original, unpadded bit string values.窶? Applications (追記ここまで)(追記) must (追記ここまで)(追記) also verify that these attributes, in an application-specific way not defined in this document, identify algorithms and parties in accordance with NIST SP800-56. (追記ここまで)
(追記)
An
example
of
an
(追記ここまで)(追記)
xenc11:DerivedKey
(追記ここまで)(追記)
element
with
this
key
derivation
algorithm
given
below.
In
this
example,
the
bitstring
value
of
(追記ここまで)(追記)
AlgorithmID
(追記ここまで)(追記)
is
(追記ここまで)(追記)
00000000
(追記ここまで),(追記)
the
bitstring
value
of
(追記ここまで)(追記)
PartyUInfo
(追記ここまで)(追記)
is
(追記ここまで)(追記)
11011
(追記ここまで)(追記)
and
the
bitstring
value
of
(追記ここまで)(追記)
PartyVInfo
(追記ここまで)(追記)
is
(追記ここまで)(追記)
11010
(追記ここまで):
(追記)
The
PBKDF2
key
derivation
algorithm
and
the
ASN.1
type
definitions
for
its
parameters
are
defined
in
PKCS
#5
v2.0
[
(追記ここまで)(追記)
PKCS5
(追記ここまで) (追記)
].
The
XML
schema
definitions
for
the
parameters
is
defined
in
[
(追記ここまで)(追記)
PKCS5Amd1
(追記ここまで) (追記)
]
and
the
same
can
be
specified
by
enclosing
them
within
an
(追記ここまで)(追記)
xenc11:PBKDF2-params
(追記ここまで)(追記)
child
element
of
the
(追記ここまで)(追記)
xenc11:KeyDerivationMethod
(追記ここまで)(追記)
element.
(追記ここまで)
(追記) (Note: A newline has been added to the Algorithm attribute to fit on this page, but is not part of the URI.) (追記ここまで)
(追記)
The
(追記ここまで)(追記)
PBKDF2-params
(追記ここまで)(追記)
element
and
its
child
elements
have
the
same
names
and
meaning
as
the
corresponding
components
of
the
(追記ここまで)(追記)
PBKDF2-params
(追記ここまで)(追記)
ASN.1
type
in
[
(追記ここまで)(追記)
PKCS5
(追記ここまで) (追記)
].
Note,
in
case
of
ConcatKDF
and
the
Diffie
Hellman
legacy
KDF,
(追記ここまで)(追記)
KeyLength
(追記ここまで)(追記)
is
an
implied
parameter
and
needs
to
be
inferred
from
the
context,
but
in
the
case
of
PBKDF2
the
(追記ここまで)(追記)
KeyLength
(追記ここまで)(追記)
child
element
has
to
be
specified,
as
it
has
been
made
a
mandatory
parameter
to
be
consistent
with
PKCS5.
For
PBKDF2,
the
inferred
key
length
must
match
the
specified
key
length,
otherwise
it
is
an
error
condition.
(追記ここまで)
(追記)
The
(追記ここまで)(追記)
AlgorithmIdentifierType
(追記ここまで)(追記)
corresponds
to
the
(追記ここまで)(追記)
AlgorithmIdentifier
(追記ここまで)(追記)
type
of
[
(追記ここまで)(追記)
PKCS5
(追記ここまで) (追記)
]
and
carries
the
algorithm
identifier
in
the
(追記ここまで)(追記)
Algorithm
(追記ここまで)(追記)
attribute.
Algorithm
specific
parameters,
where
applicable,
can
be
specified
using
the
(追記ここまで)(追記)
Parameters
(追記ここまで)(追記)
element.
(追記ここまで)
(追記)
The
(追記ここまで)(追記)
PRFAlgorithmIdentifierType
(追記ここまで)(追記)
is
derived
from
the
(追記ここまで)(追記)
AlgorithmIdentifierType
(追記ここまで)(追記)
and
constrains
the
choice
of
algorithms
to
those
contained
in
the
PBKDF2-PRFs
set
defined
in
[
(追記ここまで)(追記)
PKCS5
(追記ここまで)
(追記) ].
This
type
is
used
to
specify
a
pseudorandom
function
(PRF)
for
PBKDF2.
Whereas
HMAC-SHA1
is
the
default
PRF
algorithm
in
[
(追記ここまで)(追記)
PKCS5
(追記ここまで) (追記)
],
use
of
HMAC-SHA256
is
(追記ここまで)(追記)
recommended
(追記ここまで)(追記)
by
this
specification
(see
[
(追記ここまで)(追記)
XMLDSIG-CORE1
(追記ここまで) (追記)
],
[
(追記ここまで)(追記)
HMAC
(追記ここまで) (追記)
]).
(追記ここまで)
(追記)
An
example
of
an
(追記ここまで)(追記)
xenc11:DerivedKey
(追記ここまで)(追記)
element
with
this
key
derivation
algorithm
is:
(追記ここまで)
Key
Transport
algorithms
are
public
key
encryption
algorithms
especially
specified
for
encrypting
and
decrypting
keys.
Their
identifiers
appear
as
Algorithm
attributes
to
EncryptionMethod
elements
that
are
children
of
EncryptedKey
.
EncryptedKey
is
in
turn
the
child
of
a
ds:KeyInfo
element.
The
type
of
key
being
transported,
that
is
to
say
the
algorithm
in
which
it
is
planned
to
use
the
transported
key,
is
given
by
the
Algorithm
attribute
of
the
EncryptionMethod
child
of
the
EncryptedData
or
EncryptedKey
parent
of
this
ds:KeyInfo
element.
(Key
Transport
algorithms
may
optionally
be
used
to
encrypt
data
in
which
case
they
appear
directly
as
the
Algorithm
attribute
of
an
EncryptionMethod
child
of
an
EncryptedData
element.
Because
they
use
public
key
algorithms
directly,
Key
Transport
algorithms
are
not
efficient
for
the
transport
of
any
amounts
of
data
significantly
larger
than
symmetric
keys.)
The
RSAES-PKCS1-v1_5
algorithm,
specified
in
RFC
(削除) 2437
(削除ここまで)
(追記) 3447
(追記ここまで)
[
PKCS1
],
takes
no
explicit
parameters.
An
example
of
an
RSA
Version
1.5
EncryptionMethod
element
is:
The
CipherValue
for
such
an
encrypted
key
is
the
base64
[
(削除) MIME
(削除ここまで)
(追記) RFC2045
(追記ここまで)
]
encoding
of
the
octet
string
computed
as
per
RFC
(削除) 2437
(削除ここまで)
(追記) 3447
(追記ここまで)
[
PKCS1
(削除) ,
(削除ここまで)
(追記) ],
(追記ここまで)
section
7.2.1:
Encryption
operation].
As
specified
in
the
EME-PKCS1-v1_5
function
RFC
(削除) 2437
(削除ここまで)
(追記) 3447
(追記ここまで)
[
PKCS1
(削除) ,
(削除ここまで)
(追記) ],
(追記ここまで)
section
(削除) 9.1.2.1],
(削除ここまで)
(追記) 7.2.1,
(追記ここまで)
the
value
input
to
the
key
transport
function
is
as
follows:
CRYPT ( PAD ( KEY ))
where the padding is of the following special form:
02 |(削除) PS* (削除ここまで)(追記) PS (追記ここまで)(追記) * (追記ここまで) | 00 | key
where
"|"
is
concatenation,
"02"
and
"00"
are
fixed
octets
of
the
corresponding
hexadecimal
value,
PS
is
a
string
of
strong
pseudo-random
octets
[
RANDOM
]
at
least
eight
octets
long,
containing
no
zero
octets,
and
long
enough
that
the
value
of
the
quantity
being
CRYPTed
is
one
octet
shorter
than
the
RSA
modulus,
and
"key"
is
the
key
being
transported.
The
key
is
192
bits
for
TRIPLEDES
and
128,
192,
or
256
bits
for
AES.
(削除) Support
of
(削除ここまで)
(追記) Implementations
(追記ここまで)(追記)
must
(追記ここまで)(追記)
support
(追記ここまで)
this
key
transport
algorithm
for
transporting
(削除) 192
bit
keys
is
MANDATORY
to
implement.
(削除ここまで)
(追記) 192-bit
TRIPLEDES
keys.
(追記ここまで)
Support
of
this
algorithm
for
transporting
other
keys
is
(削除) OPTIONAL.
(削除ここまで)
(追記) optional
(追記ここまで).
RSA-OAEP
is
(削除) RECOMMENDED
(削除ここまで)
(追記) recommended
(追記ここまで)
for
the
transport
of
AES
keys.
The
resulting
base64
[
(削除) MIME
(削除ここまで)
(追記) RFC2045
(追記ここまで)
]
string
is
the
value
of
the
child
text
node
of
the
CipherData
element,
e.g.
(追記)
CipherValue
(追記ここまで)(追記)
to
fit
on
this
page,
but
is
not
part
of
value.)
(追記ここまで)(追記) Note: Implementation of RSA v1.5 is (追記ここまで)(追記) not recommended (追記ここまで)(追記) due to security risks associated with the algorithm. (追記ここまで)
(追記)
MGF1
with
SHA1
(追記ここまで)(追記)
mask
generation
function)
(追記ここまで)
The
RSAES-OAEP-ENCRYPT
algorithm,
as
specified
in
RFC
(削除) 2437
(削除ここまで)
(追記) 3447
(追記ここまで)
[
PKCS1
],
(削除) takes
three
parameters.
The
two
user
specified
parameters
are
a
MANDATORY
(削除ここまで)
(追記) has
options
that
define
the
(追記ここまで)
message
digest
function
and
(追記) mask
generation
function,
as
well
as
(追記ここまで)
an
(削除) OPTIONAL
encoding
octet
string
OAEPparams
.
The
message
digest
function
is
indicated
by
the
(削除ここまで)
(追記) optional
(追記ここまで)
(削除) Algorithm
(削除ここまで)
(追記) PSourceAlgorithm
(追記ここまで)
(削除) attribute
of
a
child
(削除ここまで)
(追記) parameter.
Default
values
defined
in
RFC
3447
are
(追記ここまで)
(削除) ds:DigestMethod
(削除ここまで)
(追記) SHA1
(追記ここまで)
(削除) element
and
the
mask
generation
function,
(削除ここまで)
(追記) for
(追記ここまで)
the
(削除) third
parameter,
is
always
(削除ここまで)
(追記) message
digest
and
(追記ここまで)
MGF1
with
SHA1
(追記) for
the
mask
generation
function.
(追記ここまで)
Both
the
message
digest
and
mask
generation
functions
are
used
in
the
EME-OAEP-ENCODE
operation
as
part
of
(削除) (mgf1SHA1Identifier).
(削除ここまで)
(削除) RSAES-OAEP-ENCRYPT.
(削除ここまで)
(追記) RSAES-
OAEP-ENCRYPT.
(追記ここまで)
The
(削除) encoding
octet
string
is
(削除ここまで)
(追記) http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
identifier
defines
(追記ここまで)
the
(削除) base64
decoding
(削除ここまで)
(追記) mask
generation
function
as
the
fixed
value
(追記ここまで)
of
(追記) MGF1
with
SHA1
(追記ここまで).(追記)
In
this
case
(追記ここまで)
the
(削除) content
(削除ここまで)
(追記) optional
(追記ここまで)(追記)
xenc11:MGF
(追記ここまで)(追記)
element
(追記ここまで)
of
(削除) an
(削除ここまで)
(追記) the
(追記ここまで)(追記)
xenc:EncryptionMethod
(追記ここまで)(追記)
element
(追記ここまで)(追記)
must
not
(追記ここまで)(追記)
be
provided.
(追記ここまで)
(追記)
The
http://www.w3.org/2009/xmlenc11#rsa-oaep
identifier
defines
the
mask
generation
function
using
the
(追記ここまで)
optional
(削除) OAEPparams
(削除ここまで)
(追記) xenc11:MGF
(追記ここまで)
(削除) child
(削除ここまで)
element
(削除) .
(削除ここまで)
(追記) of
the
(追記ここまで)(追記)
xenc:EncryptionMethod
(追記ここまで)(追記)
element.
(追記ここまで)
If
(削除) no
(削除ここまで)
(追記) not
present,
the
default
of
(追記ここまで)
(追記)
is
to
be
used.
(追記ここまで)(削除) OAEPparams
(削除ここまで)
(追記) MGF1
with
SHA1
(追記ここまで)
(追記) The following URIs define the various mask generation function URI values that may be used. These correspond to the object identifiers defined in RFC 4055 [ (追記ここまで)(追記) RFC4055 (追記ここまで) (追記) ]: (追記ここまで)
(追記) Otherwise the two identifiers define the same usage of the RSA-OAEP algorithm, as follows. (追記ここまで)
(追記)
The
message
digest
function
(追記ここまで)(追記)
should
(追記ここまで)(追記)
be
specified
using
the
Algorithm
attribute
of
the
(追記ここまで)(追記)
ds:DigestMethod
(追記ここまで)
child
(追記) element
of
the
(追記ここまで)(追記)
xenc:EncryptionMethod
(追記ここまで)(追記)
element.
If
it
(追記ここまで)
is
(削除) provided,
a
null
string
(削除ここまで)
(追記) not
specified,
the
default
value
of
(追記ここまで)(追記)
SHA1
(追記ここまで)
is
(追記) to
be
(追記ここまで)
used.
(追記) The
optional
RSA-OAEP
(追記ここまで)(追記)
PSourceAlgorithm
(追記ここまで)(追記)
parameter
value
(追記ここまで)(追記)
may
(追記ここまで)(追記)
be
explicitly
provided
by
placing
the
base64
encoded
octets
in
the
(追記ここまで)(追記)
xenc:OAEPparams
(追記ここまで)(追記)
XML
element.
(追記ここまで)
(追記)
The
XML
Encryption
1.0
schema
definition
and
description
for
the
(追記ここまで)(追記)
EncryptionMethod
(追記ここまで)(追記)
element
is
in
(追記ここまで)(追記)
section
3.2
The
EncryptionMethod
Element
(追記ここまで).(追記)
The
following
shows
the
XML
Encryption
1.1
addition
for
the
MGF
type:
(追記ここまで)
An example of an RSA-OAEP element is:
<EncryptionMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"><OAEPparams>9lWu3Q==</OAEPparams><ds:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <EncryptionMethod>
(追記) Another example is: (追記ここまで)
The
CipherValue
for
an
RSA-OAEP
encrypted
key
is
the
base64
[
(削除) MIME
(削除ここまで)
(追記) RFC2045
(追記ここまで)
]
encoding
of
the
octet
string
computed
as
per
RFC
(削除) 2437
(削除ここまで)
(追記) 3447
(追記ここまで)
[
PKCS1
(削除) ,
(削除ここまで)
(追記) ],
(追記ここまで)
section
7.1.1:
Encryption
(削除) operation].
(削除ここまで)
(追記) operation.
(追記ここまで)
As
described
in
the
EME-OAEP-ENCODE
function
RFC
(削除) 2437
(削除ここまで)
(追記) 3447
(追記ここまで)
[
PKCS1
(削除) ,
(削除ここまで)
(追記) ],
(追記ここまで)
section
(削除) 9.1.1.1],
(削除ここまで)
(追記) 7.1.1,
(追記ここまで)
the
value
input
to
the
key
transport
function
is
calculated
using
the
message
digest
function
and
string
specified
in
the
DigestMethod
and
OAEPparams
elements
and
using
(追記) either
(追記ここまで)
the
mask
generator
function
(追記) specified
with
the
(追記ここまで)(追記)
xenc11:MGF
(追記ここまで)(追記)
element
or
the
default
(追記ここまで)
MGF1
specified
in
RFC
(削除) (with
SHA1)
(削除ここまで)
(追記) with
SHA1
(追記ここまで)(削除) 2437.
(削除ここまで)
(追記) 3447.
(追記ここまで)
The
desired
output
length
for
EME-OAEP-ENCODE
is
one
byte
shorter
than
the
RSA
modulus.
The
transported
key
size
is
192
bits
for
TRIPLEDES
and
128,
192,
or
256
bits
for
AES.
Implementations
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
implement
RSA-OAEP
for
the
transport
of
(削除) 128
(削除ここまで)
(追記) all
key
types
(追記ここまで)
and
(削除) 256
bit
keys.
(削除ここまで)
(追記) sizes
that
are
mandatory
to
implement
for
symmetric
encryption.
(追記ここまで)
They
(削除) MAY
(削除ここまで)
(追記) may
(追記ここまで)
implement
RSA-OAEP
for
the
transport
of
other
keys.
A
Key
Agreement
algorithm
provides
for
the
derivation
of
a
shared
secret
key
based
on
a
shared
secret
computed
from
certain
types
of
compatible
public
keys
from
both
the
sender
and
the
recipient.
Information
from
the
originator
to
determine
the
secret
is
indicated
by
an
optional
OriginatorKeyInfo
parameter
child
of
an
AgreementMethod
element
while
that
associated
with
the
recipient
is
indicated
by
an
optional
RecipientKeyInfo
.
A
shared
key
is
derived
from
this
shared
secret
by
a
method
determined
by
the
Key
Agreement
algorithm.
Note:
XML
Encryption
does
not
provide
an
(削除) on-line
(削除ここまで)
(追記) online
(追記ここまで)
key
agreement
negotiation
protocol.
The
AgreementMethod
element
can
be
used
by
the
originator
to
identify
the
keys
and
computational
procedure
that
were
used
to
obtain
a
shared
encryption
key.
The
method
used
to
obtain
or
select
the
keys
or
algorithm
used
for
the
agreement
computation
is
beyond
the
scope
of
this
specification.
The
AgreementMethod
element
appears
as
the
content
of
a
ds:KeyInfo
since,
like
other
ds:KeyInfo
children,
it
yields
a
key.
This
ds:KeyInfo
is
in
turn
a
child
of
an
EncryptedData
or
EncryptedKey
element.
The
Algorithm
attribute
and
KeySize
child
of
the
EncryptionMethod
element
under
this
EncryptedData
or
EncryptedKey
element
are
implicit
parameters
to
the
key
agreement
computation.
In
cases
where
this
EncryptionMethod
algorithm
URI
is
insufficient
to
determine
the
key
length,
a
KeySize
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
have
been
included.
(追記) Key
derivation
algorithms
(with
associated
parameters)
may
be
explicitly
declared
by
using
the
(追記ここまで)(追記)
xenc11:KeyDerivationMethod
(追記ここまで)(追記)
element.
This
element
will
then
be
placed
at
the
extensibility
point
of
the
(追記ここまで)(追記)
xenc:AgreementMethodType
(追記ここまで)(追記)
(see
below).
(追記ここまで)
In
addition,
the
sender
may
place
a
KA-Nonce
element
under
AgreementMethod
to
assure
that
different
keying
material
is
generated
even
for
repeated
agreements
using
the
same
sender
and
recipient
public
keys.
For
example:
If
the
agreed
key
is
being
used
to
wrap
a
key,
rather
than
data
as
above,
then
AgreementMethod
would
appear
inside
a
ds:KeyInfo
inside
an
EncryptedKey
element.
The
Schema
for
AgreementMethod
is
as
follows:
Diffie-Hellman
keys
can
appear
directly
within
KeyValue
elements
or
be
obtained
by
ds:RetrievalMethod
fetches
as
well
as
appearing
in
certificates
and
the
like.
The
above
identifier
can
be
used
as
the
value
of
the
Type
attribute
of
Reference
or
ds:RetrievalMethod
elements.
As
specified
in
[
ESDH
],
a
DH
public
key
consists
of
up
to
six
quantities,
two
large
primes
p
and
q,
a
"generator"
g,
the
public
key,
and
validation
parameters
"seed"
and
"pgenCounter".
These
relate
as
follows:
The
public
key
=
(
g**x
mod
p
)
where
x
is
the
corresponding
private
key;
p
=
j*q
+
1
where
j
>=
2.
"seed"
and
"pgenCounter"
are
optional
and
can
be
used
to
determine
if
the
Diffie-Hellman
key
has
been
generated
in
conformance
with
the
algorithm
specified
in
[
ESDH
].
Because
the
primes
and
generator
can
be
safely
shared
over
many
DH
keys,
they
may
be
known
from
the
application
environment
and
are
optional.
The
schema
for
a
DHKeyValue
is
as
follows:
The
Diffie-Hellman
(DH)
key
agreement
protocol
[
ESDH
]
involves
the
derivation
of
shared
secret
information
based
on
compatible
DH
keys
from
the
sender
and
recipient.
Two
DH
public
keys
are
compatible
if
they
have
the
same
prime
and
generator.
If,
for
the
second
one,
Y
=
g**y
mod
p
,
then
the
two
parties
can
calculate
the
shared
secret
ZZ
=
(
g**(x*y)
mod
p
)
even
though
each
knows
only
their
own
private
key
and
the
other
party's
public
key.
Leading
zero
bytes
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
be
maintained
in
ZZ
so
it
will
be
the
same
length,
in
bytes,
as
p
.
The
size
of
p
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
be
at
least
512
bits
and
g
at
least
160
bits.
There
are
numerous
other
complex
security
considerations
in
the
selection
of
g
,
p
,
and
a
random
x
as
described
in
[
ESDH
].
(追記) The
Diffie-Hellman
shared
secret
(追記ここまで)(追記)
zz
(追記ここまで)(追記)
is
used
as
the
input
to
a
KDF
to
produce
a
secret
key.
XML
Signature
1.0
defined
a
specific
KDF
to
be
used
with
Diffie-Hellman;
that
KDF
is
now
known
as
the
"Legacy
KDF"
and
is
defined
in
Section
5.6.2.2.
Use
of
Diffie-Hellman
with
explicit
KDFs
is
described
in
Section
5.6.2.1.
(追記ここまで)
(追記)
Implementation
of
(追記ここまで)
Diffie-Hellman
key
agreement
is
optional
(削除) to
implement.
(削除ここまで)
.
(追記) However,
if
implemented,
such
implementations
(追記ここまで)(追記)
must
(追記ここまで)(追記)
support
the
Legacy
Key
Derivation
Function
and
(追記ここまで)(追記)
should
(追記ここまで)(追記)
support
Diffie-Hellman
with
explicit
Key
Derivation
Functions
(追記ここまで)
An
example
of
a
DH
AgreementMethod
element
(追記) using
the
Legacy
Key
Derivation
Function
(Section
5.6.2.2)
(追記ここまで)
is
as
follows:
(追記) It is (追記ここまで)(追記) recommended (追記ここまで)(追記) that the shared key material for a Diffie-Hellman key agreement be calculated from the Diffie-Hellman shared secret using a key derivation function (KDF) in accordance with (追記ここまで)(追記) Section 5.4 (追記ここまで).
(追記)
An
example
of
a
DH
(追記ここまで)(追記)
AgreementMethod
(追記ここまで)(追記)
element
using
an
explicit
key
derivation
function
is
as
follows:
(追記ここまで)
(追記) XML Signature 1.0 defined a specific KDF for use with Diffie-Hellman key agreement. In order to guarantee interoperability, implementations that choose to implement Diffie-Hellman (追記ここまで)(追記) must (追記ここまで)(追記) support the use of the Diffie-Hellman Legacy KDF defined in this section. (追記ここまで)
Assume
(追記) that
(追記ここまで)
the
Diffie-Hellman
shared
secret
is
the
octet
sequence
ZZ
.
The
(追記) Diffie-Hellman
Legacy
KDF
calculates
the
(追記ここまで)
shared
keying
material
(削除) needed
will
then
be
calculated
(削除ここまで)
as
follows:
Keying Material =(削除) KM(1) (削除ここまで)(追記) KM (追記ここまで)(追記) ( (追記ここまで)(追記) 1 (追記ここまで)(追記) ) (追記ここまで) |(削除) KM(2) (削除ここまで)(追記) KM (追記ここまで)(追記) ( (追記ここまで)(追記) 2 (追記ここまで)(追記) ) (追記ここまで) |(削除) ... (削除ここまで)...
where "|" is byte stream concatenation and
KM(counter)=DigestAlg( ZZ | counter |EncryptionAlg| (追記) KA (追記ここまで)(追記) - (追記ここまで)(追記) Nonce (追記ここまで) | KeySize )
DigestAlg
DigestMethod
child
of
AgreementMethod
.
EncryptionAlg
Algorithm
attribute
of
the
EncryptionMethod
child
of
the
EncryptedData
or
EncryptedKey
grandparent
of
AgreementMethod
.
KA-Nonce
KA-Nonce
child
of
AgreementMethod
,
if
present.
If
the
KA-Nonce
element
is
absent,
it
is
null.
Counter
KeySize
For
example,
the
initial
(KM(1))
calculation
for
the
EncryptionMethod
of
the
Key
Agreement
example
(section
5.5)
would
be
as
follows,
where
the
binary
one
byte
counter
value
of
1
is
represented
by
the
two
character
UTF-8
sequence
01
,
ZZ
is
the
shared
secret,
and
"
foo
"
is
the
base64
decoding
of
"
Zm9v
".
(追記) SHA (追記ここまで)(追記) - (追記ここまで)(追記) 1 (追記ここまで) ((削除) ZZ01Example:Block/Algfoo80 (削除ここまで)(追記) ZZ01Example (追記ここまで):(追記) Block (追記ここまで)(追記) / (追記ここまで)(追記) Algfoo80 (追記ここまで) )
Assuming
that
ZZ
is
0xDEADBEEF
,
that
would
be
(追記) SHA (追記ここまで)(追記) - (追記ここまで)(追記) 1 (追記ここまで)(追記) ( (追記ここまで) 0xDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830 )
whose value is
0x534C9B8C4ABDCB50038B42015A181711068B08C1
Each
application
of
DigestAlg
for
successive
values
of
Counter
will
produce
some
additional
number
of
bytes
of
keying
material.
From
the
concatenated
string
of
one
or
more
KM
's,
enough
leading
bytes
are
taken
to
meet
the
need
for
an
actual
key
and
the
remainder
discarded.
For
example,
if
DigestAlg
is
SHA-1
which
produces
20
octets
of
hash,
then
for
128
bit
AES
the
first
16
bytes
from
KM(1)
would
be
taken
and
the
remaining
4
bytes
discarded.
For
256
bit
AES,
all
of
KM(1)
suffixed
with
the
first
12
bytes
of
KM(2)
would
be
taken
and
the
remaining
8
bytes
of
KM(2)
discarded.
(追記)
ECDH
has
identical
public
key
parameters
as
ECDSA
and
can
be
represented
with
the
(追記ここまで)(追記)
ECKeyValue
(追記ここまで)(追記)
element
[
(追記ここまで)(追記)
XMLDSIG-CORE1
(追記ここまで) (追記)
].
Note
that
if
the
curve
parameters
are
explicitly
stated
using
the
ECParameters
element,
then
the
Cofactor
element
(追記ここまで)(追記)
must
(追記ここまで)(追記)
be
included.
(追記ここまで)
(追記)
As
with
Diffie-Hellman
keys,
Elliptic
Curve
Key
Values
can
appear
directly
within
(追記ここまで)(追記)
KeyValue
(追記ここまで)(追記)
elements
or
be
obtained
by
(追記ここまで)(追記)
ds:RetrievalMethod
(追記ここまで)(追記)
fetches
as
well
as
appearing
in
certificates
and
the
like.
The
above
identifier
can
be
used
as
the
value
of
the
(追記ここまで)(追記)
Type
(追記ここまで)(追記)
attribute
of
(追記ここまで)(追記)
Reference
(追記ここまで)(追記)
or
(追記ここまで)(追記)
ds:RetrievalMethod
(追記ここまで)(追記)
elements.
(追記ここまで)
(追記) ECDH is the elliptic curve analogue to the Diffie-Hellman key agreement algorithm. Details of the ECDH primitive can be found in [ (追記ここまで)(追記) ECC-ALGS (追記ここまで) (追記) ]. When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters. (追記ここまで)
(追記) Compliant implementations are (追記ここまで)(追記) required (追記ここまで)(追記) to support ECDH-ES key agreement using the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [ (追記ここまで)(追記) FIPS-186-3 (追記ここまで) (追記) ]. (This is the same curve that is (追記ここまで)(追記) required (追記ここまで)(追記) in XML Signature 1.1 to be supported for the ECDSAwithSHA256 algorithm.) It is further (追記ここまで)(追記) recommended (追記ここまで)(追記) that implementations also support the P-384 and P-521 prime curves for ECDH-ES; these curves are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively. (追記ここまで)
(追記)
The
shared
key
material
is
calculated
from
the
Diffie-Hellman
shared
secret
using
a
key
derivation
function
(KDF).
While
applications
may
define
other
KDFs,
compliant
implementations
(追記ここまで)(追記)
must
(追記ここまで)(追記)
implement
ConcatKDF
(see
(追記ここまで)(追記)
section
5.4.1
ConcatKDF
(追記ここまで) (追記)
).
An
example
of
(追記ここまで)(追記)
xenc:EncryptedData
(追記ここまで)(追記)
using
the
ECDH-ES
key
agreement
algorithm
with
the
ConcatKDF
key
derivation
algorithm
is
as
follows:
(追記ここまで)
Symmetric
Key
Wrap
algorithms
are
shared
secret
key
encryption
algorithms
especially
specified
for
encrypting
and
decrypting
symmetric
keys.
(削除) Their
identifiers
appear
as
Algorithm
attribute
values
to
EncryptionMethod
elements
that
(削除ここまで)
(追記) When
wrapped
keys
(追記ここまで)
are
(削除) children
of
(削除ここまで)
(追記) used,
then
an
(追記ここまで)
EncryptedKey
(削除) which
is
in
turn
(削除ここまで)
(追記) element
will
appear
as
(追記ここまで)
a
child
of
(削除) ds:KeyInfo
which
is
in
turn
(削除ここまで)
a
(削除) child
of
(削除ここまで)
(削除) EncryptedData
(削除ここまで)
(追記) ds:KeyInfo
(追記ここまで)
(削除) or
another
(削除ここまで)
(追記) element.
This
(追記ここまで)
EncryptedKey
(削除) .
The
type
of
the
key
being
wrapped
is
indicated
by
the
Algorithm
(削除ここまで)
(削除) attribute
of
(削除ここまで)
(追記) element
will
have
an
(追記ここまで)
EncryptionMethod
child
(削除) of
the
parent
of
the
ds:KeyInfo
grandparent
of
the
(削除ここまで)
(追記) whose
(追記ここまで)
(削除) EncryptionMethod
(削除ここまで)
(追記) Algorithm
(追記ここまで)
(削除) specifying
(削除ここまで)
(追記) attribute
in
turn
identifies
(追記ここまで)
the
(削除) symmetric
(削除ここまで)
key
wrap
algorithm.
(削除) Some
key
wrap
algorithms
make
use
of
a
key
checksum
as
defined
in
CMS
[
CMS-Wrap
].
(削除ここまで)
The
algorithm
(削除) that
provides
an
integrity
check
value
(削除ここまで)
for
(追記) which
(追記ここまで)
the
(追記) encrypted
(追記ここまで)
key
(削除) being
wrapped
is:
Compute
the
20
octet
SHA-1
hash
(削除ここまで)
(追記) is
intended
depends
(追記ここまで)
on
the
(削除) key
being
wrapped.
Use
the
first
8
octets
(削除ここまで)
(追記) context
(追記ここまで)
of
(削除) this
hash
(削除ここまで)
(追記) the
(追記ここまで)(追記)
ds:KeyInfo
(追記ここまで)(追記)
element:
(追記ここまで)(追記)
ds:KeyInfo
(追記ここまで)(追記)
can
occur
(追記ここまで)
as
(追記) a
child
of
either
an
(追記ここまで)(追記)
EncryptedData
(追記ここまで)(追記)
or
(追記ここまで)(追記)
EncryptedKey
(追記ここまで)(追記)
element;
in
both
cases,
(追記ここまで)(追記)
ds:KeyInfo
(追記ここまで)(追記)
will
have
an
(追記ここまで)(追記)
EncryptionMethod
(追記ここまで)(追記)
sibling
that
identifies
(追記ここまで)
the
(削除) checksum
value.
(削除ここまで)
(追記) algorithm.
(追記ここまで)
XML
Encryption
implementations
(削除) MUST
(削除ここまで)
(追記) must
(追記ここまで)
support
TRIPLEDES
wrapping
of
168
bit
keys
(追記) as
described
in
[
(追記ここまで)(追記)
CMS-WRAP
(追記ここまで) (追記)
]
(追記ここまで)
and
may
optionally
support
TRIPLEDES
wrapping
of
other
keys.
An
example
of
a
TRIPLEDES
Key
Wrap
EncryptionMethod
element
is
as
follows:
Implementation
of
AES
key
wrap
is
described
(削除) below,
as
suggested
by
NIST.
(削除ここまで)
(追記) in
[
(追記ここまで)(追記)
AES-WRAP
(追記ここまで) (追記)
].
(追記ここまで)
It
provides
for
confidentiality
and
integrity.
This
algorithm
is
defined
only
for
inputs
which
are
a
multiple
of
64
bits.
The
information
wrapped
need
not
actually
be
a
key.
The
algorithm
is
the
same
whatever
the
size
of
the
AES
key
used
in
wrapping,
called
the
key
encrypting
key
or
KEK
.
The
implementation
requirements
are
indicated
below.
Message
digest
algorithms
can
be
used
in
AgreementMethod
as
part
of
the
key
derivation,
within
RSA-OAEP
encryption
as
a
hash
function,
and
in
connection
with
the
HMAC
message
authentication
code
method
(追記) [
(追記ここまで)(追記)
HMAC
(追記ここまで) (追記)
]
(追記ここまで)
as
described
in
[
(削除) XML-DSIG
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで)
].)
(追記) Use
of
SHA-256
is
strongly
recommended
over
SHA-1
because
recent
advances
in
cryptanalysis
(see
e.g.
[
(追記ここまで)(追記)
SHA-1-Analysis
(追記ここまで) (追記)
],
[
(追記ここまで)(追記)
SHA-1-Collisions
(追記ここまで) (追記)
]
)
have
cast
doubt
on
the
long-term
collision
resistance
of
SHA-1.
Therefore,
SHA-1
support
is
(追記ここまで)(追記)
required
(追記ここまで)(追記)
in
this
specification
only
for
backwards-compatibility
reasons.
(追記ここまで)
The
SHA-1
algorithm
[
(削除) SHA
(削除ここまで)
(追記) FIPS-180-3
(追記ここまで)
]
takes
no
explicit
parameters.
An
example
of
an
SHA-1
DigestMethod
element
is:
A
SHA-1
digest
is
a
160-bit
string.
The
content
of
the
DigestValue
element
shall
be
the
base64
encoding
of
this
bit
string
viewed
as
a
20-octet
octet
stream.
For
example,
the
DigestValue
element
for
the
message
digest:
A9993E36
4706816A
BA3E2571
7850C26C
9CD0D89D
from Appendix A of the SHA-1 standard would be:
The
SHA-256
algorithm
[
(削除) SHA
(削除ここまで)
(追記) FIPS-180-3
(追記ここまで)
]
takes
no
explicit
parameters.
An
example
of
an
SHA-256
DigestMethod
element
is:
A
SHA-256
digest
is
a
256-bit
string.
The
content
of
the
DigestValue
element
shall
be
the
base64
encoding
of
this
bit
string
viewed
as
a
32-octet
octet
stream.
The
(削除) SHA-512
(削除ここまで)
(追記) SHA-384
(追記ここまで)
algorithm
[
(削除) SHA
(削除ここまで)
(追記) FIPS-180-3
(追記ここまで)
]
takes
no
explicit
parameters.
An
example
of
an
(削除) SHA-512
(削除ここまで)
(追記) SHA-384
(追記ここまで)
DigestMethod
element
is:
A
(削除) SHA-512
(削除ここまで)
(追記) SHA-384
(追記ここまで)
digest
is
a
(削除) 512-bit
(削除ここまで)
(追記) 384-bit
(追記ここまで)
string.
The
content
of
the
DigestValue
element
shall
be
the
base64
encoding
of
this
bit
string
viewed
as
a
(削除) 64-octet
(削除ここまで)
(追記) 48-octet
(追記ここまで)
octet
stream.
The
(削除) RIPEMD-160
(削除ここまで)
(追記) SHA-512
(追記ここまで)
algorithm
[
(削除) RIPEMD-160
(削除ここまで)
(追記) FIPS-180-3
(追記ここまで)
]
takes
no
explicit
parameters.
An
example
of
an
(削除) RIPEMD-160
(削除ここまで)
(追記) SHA-512
(追記ここまで)
DigestMethod
element
is:
A
(削除) RIPEMD-160
(削除ここまで)
(追記) SHA-512
(追記ここまで)
digest
is
a
(削除) 160-bit
(削除ここまで)
(追記) 512-bit
(追記ここまで)
string.
The
content
of
the
DigestValue
element
shall
be
the
base64
encoding
of
this
bit
string
viewed
as
a
(削除) 20-octet
(削除ここまで)
(追記) 64-octet
(追記ここまで)
octet
stream.
(削除) XML
Signature
(削除ここまで)
(追記) The
RIPEMD-160
algorithm
(追記ここまで)
[
(削除) XML-DSIG
(削除ここまで)
(追記) RIPEMD-160
(追記ここまで)
]
(追記) takes
no
explicit
parameters.
An
example
of
an
RIPEMD-160
(追記ここまで)(追記)
DigestMethod
(追記ここまで)(追記)
element
is:
(追記ここまで)
(追記)
A
RIPEMD-160
digest
(追記ここまで)
is
(削除) OPTIONAL
to
implement
for
XML
encryption
applications.
It
is
(削除ここまで)
(追記) a
160-bit
string.
The
content
of
(追記ここまで)
the
(削除) recommended
way
to
provide
key
based
authentication.
(削除ここまで)
(追記) DigestValue
(追記ここまで)(追記)
element
shall
be
the
base64
encoding
of
this
bit
string
viewed
as
a
20-octet
octet
stream.
(追記ここまで)
A Canonicalization of XML is a method of consistently serializing XML into an octet stream as is necessary prior to encrypting XML.
Canonical
XML
[
(削除) Canon
(削除ここまで)
(追記) XML-C14N11
(追記ここまで)
]
is
a
method
of
serializing
XML
which
includes
the
in
scope
namespace
and
xml
namespace
attribute
context
from
ancestors
of
the
XML
being
serialized.
If XML is to be encrypted and then later decrypted into a different environment and it is desired to preserve namespace prefix bindings and the value of attributes in the "xml" namespace of its original environment, then the canonical XML with comments version of the XML should be the serialization that is encrypted.
Exclusive
XML
Canonicalization
[
(削除) Exclusive
(削除ここまで)
(追記) XML-EXC-C14N
(追記ここまで)
]
serializes
XML
in
such
a
way
as
to
include
to
the
minimum
extent
practical
the
namespace
prefix
binding
and
xml
namespace
attribute
context
inherited
from
ancestor
elements.
It is the recommended method where the outer context of a fragment which was signed and then encrypted may be changed. Otherwise the validation of the signature over the fragment may fail because the canonicalization by signature validation may include unnecessary namespaces into the fragment.
(追記) A number of chosen-ciphertext attacks against implementations of this specification have been published and demonstrated. They all involve the following elements: (追記ここまで)
(追記) The attacker uses the knowledge of the format and the information about well-formedness to construct a series of ciphertext guesses which reveal the plaintext with much less work than brute force. Attacks of this type have been demonstrated against symmetric encryption using CBC mode [ (追記ここまで)(追記) XMLENC-CBC-ATTACK (追記ここまで) (追記) ][ (追記ここまで)(追記) XMLENC-CBC-ATTACK-COUNTERMEASURES (追記ここまで) (追記) ] and on PKCS#1 v1.5. Other future attacks can be expected whenever these conditions are met. (追記ここまで)
(追記)
<EncryptedData>
(追記ここまで)(追記)
part)
(追記ここまで)(追記)
Using
the
CBC-based
chosen-ciphertext
attacks,
the
attacker
sends
to
the
server
an
XML
document
with
modified
encrypted
data
in
the
symmetric
part
(
(追記ここまで)(追記)
<EncryptedData>
(追記ここまで)(追記)
).
After
a
few
requests,
the
attacker
is
able
to
get
the
whole
cleartext
without
knowledge
of
the
symmetric
key.
(追記ここまで)
(追記) It would seem that these attacks can be countered by by disrupting any of the conditions, however in practice only preventing condition 3 (sending arbitrary ciphertext) is fully effective. To counter condition 3, it is necessary for the decrypting system to require authenticated integrity protection over the ciphertext. However, unless the mechanism used is bound to the encryption key, there will no way to be sure that the signer is not attempting to recover the plaintext. The simplest and most efficient way to do this is to use an authenticating block mode, such as GCM. An alternative would be an HMAC based on the encryption key over the ciphertext, but it is less efficient and provides no advantages. (追記ここまで)
(追記) Other countermeasures are not likely to be effective. Limiting the number of messages presented or the number of messages using the same key is not practical in large server farms. Attackers can spread their attempts over different servers and long or short periods of time, to foil attempts to detect attacks in progress or determine the location of the attacker. (追記ここまで)
(追記) Signaling well-formedness can occur by emitting different messages for distinct security errors or by exhibiting timing differences. Implementations should avoid these practices, however that is not sufficient to prevent such attacks in an XML protocol environment, such as SOAP. Using a technique called encryption wrapping, the attacker can insert the ciphertext in some schema-legal part of the message. If the decryption code notices a format error, an error will be returned, but if not the message will be passed to the application which will ignore the bogus plaintext and ultimately respond with an application level success or failure message. (追記ここまで)
(追記)
The
goal
of
the
attacker
applying
the
Bleichenbacher's
attack
is
to
get
the
symmetric
secret
key,
which
is
encrypted
in
the
(追記ここまで)(追記)
<EncryptedKey>
(追記ここまで)(追記)
part.
Afterward,
he
would
be
able
to
decrypt
the
whole
data
carried
in
the
(追記ここまで)(追記)
<EncryptedData>
(追記ここまで)(追記)
part.
(追記ここまで)
(追記)
The
basic
idea
of
this
attack
is
to
modify
the
data
in
the
(追記ここまで)(追記)
<EncryptedKey>
(追記ここまで)(追記)
part,
send
the
document
to
the
server,
and
observe
if
the
modified
ciphertext
contains
PKCS#1.5
conformant
data.
This
can
be
done
by:
(追記ここまで)
(追記)
<EncryptedData>
(追記ここまで)(追記)
part
and
observing
the
timing
differences
between
inclusion
of
PKCS-valid
and
PKCS-invalid
keys:
if
the
key
is
PKCS-valid,
the
session
key
is
extracted,
and
the
large
data
is
decrypted.
Otherwise,
the
session
key
cannot
be
extracted
and
the
large
data
is
not
processed,
which
yields
a
timing
difference.
(追記ここまで)(追記)
<EncryptedData>
(追記ここまで)(追記)
part
based
on
CBC
and
padding-properties.
(追記ここまで)(追記) These problems are described in detail in RFC 3218 [ (追記ここまで)(追記) RFC3218 (追記ここまで) (追記) ]. (追記ここまで)
(追記) The most effective countermeasure against the timing attack (2) is to generate a random secret key every time when the decrypted data was not PKCS#1-conformant. This way, the attacker would not get any timing side-channel. (追記ここまで)
(追記)
Please
note
however
that
this
is
not
a
valid
countermeasure
against
the
specific
modification
of
the
(追記ここまで)(追記)
<EncryptedData>
(追記ここまで)(追記)
described
in
part
(3).
The
attacker
could
still
use
a
few
millions
of
requests
to
decrypt
the
encrypted
symmetric
key.
Therefore,
we
recommend
the
usage
of
RSA-OAEP.
RSA-OAEP
also
has
a
risk
of
a
chosen
ciphertext
attack
[
(追記ここまで)(追記)
OAEP-ATTACK
(追記ここまで) (追記)
]
which
can
be
mitigated
in
security
library
implementations.
(追記ここまで)
(追記) Use of state-of-the-art and secure encryption algorithms such as RSA-OAEP and AES-GCM can become insecure when the adversary can force the server to process eavesdropped ciphertext with legacy algorithms such as RSA-PKCS#1 v1.5 or AES-CBC [ (追記ここまで)(追記) XMLENC-BACKWARDS-COMP (追記ここまで) (追記) ]: (追記ここまで)
(追記) Accordingly, in situations where an attacker may be able to mount chosen-ciphertext attacks, we recommend the following to implementers: (追記ここまで)
The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature verification difficult. In particular, when verifying a signature one must know whether the signature was computed over the encrypted or unencrypted form of elements.
A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a common XML element. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may allow plaintext guessing attacks. This vulnerability can be mitigated by using secure hashes and the nonces in the text being processed.
In
accordance
with
the
requirements
document
[
(削除) EncReq
(削除ここまで)
(追記) XML-ENCRYPTION-REQ
(追記ここまで)
]
the
interaction
of
encryption
and
signing
is
an
application
issue
and
out
of
scope
of
the
specification.
However,
we
make
the
following
recommendations:
When data is encrypted, any digest or signature over that data should be encrypted. This satisfies the first issue in that only those signatures that can be seen can be validated. It also addresses the possibility of a plaintext guessing vulnerability, though it may not be possible to identify (or even know of) all the signatures over a given piece of data.
Employ
the
"decrypt-except"
signature
transform
[
(削除) XML-DSIG-Decrypt]
.
(削除ここまで)
(追記) XMLENC-DECRYPT
(追記ここまで) (追記)
].
(追記ここまで)
It
works
as
follows:
during
signature
transform
processing,
if
you
encounter
a
decrypt
transform,
decrypt
all
encrypted
content
in
the
document
except
for
those
excepted
by
an
enumerated
set
of
references.
Additionally, while the following warnings pertain to incorrect inferences by the user about the authenticity of information encrypted, applications should discourage user misapprehension by communicating clearly which information has integrity, or is authenticated, confidential, or non-repudiable when multiple processes (e.g., signature and encryption) and algorithms (e.g., symmetric and asymmetric) are used:
When
an
encrypted
envelope
contains
a
signature,
the
signature
does
not
necessarily
protect
the
authenticity
or
integrity
of
the
ciphertext
[
Davis
(削除) ]
.
(削除ここまで)
(追記) ].
(追記ここまで)
While
the
signature
secures
plaintext
it
only
covers
that
which
is
signed,
recipients
of
encrypted
messages
must
not
infer
integrity
or
authenticity
of
other
unsigned
information
(e.g.,
headers)
within
the
encrypted
envelope,
see
[
(削除) XML-DSIG
,
(削除ここまで)
(追記) XMLDSIG-CORE1
(追記ここまで) (追記)
],
(追記ここまで)
(追記) section
(追記ここまで)
8.1.1
Only
What
is
Signed
is
Secure
].
Where a symmetric key is shared amongst multiple recipients, that symmetric key should only be used for the data intended for all recipients; even if one recipient is not directed to information intended (exclusively) for another in the same symmetric key, the information might be discovered and decrypted.
Additionally, application designers should be careful not to reveal any information in parameters or algorithm identifiers (e.g., information in a URI) that weakens the encryption.
An
undesirable
characteristic
of
many
encryption
algorithms
and/or
their
modes
is
that
the
same
plaintext
when
encrypted
with
the
same
key
has
the
same
resulting
ciphertext.
While
this
is
unsurprising,
it
invites
various
attacks
which
are
mitigated
by
including
an
arbitrary
and
non-repeating
(under
a
given
key)
data
with
the
plaintext
prior
to
encryption.
In
encryption
chaining
modes
this
data
is
the
first
to
be
encrypted
and
is
consequently
called
the
IV
(削除) (initalization
(削除ここまで)
(追記) (initialization
(追記ここまで)
value
or
vector).
Different
algorithms
and
modes
have
further
requirements
on
the
characteristic
of
this
information
(e.g.,
randomness
and
secrecy)
that
affect
the
features
(e.g.,
confidentiality
and
integrity)
and
their
(削除) resistence
(削除ここまで)
(追記) resistance
(追記ここまで)
to
attack.
Given that XML data is redundant (e.g., Unicode encodings and repeated tags ) and that attackers may know the data's structure (e.g., DTDs and schemas) encryption algorithms must be carefully implemented and used in this regard.
For the Cipher Block Chaining (CBC) mode used by this specification, the IV must not be reused for any key and should be random, but it need not be secret. Additionally, under this mode an adversary modifying the IV can make a known change in the plain text after decryption. This attack can be avoided by securing the integrity of the plain text data, for example by signing it.
(追記) Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks. (追記ここまで)
(追記) For the Galois/Counter Mode (GCM) used by this specification, the IV must not be reused for any key and should be random, but it need not be secret. (追記ここまで)
This
specification
permits
recursive
processing.
For
example,
the
following
scenario
is
possible:
EncryptedKey
A
requires
EncryptedKey
B
to
be
decrypted,
which
itself
requires
EncryptedKey
A
!
Or,
an
attacker
might
submit
an
EncryptedData
for
decryption
that
references
network
resources
that
are
very
large
or
continually
redirected.
Consequently,
implementations
should
be
able
to
restrict
arbitrary
recursion
and
the
total
amount
of
processing
and
networking
resources
a
request
can
consume.
XML Encryption can be used to obscure, via encryption, content that applications (e.g., firewalls, virus detectors, etc.) consider unsafe (e.g., executable code, viruses, etc.). Consequently, such applications must consider encrypted content to be as unsafe as the unsafest content transported in its application context. Consequently, such applications may choose to (1) disallow such content, (2) require access to the decrypted form for inspection, or (3) ensure that arbitrary content can be safely processed by receiving applications.
(追記) Implementations (追記ここまで)(追記) should not (追記ここまで)(追記) provide detailed error responses related to security algorithm processing. Error messages should be limited to a generic error message to avoid providing information to a potential attacker related to the specifics of the algorithm implementation. For example, if an error occurs in decryption processing the error response should be a generic message providing no specifics on the details of the processing error. (追記ここまで)
(追記) It has been known for some time that it is feasible for an attacker to recover keys or cleartext by repeatedly sending chosen ciphertext and measuring the time required to process different requests with different types of errors. It has been demonstrated that attacks of this type are practical even when communicating over large and busy networks, especially if the receiver is willing to process large numbers of ciphertext blocks. (追記ここまで)
(追記) Implementers (追記ここまで)(追記) should (追記ここまで)(追記) ensure that distinct errors detected during security algorithm processing do not consume systematically different amounts of processing time from each other. Implementers (追記ここまで)(追記) should (追記ここまで)(追記) consult the technical literature for more details on specific attacks and recommended countermeasures. (追記ここまで)
(追記) Deployments (追記ここまで)(追記) should (追記ここまで)(追記) treat as suspect inputs when a large number of security algorithm processing errors are detected within a short period of time, especially in messages from the same origin. (追記ここまで)
(追記) Note (追記ここまで):(追記) CBC block encryption algorithms should not be used without consideration of (追記ここまで)(追記) possibly severe security risks (追記ここまで).
An
implementation
is
conformant
to
this
specification
if
it
successfully
generates
syntax
according
to
the
schema
definitions
and
satisfies
all
(削除) MUST/REQUIRED/SHALL
(削除ここまで)
(追記) must
(追記ここまで)(追記)
/
(追記ここまで)(追記)
required
(追記ここまで)(追記)
/
(追記ここまで)(追記)
shall
(追記ここまで)
requirements,
including
algorithm
support
and
processing
.
Processing
requirements
are
specified
over
the
roles
of
decryptor
,
encryptor
,
and
their
calling
application
.
XML
Encryption
Syntax
and
Processing
(削除) [
XML-Encryption
]
(削除ここまで)
(追記) (XMLENC-CORE1,
this
document)
(追記ここまで)
specifies
a
process
for
encrypting
data
and
representing
the
result
in
XML.
The
data
may
be
arbitrary
data
(including
an
XML
document),
an
XML
element,
or
XML
element
content.
The
result
of
encrypting
data
is
an
XML
Encryption
element
which
contains
or
references
the
cipher
data.
The
application/xenc+xml
media
type
allows
XML
Encryption
applications
to
identify
encrypted
documents.
Additionally
it
allows
applications
cognizant
of
this
media-type
(even
if
they
are
not
XML
Encryption
implementations)
to
note
that
the
media
type
of
the
decrypted
(original)
object
might
be
a
type
other
than
XML.
This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [ MIME-REG ]
(削除) MIME
media
type
(削除ここまで)
(追記) Type
(追記ここまで)
name:
application
(削除) MIME
subtype
(削除ここまで)
(追記) Subtype
(追記ここまで)
name:
xenc+xml
Required parameters: none
Optional parameters: charset
The allowable and recommended values for, and interpretation of the charset parameter are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [ XML-MT ].
Encoding considerations:
The encoding considerations are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [ XML-MT ].
Security considerations:
See the(削除) [ XML-Encryption ] (削除ここまで)(追記) (XMLENC-CORE1, this document) (追記ここまで) Security Considerations section.
Interoperability considerations: none
Published
specification:
(削除) [
XML-Encryption
]
(削除ここまで)
(追記) (XMLENC-CORE1,
this
document)
(追記ここまで)
Applications which use this media type:
XML Encryption is device-, platform-, and vendor-neutral and is supported by a range of Web applications.
Additional Information:
Magic number(s): none
Although no byte sequences can be counted on to consistently identify XML Encryption documents,(削除) they (削除ここまで)(追記) there (追記ここまで) will be XML documents in which the root element'sQName'sLocalPartis'EncryptedData'or 'EncryptedKey' with an associated namespace name of ' http://www.w3.org/2001/04/xmlenc# '. Theapplication/xenc+xmltype name(削除) MUST (削除ここまで)(追記) must (追記ここまで) only be used for data objects in which the root element is from the XML Encryption namespace. XML documents which contain these element types in places other than the root element can be described using facilities such as [(削除) XML-schema (削除ここまで)(追記) XMLSCHEMA-1 (追記ここまで) (追記) ], [ (追記ここまで)(追記) XMLSCHEMA-2 (追記ここまで) ].File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information:
(削除) Joseph Reagle <reagle@w3.org> XENC Working Group <xml-encryption@w3.org> (削除ここまで)(追記) World Wide Web Consortium <web-human at w3.org> (追記ここまで)
Intended usage: COMMON
Author/Change controller:
The
XML
Encryption
specification
is
a
work
product
of
the
World
Wide
Web
Consortium
(削除) (W3C)
(削除ここまで)
(追記) (
(追記ここまで)(追記)
W3C
(追記ここまで)(追記)
)
(追記ここまで)
which
has
change
control
over
the
specification.
(追記) This section is non-normative. (追記ここまで)
(追記) Non-normative RELAX NG schema [ (追記ここまで)(追記) RELAXNG-SCHEMA (追記ここまで) (追記) ] information is available in a separate document [ (追記ここまで)(追記) XMLSEC-RELAXNG (追記ここまで) (追記) ]. (追記ここまで)
(追記) This informative section outlines the definition and reserves identifiers for algorithms that have no requirements for implementation and have not been tested for interoperability. (追記ここまで)
(追記) This section is non-normative. (追記ここまで)
(追記) These identifiers are reserved for symmetric key wrapping using the (追記ここまで) AES (追記) key wrap with padding algorithm with a 128, 192, and 256 bit AES key encrypting key, respectively. Implementation of AES key wrap with padding is defined in [ (追記ここまで)(追記) AES-WRAP-PAD (追記ここまで) (追記) ]. The algorithm is defined for inputs between 9 and 2^32 octets. Unlike the unpadded AES Key Wrap algorithm, the input length is not constrained to multiples of 64 bits (8 octets). (追記ここまで)
(追記) Note that the wrapped key will be distinct from the one generated by the unpadded AES Key Wrap algorithm, even if the input length is a multiple of 64 bits. (追記ここまで)
(追記) Dated references below are to the latest known or appropriate edition of the referenced work. The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which editions are supported. (追記ここまで)