Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)

Hi Robert, all,

> On 20 May 2016, at 13:32, Robert Kisteleki <robert@ripe.net> wrote:
> 
> Chiming it late...
> 
> On 2016-05-19 0:39, George Michaelson wrote:
>> I would rather the sigs were signed by ee certs which were in the
>> blob, than have to make an external reference and I would rather we
>> varied the compliance needs to remove a pointless external ref.
>> 
>> If there has to be a ref, I think making it mandated to a specific
>> scheme is over specifying, especially in a context where we might
>> begin to understand *where you get cryptographic materials from is
>> less important than proving who said them*.
>> 
>> Rsync is a bad fit. for the actual signing cert, Inline is better. It
>> can refer to whatever chain it likes.
>> 
>> -G
> 
> In the good ol' days a reference was put in because while the signature
> itself is relatively small, including the full EE cert would bloat the whole
> RPSL object to potentially multiple times its original size -- and for those
> who don't care about signatures this is a huge overhead. Furthermore, if one
> would reuse EE certs in multiple signatures (I don't see why that would be
> prohibited -- for example if I want to sign multiple objects at the same
> time), then this method makes even more sense.

Let me attempt a different angle. I think a more fundamental question is whether we would expect this EE certificate a) to appear in the normal RPKI repository as one of the signed products of a CA, and appear on the manifest - or b) to be an embedded certificate, or c) that it can be a detached EE certificate that lives elsewhere, but is validated against a signing CA cert and CRL that do live in the 'normal' RPKI repository.

Currently looking at the document it's not clear to me whether 'a' or 'c' is intended. My preference however is 'b'.

if a) in the normal RPKI

Then I think we should stick to rsync as it's currently required for all RPKI certificates. Even if using RRDP, we still have the rsync URIs as a hint in the XML so we can find the certificate.

If this is the way, then there are some amendments needed to profile and repository standards - as discussed in the thread - let me not repeat here. Currently deployed RPs *will* choke on this. So this option does not have my preference.

if b) embedded

I prefer this approach because it makes it easier to specify the certificate and define validation in the RPSL-SIG document, and it has no impact on RPKI deployment. If you like I can suggest text..

And if you want to multi-use and fate-share (indeed I think this is generally an easy way to shoot in one's own foot, and don't see optimisation by doing this), you can just embed the same certificate. As I stated in my response to George I am not convinced that the size is problematic. I think we can filter this if we must.

In response to Stephen's suggestion to use another attribute for the certificate: I prefer not to. The reason is that we would have to introduce two new optional attributes that need to appear in conjunction, and I believe this makes it unnecessarily difficult to implement RPSL object validation and attribute filtering. The value of the 'signature' attribute is well-defined and needs to be parsed anyway, so adding an element to contain the certificate does not seem problematic to me.

if c) third location

I believe this is the worst option. Having random third locations to retrieve the EE certificates over http(s) or rsync, different from the RPKI repository itself and from where the RPSL objects are retrieved introduces a lot of overhead for both RPs and publishers, and introduces a potential for failure to retrieve.

> Then the whole back-and-forth started about whether it should be rsync or
> http(s) and now perhaps it's neither. It feels like we're going around in
> circles here :)

Yep, you have my sympathy and I am sorry for not engaging more actively earlier.

We found this and the concerns raised by Tom when we worked on an inter-operating proof of concept implementation recently. On a positive note, as a general concept we found this works. It's really about where to find EE cert, and how to relate it to a CA certificate and CRL in the existing RPKI.

> 
> Robert
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr