>>
>> Provided of course that you have a valid GB object since without a
>> manifest a simple `cp 1.gbr 1.cer` will fail to validate under
oops that should have been `mv 1.gbr 1.cer`.
>> the assumption you make the validation selection regime based on
>> filename extension
>
>
On 21/07/11 2:15 AM, "Rob Austein" 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 as
>>> I would prefer, given the identified case, that where a situation
>>> exists that a manifest is is non-existent or discarded that the entire
>>> publication point MUST be considered suspicious and not used for
>>> validation of operational objects. I would be fine if the GB object
>>> were stil
On 21/07/11 12:42 PM, "Randy Bush" wrote:
>> I would prefer, given the identified case, that where a situation
>> exists that a manifest is is non-existent or discarded that the entire
>> publication point MUST be considered suspicious and not used for
>> validation of operational objects. I w
> I would prefer, given the identified case, that where a situation
> exists that a manifest is is non-existent or discarded that the entire
> publication point MUST be considered suspicious and not used for
> validation of operational objects. I would be fine if the GB object
> were still validate
Steve,
On 21/07/11 3:22 AM, "Stephen Kent" wrote:
> Terry,
>
> The repository document mandates that each CA
> issue a manifest and maintain it in an up-to-date
> fashion; that's pretty clear. For example, 4.2.1
> says "If the authority alters any of the items
> that it has published in the r
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 Wed, 20 Jul 2011, Stephen Kent wrote:
Terry,
The repository document mandates that each CA issue a manifest and maintain
it in an up-to-date fashion; that's pretty clear.
There's also the following text:
2.1. Manifests
Every repository publication point MUST contain a manifest
-
Terry,
The repository document mandates that each CA
issue a manifest and maintain it in an up-to-date
fashion; that's pretty clear. For example, 4.2.1
says "If the authority alters any of the items
that it has published in the repository
publication point, then the authority MUST issue
a
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 9:08 PM -0700 7/17/11, Terry Manderson wrote:
On 18/07/11 12:42 PM, "Stephen Kent" 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
...
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 for
12 matches
Mail list logo
