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 <[email protected]> wrote: > Hi Tim, > > On 5/18/16 10:32 AM, Tim Bruijnzeels wrote: >> Hi, >> >>> On 18 May 2016, at 15:08, Brian Haberman <[email protected]> >>> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
