BPKI CA certificates in CMS

[sraustein]

Tim points out that rpkid may be too strict about receiving BPKI CA certs in CMS:

Just found that CA certs in the CMS are actually in the latest provisioning doc:

http://tools.ietf.org/html/draft-ietf-sidr-rescerts-provisioning-10#section-3.1.1.4

"... This field MAY contain CA certificates that a relying party MAY use to validate the EE certificate."

This is probably a bug in the spec, as there's nothing useful the receiver can do with such a CA cert, but given what the spec says we probably should not reject an otherwise valid message just for this.

Tim has since hacked his code not to send these, so it's not a serious interoperability problem.

Trac ticket #9 component rpkid priority minor, owner sra, created by sra on 2011-08-10T23:07:02Z, last modified 2012-02-03T17:16:18Z

[sraustein]

Nobody is sending this, but it stayed in the spec, and my co-authors were (understandably) somewhat reluctant to remove it during AUTH48, so we need to allow this silliness.

Trac comment by sra on 2012-02-03T05:24:02Z

[sraustein]

Since CMS validation code is common to everything derived from rpki.x509.CMS_object, least bad approach here looks like adding class variables to control this behavior, which can be overridden by subclasses.

Default behavior should remain to disallow gratuitous certificates and CRLs in CMS messages. At the moment the only subclass that would need to override and allow these looks to be rpki.up_down.cms_msg.

Trac comment by sra on 2012-02-03T16:33:46Z

[sraustein]

In [4287]: {{{

!CommitTicketReference repository="" revision="4287"

Clean up exceptions in rpki.x509.CMS_object.verify().

Up-down specification explictly allows certificates and CRLs we consider extraneous to be included in CMS messages. I think that any verification model which relies on these is flawed, so I don't use them, in fact, nobody does, but I was unable to convince my co-authors to change the specification. Sigh. So the up-down code has to allow these. In theory, OpenSSL's verification code should have no problem picking the useful bits out of the garbage, since that's a normal part of OpenSSL's job when acting as a TLS client, so we just pass the mess along to OpenSSL and let OpenSSL sort it out.

This closes #9. }}}

Trac comment by sra on 2012-02-03T17:16:18Z

[sraustein]

Closed with resolution fixed