On 09/22/2013 05:25 PM, Erik Andersen wrote:
> Hi Stephen,
> 
> At the current state we are not making any technical changes. It is pure
> editorial, like getting the terminology consistent. I am only at this stage
> asking question related to editorial issues.

Ah, good to hear. In the past Hoyt and Sharon have made drafts
available informally. If you can do that in the same way, (just
sending a version we can circulate) that'd be useful since I'm
sure some would be happy to check no problems had slipped in by
accident. I'd just ask that you be extra-careful with any ASN.1
modules changes - things that don't affect the on-the-wire
encoding can still impact on people's code as you know.

> In the next stage, we will start extending X.509 to support future
> requirement, e.g., Smart Grid, which in places are very constraint in
> processing, bandwidth, response time requirements. It is also a
> Machine-to-Machine (M2) environment requiring special considerations. If you
> are interested in the subject you are very welcome to participate.

When is that "next stage" planned for roughly? It'd probably be
good to check if various folks involved in the many IETF activities
on IoT stuff are interested. FWIW, we've not so far had any folks
pressing for changes to 5280 for such applications so far that I
can recall.

Cheers,
S.


> 
> Kind regards,
> 
> Erik
> 
> -----Oprindelig meddelelse-----
> Fra: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
> Sendt: 22. september 2013 14:42
> Til: Erik Andersen
> Cc: anthony.rutkow...@ties.itu.int; t13sg17...@lists.itu.int; Directory
> list; 'wpkops@ietf.org'
> Emne: Re: SV: [T17Q11] Attribute certificate path
> 
> 
> Hi Erik,
> 
> (Adding back wpkops since that's where I asked the question.)
> 
> On 09/22/2013 10:47 AM, Erik Andersen wrote:
>> We are in the middle of the final editing of X.509. My questions on 
>> the lists are related to that process and I am happy for responses 
>> aiding that process. As project editor it is my duty together with the 
>> very capable ITU-T editing team to bring the seventh edition into the 
>> best possible editorial state. It is my intension to do exactly that - 
>> come hell or high water.
> 
> Sorry, but that doesn't help me. I'm asking why these changes are being
> done, not whether or not you're going to finish them.
> 
> If the answer is "we're fixing problems a,b,c" then that'd be interesting,
> if those problems are things that affect real world code.
> 
> If the answer is "because we started" then that'd be a concern, since making
> changes for fun is quite likely to badly impact on interop. But in that
> case, there is an obvious answer which is to point to 5280, and to say to
> ignore these later editions of
> x.509 so the damage is fairly limited, but that seems like an unfortunate
> outcome.
> 
> Or maybe the answer is something else?
> 
> S.
> 
> PS: I'm not asking at all about ITU-T internal stuff here.
> That's neither my problem, nor interesting. I'm just interested in why stuff
> is being done to documents that overlap with IETF work.
> 
>>
>> Regards,
>>
>> Erik
>>
>> -----Oprindelig meddelelse-----
>> Fra: anthony.rutkow...@ties.itu.int 
>> [mailto:anthony.rutkow...@ties.itu.int]
>> Sendt: 21. september 2013 18:22
>> Til: t13sg17...@lists.itu.int
>> Emne: Re: [T17Q11] Attribute certificate path
>>
>> -------- Original Message --------
>> Subject:     Re: [wpkops] Fwd: [T17Q11] Attribute certificate path
>> Date:        Sat, 21 Sep 2013 17:07:17 +0100
>> From:        Stephen Farrell <stephen.farr...@cs.tcd.ie>
>> To:  David Chadwick <d.w.chadw...@kent.ac.uk>
>> CC:  Erik Andersen <e...@x500.eu>, <wpkops@ietf.org>, <t...@yaanatech.com>
>>
>>
>> Hiya David,
>>
>> On 09/21/2013 04:32 PM, David Chadwick wrote:
>>>
>>>
>>> On 21/09/2013 13:48, Stephen Farrell wrote:
>>>>
>>>> Not sure what the question is really, but I absolutely do wonder why 
>>>> anyone would consider it a good plan to change specs like x.509 
>>>> apparently without there being any implementers who want those 
>>>> changes.
>>>>
>>>> Luckily, rfc 5280 has all you need anyway so its not that important 
>>>> any more if x.509 changes.
>>>
>>> Yes for PKCs, but it does not address Erik's point which is about ACs
>>
>> He asked about ACs, I asked about motivation. Mine is a real question 
>> btw, I really don't get why its useful to keep messing with x.509, nor 
>> why folks want to do that when no implementers afaik want them to. If 
>> you know the answer, I'd love to hear it.
>>
>> Also, Tim just sent a mail looking for editors in this wg. Doing that 
>> would seem to me to be far more beneficial to all interested in PKI.
>>
>> As for ACs, rfc 5755 does the job there, but is afaik almost 
>> ubiquitously ignored. In the 20 or so years since I started working 
>> with attribute certs
>> (*) every single proposed use-case turned out to have a better non-AC 
>> approach. But maybe I've just been (un)lucky;-)
>>
>> Cheers,
>> S.
>>
>> (*) They were called PACs back then, based on ETSI TR/46.
>> The x.509 flavour ACs were added some time later.
>>
>>>
>>> David
>>>>
>>>> S
>>>>
>>>> On 09/21/2013 01:42 PM, Tony Rutkowski wrote:
>>>>> does anyone have any druthers here for Erik who is trying to update 
>>>>> the old
>>>>> X.509 spec?
>>>>>
>>>>> --tony
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject:     [T17Q11] Attribute certificate path
>>>>> Date:     Sat, 21 Sep 2013 14:10:20 +0200
>>>>> From:     Erik Andersen <e...@x500.eu>
>>>>> To:     <t13sg17...@lists.itu.int>
>>>>>
>>>>>
>>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I noticed that 12.2 of X.509 talks about attribute certificate path.
>>>>> However, the associated ASN.1 is a data type is called 
>>>>> AttributeCertificationPath. As we for public-key certificates talk 
>>>>> about certification path, it seems reasonable to use the term 
>>>>> "attribute certification path" rather that "attribute certificate
> path".
>>>>>
>>>>> I also noticed that the ASN.1 indicates that the path is bottom up 
>>>>> rather top down:
>>>>>
>>>>> AttributeCertificationPath ::= SEQUENCE {
>>>>>
>>>>>    attributeCertificate  AttributeCertificate,
>>>>>
>>>>>    acPath                SEQUENCE OF ACPathData OPTIONAL,
>>>>>
>>>>>    ... }
>>>>>
>>>>> Please come back with comments.
>>>>>
>>>>> Erik
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wpkops mailing list
>>>>> wpkops@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/wpkops
>>>>>
>>>> _______________________________________________
>>>> wpkops mailing list
>>>> wpkops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/wpkops
>>>>
>>> _______________________________________________
>>> wpkops mailing list
>>> wpkops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/wpkops
>>>
>>>
>>
>>
>>
>>
> 
> _______________________________________________
> wpkops mailing list
> wpkops@ietf.org
> https://www.ietf.org/mailman/listinfo/wpkops
> 
> 
_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops

Reply via email to