Subject: Re: [wpkops] [T17Q11] Attribute certificate path

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Sep 2013 13:41:42 +0100

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: [email-masked] [mailto:[email-masked]] 
> Sendt: 21. september 2013 18:22
> Til: [email-masked]
> 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 <[email-masked]>
> To: 	David Chadwick <[email-masked]>
> CC: 	Erik Andersen <[email-masked]>, <[email-masked]>, <[email-masked]>
> 
> 
> 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 <[email-masked]>
>>>> To:     <[email-masked]>
>>>>
>>>>
>>>>
>>>> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/wpkops
>>>>
>>> _______________________________________________
>>> wpkops mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/wpkops
>>>
>> _______________________________________________
>> wpkops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/wpkops
>>
>>
> 
> 
> 
>

---

From: "Erik Andersen" <[email-masked]>
Date: Sun, 22 Sep 2013 18:25:47 +0200

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.

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.

Kind regards,

Erik

-----Oprindelig meddelelse-----
Fra: Stephen Farrell [mailto:[email-masked]] 
Sendt: 22. september 2013 14:42
Til: Erik Andersen
Cc: [email-masked]; [email-masked]; Directory
list; [email-masked]'
Emne: Re: SV: [T17Q11] Attribute certificate path

Hi Erik,

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.

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.

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Sep 2013 17:41:24 +0100

> 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.

> 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.

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 22 Sep 2013 19:23:32 +0200

> encoding can still impact on people's code as you know.
Changing the name of a component, i.e asn.1 modules
has an impact to code that is generated by asn.1 compilers.

A similar pb has already happened with the non-repudiation bit,
for which x.509 allows 2 names.

Consistent terminology and naming conventions may be nice,
but not at the price of breaking things.

regards

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 22 Sep 2013 20:38:48 +0100

WARNING: contains banned part

Subject: Re: [wpkops] [T17Q11] Attribute certificate path
From: Tony Rutkowski <[email-masked]>
To: Erik Andersen <[email-masked]>, 'Stephen Farrell' <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], 'Directory list' <[email-masked]>
Date: Sun, 22 Sep 2013 20:38:48 +0100

Hi Eric,

In summary today, we learned:

1) "editorial" changes to ASN.1 is not
without potential adverse consequences;

2) industry feedback suggests that no
changes really seem needed;

3) that you have received more feedback
in one day on the wpkops list than you have
in several years on Q11/17 lists;

4) that you envision "extending X.509 to
support future requirement"...such as
smartgrid and M2M uses (if you receive
funding from a prospective client).

What wpkops doesn't know is that the
skids have been greased a little by your
concurrent pursuit of the attached work
item in your own ITU-T group, expecting
that the X.500 series will spring to life
in the M2M/IoT world.

What is somewhat problematic here, however,
is that because the ITU-T is a Nation State
body, you will eventually have to get their
approval, even though thusfar you have kept
this going as only contributor, editing your
own material, and approving it yourself.

The problem set of object tagging and PKI
based trust is one that is being pursued in
multiple bodies today, e.g., the IETF, 3GPP,
ETSI, NIST, etc, with significant industry
involvement.  Somehow, it seems for more
productive and useful to engage your energies
in those forums, rather than basically having
a conversation with yourself in ITU-T, no?

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 23 Sep 2013 06:22:59 +0100

Subject: X.509 versions and proposed changes
From: Tony Rutkowski <[email-masked]>
To: 'Stephen Farrell' <[email-masked]>
Cc: Erik Andersen <[email-masked]>, [email-masked]
Date: Mon, 23 Sep 2013 06:22:59 +0100

Hi Steve,

It is helpful to have the complete
current set of X.509 materials.
These consist of the 2012 and
2006 versions, the defect report,
and the current draft proposed
changes to the 2012 version.

--tony

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Sep 2013 13:29:58 +0100

> changes to the 2012 version.

The 2012 version doesn't have any mention of a "trust broker"
but one of the word documents appears to be adding that to
x.509.

Two comments:-

1) that doesn't strike me as "editorial," even if there's
no change to an ASN.1 module.

2) I don't think adding that to x.509 without getting a lot
more input from people who develop PKI code is a good plan
at all. I'm not aware that such input has been sought or
given. But I doubt it'll have any impact if that is added
other than to make it less likely folks will make use of
the x.509 document.

So fwiw, count this as a "please don't, but I don't really
care if you do" comment from me. (And note "me" == Stephen,
not "the IETF" - if some kind of liaison about this is
helpful to SG17, we can ask to see what the IETF think
about it.)

S.

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 23 Sep 2013 17:33:57 +0200

Hi Steve,

You are confusing two things, the current 2012 edition and the future
edition 2016(?).

My mind is currently concerned with the final editing touch on X.509 (2012).
No technical changes to PKI and PMI have been made since the 2008 edition.
We have just updating the terminology to reflect what is currently used
within the PKI community, like introducing the concept of relying party. We
have made some clarification for new readers, etc.

There are some proposals for extending X.509 for the next edition (probably
to be published 2016). For example has a trust broker been proposed, but
this is still just a suggestion for everyone to comment on. It will take
another three years before such changes are incorporated assuming they are
approved. You are very welcome to comment on that proposal and any other
additions to be proposed.

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: Stephen Farrell [mailto:[email-masked]] 
Sendt: 23. september 2013 14:30
Til: [email-masked]
Cc: Erik Andersen; [email-masked]
Emne: Re: X.509 versions and proposed changes

The 2012 version doesn't have any mention of a "trust broker"
but one of the word documents appears to be adding that to x.509.

Two comments:-

1) that doesn't strike me as "editorial," even if there's no change to an
ASN.1 module.

2) I don't think adding that to x.509 without getting a lot more input from
people who develop PKI code is a good plan at all. I'm not aware that such
input has been sought or given. But I doubt it'll have any impact if that is
added other than to make it less likely folks will make use of the x.509
document.

So fwiw, count this as a "please don't, but I don't really care if you do"
comment from me. (And note "me" == Stephen, not "the IETF" - if some kind of
liaison about this is helpful to SG17, we can ask to see what the IETF think
about it.)

S.

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 23 Sep 2013 17:28:04 +0100

Hi Eric,

I distributed all know documents on this list.
They include the 2006 "published" edition;
the 10/2012 "prepublished" edition; TD0631
containing "2nd draft amendment 2 for
Rec. ITU-T X.509 | ISO/IEC 9594-8;" and
TD0634 containing "Defect Report 390 on
Rec. ITU-T X.509 | ISO/IEC 9594-8."

You own meeting report (TD0683R3) says:
>
> oMuch time was spent on reviewing X.509 to streamline it to provide a 
> good foundation for the future work. In addition, the work on 
> introducing a new component, called trust broker was progressed. A 
> second Working Draft for an amendment to Rec. ITU-T X.509 | ISO/IEC 
> 9594-8 was produced and may be found as TD 0631.
>

TD0631 is what has been discussed, and your own
meeting report seems at odds with your characterization
that you are just making minor edits.

--tony