Hi Brian, On 18/05/2016, 11:08 PM, "Brian Haberman" <[email protected]> wrote: > >You are correct that the use of the RPKI repository is one of >convenience. My original implementation of this approach used non-RPKI >certificates. I would be fine with putting a statement in the >Introduction along the lines of: > >"While the approach outlined in this document mandates the use of the >RPKI for certificate distribution, it is not dependent upon the RPKI for >correct functionality. Equivalent functionality can be achieved with a >more traditional certificate authority, RFC 3779 extensions within the >certificates, and the appropriate trust anchor material to verify the >digital signature."
That is a fine snippet to include. Thank you.
>
>>
>> The Signature expiration time field ("x") currently has no time
>> constraints, and I'm very surprised that it is optional with the text in
>> s2.5, given that the expiration time, by my reading, could not be beyond
>> the 'not after' time of the corresponding certificate. Can you please
>> instruct me as to what the consensus position on this was? A criticism
>>of
>> many IRRs is that data becomes stale. have the signature expiration time
>> field could aide in data freshness models and reduce load on automated
>> import and validation of these RPSL signatures.
>
>The validity of the signature is driven by the notAfter field of the
>certificate described in 6487. My implementation does the validation
>based on notAfter regardless of what is included in the "x" field. I
>view "x" as a simple way for RPSL object signers to indicate the
>lifetime, but not the authoritative way.
Understood. I was considering a more operational triage of the signed
objects prior to validation.
But in reflection that can introduce an unintentional error situation. Put
aside this item.
>
>>
>> And lastly, IRRs tend to run over the (legacy?) whois port 43 that
>> doesn't provide channel layer security. This means that while signature
>> provide a means of detecting modification it may not stop a a MiTM event
>> where the entire object is omitted. Do you agree? if so that might be
>> appropriate for the Security Considerations section.
>>
>
>I agree with the potential MiTM attack described, but view that as
>orthogonal to digital signatures providing integrity protection. This
>type of attack could easily occur regardless of whether objects are
>signed or not.
Correct. I raise the point so that people who implement and/or use
rpsl-sig do not accidentally assume that by adding a signature some form
of magic happens that unreservedly protects the object - you can take this
now as 'comment' fodder.
>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> one nit:
>>
>> "MUST reject the signature and threat the object as a regular" I think
>> you mean `s/threat/treat`
>
>Fixed in my pending edit buffer.
Thanks
>
>>
>> Misc comments:
>>
>> * Thank you for the very clear canonicalisation requirements!
>>
>> * For route6 objects, where two resource holder's signatures considered
>> such that it might address the inability to properly sign the RPSL when
>> one holder possesses the ASN and another possesses the prefix? (just a
>> comment, nothing more)
>>
>
>Not sure I can parse the above unless s/where/were/... If so, that was
>originally in the document prior to -09, but the consensus of the WG was
>to remove multiple signature support.
Yes, I typo'd.
Thanks for the info on the WG consensus for multiple signature support.
I'll clear my discuss shortly.
Cheers
Terry
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
