+1
As far as we programmed to support Validation Reconsidered by using OPENSSL , a
bug was found.
For instance, if one calls v3_addr_get_range() in OPENSSEL library to get INR
1::/16 from a RC, one will get a right MAX but a wrong MIN NULL, which should
have been 1:: .
Di
> 在 2017年3月13日，23:4
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing of the IETF.
Title : RPKI Repository Delta Protocol (RRDP)
Authors : Tim Bruijnzeels
Oleg Muravs
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing of the IETF.
Title : Simplified Local internet nUmber Resource Management
with the RPKI
Authors : David Mandelberg
Rob,
On 13 Mar 2017, at 12:16, Rob Austein wrote:
You are making assumptions about how the library code works. As it
happens, those assumptions are incorrect for the OpenSSL case.
can you expand on this ? I think if you help us on this front a lot of
the concerns and misunderstandings will
At Mon, 13 Mar 2017 15:25:13 +0100, Tim Bruijnzeels wrote:
>
> I understand that. I meant to say that the switch should be based on
> the RPKI CA certificate policy qualifier. That is specific to RPKI
> so, other applications would not break.
The problem is that you're talking about applications,
Hi Rob, all,
> On 13 Mar 2017, at 14:11, Rob Austein wrote:
>
> At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote:
>>
>> So, to me it seems that having new OIDs makes perfect sense as long
>> as there is a choice of two validation algorithms. Then having an
>> explicit flag set by CAs t
At Mon, 13 Mar 2017 10:55:56 +0100,
Tim Bruijnzeels wrote:
>
> Hi,
>
> So, to me it seems that having new OIDs makes perfect sense as long as
> there is a choice of two validation algorithms. Then having an
> explicit flag set by CAs tells RPs decide which way to go. Because of
> this I also do
At Mon, 13 Mar 2017 08:47:11 -0400,
Rob Austein wrote:
>
> At Mon, 13 Mar 2017 14:16:59 +0800, Declan Ma wrote:
> ...
> > It seems to me that the only concern on OID is about using OPENSSL
> > to get resource sets for further validation process. If the WG has
> > decided to deprecate the original
At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote:
>
> So, to me it seems that having new OIDs makes perfect sense as long
> as there is a choice of two validation algorithms. Then having an
> explicit flag set by CAs tells RPs decide which way to go. Because
> of this I also do not see an
At Mon, 13 Mar 2017 14:16:59 +0800, Declan Ma wrote:
...
> It seems to me that the only concern on OID is about using OPENSSL
> to get resource sets for further validation process. If the WG has
> decided to deprecate the original by using the Validation
> Reconsidered, why bother to bring a new OI
Hi,
So, to me it seems that having new OIDs makes perfect sense as long as there is
a choice of two validation algorithms. Then having an explicit flag set by CAs
tells RPs decide which way to go. Because of this I also do not see an
immediate need to have a time line for all CAs to use the new
11 matches
Mail list logo
