Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS)

[Terry Manderson <[e-mail]>]

Hi Sandy,


On 20/11/2015 4:27 am, "Sandra Murphy" <[e-mail]> wrote:

>A bit of history here.
>
>After RFC6485 was published, it was discovered that it incorrectly used
>the same OID for all RPKI crypto uses, which conflicts with CMS specs and
>is inconsistent with known implementations.

I am aware of that.

>
>The wg decided to create RFC6485bis, to correct the OID problem and the
>OID problem only, with emphasis on the ³only².

Timeline leap is not your friend here. 6485 pre-dates 6916. 6485 is
minimalist (and from a point of view, wrong) about algorithm changes.

>
>The ³SHOULD² language in section 5 is inherited from RFC6485, except for:
>
>   The recommended
>   procedures to implement such a transition of key sizes and algorithms
>   is specified in [RFC6916]
>
>RFC6916, which was published a year after RFC6485, is "Algorithm Agility
>Procedure for the Resource Public Key Infrastructure (RPKI)².  It
>describes the procedure to follow in transitioning from one algorithm/key
>size to another.

Correct. It was this text that drew me to the section. And since the text
pre-dates 6916, which takes a more encompassing view of an
algorithm/profile change with a security section that adequately warns of
invalidity due to a RP not supporting the new certificate profile, I view
6916 as more 'with the times' (YMMV).


>
>Does RFC6916 satisfy your concerns about a change of algorithm?

It does a better job that allowing a CA or RP to opt out and fracture the
RPKI.

>
>Would you prefer that RFC6485bis remove the inherited ³SHOULD² language
>and point only to RFC6916?

Yes, That is certainly one way to address this. And I would be OK with
that.


Cheers
Terry

>
>‹Sandy
>
>On Nov 17, 2015, at 9:09 PM, Terry Manderson <[e-mail]>
>wrote:
>
>> Terry Manderson has entered the following ballot position for
>> draft-ietf-sidr-rfc6485bis-04: 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-rfc6485bis/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> I'm not so sure that this will be an easy DISCUSS to work through as I
>> view this in light of future sustainability/deployability of RPKI and
>>any
>> protocol wedded to it (eg BGPSEC).
>> 
>> Section 5 "Additional Requirements" suggests that both CAs and RPs
>> "SHOULD" be capable of supporting a transition and thus able to support
>> multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it
>> invites fragility in any such transition. An immediate example would be
>> the root DNSSEC ksk rollover. An rather large amount of work is underway
>> to ascertain the impact. By leaving the SHOULDs in place is this walking
>> the same path?
>> 
>> Let me ask another way. Under what situations is it actually appropriate
>> for a CA or RP to be able to ignore the requirement of being able to
>> support a phased introduction/deprecation of new/different RPKI
>>algorithm
>> and key profiles? And if they ignore such a recommendation does this
>>make
>> the entire RPKI infrastructure a fractured PKI by algorithm?
>> 
>> 
>> 
>> 
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>