[sidr] RFC 6485 is inconsistent with base CMS specifications

[Rob Austein <[e-mail]>]

Section 2 of RFC 6485 says that the OID in the CMS signatureAlgorithm
field MUST be sha256WithRSAEncryption.  This turns out not to be
consistent either with the base CMS specifications or, more
importantly, with the running code in the existing RPKI
implementations.

For those not familiar with the details of CMS: the SignerInfo
structure includes separate fields indicating the digest and signature
algorithms (digestAlgorithm and signatureAlgorithm, respectively).
RFC 2630 12.2.2 specified that the signatureAlgorithm should be
rsaEncryption when using RSA.

RFC 3370 3.2 added the option of using OIDs like
sha256WithRSAEncryption which indicate both digest and signature
algorithm in a single OID, but maintained the requirement that CMS
implementations which include RSA MUST support the rsaEncryption value
of signatureAlgorithm.  RFCs 4055 and 5754 define OIDs for SHA-2
(including SHA-256) and specify how to use them in CMS, but do not
relax the MUST requirement for rsaEncryption.  Furthermore, RFC 5754
3.2 explicitly refers back to RFC 3370 3.2.

So the requirement to support rsaEncryption is consistent throughout
the CMS specifications.  Given this history, it should not be a
surprise that existing CMS implementations such as OpenSSL and
BouncyCastle just use rsaEncryption; it's the only
mandatory-to-implement value for this field when using RSA, thus is
the obvious choice for a signer whose author wants to maximize the
chance that relying parties will be able to verify the message.

Unfortunately, RFC 6485 says that only sha256WithRSAEncryption is
allowed, so any CMS signer which takes the conservative approach
suggested above will be in violation of RFC 6485.  It turns out that
all of the current RPKI CA engines of which I am aware (APNIC's,
RIPE's, and mine) use CMS engines which do the conservative thing,
thus are in violation of this portion of RFC 6485.  I do not believe
that this is what the SIDR WG intended, but that, of course, is for
the WG chairs to determine.

Given both the history of the base CMS specifications and the current
text in RFC 6485, the correct fix for this appears to be to say that
RPKI implementations MUST support rsaEncryption for the
signatureAlgorithm field and MAY support sha256WithRSAEncryption.

If we're seriously worried about compatibility with implementations
which only support sha256WithRSAEncryption per RFC 6485, we could
require support for both, but as far as I know, no such
implementations exist, so it would be cleaner just to re-align the
RPKI specifications with the base CMS specification and have done.

Note that this is not a blanket change to all uses of
sha256WithRSAEncryption in RFC 6485, it's only a change to the
signatureAlgorithm field in the CMS SignerInfo.

I will leave it for the WG to decide whether this change should take
the form of an updated RFC or an erratum, I don't much care.

Thanks to Andrew Chi, David Mandelberg, and Russ Housley for their
help in finding and understanding this problem.  Any errors here are
my fault, not theirs.