Hiya Stephen, On 5/18/16 12:09 PM, Stephen Farrell wrote: > > Hiya, > > On 18/05/16 17:06, Brian Haberman wrote: >> Hiya Stephen, >> >> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>> Stephen Farrell 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: >>> ---------------------------------------------------------------------- >>> >>> >>> I'd like to check one thing - this may be needed for strict >>> compliance with RPKI thing but it seems kinda weird to also >>> impose that here, but anyway... >>> >>> Is 3.2 step 1 needed? That seems like useless complexity >>> here. If it is needed, how does the verifier check that >>> it's really a single-use? I don't see the point TBH. >>> >> >> This text was driven by the statement in RFC 6487 (Section 3) that says: >> >> The private key associated with an EE certificate is used to sign a >> single RPKI signed object, i.e., the EE certificate is used to >> validate only one object. >> >> Step 1 in 3.2 is there so that this approach follows the above directive >> on the use of the RPKI infrastructure/certificates. > > Well... sure. But what is the benefit here? IIRC that was
I *think* the benefit is supposed to be compliance with the RPKI approach... > something related to making more fine-grained revocation > possible or something which doesn't seem that useful here > since a verifier will likely already have processed stuff > already or am I mixed up? I don't think you are mixed up, but I will let others in SIDR chime in... > > If there's no benefit, it seems like that adds a bunch of > CA code just for fun (or "compliance" maybe;-) I could very easily see dropping step 1 from 3.2 and simply augmenting the intro sentence with something about certs/keys generated per 3487. Regards, Brian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
