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

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

On Thu, May 19, 2016 at 1:02 AM, Brian Haberman
<brian@innovationslab.net> wrote:
> Hi Tim,
>
> On 5/18/16 10:32 AM, Tim Bruijnzeels wrote:
>> Hi,
>>
>>> On 18 May 2016, at 15:08, Brian Haberman <brian@innovationslab.net>
>>> wrote:
>>>
>>> Hi Terry,
>>>
>>> On 5/17/16 11:37 PM, Terry Manderson wrote:
>>>> Terry Manderson has entered the following ballot position for
>>>> draft-ietf-sidr-rpsl-sig-11: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to
>>>> all email addresses included in the To and CC lines. (Feel free
>>>> to cut this introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for
>>>> more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found
>>>> here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>>
> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>>
> Thank you for putting substantial effort into this document.
>>>>
>>>> I have a few discusses. I hope they can be resolved quickly.
>>>>
>>>> In Section 2.1. The reference to the aligned certificate  which
>>>> has the same private key that signed the RPSL object is
>>>> mandatory, and defined by a RSYNC URL or a HTTP(S) URL. My
>>>> question surrounds the "or". The architecture of RPKI (IIRC) is
>>>> centered around RSYNC, and thus SIA/AIA values MUST have a RSYNC
>>>> URL, and MAY have other types. By this are you leaving it to the
>>>> issuing party to control the RPKI Distribution mechanisms of the
>>>> Replying Party? I am quite comfortable with "or" personally,
>>>> however this facet of fetching the RPSL Certificate to validate
>>>> the private key usage is seemingly orthogonal to the RPKI
>>>> architecture of RSYNC preferred and should be called out if 'or'
>>>> is the clear intention. Or, has the consensus of the WG moved on
>>>> from being wedded to RSYNC?
>>>
>>> I am not aware of the WG moving away from their rsync leanings...
>>
>> My take on this: for the moment I would stick to rsync as it's
>> required and EE certificates appearing in the rsync repository, and
>> leave out http(s).
>>
>
> If the consensus is to remove mention of an http(s) URI, I can live with
> that. The current state of affairs within the SIDR documentation is such
> that only an rsync URI will be feasible in the near future. I don't
> believe that the mention of an http(s) URI in this context affects that
> one way or the other.
>
> Regards,
> Brian
>
>
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>