Hi all, Actually, yes, I agree with George on in-line.
In-line would have my preference. Include the entire EE certificate in the signature field. This way it does not need to be fetched separately, and it does not need to appear in a repository or a manifest. Mandate that the EE certificate is signed by CA certificate in the RPKI (i.e. no longer chain possible). The EE certificate should have an AIA and AKI that can then be easily referenced against known CA certificates that a validator found. So in short: a validator can do its normal top-down validation for a TA. And to perform bottom-up validation of a signed RPSL object the process of validating the EE cert would be fairly simple -> find a CA cert with SKI matching the AKI of the EE, verify the signature of the EE (proof of possession), verify the CRL. Omitting the other checks here - would be good to specify this explicitly in the document, but for the discussion here seems excessive. I think there was some discussion around this earlier and back then the thought was that we wouldn't want to make the RPSL objects bigger. However, I don't know if that should be a concern. The way I see it looking at our own whois implementation I imagine that this field could actually only be shown to RPs when they supply an additional flag, if size is a concern. And in our web UI (ad-hoc queries by humans) we would not show the signature field as is, but process it and highlight signed fields somehow. Tim > On 19 May 2016, at 00:39, George Michaelson <[email protected]> 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 > > 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
