At 7:16 PM -0700 7/21/11, Terry Manderson wrote:
Hi Andrew,
Therefore, the BBN validator does the only thing sensible, which is
validate based on filename and certificate chain. After that, we check
against the manifest and emit a warning if it doesn't look right. And
we provide the
- Original Message -
From: Stephen Kent k...@bbn.com
To: t.petch ie...@btconnect.com
Cc: Terry Manderson terry.mander...@icann.org; Rob Austein s...@isc.org;
draft-ietf-sidr-repos-str...@tools.ietf.org; sidr-cha...@tools.ietf.org;
sidr@ietf.org
Sent: Saturday, July 23, 2011 3:37 PM
...
On 7/20/2011 11:03 PM, Terry Manderson wrote:
On 21/07/11 2:15 AM, Rob Austeins...@isc.org wrote:
At Tue, 19 Jul 2011 14:03:18 -0700, Terry Manderson wrote:
Rob's observation that the extension exists in the manifest file name is a
close approximation provided words exist as highlighted
Hi Andrew,
Therefore, the BBN validator does the only thing sensible, which is
validate based on filename and certificate chain. After that, we check
against the manifest and emit a warning if it doesn't look right. And
we provide the user with configuration flags to control the output
...
I'm happy to see things tagged in a normative fashion, I just think putting
the eggs into the filename/directory basket as a standards action is
worrying.
Cheers
Terry
Since we're using basic file systems for the repository (e.g., vs.
LDAP), I think file names are an obvious candidate
At 9:08 PM -0700 7/17/11, Terry Manderson wrote:
On 18/07/11 12:42 PM, Stephen Kent k...@bbn.com wrote:
At 4:42 PM -0700 7/17/11, Terry Manderson wrote:
the filename extension, which is part of the file data type above,
conveys the needed info. yes, one could add an OID here, but
At Tue, 19 Jul 2011 14:03:18 -0700, Terry Manderson wrote:
Rob's observation that the extension exists in the manifest file name is a
close approximation provided words exist as highlighted which gives clear
instruction to implementers as to
1) make the first approximation of validation
At 12:53 PM +1000 7/18/11, Geoff Huston wrote:
...
How is this X.500 directory tagging achieved in other PKIs? Three
letter filename extension conventions? Or some other tag mechanism?
I was referring specifically to the X.500 directory, which tags via
its ASN.1 encoding for data types. But,
On 21/07/11 2:15 AM, Rob Austein s...@isc.org wrote:
At Tue, 19 Jul 2011 14:03:18 -0700, Terry Manderson wrote:
Rob's observation that the extension exists in the manifest file name is a
close approximation provided words exist as highlighted which gives clear
instruction to implementers
On 19/07/11 9:15 PM, Randy Bush ra...@psg.com wrote:
I think there is an easier way, as already suggested. Add the object
type to the manifest in FileandHash.
1) the rescert points to the publication point and manifest
2) the manifest is mandatory
3) the manifest is signed
4) the
At Tue, 19 Jul 2011 05:51:50 -0700, Terry Manderson wrote:
The win is to eliminate a threat that has already been identified on the
list.
What threat? Please describe it.
The only threat I saw discussed is, in my opinion, a non-issue: an
attacker can mangle filenames in the unprotected data
On Jul 19, 2011, at 3:59 PM, Rob Austein wrote:
At Tue, 19 Jul 2011 05:51:50 -0700, Terry Manderson wrote:
The win is to eliminate a threat that has already been identified on the
list.
What threat? Please describe it.
The only threat I saw discussed is, in my opinion, a non-issue:
On Tue, 19 Jul 2011, Tim Bruijnzeels wrote:
On Jul 19, 2011, at 3:59 PM, Rob Austein wrote:
At Tue, 19 Jul 2011 05:51:50 -0700, Terry Manderson wrote:
The win is to eliminate a threat that has already been identified on the
list.
What threat? Please describe it.
The only threat I saw
On Tue, 19 Jul 2011, Terry Manderson wrote:
On 19/07/11 9:15 PM, Randy Bush ra...@psg.com wrote:
I think there is an easier way, as already suggested. Add the object
type to the manifest in FileandHash.
1) the rescert points to the publication point and manifest
2) the manifest is
On Mon, 18 Jul 2011, Terry Manderson wrote:
On 18/07/11 9:39 PM, Tim Bruijnzeels t...@ripe.net wrote:
Hi,
I agree that not having this mapping is tedious and error prone for RPs.
I can agree that a mapping system is useful. It may just be that living unix
world for far too long has seen
I think there is an easier way, as already suggested. Add the object
type to the manifest in FileandHash.
1) the rescert points to the publication point and manifest
2) the manifest is mandatory
3) the manifest is signed
4) the manifest is nicely(?) readable ASN.1
so move the deck
On 19/07/11 11:59 PM, Rob Austein s...@isc.org wrote:
What threat? Please describe it.
The only threat I saw discussed is, in my opinion, a non-issue: an
attacker can mangle filenames in the unprotected data stream, thus
causing objects to fail validation. An attacker who can do that
ok. So in which case before I give in to making repos-struct a PS, I would
want to see words somewhere that say that the validation choice for an RPKI
object file is to based on the filename in the manifest and not on the
transferred filename.
again, the manifest may represent a proper subset
A process reminder here. Several other documents point to the
repos-struct draft, some of them specifically regarding the file
extensions. Separating out the tagging into a separate document could
mean some serious review of multiple documents.
I think the question might be if the
On 20/07/11 1:02 AM, Sandra Murphy sandra.mur...@sparta.com wrote:
There was a brief discussion of the use of file names extensions when the
repos-struct document came up for last call. See the following messages:
http://www.ietf.org/mail-archive/web/sidr/current/msg02281.html
On Tue, 19 Jul 2011, Terry Manderson wrote:
On 20/07/11 1:02 AM, Sandra Murphy sandra.mur...@sparta.com wrote:
There was a brief discussion of the use of file names extensions when the
repos-struct document came up for last call. See the following messages:
On Tue, 19 Jul 2011, Terry Manderson wrote:
On 20/07/11 6:43 AM, Randy Bush ra...@psg.com wrote:
ok. So in which case before I give in to making repos-struct a PS, I would
want to see words somewhere that say that the validation choice for an RPKI
object file is to based on the filename in
Hi,
On Jul 17, 2011, at 4:53 PM, Rob Austein wrote:
This draft defines the mappings from filename extension (.cer, .roa,
.crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc).
Without this mapping, relying party tools have no way of knowing what
they're looking at in most
On 18/07/11 9:39 PM, Tim Bruijnzeels t...@ripe.net wrote:
Hi,
I agree that not having this mapping is tedious and error prone for RPs.
I can agree that a mapping system is useful. It may just be that living unix
world for far too long has seen me move away from the mandatory dos-like
And I'm happy to see it written as a hint. A validated mapping should
come, in my opinion from something more robust which also transcends
the technology used in the repository.
easy. throw away the entire structure and code to date and do it as a
collection of tlvs.
i suspect no one else
On 19/07/11 2:23 PM, Randy Bush ra...@psg.com wrote:
And I'm happy to see it written as a hint. A validated mapping should
come, in my opinion from something more robust which also transcends
the technology used in the repository.
easy. throw away the entire structure and code to date and
This draft defines the mappings from filename extension (.cer, .roa,
.crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc).
Without this mapping, relying party tools have no way of knowing what
they're looking at in most cases, and would have to attempt to decode
every object in
On 18/07/2011, at 12:53 AM, Rob Austein wrote:
This draft defines the mappings from filename extension (.cer, .roa,
.crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc).
Without this mapping, relying party tools have no way of knowing what
they're looking at in most cases,
On 18/07/2011, at 9:42 AM, Terry Manderson wrote:
On 18/07/11 12:53 AM, Rob Austein s...@isc.org wrote:
This draft defines the mappings from filename extension (.cer, .roa,
.crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc).
Without this mapping, relying party tools
At 7:41 AM +1000 7/18/11, Geoff Huston wrote:
On 18/07/2011, at 12:53 AM, Rob Austein wrote:
This draft defines the mappings from filename extension (.cer, .roa,
.crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc).
Without this mapping, relying party tools have no way of
At 4:42 PM -0700 7/17/11, Terry Manderson wrote:
...
This actually makes me wonder why the manifest (
draft-ietf-sidr-rpki-manifests) in:
FileAndHash ::= SEQUENCE {
fileIA5String,
hashBIT STRING
}
Doesn't have a RPKIObjectIdentifier that tells the
On 18/07/11 11:29 AM, Geoff Huston g...@apnic.net wrote:
On 18/07/2011, at 9:42 AM, Terry Manderson wrote:
This actually makes me wonder why the manifest (
draft-ietf-sidr-rpki-manifests) in:
FileAndHash ::= SEQUENCE {
fileIA5String,
hashBIT
On 18/07/11 12:32 PM, Stephen Kent k...@bbn.com wrote:
But wouldn't the CMS (and ASN.1 for that matter) effectively tell
the RP what the object was intended to be? It strikes me that the
file name extension is a bit of syntactic sugar rather than an
essential and necessary component, so I'm
On 18/07/11 12:42 PM, Stephen Kent k...@bbn.com wrote:
At 4:42 PM -0700 7/17/11, Terry Manderson wrote:
the filename extension, which is part of the file data type above,
conveys the needed info. yes, one could add an OID here, but
ultimately an RP will check the syntax and know which file
If youy want to compare the RPKI to the general PKI repository model
(X.500), note that in an X.500 directory, every object is tagged in a
fashion analogous to the filename extension. LDAP tags objects as
well. So why is it not appropriate to do so, in a normative fashion
here?
it is
So, I'm confused.. if the RP ultimately checks the syntax, why is tagging
needed at all?
think tlv. that's the t
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
At 8:53 PM +0100 7/15/11, Stewart Bryant wrote:
SIDR WG,
During IESG review the there was a preference for
draft-ietf-sidr-repos-struct to be Standards Track
rather than BCP.
Making this change does not require a new IETF LC.
I want to get sense of whether the WG would be OK
with this change
37 matches
Mail list logo
