<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 9/24/14 10:28 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:D048F0A7.1132F%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 9/24/14, 8:36 PM, "Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:putmanb@georgetown.edu"><putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
In v2, on encryption we always add an explicit ds:DigestMethod with SHA-1
</pre>
</blockquote>
<pre wrap="">
No, especially if we're already doing that, I wouldn't want to try and
figure out what breaks if we remove it. I vaguely recall there being a
bug, yes.</pre>
</blockquote>
<br>
Good, I'll leave it.<br>
<br>
<blockquote cite="mid:D048F0A7.1132F%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Now with the new Encryption 1.1 variant, I was looking at what to do with
xenc11:MGF re: always expressing it explicitly (or not) if it's the SHA-1
default. Do you have any opinions?
</pre>
</blockquote>
<pre wrap="">
IIRC, that only applies when the algorithm is explicitly the 1.1 OAEP
variant? </pre>
</blockquote>
<br>
Yes the old one fixes the MGF:<br>
<br>
<blockquote type="cite">The
<a class="moz-txt-link-freetext" href="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</a> identifier defines
the mask generation function as the fixed value of <code>MGF1
with SHA1</code>. In this case the optional <code>xenc11:MGF</code>
element of the <code>xenc:EncryptionMethod</code> element <em
class="rfc2119" title="MUST NOT">MUST NOT</em> be provided. </blockquote>
<br>
I just checked Santuario's impl of the MUST NOT and they have a bug
there. If you pass a non-null MGF URI to XMLCipher, it winds up in
the XML. Our Encrypter isn't affected, since I don't pass a
non-null value unless it's the 1.1 algorithm.<br>
<br>
(They also have another minor bug in that they emit an empty
<xenc:OAEPparams></xenc:OAEPparams> if a non-null but
empty OAEPparams byte[] is passed. This is a more minor nit and our
Encrypter isn't affected b/c I similarly compute the effective value
and return null appropriately. )<br>
<br>
I was going to open issues for both, but the don't affect us per se.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<br>
<br>
<blockquote cite="mid:D048F0A7.1132F%25cantor.2@osu.edu" type="cite">
<pre wrap="">In which case it won't really break any old code, so I would say
just express it, that's just clearer/simpler.</pre>
</blockquote>
<br>
I agree, I think explicit is better.<br>
<br>
<br>
<blockquote cite="mid:D048F0A7.1132F%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">In particular, I was wondering what the current state of Santuario C++
and the SP is wrt the 1.1 variant. I'm assuming it fundamentally
supports this key transport at some level. Does it support MGF's other
than the default MGF-1 w/ SHA-1?
</pre>
</blockquote>
<pre wrap="">
The comment in the code is outdated, but eyeballing it appears to support
all the SHA-2 variants as both DigestMethod and MGF digest, as long as
OpenSSL has the SHA-2 support. I doubt I tested it much other than against
any test vectors I scrounged up.</pre>
</blockquote>
<br>
Ok, thanks, good to know.<br>
<br>
<br>
<blockquote cite="mid:D048F0A7.1132F%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I would be pleasantly surprised if GCM or OAEP 1.1 were supported, but I
don't know.
</pre>
</blockquote>
<br>
<br>
Yeah. Remember however that plain Oracle Java 7 doesn't support
those either. And on Java 7 Santuario won't support the old OAEP
1.0 with any digest other than SHA-1. Either you have to add BC as
a provider, or else switch to Java 8. (This has sort of made unit
testing some of this kind of "fun").<br>
<br>
<br>
</body>
</html>