From denis.ietf@free.fr Tue Jun 4 10:11:02 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F2D21F9B6A for ; Tue, 4 Jun 2013 10:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.153 X-Spam-Level: ** X-Spam-Status: No, score=2.153 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8q58Du59n-z for ; Tue, 4 Jun 2013 10:10:58 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12]) by ietfa.amsl.com (Postfix) with ESMTP id E424921F9AE1 for ; Tue, 4 Jun 2013 08:01:50 -0700 (PDT) Received: from [127.0.0.1] (unknown [88.182.125.39]) by smtp3-g21.free.fr (Postfix) with ESMTP id 62D74A62C0; Tue, 4 Jun 2013 17:01:43 +0200 (CEST) Message-ID: <51AE0154.8040607@free.fr> Date: Tue, 04 Jun 2013 17:01:40 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000707000606030109010109" X-Antivirus: avast! (VPS 130604-0, 04/06/2013), Outbound message X-Antivirus-Status: Clean Cc: pkix@ietf.org Subject: Re: [pkix] Update need to RFC 3739 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:11:02 -0000 This is a multi-part message in MIME format. --------------000707000606030109010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stefan, The latest version published at http://www.x500standard.com/index.php?n=Ig.LatestAvail. is: ISO/IEC 9594-6:2008 I could not find organisationIdentifier in it. Would you be able indicate your source and copy the text ? Nevertheless, I wonder whether using a new attribute is really necessary. In France, we have defined a French standard (RGS 1.0). I will provide an approximate translation of it: "One instance of an attribute organizationalUnitName MUST be present and MUST contain the identification of the entity. This attribute MUST be structured according to ISO 6523. In France, the format that MUST be used is: - the ICD (International Code Designator) using four characters, - the character "space", and - the identification of the organisation up to 35 characters, As an example, for french organizations the format will be: ICD= 0002 the character "space", the SIREN (9 characters) or SIRET number (14 characters) as given by the french INSEE organisation. If we follow this direction, then already issued certificates for french organisation would already be conformant (in other words nothing would need to be changed). The changes that would be required in RFC 3739 are much more important than you say, starting with the abstract: This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. continuing with : -The Qualified Certificate is issued to a natural person (living human being). continuing with : Of these attributes, the subject field SHALL include at least one of the following: ChoiceI:commonName ChoiceII:givenName Choice III:pseudonym etc... The changes are so important that I wonder that the current proposal is the right way to proceed. A new RFC (or a new ETSI TS) dedicated to organisations be more appropriate. Organisations currently delivering certificates to human beings would be able to continue to refer to RFC 3739 and would not need to change their documentation in order to refer to the latest document (please save our money and our forests !). Organisations that will deliver QCs to organisation units would be able to refer to a new RFC or a new ETSI TS. Denis > Denis, > > The content of the organisationIdentifier is an interesting question. But > it can be done separate to the discussion of the need for an update of > 3739. > The organisationIdentifier is already defined in X.520, so we have no > power over it. It is an unstructured string, much like serialNumber is, > except it is not limited to PrintableString which is a good thing. > > What we need to agree on in the case of 3739 is simply to remove the > requirement that any particular set of attributes must provide a unique > identity, and simply accept that the unique identity is provided by the > complete set of any attributes. > > /Stefan > > > On 5/30/13 4:00 PM, "Denis" wrote: > >> Stefan, >> >> Thank you for raising the issue to the list. >> However, at the time the document was written, there was no mistake. >> >> In France, nobody may get a certificate representing a company or an >> organization. >> Thus a QC cannot be issued to an organization. >> >> However, a certificate could be issued to a department within an >> organisation. >> Thus identifying the department within the organisation (as well as the >> organisation of course) is necessary. >> In other words, using only an organisation identifier is insufficient. >> >> The point which should be discussed on the list is the content of >> proposed "organisationIdentifier". >> It would be interesting to know what you propose for it in principle, >> before issuing a diff document. >> >> Denis >> : >>> Most of what got defined in RFC 3739 was good. >>> >>> It is a very highly deployed standard in the EU. >>> At the time, EU defined Qualified Certificates as something that was >>> only >>> issued to a natural person. >>> >>> However, there is one requirement of RFC 3739 that was doomed to fail >>> given enough time. >>> And that is the required list of attributes in section 3.1.2. >>> >>> In particular this sentence: >>> "Other attributes MAY also be present; however, the use of other >>> attributes MUST NOT be necessary to distinguish one subject name >>> from >>> another subject name. That is, the attributes listed above are >>> sufficient to ensure unique subject names." >>> >>> Yes, I wrote that. And I fully admit my mistake. >>> >>> In particular two things have happened that makes this requirement plain >>> wrong and obsolete. >>> >>> 1) EU has now concluded that QC can be issued not only to people, but to >>> organisations. >>> 2) X.520 has defined a new attribute for organisationIdentifier >>> >>> That attribute is much more suitable to use for an organisation unique >>> identifier rather than serialNumber. Especially if the cert includes >>> information about both a person and an organisation. >>> So the organisationIdentifier attribute may very well be necessary to >>> achieve uniqueness in many cases. >>> >>> It is nether very future proof to assume that serialNumber will be used >>> forever. >>> There are other more suitable attributes that you may want at times. >>> >>> As an example, there is a local Swedish attribute for national Swedish >>> ID >>> numbers used in many Swedish PKI deployments. They will never fit the >>> attribute requirement of RFC 3739. >>> >>> ETSI is currently making interop profiles for QC that are not natural >>> persons. >>> But the EU QC profile EN 319 412-5 relies on RFC 3739. >>> >>> This has created a deadlock where the interop profile will have to >>> violate >>> RFC 3739, unless RFC 3739 is updated. >>> >>> I will initiate an effort to create an update RFC that opens up this >>> requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:) >>> update document. >>> >>> I raise the issue here to get feedback. This probably has to go as a >>> private submission, but as this list is still open, we can always >>> discuss >>> the issue here. >>> >>> /Stefan >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > --------------000707000606030109010109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Stefan,

The latest version published at http://www.x500standard.com/index.php?n=Ig.LatestAvail.
 is: ISO/IEC 9594-6:2008

I could not find organisationIdentifier in it.
 
Would you be able indicate your source and copy the text ?

Nevertheless, I wonder whether using a new attribute is really necessary.

In France, we have defined a French standard (RGS 1.0). I will provide an approximate translation of it:

"One instance of an attribute organizationalUnitName MUST be present and MUST contain the identification of the entity.
This attribute MUST be structured according to ISO 6523.

In France, the format that MUST be used is:

- the ICD (International Code Designator) using four characters,
- the character "space", and
- the identification of the organisation up to 35 characters,

As an example, for french organizations the format will be:

ICD= 0002
the character "space",
the SIREN (9 characters) or SIRET number (14 characters) as given by the french INSEE organisation.

If we follow this direction, then already issued certificates for french organisation would
already be conformant (in other words nothing would need to be changed).

The changes that would be required in RFC 3739 are much more important than you say, starting with the abstract:

   This document forms a certificate profile, based on RFC 3280, for

   identity certificates issued to natural persons.


continuing with :

   -  The Qualified Certificate is issued to a natural person (living

      human being).


continuing with :

   Of these attributes, the subject field SHALL include at least one of

   the following:

 

      Choice   I:  commonName

      Choice  II:  givenName

      Choice III:  pseudonym


etc...

The changes are so important that I wonder that the current proposal is the right way to proceed.

A new RFC (or a new ETSI TS) dedicated to organisations be more appropriate.

Organisations currently delivering certificates to human beings would be able to continue to refer to RFC 3739
and would not need to change their documentation in order to refer to the latest document
(please save our money and our forests !).

Organisations that will deliver QCs to organisation units would be able to refer to a new RFC or a new ETSI TS.

Denis

Denis,

The content of the organisationIdentifier is an interesting question. But
it can be done separate to the discussion of the need for an update of
3739.
The organisationIdentifier is already defined in X.520, so we have no
power over it. It is an unstructured string, much like serialNumber is,
except it is not limited to PrintableString which is a good thing.

What we need to agree on in the case of 3739 is simply to remove the
requirement that any particular set of attributes must provide a unique
identity, and simply accept that the unique identity is provided by the
complete set of any attributes.

/Stefan


On 5/30/13 4:00 PM, "Denis" <denis.ietf@free.fr> wrote:


 Stefan,

Thank you for raising the issue to the list.
However, at the time the document was written, there was no mistake.

In France, nobody may get a certificate representing a company or an
organization.
Thus a QC cannot be issued to an organization.

However, a certificate could be issued to a department within an
organisation.
Thus identifying the department within the organisation (as well as the
organisation of course) is necessary.
In other words, using only an organisation identifier is insufficient.

The point which should be discussed on the list is the content of
proposed "organisationIdentifier".
It would be interesting to know what you propose for it in principle,
before issuing a diff document.

Denis
:

Most of what got defined in RFC 3739 was good.

It is a very highly deployed standard in the EU.
At the time, EU defined Qualified Certificates as something that was
only
issued to a natural person.

However, there is one requirement of RFC 3739 that was doomed to fail
given enough time.
And that is the required list of attributes in section 3.1.2.

In particular this sentence:
"Other attributes MAY also be present; however, the use of other
    attributes MUST NOT be necessary to distinguish one subject name
from
    another subject name.  That is, the attributes listed above are
sufficient to ensure unique subject names."

Yes, I wrote that. And I fully admit my mistake.

In particular two things have happened that makes this requirement plain
wrong and obsolete.

1) EU has now concluded that QC can be issued not only to people, but to
organisations.
2) X.520 has defined a new attribute for organisationIdentifier

That attribute is much more suitable to use for an organisation unique
identifier rather than serialNumber. Especially if the cert includes
information about both a person and an organisation.
So the organisationIdentifier attribute may very well be necessary to
achieve uniqueness in many cases.

It is nether very future proof to assume that serialNumber will be used
forever.
There are other more suitable attributes that you may want at times.

As an example, there is a local Swedish attribute for national Swedish
ID
numbers used in many Swedish PKI deployments. They will never fit the
attribute requirement of RFC 3739.

ETSI is currently making interop profiles for QC that are not natural
persons.
But the EU QC profile EN 319 412-5 relies on RFC 3739.

This has created a deadlock where the interop profile will have to
violate
RFC 3739, unless RFC 3739 is updated.

I will initiate an effort to create an update RFC that opens up this
requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
update document.

I raise the issue here to get feedback. This probably has to go as a
private submission, but as this list is still open, we can always
discuss
the issue here.

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------000707000606030109010109-- From stefan@aaa-sec.com Tue Jun 4 10:21:31 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2C421F99CA for ; Tue, 4 Jun 2013 10:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.993 X-Spam-Level: X-Spam-Status: No, score=-98.993 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em4GJ+6l9SL6 for ; Tue, 4 Jun 2013 10:21:25 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 217B521F96FE for ; Tue, 4 Jun 2013 08:31:27 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7F633D20090 for ; Tue, 4 Jun 2013 17:31:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K3j4Te_B8qC0 for ; Tue, 4 Jun 2013 17:31:24 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 26400D200A0 for ; Tue, 4 Jun 2013 17:31:24 +0200 (CEST) Received: (qmail 59242 invoked from network); 4 Jun 2013 15:31:14 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.220]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Jun 2013 15:31:14 -0000 User-Agent: Microsoft-MacOutlook/14.3.4.130416 Date: Tue, 04 Jun 2013 17:31:06 +0200 From: Stefan Santesson To: Denis Message-ID: Thread-Topic: [pkix] Update need to RFC 3739 In-Reply-To: <51AE0154.8040607@free.fr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3453211873_40545135" Cc: pkix@ietf.org Subject: Re: [pkix] Update need to RFC 3739 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:21:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3453211873_40545135 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit http://www.itu.int/rec/T-REC-X.520-201210-I!Cor3 If we want the new QC profiles of EU to confirm to RFC3739, then RFC 3739 must be updated. That is not only caused by this attribute. /Stefan From: Denis Date: Tuesday, June 4, 2013 5:01 PM To: Stefan Santesson Cc: Subject: Re: [pkix] Update need to RFC 3739 > > > Stefan, > > The latest version published at > http://www.x500standard.com/index.php?n=Ig.LatestAvail. > is: ISO/IEC 9594-6:2008 > > I could not find organisationIdentifier in it. > > Would you be able indicate your source and copy the text ? > > Nevertheless, I wonder whether using a new attribute is really necessary. > > In France, we have defined a French standard (RGS 1.0). I will provide an > approximate translation of it: > > "One instance of an attribute organizationalUnitName MUST be present and MUST > contain the identification of the entity. > This attribute MUST be structured according to ISO 6523. > > In France, the format that MUST be used is: > > - the ICD (International Code Designator) using four characters, > - the character "space", and > - the identification of the organisation up to 35 characters, > > As an example, for french organizations the format will be: > > ICD= 0002 > the character "space", > the SIREN (9 characters) or SIRET number (14 characters) as given by the > french INSEE organisation. > > If we follow this direction, then already issued certificates for french > organisation would > already be conformant (in other words nothing would need to be changed). > > The changes that would be required in RFC 3739 are much more important than > you say, starting with the abstract: > > > > This document forms a certificate profile, based on RFC 3280, for > > identity certificates issued to natural persons. > > continuing with : > > > - The Qualified Certificate is issued to a natural person (living > > human being). > > continuing with : > > > Of these attributes, the subject field SHALL include at least one of > > the following: > > > > Choice I: commonName > > Choice II: givenName > > Choice III: pseudonym > > etc... > > The changes are so important that I wonder that the current proposal is the > right way to proceed. > > A new RFC (or a new ETSI TS) dedicated to organisations be more appropriate. > > Organisations currently delivering certificates to human beings would be able > to continue to refer to RFC 3739 > and would not need to change their documentation in order to refer to the > latest document > (please save our money and our forests !). > > Organisations that will deliver QCs to organisation units would be able to > refer to a new RFC or a new ETSI TS. > > Denis > > > >> >> Denis, >> >> The content of the organisationIdentifier is an interesting question. But >> it can be done separate to the discussion of the need for an update of >> 3739. >> The organisationIdentifier is already defined in X.520, so we have no >> power over it. It is an unstructured string, much like serialNumber is, >> except it is not limited to PrintableString which is a good thing. >> >> What we need to agree on in the case of 3739 is simply to remove the >> requirement that any particular set of attributes must provide a unique >> identity, and simply accept that the unique identity is provided by the >> complete set of any attributes. >> >> /Stefan >> >> >> On 5/30/13 4:00 PM, "Denis" >> wrote: >> >> >>> >>> Stefan, >>> >>> Thank you for raising the issue to the list. >>> However, at the time the document was written, there was no mistake. >>> >>> In France, nobody may get a certificate representing a company or an >>> organization. >>> Thus a QC cannot be issued to an organization. >>> >>> However, a certificate could be issued to a department within an >>> organisation. >>> Thus identifying the department within the organisation (as well as the >>> organisation of course) is necessary. >>> In other words, using only an organisation identifier is insufficient. >>> >>> The point which should be discussed on the list is the content of >>> proposed "organisationIdentifier". >>> It would be interesting to know what you propose for it in principle, >>> before issuing a diff document. >>> >>> Denis >>> : >>> >>>> >>>> Most of what got defined in RFC 3739 was good. >>>> >>>> It is a very highly deployed standard in the EU. >>>> At the time, EU defined Qualified Certificates as something that was >>>> only >>>> issued to a natural person. >>>> >>>> However, there is one requirement of RFC 3739 that was doomed to fail >>>> given enough time. >>>> And that is the required list of attributes in section 3.1.2. >>>> >>>> In particular this sentence: >>>> "Other attributes MAY also be present; however, the use of other >>>> attributes MUST NOT be necessary to distinguish one subject name >>>> from >>>> another subject name. That is, the attributes listed above are >>>> sufficient to ensure unique subject names." >>>> >>>> Yes, I wrote that. And I fully admit my mistake. >>>> >>>> In particular two things have happened that makes this requirement plain >>>> wrong and obsolete. >>>> >>>> 1) EU has now concluded that QC can be issued not only to people, but to >>>> organisations. >>>> 2) X.520 has defined a new attribute for organisationIdentifier >>>> >>>> That attribute is much more suitable to use for an organisation unique >>>> identifier rather than serialNumber. Especially if the cert includes >>>> information about both a person and an organisation. >>>> So the organisationIdentifier attribute may very well be necessary to >>>> achieve uniqueness in many cases. >>>> >>>> It is nether very future proof to assume that serialNumber will be used >>>> forever. >>>> There are other more suitable attributes that you may want at times. >>>> >>>> As an example, there is a local Swedish attribute for national Swedish >>>> ID >>>> numbers used in many Swedish PKI deployments. They will never fit the >>>> attribute requirement of RFC 3739. >>>> >>>> ETSI is currently making interop profiles for QC that are not natural >>>> persons. >>>> But the EU QC profile EN 319 412-5 relies on RFC 3739. >>>> >>>> This has created a deadlock where the interop profile will have to >>>> violate >>>> RFC 3739, unless RFC 3739 is updated. >>>> >>>> I will initiate an effort to create an update RFC that opens up this >>>> requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:) >>>> update document. >>>> >>>> I raise the issue here to get feedback. This probably has to go as a >>>> private submission, but as this list is still open, we can always >>>> discuss >>>> the issue here. >>>> >>>> /Stefan >>>> >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix >>>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix >>> >> >> > > --B_3453211873_40545135 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

If we want the new QC profiles of EU to con= firm to RFC3739, then RFC 3739 must be updated.
That is not only c= aused by this attribute.

/Stefan

<= span style=3D"font-weight:bold">From: Denis <denis.ietf@free.fr>
D= ate: Tuesday, June 4, 2013 5:01 PM
To: Stefan Santesson <stefan= @aaa-sec.com>
Cc: <pkix@ietf.org>
Subject: Re: [pkix] Update need to RFC 3739

=
Stefan,

The latest version published at htt= p://www.x500standard.com/index.php?n=3DIg.LatestAvail.
 is: ISO/IEC 9594-6:2008

I could not find organisationIdentifier in it.
 
Would you be able indicate your source and copy the text ?

Nevertheless, I wonder whether using a new attribute is really necessary.

In France, we have defined a French standard (RGS 1.0). I will provide an approximate translation of it:

"One instance of an attribute organizationalUnitName MUST be present and MUST contain the identification of the entity.
This attribute MUST be structured according to ISO 6523.

In France, the format that MUST be used is:

- the ICD (International Code Designator) usi= ng four characters,
- the character "space", and
- the identification of the organisation up to 35 characters,

As an example, for french organizations the format will be:

ICD=3D 0002
the character "space",
the SIREN (9 characters) or SIRET number (14 characters) as given by the french INSEE organisation.

If we follow this direction, then already issued certificates for french organisation would
already be conformant (in other words nothing would need to be changed).

The changes that would be required in RFC 3739 are much more important than you say, starting with the abstract:

   = This document forms a certificate profile, based on RFC 3280, for

=

   = identity certificates issued to natural persons.


continuing with :

   = -  The Qualified Certificate is issued to a natural person (living

  &= nbsp;   human being).


continuing with :

   Of these attributes, the subject field SHALL include at least one of

   the following:

 

      Choice   I: = commonName

      Choice  II:  givenName

      Choice III:  pseudonym


etc...

The changes are so important that I wonder that the current proposal is the right way to proceed.

A new RFC (or a new ETSI TS) dedicated to organisations be more appropriate.

Organisations currently delivering certificates to human beings would be able to continue to refer to RFC 3739
and would not need to change their documentation in order to refer to the latest document
(please save our money and our forests !).

Organisations that will deliver QCs to organisation units would be able to refer to a new RFC or a new ETSI TS.

Denis

= 
Denis,

The content of the organisationIdentifier is an interesting question. But
it can be done separate to the discussion of the need for an update of
3739.
The organisationIdentifier is already defined in X.520, so we have no
power over it. It is an unstructured string, much like serialNumber is,
except it is not limited to PrintableString which is a good thing.

What we need to agree on in the case of 3739 is simply to remove the
requirement that any particular set of attributes must provide a unique
identity, and simply accept that the unique identity is provided by the
complete set of any attributes.

/Stefan


On 5/30/13 4:00 PM, "Denis" <denis.ietf@free.fr> wrote:


 Stefan,

Thank you for raising the issue to the list.
However, at the time the document was written, there was no mistake.

In France, nobody may get a certificate representing a company or an
organization.
Thus a QC cannot be issued to an organization.

However, a certificate could be issued to a department within an
organisation.
Thus identifying the department within the organisation (as well as the
organisation of course) is necessary.
In other words, using only an organisation identifier is insufficient.

The point which should be discussed on the list is the content of
proposed "organisationIdentifier".
It would be interesting to know what you propose for it in principle,
before issuing a diff document.

Denis
:

Most of what got defined in RFC 3739 was good.

It is a very highly deployed standard in the EU.
At the time, EU defined Qualified Certificates as something that was
only
issued to a natural person.

However, there is one requirement of RFC 3739 that was doomed to fail
given enough time.
And that is the required list of attributes in section 3.1.2.

In particular this sentence:
"Other attributes MAY also be present; however, the use of other
    attributes MUST NOT be necessary to distinguish one subject name
from
    another subject name.  That is, the attributes listed above are
sufficient to ensure unique subject names."

Yes, I wrote that. And I fully admit my mistake.

In particular two things have happened that makes this requirement plain
wrong and obsolete.

1) EU has now concluded that QC can be issued not only to people, but to
organisations.
2) X.520 has defined a new attribute for organisationIdentifier

That attribute is much more suitable to use for an organisation unique
identifier rather than serialNumber. Especially if the cert includes
information about both a person and an organisation.
So the organisationIdentifier attribute may very well be necessary to
achieve uniqueness in many cases.

It is nether very future proof to assume that serialNumber will be used
forever.
There are other more suitable attributes that you may want at times.

As an example, there is a local Swedish attribute for national Swedish
ID
numbers used in many Swedish PKI deployments. They will never fit the
attribute requirement of RFC 3739.

ETSI is currently making interop profiles for QC that are not natural
persons.
But the EU QC profile EN 319 412-5 relies on RFC 3739.

This has created a deadlock where the interop profile will have to
violate
RFC 3739, unless RFC 3739 is updated.

I will initiate an effort to create an update RFC that opens up this
requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
update document.

I raise the issue here to get feedback. This probably has to go as a
private submission, but as this list is still open, we can always
discuss
the issue here.

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.o=
rghttps://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix@ietf.o=
rghttps://www.ietf.org/mailman/listinfo/pkix

    

    

  


--B_3453211873_40545135--



From denis.ietf@free.fr  Tue Jun  4 10:46:34 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3721F93D2 for ; Tue,  4 Jun 2013 10:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.153
X-Spam-Level: **
X-Spam-Status: No, score=2.153 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmSqM5SEnS8z for ; Tue,  4 Jun 2013 10:46:30 -0700 (PDT)
Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12]) by ietfa.amsl.com (Postfix) with ESMTP id F2ED221F91B8 for ; Tue,  4 Jun 2013 09:46:01 -0700 (PDT)
Received: from [127.0.0.1] (unknown [88.182.125.39]) by smtp3-g21.free.fr (Postfix) with ESMTP id 56CDBA60E4; Tue,  4 Jun 2013 18:45:54 +0200 (CEST)
Message-ID: <51AE19BF.8090506@free.fr>
Date: Tue, 04 Jun 2013 18:45:51 +0200
From: Denis 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Stefan Santesson 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090300080301060908030303"
X-Antivirus: avast! (VPS 130604-0, 04/06/2013), Outbound message
X-Antivirus-Status: Clean
Cc: pkix@ietf.org
Subject: Re: [pkix] Update need to RFC 3739
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jun 2013 17:46:34 -0000

This is a multi-part message in MIME format.
--------------090300080301060908030303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan,

Thank you for the link.

The definition is:

organizationIdentifier ATTRIBUTE ::= {
   WITH SYNTAX               UnboundedDirectoryString
   EQUALITY MATCHING RULE    caseIgnoreMatch
   SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
   SINGLE VALUE              TRUE
   ID                        id-at-organizationIdentifier }

This structure is insufficient, since it is too wide open (it is not a 
structured field).
The second question will be whether using organisationIdentifier would 
more appropriate or not than using organizationalUnitName.

The second point is that the only currently valid text is the EU 
Directive from 1999.

You seem to anticipate some changes. However at the present time, no 
change has been agreed by the EU MS.

There is a proposed regulation currently being discussed. I am not keen 
to make change in anticipation of a text
which has not yet been approved and which is not even public anymore.

Finally, you mention that there are other changes are needed, but I 
omitted to provide a rational.

Denis

> http://www.itu.int/rec/T-REC-X.520-201210-I!Cor3 
> 
>
> If we want the new QC profiles of EU to confirm to RFC3739, then RFC 
> 3739 must be updated.
> That is not only caused by this attribute.
>
> /Stefan
>
> From: Denis >
> Date: Tuesday, June 4, 2013 5:01 PM
> To: Stefan Santesson >
> Cc: >
> Subject: Re: [pkix] Update need to RFC 3739
>
>     Stefan,
>
>     The latest version published at
>     http://www.x500standard.com/index.php?n=Ig.LatestAvail.
>     is: ISO/IEC 9594-6:2008
>
>     I could not find organisationIdentifier in it.
>
>     Would you be able indicate your source and copy the text ?
>
>     Nevertheless, I wonder whether using a new attribute is really
>     necessary.
>
>     In France, we have defined a French standard (RGS 1.0). I will
>     provide an approximate translation of it:
>
>     "One instance of an attribute organizationalUnitName MUST be
>     present and MUST contain the identification of the entity.
>     This attribute MUST be structured according to ISO 6523.
>
>     In France, the format that MUST be used is:
>
>     - the ICD (International Code Designator) using four characters,
>     - the character "space", and
>     - the identification of the organisation up to 35 characters,
>
>     As an example, for french organizations the format will be:
>
>     ICD= 0002
>     the character "space",
>     the SIREN (9 characters) or SIRET number (14 characters) as given
>     by the french INSEE organisation.
>
>     If we follow this direction, then already issued certificates for
>     french organisation would
>     already be conformant (in other words nothing would need to be
>     changed).
>
>     The changes that would be required in RFC 3739 are much more
>     important than you say, starting with the abstract:
>
>     This document forms a certificate profile, based on RFC 3280, for
>
>     identity certificates issued to natural persons.
>
>
>     continuing with :
>
>     -The Qualified Certificate is issued to a natural person (living
>
>     human being).
>
>
>     continuing with :
>
>     Of these attributes, the subject field SHALL include at least one of
>
>     the following:
>
>     ChoiceI:commonName
>
>     ChoiceII:givenName
>
>     Choice III:pseudonym
>
>
>     etc...
>
>     The changes are so important that I wonder that the current
>     proposal is the right way to proceed.
>
>     A new RFC (or a new ETSI TS) dedicated to organisations be more
>     appropriate.
>
>     Organisations currently delivering certificates to human beings
>     would be able to continue to refer to RFC 3739
>     and would not need to change their documentation in order to refer
>     to the latest document
>     (please save our money and our forests !).
>
>     Organisations that will deliver QCs to organisation units would be
>     able to refer to a new RFC or a new ETSI TS.
>
>     Denis
>
>>     Denis,
>>
>>     The content of the organisationIdentifier is an interesting question. But
>>     it can be done separate to the discussion of the need for an update of
>>     3739.
>>     The organisationIdentifier is already defined in X.520, so we have no
>>     power over it. It is an unstructured string, much like serialNumber is,
>>     except it is not limited to PrintableString which is a good thing.
>>
>>     What we need to agree on in the case of 3739 is simply to remove the
>>     requirement that any particular set of attributes must provide a unique
>>     identity, and simply accept that the unique identity is provided by the
>>     complete set of any attributes.
>>
>>     /Stefan
>>
>>
>>     On 5/30/13 4:00 PM, "Denis"  wrote:
>>
>>>       Stefan,
>>>
>>>     Thank you for raising the issue to the list.
>>>     However, at the time the document was written, there was no mistake.
>>>
>>>     In France, nobody may get a certificate representing a company or an
>>>     organization.
>>>     Thus a QC cannot be issued to an organization.
>>>
>>>     However, a certificate could be issued to a department within an
>>>     organisation.
>>>     Thus identifying the department within the organisation (as well as the
>>>     organisation of course) is necessary.
>>>     In other words, using only an organisation identifier is insufficient.
>>>
>>>     The point which should be discussed on the list is the content of
>>>     proposed "organisationIdentifier".
>>>     It would be interesting to know what you propose for it in principle,
>>>     before issuing a diff document.
>>>
>>>     Denis
>>>     :
>>>>     Most of what got defined in RFC 3739 was good.
>>>>
>>>>     It is a very highly deployed standard in the EU.
>>>>     At the time, EU defined Qualified Certificates as something that was
>>>>     only
>>>>     issued to a natural person.
>>>>
>>>>     However, there is one requirement of RFC 3739 that was doomed to fail
>>>>     given enough time.
>>>>     And that is the required list of attributes in section 3.1.2.
>>>>
>>>>     In particular this sentence:
>>>>     "Other attributes MAY also be present; however, the use of other
>>>>          attributes MUST NOT be necessary to distinguish one subject name
>>>>     from
>>>>          another subject name.  That is, the attributes listed above are
>>>>     sufficient to ensure unique subject names."
>>>>
>>>>     Yes, I wrote that. And I fully admit my mistake.
>>>>
>>>>     In particular two things have happened that makes this requirement plain
>>>>     wrong and obsolete.
>>>>
>>>>     1) EU has now concluded that QC can be issued not only to people, but to
>>>>     organisations.
>>>>     2) X.520 has defined a new attribute for organisationIdentifier
>>>>
>>>>     That attribute is much more suitable to use for an organisation unique
>>>>     identifier rather than serialNumber. Especially if the cert includes
>>>>     information about both a person and an organisation.
>>>>     So the organisationIdentifier attribute may very well be necessary to
>>>>     achieve uniqueness in many cases.
>>>>
>>>>     It is nether very future proof to assume that serialNumber will be used
>>>>     forever.
>>>>     There are other more suitable attributes that you may want at times.
>>>>
>>>>     As an example, there is a local Swedish attribute for national Swedish
>>>>     ID
>>>>     numbers used in many Swedish PKI deployments. They will never fit the
>>>>     attribute requirement of RFC 3739.
>>>>
>>>>     ETSI is currently making interop profiles for QC that are not natural
>>>>     persons.
>>>>     But the EU QC profile EN 319 412-5 relies on RFC 3739.
>>>>
>>>>     This has created a deadlock where the interop profile will have to
>>>>     violate
>>>>     RFC 3739, unless RFC 3739 is updated.
>>>>
>>>>     I will initiate an effort to create an update RFC that opens up this
>>>>     requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
>>>>     update document.
>>>>
>>>>     I raise the issue here to get feedback. This probably has to go as a
>>>>     private submission, but as this list is still open, we can always
>>>>     discuss
>>>>     the issue here.
>>>>
>>>>     /Stefan
>>>>
>>>>
>>>>     _______________________________________________
>>>>     pkix mailing list
>>>>     pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>     _______________________________________________
>>>     pkix mailing list
>>>     pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>


--------------090300080301060908030303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Stefan,

      

      Thank you for the link.

      

      The definition is:

      

      organizationIdentifier ATTRIBUTE ::= { 

        WITH SYNTAX               UnboundedDirectoryString 

        EQUALITY MATCHING RULE    caseIgnoreMatch 

        SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch 

        SINGLE VALUE              TRUE 

        ID                        id-at-organizationIdentifier } 

      

      This structure is insufficient, since it is too wide open (it is
      not a structured field). 

      The second question will be whether using organisationIdentifier would more appropriate
      or not than using organizationalUnitName.

      

      The second point is that the only currently valid text is the EU
      Directive from 1999.

      

      You seem to anticipate some changes. However at the present time,
      no change has been agreed by the EU MS.

      

      There is a proposed regulation currently being discussed. I am not
      keen to make change in anticipation of a text 

      which has not yet been approved and which is not even public
      anymore.

      

      Finally, you mention that there are other changes are needed, but
      I omitted to provide a rational.

      

      Denis

      

    

    

      
      


      

      
If we want the new QC profiles of EU to confirm to RFC3739,
        then RFC 3739 must be updated.

      
That is not only caused by this attribute.

      


      

      
/Stefan

      


      

      
        
From:  Denis <denis.ietf@free.fr>

          Date:  Tuesday, June 4,
          2013 5:01 PM

          To:  Stefan Santesson
          <stefan@aaa-sec.com>

          Cc:  <pkix@ietf.org>

          Subject:  Re: [pkix]
          Update need to RFC 3739

        

        


        

        

          

            
            

              
Stefan,

                

                The latest version published at
                
                http://www.x500standard.com/index.php?n=Ig.LatestAvail.

                
                
                
                
                
                
                is: ISO/IEC 9594-6:2008

                

                I could not find organisationIdentifier in it.

                  

                Would you be able indicate your source and copy the text
                ?

                

                Nevertheless, I wonder whether using a new attribute is
                really necessary.

                

                In France, we have defined a French standard (RGS 1.0).
                I will provide an approximate translation of it:

                

                "One instance of an attribute organizationalUnitName
                MUST be present and MUST contain the identification of
                the entity. 

                This attribute MUST be structured according to ISO 6523.

                

                In France, the format that MUST be used is:

                

                - the ICD (International Code
                  Designator) using four characters,

                - the character "space", and

                - the identification of the organisation up to 35
                characters,

                

                As an example, for french organizations the format will
                be:

                

                ICD= 0002

                the character "space",

                the SIREN (9 characters) or SIRET number (14 characters)
                as given by the french INSEE organisation.

                

                If we follow this direction, then already issued
                certificates for french organisation would 

                already be conformant (in other words nothing would need
                to be changed).

                

                The changes that would be required in RFC 3739 are much
                more important than you say, starting with the abstract:

                

                
                
   This document
                    forms a certificate profile, based on RFC 3280, for

                
   identity
                    certificates issued to natural persons.

                
                
                
                
                
                

                continuing with :

                

                
                
   -  The Qualified
                    Certificate is issued to a natural person (living

                
      human

                  being).

                

                continuing with :

                

                
                
   Of these
                  attributes, the subject field SHALL include at least
                  one of

                
   the following:

                
 

                
      Choice   I:  commonName

                
      Choice  II:  givenName

                
      Choice III:  pseudonym

                
                
                
                
                
                

                etc...
                
                
                
                
                
                

                

                The changes are so important that I wonder that the
                current proposal is the right way to proceed.

                

                A new RFC (or a new ETSI TS) dedicated to organisations
                be more appropriate.

                

                Organisations currently delivering certificates to human
                beings would be able to continue to refer to RFC 3739 

                and would not need to change their documentation in
                order to refer to the latest document 

                (please save our money and our forests !).

                

                Organisations that will deliver QCs to organisation
                units would be able to refer to a new RFC or a new ETSI
                TS.

                

                Denis

                

              

              

                
Denis,

The content of the organisationIdentifier is an interesting question. But
it can be done separate to the discussion of the need for an update of
3739.
The organisationIdentifier is already defined in X.520, so we have no
power over it. It is an unstructured string, much like serialNumber is,
except it is not limited to PrintableString which is a good thing.

What we need to agree on in the case of 3739 is simply to remove the
requirement that any particular set of attributes must provide a unique
identity, and simply accept that the unique identity is provided by the
complete set of any attributes.

/Stefan


On 5/30/13 4:00 PM, "Denis" <denis.ietf@free.fr> wrote:



                

                  
 Stefan,

Thank you for raising the issue to the list.
However, at the time the document was written, there was no mistake.

In France, nobody may get a certificate representing a company or an
organization.
Thus a QC cannot be issued to an organization.

However, a certificate could be issued to a department within an
organisation.
Thus identifying the department within the organisation (as well as the
organisation of course) is necessary.
In other words, using only an organisation identifier is insufficient.

The point which should be discussed on the list is the content of
proposed "organisationIdentifier".
It would be interesting to know what you propose for it in principle,
before issuing a diff document.

Denis
:


                  

                    
Most of what got defined in RFC 3739 was good.

It is a very highly deployed standard in the EU.
At the time, EU defined Qualified Certificates as something that was
only
issued to a natural person.

However, there is one requirement of RFC 3739 that was doomed to fail
given enough time.
And that is the required list of attributes in section 3.1.2.

In particular this sentence:
"Other attributes MAY also be present; however, the use of other
    attributes MUST NOT be necessary to distinguish one subject name
from
    another subject name.  That is, the attributes listed above are
sufficient to ensure unique subject names."

Yes, I wrote that. And I fully admit my mistake.

In particular two things have happened that makes this requirement plain
wrong and obsolete.

1) EU has now concluded that QC can be issued not only to people, but to
organisations.
2) X.520 has defined a new attribute for organisationIdentifier

That attribute is much more suitable to use for an organisation unique
identifier rather than serialNumber. Especially if the cert includes
information about both a person and an organisation.
So the organisationIdentifier attribute may very well be necessary to
achieve uniqueness in many cases.

It is nether very future proof to assume that serialNumber will be used
forever.
There are other more suitable attributes that you may want at times.

As an example, there is a local Swedish attribute for national Swedish
ID
numbers used in many Swedish PKI deployments. They will never fit the
attribute requirement of RFC 3739.

ETSI is currently making interop profiles for QC that are not natural
persons.
But the EU QC profile EN 319 412-5 relies on RFC 3739.

This has created a deadlock where the interop profile will have to
violate
RFC 3739, unless RFC 3739 is updated.

I will initiate an effort to create an update RFC that opens up this
requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
update document.

I raise the issue here to get feedback. This probably has to go as a
private submission, but as this list is still open, we can always
discuss
the issue here.

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix

                  

                  
_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix

                

              

              

            

          

        

      
    

    

  


--------------090300080301060908030303--

From stefan@aaa-sec.com  Tue Jun  4 10:53:49 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D6121F9CF8 for ; Tue,  4 Jun 2013 10:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.363
X-Spam-Level: 
X-Spam-Status: No, score=-99.363 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt1-bp61fZkL for ; Tue,  4 Jun 2013 10:53:44 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 67B4621E80FA for ; Tue,  4 Jun 2013 10:05:22 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id AA1C4D21B5F for ; Tue,  4 Jun 2013 19:05:20 +0200 (CEST)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ehHCL_b4d6Tm for ; Tue,  4 Jun 2013 19:05:19 +0200 (CEST)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 020D5D21B77 for ; Tue,  4 Jun 2013 19:05:19 +0200 (CEST)
Received: (qmail 76220 invoked from network); 4 Jun 2013 17:05:18 -0000
Received: from unknown (HELO [192.168.1.87]) (stefan@fiddler.nu@[85.219.172.67]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Jun 2013 17:05:18 -0000
User-Agent: Microsoft-MacOutlook/14.3.4.130416
Date: Tue, 04 Jun 2013 19:04:51 +0200
From: Stefan Santesson 
To: Denis 
Message-ID: 
Thread-Topic: [pkix] Update need to RFC 3739
In-Reply-To: <51AE19BF.8090506@free.fr>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3453217518_40902510"
Cc: pkix@ietf.org
Subject: Re: [pkix] Update need to RFC 3739
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jun 2013 17:53:49 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3453217518_40902510
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Denis,

I have limited time right now.

Since the organizationIdentifier is simply a string, you can set it to any
string value.
It will then be understood as an arbitrary identifier unless you use some
mechanism to further contrain the format.
A typical use of this attribute I foresee is an identifier from a national
company registry. But that is not mandated.

OranizationalUnitName is a bit different, as it is a name of an
organisational unit.

EU has proposed to allow legal person and web server certificates to be
issued as QC. Neither will fit the narrow attribute list of RFC 3739.
ETSI is creating cert profiles for it in the 319 412 series.

This will require an update of RFC 3739.

/Stefan



From:  Denis 
Date:  Tuesday, June 4, 2013 6:45 PM
To:  Stefan Santesson 
Cc:  
Subject:  Re: [pkix] Update need to RFC 3739

>     
>  
> Stefan,
>  
>  Thank you for the link.
>  
>  The definition is:
>  
>  organizationIdentifier ATTRIBUTE ::= {
>    WITH SYNTAX               UnboundedDirectoryString
>    EQUALITY MATCHING RULE    caseIgnoreMatch
>    SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
>    SINGLE VALUE              TRUE
>    ID                        id-at-organizationIdentifier }
>  
>  This structure is insufficient, since it is too wide open (it is not a
> structured field).
>  The second question will be whether using organisationIdentifier would more
> appropriate or not than using organizationalUnitName.
>  
>  The second point is that the only currently valid text is the EU Directive
> from 1999.
>  
>  You seem to anticipate some changes. However at the present time, no change
> has been agreed by the EU MS.
>  
>  There is a proposed regulation currently being discussed. I am not keen to
> make change in anticipation of a text
>  which has not yet been approved and which is not even public anymore.
>  
>  Finally, you mention that there are other changes are needed, but I omitted
> to provide a rational.
>  
>  Denis
>  
>  
>  
>>  
>> http://www.itu.int/rec/T-REC-X.520-201210-I!Cor3
>> 
>>  
>> 
>>  
>>  
>> If we want the new QC profiles of EU to confirm to RFC3739, then RFC 3739
>> must be updated.
>>  
>> That is not only caused by this attribute.
>>  
>> 
>>  
>>  
>> /Stefan
>>  
>> 
>>  
>>   
>> From:  Denis 
>>  Date:  Tuesday, June 4, 2013 5:01 PM
>>  To:  Stefan Santesson 
>>  Cc:  
>>  Subject:  Re: [pkix] Update need to RFC 3739
>>  
>>  
>> 
>>  
>>  
>>>  
>>>   
>>>  
>>> Stefan,
>>>  
>>>  The latest version published at
>>> http://www.x500standard.com/index.php?n=Ig.LatestAvail.
>>>        is: ISO/IEC 9594-6:2008
>>>  
>>>  I could not find organisationIdentifier in it.
>>>    
>>>  Would you be able indicate your source and copy the text ?
>>>  
>>>  Nevertheless, I wonder whether using a new attribute is really necessary.
>>>  
>>>  In France, we have defined a French standard (RGS 1.0). I will provide an
>>> approximate translation of it:
>>>  
>>>  "One instance of an attribute organizationalUnitName MUST be present and
>>> MUST contain the identification of the entity.
>>>  This attribute MUST be structured according to ISO 6523.
>>>  
>>>  In France, the format that MUST be used is:
>>>  
>>>  - the ICD (International Code Designator) using four characters,
>>>  - the character "space", and
>>>  - the identification of the organisation up to 35 characters,
>>>  
>>>  As an example, for french organizations the format will be:
>>>  
>>>  ICD= 0002
>>>  the character "space",
>>>  the SIREN (9 characters) or SIRET number (14 characters) as given by the
>>> french INSEE organisation.
>>>  
>>>  If we follow this direction, then already issued certificates for french
>>> organisation would
>>>  already be conformant (in other words nothing would need to be changed).
>>>  
>>>  The changes that would be required in RFC 3739 are much more important than
>>> you say, starting with the abstract:
>>>  
>>>   
>>> 
>>>    This document forms a certificate profile, based on RFC 3280, for
>>>  
>>>    identity certificates issued to natural persons.
>>>       
>>>  continuing with :
>>>  
>>>   
>>>    -  The Qualified Certificate is issued to a natural person (living
>>>  
>>>       human  being).
>>>  
>>>  continuing with :
>>>  
>>>   
>>>    Of these attributes, the subject field SHALL include at least one of
>>>  
>>>    the following:
>>>  
>>>  
>>>  
>>>       Choice   I:  commonName
>>>  
>>>       Choice  II:  givenName
>>>  
>>>       Choice III:  pseudonym
>>>       
>>>  etc...      
>>>  
>>>  The changes are so important that I wonder that the current proposal is the
>>> right way to proceed.
>>>  
>>>  A new RFC (or a new ETSI TS) dedicated to organisations be more
>>> appropriate.
>>>  
>>>  Organisations currently delivering certificates to human beings would be
>>> able to continue to refer to RFC 3739
>>>  and would not need to change their documentation in order to refer to the
>>> latest document
>>>  (please save our money and our forests !).
>>>  
>>>  Organisations that will deliver QCs to organisation units would be able to
>>> refer to a new RFC or a new ETSI TS.
>>>  
>>>  Denis
>>>  
>>>  
>>>  
>>>>  
>>>> Denis,
>>>> 
>>>> The content of the organisationIdentifier is an interesting question. But
>>>> it can be done separate to the discussion of the need for an update of
>>>> 3739.
>>>> The organisationIdentifier is already defined in X.520, so we have no
>>>> power over it. It is an unstructured string, much like serialNumber is,
>>>> except it is not limited to PrintableString which is a good thing.
>>>> 
>>>> What we need to agree on in the case of 3739 is simply to remove the
>>>> requirement that any particular set of attributes must provide a unique
>>>> identity, and simply accept that the unique identity is provided by the
>>>> complete set of any attributes.
>>>> 
>>>> /Stefan
>>>> 
>>>> 
>>>> On 5/30/13 4:00 PM, "Denis" 
>>>>   wrote:
>>>> 
>>>>  
>>>>>  
>>>>>  Stefan,
>>>>> 
>>>>> Thank you for raising the issue to the list.
>>>>> However, at the time the document was written, there was no mistake.
>>>>> 
>>>>> In France, nobody may get a certificate representing a company or an
>>>>> organization.
>>>>> Thus a QC cannot be issued to an organization.
>>>>> 
>>>>> However, a certificate could be issued to a department within an
>>>>> organisation.
>>>>> Thus identifying the department within the organisation (as well as the
>>>>> organisation of course) is necessary.
>>>>> In other words, using only an organisation identifier is insufficient.
>>>>> 
>>>>> The point which should be discussed on the list is the content of
>>>>> proposed "organisationIdentifier".
>>>>> It would be interesting to know what you propose for it in principle,
>>>>> before issuing a diff document.
>>>>> 
>>>>> Denis
>>>>> :
>>>>>  
>>>>>>  
>>>>>> Most of what got defined in RFC 3739 was good.
>>>>>> 
>>>>>> It is a very highly deployed standard in the EU.
>>>>>> At the time, EU defined Qualified Certificates as something that was
>>>>>> only
>>>>>> issued to a natural person.
>>>>>> 
>>>>>> However, there is one requirement of RFC 3739 that was doomed to fail
>>>>>> given enough time.
>>>>>> And that is the required list of attributes in section 3.1.2.
>>>>>> 
>>>>>> In particular this sentence:
>>>>>> "Other attributes MAY also be present; however, the use of other
>>>>>>     attributes MUST NOT be necessary to distinguish one subject name
>>>>>> from
>>>>>>     another subject name.  That is, the attributes listed above are
>>>>>> sufficient to ensure unique subject names."
>>>>>> 
>>>>>> Yes, I wrote that. And I fully admit my mistake.
>>>>>> 
>>>>>> In particular two things have happened that makes this requirement plain
>>>>>> wrong and obsolete.
>>>>>> 
>>>>>> 1) EU has now concluded that QC can be issued not only to people, but to
>>>>>> organisations.
>>>>>> 2) X.520 has defined a new attribute for organisationIdentifier
>>>>>> 
>>>>>> That attribute is much more suitable to use for an organisation unique
>>>>>> identifier rather than serialNumber. Especially if the cert includes
>>>>>> information about both a person and an organisation.
>>>>>> So the organisationIdentifier attribute may very well be necessary to
>>>>>> achieve uniqueness in many cases.
>>>>>> 
>>>>>> It is nether very future proof to assume that serialNumber will be used
>>>>>> forever.
>>>>>> There are other more suitable attributes that you may want at times.
>>>>>> 
>>>>>> As an example, there is a local Swedish attribute for national Swedish
>>>>>> ID
>>>>>> numbers used in many Swedish PKI deployments. They will never fit the
>>>>>> attribute requirement of RFC 3739.
>>>>>> 
>>>>>> ETSI is currently making interop profiles for QC that are not natural
>>>>>> persons.
>>>>>> But the EU QC profile EN 319 412-5 relies on RFC 3739.
>>>>>> 
>>>>>> This has created a deadlock where the interop profile will have to
>>>>>> violate
>>>>>> RFC 3739, unless RFC 3739 is updated.
>>>>>> 
>>>>>> I will initiate an effort to create an update RFC that opens up this
>>>>>> requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
>>>>>> update document.
>>>>>> 
>>>>>> I raise the issue here to get feedback. This probably has to go as a
>>>>>> private submission, but as this list is still open, we can always
>>>>>> discuss
>>>>>> the issue here.
>>>>>> 
>>>>>> /Stefan
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> pkix mailing list
>>>>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>>>>  
>>>>>  
>>>>> _______________________________________________
>>>>> pkix mailing list
>>>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>>>  
>>>>  
>>>  
>>>  
>>>  
>>>  
>>   
>  
>  



--B_3453217518_40902510
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


Denis,

<=
div>I have limited time right now.

Since the organi=
zationIdentifier is simply a string, you can set it to any string value.
It will then be understood as an arbitrary identifier unless you use =
some mechanism to further contrain the format.
A typical use of th=
is attribute I foresee is an identifier from a national company registry. Bu=
t that is not mandated.

OranizationalUnitName is a =
bit different, as it is a name of an organisational unit.

EU has proposed to allow legal person and web server certificates to =
be issued as QC. Neither will fit the narrow attribute list of RFC 3739.
ETSI is creating cert profiles for it in the 319 412 series.

This will require an update of RFC 3739.

/Stefan



From:  Denis <denis.ietf@free.fr>
Date:  =
Tuesday, June 4, 2013 6:45 PM
To:  =
Stefan Santesson <stefan@aaa-sec.com<=
/a>>
Cc:  <pkix@ietf.org>
Subject=
:  Re: [pkix] Update need to RFC 3739


  
    
  
  

    
Stefan,

      

      Thank you for the link.

      

      The definition is:

      

      organizationIdentifier ATTRIBUTE ::=3D { 

        WITH SYNTAX        &nb=
sp;      UnboundedDirectoryString 

        EQUALITY MATCHING RULE    caseIgnoreMatch 

        SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch 

        SINGLE VALUE        &n=
bsp;     TRUE 

        ID          =
            &nbs=
p; id-at-organizationIdentifier } 

      

      This structure is insufficient, since it is too wide open (it is
      not a structured field). 

      The second question will be whether using organisationIdentifier would more appropriate
      or not than using organizationalUnitN=
ame.

      

      The second point is that the only currently valid text is the EU
      Directive from 1999.

      

      You seem to anticipate some changes. However at the present time,
      no change has been agreed by the EU MS.

      

      There is a proposed regulation currently being discussed. I am not
      keen to make change in anticipation of a text 

      which has not yet been approved and which is not even public
      anymore.

      

      Finally, you mention that there are other changes are needed, but
      I omitted to provide a rational.

      

      Denis

      

    

    
=

      
http://www.itu.int/rec/T-REC-X.520-201210-I!Cor3
      


      

      
If we want the new QC profiles of EU to confirm to RFC3739,
        then RFC 3739 must be updated.

      
That is not only caused by this attribute.

      


      

      
/Stefan

      


      

      
        
From:  Denis <denis.ietf@free.fr>

          Date:  Tuesday, June 4,
          2013 5:01 PM

          To:  Stefan Santesson
          <st=
efan@aaa-sec.com>

          Cc:  <pkix@ietf.org>

          Subject:  Re: [pkix]
          Update need to RFC 3739

        

        


        

        

          

            
            

              
Stefan,

                

                The latest version published at
                
                http://www.x500standar=
d.com/index.php?n=3DIg.LatestAvail.

                
                
                
                
                
                
                is: ISO/IEC 9594-6:2008

                

                I could not find organisationIdentifier in it.

                  

                Would you be able indicate your source and copy the text
                ?

                

                Nevertheless, I wonder whether using a new attribute is
                really necessary.

                

                In France, we have defined a French standard (RGS 1.0).
                I will provide an approximate translation of it:

                

                "One instance of an attribute organizationalUnitName
                MUST be present and MUST contain the identification of
                the entity. 

                This attribute MUST be structured according to ISO 6523.
                

                In France, the format that MUST be used is:

                

                - the ICD (International Code
                  Designator) using four characters,

                - the character "space", and

                - the identification of the organisation up to 35
                characters,

                

                As an example, for french organizations the format will
                be:

                

                ICD=3D 0002

                the character "space",

                the SIREN (9 characters) or SIRET number (14 characters)
                as given by the french INSEE organisation.

                

                If we follow this direction, then already issued
                certificates for french organisation would 

                already be conformant (in other words nothing would need
                to be changed).

                

                The changes that would be required in RFC 3739 are much
                more important than you say, starting with the abstract:
                

                
                
&nbs=
p;  This document
                    forms a certificate profile, based on RFC 3280, for

                
&nbs=
p;  identity
                    certificates issued to natural persons.

                
                
                
                
                
                

                continuing with :

                

                
                
&nbs=
p;  -  The Qualified=

                    Certificate is issued to a natural person (living<=
/o:p>

                
&nbs=
p;     human

                  being).

                

                continuing with :

                

                
                
   Of these
                  attributes, the subject field SHALL include at least
                  one of

                
   the following:

                
 

                
      Choice   I:&n=
bsp; commonName

                
      Choice  II:  =
givenName

                
      Choice III:  pseudonym

                
                
                
                
                
                

                etc...
                
                
                
                
                
                

                

                The changes are so important that I wonder that the
                current proposal is the right way to proceed.

                

                A new RFC (or a new ETSI TS) dedicated to organisations
                be more appropriate.

                

                Organisations currently delivering certificates to human
                beings would be able to continue to refer to RFC 3739 

                and would not need to change their documentation in
                order to refer to the latest document 

                (please save our money and our forests !).

                

                Organisations that will deliver QCs to organisation
                units would be able to refer to a new RFC or a new ETSI
                TS.

                

                Denis

                

              

              

                
Denis,

The content of the organisationIdentifier is an interesting question. But
it can be done separate to the discussion of the need for an update of
3739.
The organisationIdentifier is already defined in X.520, so we have no
power over it. It is an unstructured string, much like serialNumber is,
except it is not limited to PrintableString which is a good thing.

What we need to agree on in the case of 3739 is simply to remove the
requirement that any particular set of attributes must provide a unique
identity, and simply accept that the unique identity is provided by the
complete set of any attributes.

/Stefan


On 5/30/13 4:00 PM, "Denis" <denis.ietf@free.fr> wro=
te:



                

                  
 Stefan,

Thank you for raising the issue to the list.
However, at the time the document was written, there was no mistake.

In France, nobody may get a certificate representing a company or an
organization.
Thus a QC cannot be issued to an organization.

However, a certificate could be issued to a department within an
organisation.
Thus identifying the department within the organisation (as well as the
organisation of course) is necessary.
In other words, using only an organisation identifier is insufficient.

The point which should be discussed on the list is the content of
proposed "organisationIdentifier".
It would be interesting to know what you propose for it in principle,
before issuing a diff document.

Denis
:


                  

                    
Most of what got defined in RFC 3739 was g=
ood.

It is a very highly deployed standard in the EU.
At the time, EU defined Qualified Certificates as something that was
only
issued to a natural person.

However, there is one requirement of RFC 3739 that was doomed to fail
given enough time.
And that is the required list of attributes in section 3.1.2.

In particular this sentence:
"Other attributes MAY also be present; however, the use of other
    attributes MUST NOT be necessary to distinguish one subject name
from
    another subject name.  That is, the attributes listed above are
sufficient to ensure unique subject names."

Yes, I wrote that. And I fully admit my mistake.

In particular two things have happened that makes this requirement plain
wrong and obsolete.

1) EU has now concluded that QC can be issued not only to people, but to
organisations.
2) X.520 has defined a new attribute for organisationIdentifier

That attribute is much more suitable to use for an organisation unique
identifier rather than serialNumber. Especially if the cert includes
information about both a person and an organisation.
So the organisationIdentifier attribute may very well be necessary to
achieve uniqueness in many cases.

It is nether very future proof to assume that serialNumber will be used
forever.
There are other more suitable attributes that you may want at times.

As an example, there is a local Swedish attribute for national Swedish
ID
numbers used in many Swedish PKI deployments. They will never fit the
attribute requirement of RFC 3739.

ETSI is currently making interop profiles for QC that are not natural
persons.
But the EU QC profile EN 319 412-5 relies on RFC 3739.

This has created a deadlock where the interop profile will have to
violate
RFC 3739, unless RFC 3739 is updated.

I will initiate an effort to create an update RFC that opens up this
requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
update document.

I raise the issue here to get feedback. This probably has to go as a
private submission, but as this list is still open, we can always
discuss
the issue here.

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix

                  

                  
____________________________________________=
___
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix

                

              

              

            

          

        

      
    

    

  


--B_3453217518_40902510--




From denis.ietf@free.fr  Tue Jun  4 11:07:20 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF97021F96EA for ; Tue,  4 Jun 2013 11:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.153
X-Spam-Level: **
X-Spam-Status: No, score=2.153 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfactaiw1Kxl for ; Tue,  4 Jun 2013 11:07:15 -0700 (PDT)
Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12]) by ietfa.amsl.com (Postfix) with ESMTP id A6C7121F9302 for ; Tue,  4 Jun 2013 10:19:07 -0700 (PDT)
Received: from [127.0.0.1] (unknown [88.182.125.39]) by smtp3-g21.free.fr (Postfix) with ESMTP id A832FA6163; Tue,  4 Jun 2013 19:19:01 +0200 (CEST)
Message-ID: <51AE2182.3050709@free.fr>
Date: Tue, 04 Jun 2013 19:18:58 +0200
From: Denis 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Stefan Santesson 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060803030304040303090304"
X-Antivirus: avast! (VPS 130604-0, 04/06/2013), Outbound message
X-Antivirus-Status: Clean
Cc: pkix@ietf.org
Subject: Re: [pkix] Update need to RFC 3739
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Jun 2013 18:07:20 -0000

This is a multi-part message in MIME format.
--------------060803030304040303090304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan,

A short reply.

RFC 3739 is a QC (for natural persons).

There is plenty of room for a RFC or an ETSI TS dedicated to QC for 
organisational units under the responsibility of a legal person.

Thus an update of RFC 3739 is not needed,
unless you have other arguments that have not yet been disclosed.

You said: "EU has proposed", but the reality is that EU MS have not yet 
agreed.

Denis

P.S. Please save our trees !
:
> Denis,
>
> I have limited time right now.
>
> Since the organizationIdentifier is simply a string, you can set it to 
> any string value.
> It will then be understood as an arbitrary identifier unless you use 
> some mechanism to further contrain the format.
> A typical use of this attribute I foresee is an identifier from a 
> national company registry. But that is not mandated.
>
> OranizationalUnitName is a bit different, as it is a name of an 
> organisational unit.
>
> EU has proposed to allow legal person and web server certificates to 
> be issued as QC. Neither will fit the narrow attribute list of RFC 3739.
> ETSI is creating cert profiles for it in the 319 412 series.
>
> This will require an update of RFC 3739.
>
> /Stefan
>
>
>
> From: Denis >
> Date: Tuesday, June 4, 2013 6:45 PM
> To: Stefan Santesson >
> Cc: >
> Subject: Re: [pkix] Update need to RFC 3739
>
>     Stefan,
>
>     Thank you for the link.
>
>     The definition is:
>
>     organizationIdentifier ATTRIBUTE ::= {
>       WITH SYNTAX               UnboundedDirectoryString
>       EQUALITY MATCHING RULE    caseIgnoreMatch
>       SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
>       SINGLE VALUE              TRUE
>       ID                        id-at-organizationIdentifier }
>
>     This structure is insufficient, since it is too wide open (it is
>     not a structured field).
>     The second question will be whether using organisationIdentifier
>     would more appropriate or not than using organizationalUnitName.
>
>     The second point is that the only currently valid text is the EU
>     Directive from 1999.
>
>     You seem to anticipate some changes. However at the present time,
>     no change has been agreed by the EU MS.
>
>     There is a proposed regulation currently being discussed. I am not
>     keen to make change in anticipation of a text
>     which has not yet been approved and which is not even public anymore.
>
>     Finally, you mention that there are other changes are needed, but
>     I omitted to provide a rational.
>
>     Denis
>
>>     http://www.itu.int/rec/T-REC-X.520-201210-I!Cor3
>>     
>>
>>     If we want the new QC profiles of EU to confirm to RFC3739, then
>>     RFC 3739 must be updated.
>>     That is not only caused by this attribute.
>>
>>     /Stefan
>>
>>     From: Denis >
>>     Date: Tuesday, June 4, 2013 5:01 PM
>>     To: Stefan Santesson >
>>     Cc: >
>>     Subject: Re: [pkix] Update need to RFC 3739
>>
>>         Stefan,
>>
>>         The latest version published at
>>         http://www.x500standard.com/index.php?n=Ig.LatestAvail.
>>         is: ISO/IEC 9594-6:2008
>>
>>         I could not find organisationIdentifier in it.
>>
>>         Would you be able indicate your source and copy the text ?
>>
>>         Nevertheless, I wonder whether using a new attribute is
>>         really necessary.
>>
>>         In France, we have defined a French standard (RGS 1.0). I
>>         will provide an approximate translation of it:
>>
>>         "One instance of an attribute organizationalUnitName MUST be
>>         present and MUST contain the identification of the entity.
>>         This attribute MUST be structured according to ISO 6523.
>>
>>         In France, the format that MUST be used is:
>>
>>         - the ICD (International Code Designator) using four characters,
>>         - the character "space", and
>>         - the identification of the organisation up to 35 characters,
>>
>>         As an example, for french organizations the format will be:
>>
>>         ICD= 0002
>>         the character "space",
>>         the SIREN (9 characters) or SIRET number (14 characters) as
>>         given by the french INSEE organisation.
>>
>>         If we follow this direction, then already issued certificates
>>         for french organisation would
>>         already be conformant (in other words nothing would need to
>>         be changed).
>>
>>         The changes that would be required in RFC 3739 are much more
>>         important than you say, starting with the abstract:
>>
>>         This document forms a certificate profile, based on RFC 3280, for
>>
>>         identity certificates issued to natural persons.
>>
>>
>>         continuing with :
>>
>>         -The Qualified Certificate is issued to a natural person (living
>>
>>         human being).
>>
>>
>>         continuing with :
>>
>>         Of these attributes, the subject field SHALL include at least
>>         one of
>>
>>         the following:
>>
>>         ChoiceI:commonName
>>
>>         ChoiceII:givenName
>>
>>         Choice III:pseudonym
>>
>>
>>         etc...
>>
>>         The changes are so important that I wonder that the current
>>         proposal is the right way to proceed.
>>
>>         A new RFC (or a new ETSI TS) dedicated to organisations be
>>         more appropriate.
>>
>>         Organisations currently delivering certificates to human
>>         beings would be able to continue to refer to RFC 3739
>>         and would not need to change their documentation in order to
>>         refer to the latest document
>>         (please save our money and our forests !).
>>
>>         Organisations that will deliver QCs to organisation units
>>         would be able to refer to a new RFC or a new ETSI TS.
>>
>>         Denis
>>
>>>         Denis,
>>>
>>>         The content of the organisationIdentifier is an interesting question. But
>>>         it can be done separate to the discussion of the need for an update of
>>>         3739.
>>>         The organisationIdentifier is already defined in X.520, so we have no
>>>         power over it. It is an unstructured string, much like serialNumber is,
>>>         except it is not limited to PrintableString which is a good thing.
>>>
>>>         What we need to agree on in the case of 3739 is simply to remove the
>>>         requirement that any particular set of attributes must provide a unique
>>>         identity, and simply accept that the unique identity is provided by the
>>>         complete set of any attributes.
>>>
>>>         /Stefan
>>>
>>>
>>>         On 5/30/13 4:00 PM, "Denis"  wrote:
>>>
>>>>           Stefan,
>>>>
>>>>         Thank you for raising the issue to the list.
>>>>         However, at the time the document was written, there was no mistake.
>>>>
>>>>         In France, nobody may get a certificate representing a company or an
>>>>         organization.
>>>>         Thus a QC cannot be issued to an organization.
>>>>
>>>>         However, a certificate could be issued to a department within an
>>>>         organisation.
>>>>         Thus identifying the department within the organisation (as well as the
>>>>         organisation of course) is necessary.
>>>>         In other words, using only an organisation identifier is insufficient.
>>>>
>>>>         The point which should be discussed on the list is the content of
>>>>         proposed "organisationIdentifier".
>>>>         It would be interesting to know what you propose for it in principle,
>>>>         before issuing a diff document.
>>>>
>>>>         Denis
>>>>         :
>>>>>         Most of what got defined in RFC 3739 was good.
>>>>>
>>>>>         It is a very highly deployed standard in the EU.
>>>>>         At the time, EU defined Qualified Certificates as something that was
>>>>>         only
>>>>>         issued to a natural person.
>>>>>
>>>>>         However, there is one requirement of RFC 3739 that was doomed to fail
>>>>>         given enough time.
>>>>>         And that is the required list of attributes in section 3.1.2.
>>>>>
>>>>>         In particular this sentence:
>>>>>         "Other attributes MAY also be present; however, the use of other
>>>>>              attributes MUST NOT be necessary to distinguish one subject name
>>>>>         from
>>>>>              another subject name.  That is, the attributes listed above are
>>>>>         sufficient to ensure unique subject names."
>>>>>
>>>>>         Yes, I wrote that. And I fully admit my mistake.
>>>>>
>>>>>         In particular two things have happened that makes this requirement plain
>>>>>         wrong and obsolete.
>>>>>
>>>>>         1) EU has now concluded that QC can be issued not only to people, but to
>>>>>         organisations.
>>>>>         2) X.520 has defined a new attribute for organisationIdentifier
>>>>>
>>>>>         That attribute is much more suitable to use for an organisation unique
>>>>>         identifier rather than serialNumber. Especially if the cert includes
>>>>>         information about both a person and an organisation.
>>>>>         So the organisationIdentifier attribute may very well be necessary to
>>>>>         achieve uniqueness in many cases.
>>>>>
>>>>>         It is nether very future proof to assume that serialNumber will be used
>>>>>         forever.
>>>>>         There are other more suitable attributes that you may want at times.
>>>>>
>>>>>         As an example, there is a local Swedish attribute for national Swedish
>>>>>         ID
>>>>>         numbers used in many Swedish PKI deployments. They will never fit the
>>>>>         attribute requirement of RFC 3739.
>>>>>
>>>>>         ETSI is currently making interop profiles for QC that are not natural
>>>>>         persons.
>>>>>         But the EU QC profile EN 319 412-5 relies on RFC 3739.
>>>>>
>>>>>         This has created a deadlock where the interop profile will have to
>>>>>         violate
>>>>>         RFC 3739, unless RFC 3739 is updated.
>>>>>
>>>>>         I will initiate an effort to create an update RFC that opens up this
>>>>>         requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
>>>>>         update document.
>>>>>
>>>>>         I raise the issue here to get feedback. This probably has to go as a
>>>>>         private submission, but as this list is still open, we can always
>>>>>         discuss
>>>>>         the issue here.
>>>>>
>>>>>         /Stefan
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         pkix mailing list
>>>>>         pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>>         _______________________________________________
>>>>         pkix mailing list
>>>>         pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>
>


--------------060803030304040303090304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Stefan,

      

      A short reply.

      

      RFC 3739 is a QC (for natural persons).

      

      There is plenty of room for a RFC or an ETSI TS dedicated to QC
      for organisational units under the responsibility of a legal
      person.

      

      Thus an update of RFC 3739 is not needed, 

      unless you have other arguments that have not yet been disclosed.

      

      You said: "EU has proposed", but the reality is that EU MS have
      not yet agreed.

      

      Denis

      

      P.S. Please save our trees !

      :

    

    

      
Denis,

      


      

      
I have limited time right now.

      


      

      
Since the organizationIdentifier is simply a string, you can
        set it to any string value.

      
It will then be understood as an arbitrary identifier unless
        you use some mechanism to further contrain the format.

      
A typical use of this attribute I foresee is an identifier
        from a national company registry. But that is not mandated.

      


      

      
OranizationalUnitName is a bit different, as it is a name of
        an organisational unit.

      


      

      
EU has proposed to allow legal person and web server
        certificates to be issued as QC. Neither will fit the narrow
        attribute list of RFC 3739.

      
ETSI is creating cert profiles for it in the 319 412 series.

      


      

      
This will require an update of RFC 3739.

      


      

      
/Stefan

      


      

      


      

      


      

      
        
From:  Denis <denis.ietf@free.fr>

          Date:  Tuesday, June 4,
          2013 6:45 PM

          To:  Stefan Santesson
          <stefan@aaa-sec.com>

          Cc:  <pkix@ietf.org>

          Subject:  Re: [pkix]
          Update need to RFC 3739

        

        


        

        

          

            
            

              
Stefan,

                

                Thank you for the link.

                

                The definition is:

                

                organizationIdentifier ATTRIBUTE ::= { 

                  WITH SYNTAX               UnboundedDirectoryString 

                  EQUALITY MATCHING RULE    caseIgnoreMatch 

                  SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch 

                  SINGLE VALUE              TRUE 

                  ID                        id-at-organizationIdentifier
                } 

                

                This structure is insufficient, since it is too wide
                open (it is not a structured field). 

                The second question will be whether using organisationIdentifier would
                  more appropriate or not than using organizationalUnitName.

                

                The second point is that the only currently valid text
                is the EU Directive from 1999.

                

                You seem to anticipate some changes. However at the
                present time, no change has been agreed by the EU MS.

                

                There is a proposed regulation currently being
                discussed. I am not keen to make change in anticipation
                of a text 

                which has not yet been approved and which is not even
                public anymore.

                

                Finally, you mention that there are other changes are
                needed, but I omitted to provide a rational.

                

                Denis

                

              

              

                
                


                

                
If we want the new QC profiles of EU to confirm to
                  RFC3739, then RFC 3739 must be updated.

                
That is not only caused by this attribute.

                


                

                
/Stefan

                


                

                
                  
From:
                     Denis <denis.ietf@free.fr>

                    Date: 
                    Tuesday, June 4, 2013 5:01 PM

                    To:  Stefan
                    Santesson <stefan@aaa-sec.com>

                    Cc:  <pkix@ietf.org>

                    Subject:  Re:
                    [pkix] Update need to RFC 3739

                  

                  


                  

                  

                    

                      
                      

                        
Stefan,

                          

                          The latest version published at
                          
                          http://www.x500standard.com/index.php?n=Ig.LatestAvail.

                          
                          
                          
                          
                          
                          
                          is: ISO/IEC 9594-6:2008

                          

                          I could not find organisationIdentifier in it.

                            

                          Would you be able indicate your source and
                          copy the text ?

                          

                          Nevertheless, I wonder whether using a new
                          attribute is really necessary.

                          

                          In France, we have defined a French standard
                          (RGS 1.0). I will provide an approximate
                          translation of it:

                          

                          "One instance of an attribute
                          organizationalUnitName MUST be present and
                          MUST contain the identification of the entity.
                          

                          This attribute MUST be structured according to
                          ISO 6523.

                          

                          In France, the format that MUST be used is:

                          

                          - the ICD (International Code
                            Designator) using four characters,

                          - the character "space", and

                          - the identification of the organisation up to
                          35 characters,

                          

                          As an example, for french organizations the
                          format will be:

                          

                          ICD= 0002

                          the character "space",

                          the SIREN (9 characters) or SIRET number (14
                          characters) as given by the french INSEE
                          organisation.

                          

                          If we follow this direction, then already
                          issued certificates for french organisation
                          would 

                          already be conformant (in other words nothing
                          would need to be changed).

                          

                          The changes that would be required in RFC 3739
                          are much more important than you say, starting
                          with the abstract:

                          

                          
                          
   This document forms a
                              certificate profile, based on RFC 3280,
                              for

                          
   identity certificates
                              issued to natural persons.

                          
                          
                          
                          
                          
                          

                          continuing with :

                          

                          
                          
   -  The
                              Qualified Certificate is issued to a
                              natural person (living

                          
      human being).

                          

                          continuing with :

                          

                          
                          
   Of
                            these attributes, the subject field SHALL
                            include at least one of

                          
   the
                            following:

                          
 

                          
      Choice   I:  commonName

                          
      Choice  II:  givenName

                          
      Choice
                            III:  pseudonym

                          
                          
                          
                          
                          
                          

                          etc...
                          
                          
                          
                          
                          
                          

                          

                          The changes are so important that I wonder
                          that the current proposal is the right way to
                          proceed.

                          

                          A new RFC (or a new ETSI TS) dedicated to
                          organisations be more appropriate.

                          

                          Organisations currently delivering
                          certificates to human beings would be able to
                          continue to refer to RFC 3739 

                          and would not need to change their
                          documentation in order to refer to the latest
                          document 

                          (please save our money and our forests !).

                          

                          Organisations that will deliver QCs to
                          organisation units would be able to refer to a
                          new RFC or a new ETSI TS.

                          

                          Denis

                          

                        

                        

                          
Denis,

The content of the organisationIdentifier is an interesting question. But
it can be done separate to the discussion of the need for an update of
3739.
The organisationIdentifier is already defined in X.520, so we have no
power over it. It is an unstructured string, much like serialNumber is,
except it is not limited to PrintableString which is a good thing.

What we need to agree on in the case of 3739 is simply to remove the
requirement that any particular set of attributes must provide a unique
identity, and simply accept that the unique identity is provided by the
complete set of any attributes.

/Stefan


On 5/30/13 4:00 PM, "Denis" <denis.ietf@free.fr> wrote:



                          

                            
 Stefan,

Thank you for raising the issue to the list.
However, at the time the document was written, there was no mistake.

In France, nobody may get a certificate representing a company or an
organization.
Thus a QC cannot be issued to an organization.

However, a certificate could be issued to a department within an
organisation.
Thus identifying the department within the organisation (as well as the
organisation of course) is necessary.
In other words, using only an organisation identifier is insufficient.

The point which should be discussed on the list is the content of
proposed "organisationIdentifier".
It would be interesting to know what you propose for it in principle,
before issuing a diff document.

Denis
:


                            

                              
Most of what got defined in RFC 3739 was good.

It is a very highly deployed standard in the EU.
At the time, EU defined Qualified Certificates as something that was
only
issued to a natural person.

However, there is one requirement of RFC 3739 that was doomed to fail
given enough time.
And that is the required list of attributes in section 3.1.2.

In particular this sentence:
"Other attributes MAY also be present; however, the use of other
    attributes MUST NOT be necessary to distinguish one subject name
from
    another subject name.  That is, the attributes listed above are
sufficient to ensure unique subject names."

Yes, I wrote that. And I fully admit my mistake.

In particular two things have happened that makes this requirement plain
wrong and obsolete.

1) EU has now concluded that QC can be issued not only to people, but to
organisations.
2) X.520 has defined a new attribute for organisationIdentifier

That attribute is much more suitable to use for an organisation unique
identifier rather than serialNumber. Especially if the cert includes
information about both a person and an organisation.
So the organisationIdentifier attribute may very well be necessary to
achieve uniqueness in many cases.

It is nether very future proof to assume that serialNumber will be used
forever.
There are other more suitable attributes that you may want at times.

As an example, there is a local Swedish attribute for national Swedish
ID
numbers used in many Swedish PKI deployments. They will never fit the
attribute requirement of RFC 3739.

ETSI is currently making interop profiles for QC that are not natural
persons.
But the EU QC profile EN 319 412-5 relies on RFC 3739.

This has created a deadlock where the interop profile will have to
violate
RFC 3739, unless RFC 3739 is updated.

I will initiate an effort to create an update RFC that opens up this
requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
update document.

I raise the issue here to get feedback. This probably has to go as a
private submission, but as this list is still open, we can always
discuss
the issue here.

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix

                            

                            
_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix

                          

                        

                        

                      

                    

                  

                 

              

            

          

        

      
    

    

  


--------------060803030304040303090304--

From wwwrun@rfc-editor.org  Thu Jun  6 13:58:36 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFA11E8107; Thu,  6 Jun 2013 13:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.233
X-Spam-Level: 
X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ1hlnJPY3sW; Thu,  6 Jun 2013 13:58:36 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 724C421E80DE; Thu,  6 Jun 2013 13:58:34 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5569EB1E004; Thu,  6 Jun 2013 13:57:07 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130606205707.5569EB1E004@rfc-editor.org>
Date: Thu,  6 Jun 2013 13:57:07 -0700 (PDT)
Cc: pkix@ietf.org, rfc-editor@rfc-editor.org
Subject: [pkix] RFC 6960 on X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jun 2013 20:58:37 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6960

        Title:      X.509 Internet Public Key Infrastructure 
                    Online Certificate Status Protocol - OCSP 
        Author:     S. Santesson, M. Myers,
                    R. Ankney, A. Malpani,
                    S. Galperin, C. Adams
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2013
        Mailbox:    sts@aaa-sec.com, 
                    mmyers@fastq.com, 
                    none,  ambarish@gmail.com, 
                    slava.galperin@gmail.com,
                    cadams@eecs.uottawa.ca
        Pages:      41
        Characters: 82037
        Obsoletes:  RFC 2560, RFC 6277
        Updates:    RFC 5912

        I-D Tag:    draft-ietf-pkix-rfc2560bis-20.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6960.txt

This document specifies a protocol useful in determining the current 
status of a digital certificate without requiring Certificate Revocation 
Lists (CRLs).  Additional mechanisms addressing PKIX operational 
requirements are specified in separate documents.  This document obsoletes 
RFCs 2560 and 6277.  It also updates RFC 5912.

This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From internet-drafts@ietf.org  Sun Jun  9 21:31:17 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE05D21F8F0E; Sun,  9 Jun 2013 21:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGvaG3X18A3U; Sun,  9 Jun 2013 21:31:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09921F8EB2; Sun,  9 Jun 2013 21:31:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.50
Message-ID: <20130610043117.23438.86835.idtracker@ietfa.amsl.com>
Date: Sun, 09 Jun 2013 21:31:17 -0700
Cc: pkix@ietf.org
Subject: [pkix] I-D Action: draft-ietf-pkix-est-07.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jun 2013 04:31:17 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Public-Key Infrastructure (X.509) Working=
 Group of the IETF.

	Title           : Enrollment over Secure Transport
	Author(s)       : Max Pritikin
                          Peter E. Yee
                          Dan Harkins
	Filename        : draft-ietf-pkix-est-07.txt
	Pages           : 48
	Date            : 2013-06-09

Abstract:
   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple yet functional certificate management
   protocol targeting Public Key Infrastructure (PKI) clients that need
   to acquire client certificates and associated Certification Authority
   (CA) certificate(s).  It also supports client-generated public/
   private key pairs as well as key pairs generated by the CA.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-est

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-est-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-est-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From stefan@aaa-sec.com  Mon Jun 10 03:52:29 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C54F21F85C0 for ; Mon, 10 Jun 2013 03:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.252
X-Spam-Level: 
X-Spam-Status: No, score=-98.252 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNgZb20RPdmP for ; Mon, 10 Jun 2013 03:52:24 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A215021F86FB for ; Mon, 10 Jun 2013 03:52:13 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D5542DB5658 for ; Mon, 10 Jun 2013 12:52:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5GHA9Z_WPXVf for ; Mon, 10 Jun 2013 12:52:03 +0200 (CEST)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 72A6DDB5961 for ; Mon, 10 Jun 2013 12:25:20 +0200 (CEST)
Received: (qmail 75362 invoked from network); 10 Jun 2013 10:25:20 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.103]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Jun 2013 10:25:20 -0000
User-Agent: Microsoft-MacOutlook/14.3.4.130416
Date: Mon, 10 Jun 2013 12:25:15 +0200
From: Stefan Santesson 
To: Denis 
Message-ID: 
Thread-Topic: [pkix] Update need to RFC 3739
In-Reply-To: <51AE2182.3050709@free.fr>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3453711920_54636606"
Cc: pkix@ietf.org
Subject: Re: [pkix] Update need to RFC 3739
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jun 2013 10:52:30 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3453711920_54636606
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Denis,

The new profiles decided for Qualified Certificates decided in the ETSI ESI
work group does not fit within the current set of attributes listed in RFC
3739.

The legal person profile does not fit as it uses the organisationIdentifier
attribute instead of serialNumber.
The web server certificate profile does not fit either as it aligns with the
CAB forum certificate profile which relies on the SubjectAltName extension
for uniqueness.

The serialNumber is not desirable for organisation unique identifiers as
this attribute is used for natural person unique identifiers in certificates
issued to a natural person that is associated with an organisation.
So in certificates issued to a natural person that is associated with an
organisation and where you need a unique identifier both for the person and
the organisation, then you need different attributes for these unique
identifiers.
This is why the organizationIdentifier was added to X.520.

Thus using serial number for organisation unique identifiers in certificate
issued to legal persons will be very confusing.

I'v checked through RFC 3739 and find nothing that prevents this RFC from
being used for a legal person.
Yes, there are some text in the scoping of the standard that declares the
intent of the standard to support natural persons, but there are no
technical definitions that would prevent the document from being used for
legal person certificate, except the attribute list.

This is why I propose to do an update that;
1. opens up the current attribute requirements
2. Clarifies the scope to include certificates issued to legal persons.

/Stefan


From:  Denis 
Date:  Tuesday, June 4, 2013 7:18 PM
To:  Stefan Santesson 
Cc:  
Subject:  Re: [pkix] Update need to RFC 3739

>     
>  
> Stefan,
>  
>  A short reply.
>  
>  RFC 3739 is a QC (for natural persons).
>  
>  There is plenty of room for a RFC or an ETSI TS dedicated to QC for
> organisational units under the responsibility of a legal person.
>  
>  Thus an update of RFC 3739 is not needed,
>  unless you have other arguments that have not yet been disclosed.
>  
>  You said: "EU has proposed", but the reality is that EU MS have not yet
> agreed.
>  
>  Denis
>  
>  P.S. Please save our trees !
>  :
>  
>  
>>  
>> Denis,
>>  
>> 
>>  
>>  
>> I have limited time right now.
>>  
>> 
>>  
>>  
>> Since the organizationIdentifier is simply a string, you can set it to any
>> string value.
>>  
>> It will then be understood as an arbitrary identifier unless you use some
>> mechanism to further contrain the format.
>>  
>> A typical use of this attribute I foresee is an identifier from a national
>> company registry. But that is not mandated.
>>  
>> 
>>  
>>  
>> OranizationalUnitName is a bit different, as it is a name of an
>> organisational unit.
>>  
>> 
>>  
>>  
>> EU has proposed to allow legal person and web server certificates to be
>> issued as QC. Neither will fit the narrow attribute list of RFC 3739.
>>  
>> ETSI is creating cert profiles for it in the 319 412 series.
>>  
>> 
>>  
>>  
>> This will require an update of RFC 3739.
>>  
>> 
>>  
>>  
>> /Stefan
>>  
>> 
>>  
>>  
>> 
>>  
>>  
>> 
>>  
>>   
>> From:  Denis 
>>  Date:  Tuesday, June 4, 2013 6:45 PM
>>  To:  Stefan Santesson 
>>  Cc:  
>>  Subject:  Re: [pkix] Update need to RFC 3739
>>  
>>  
>> 
>>  
>>  
>>>  
>>>   
>>>  
>>> Stefan,
>>>  
>>>  Thank you for the link.
>>>  
>>>  The definition is:
>>>  
>>>  organizationIdentifier ATTRIBUTE ::= {
>>>    WITH SYNTAX               UnboundedDirectoryString
>>>    EQUALITY MATCHING RULE    caseIgnoreMatch
>>>    SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
>>>    SINGLE VALUE              TRUE
>>>    ID                        id-at-organizationIdentifier }
>>>  
>>>  This structure is insufficient, since it is too wide open (it is not a
>>> structured field).
>>>  The second question will be whether using organisationIdentifier would more
>>> appropriate or not than using organizationalUnitName.
>>>  
>>>  The second point is that the only currently valid text is the EU Directive
>>> from 1999.
>>>  
>>>  You seem to anticipate some changes. However at the present time, no change
>>> has been agreed by the EU MS.
>>>  
>>>  There is a proposed regulation currently being discussed. I am not keen to
>>> make change in anticipation of a text
>>>  which has not yet been approved and which is not even public anymore.
>>>  
>>>  Finally, you mention that there are other changes are needed, but I omitted
>>> to provide a rational.
>>>  
>>>  Denis
>>>  
>>>  
>>>  
>>>>  
>>>> http://www.itu.int/rec/T-REC-X.520-201210-I!Cor3
>>>> 
>>>>  
>>>> 
>>>>  
>>>>  
>>>> If we want the new QC profiles of EU to confirm to RFC3739, then RFC 3739
>>>> must be updated.
>>>>  
>>>> That is not only caused by this attribute.
>>>>  
>>>> 
>>>>  
>>>>  
>>>> /Stefan
>>>>  
>>>> 
>>>>  
>>>>   
>>>> From:  Denis 
>>>>  Date:  Tuesday, June 4, 2013 5:01 PM
>>>>  To:  Stefan Santesson 
>>>>  Cc:  
>>>>  Subject:  Re: [pkix] Update need to RFC 3739
>>>>  
>>>>  
>>>> 
>>>>  
>>>>  
>>>>>  
>>>>>   
>>>>>  
>>>>> Stefan,
>>>>>  
>>>>>  The latest version published at
>>>>> http://www.x500standard.com/index.php?n=Ig.LatestAvail.
>>>>>        is: ISO/IEC 9594-6:2008
>>>>>  
>>>>>  I could not find organisationIdentifier in it.
>>>>>    
>>>>>  Would you be able indicate your source and copy the text ?
>>>>>  
>>>>>  Nevertheless, I wonder whether using a new attribute is really necessary.
>>>>>  
>>>>>  In France, we have defined a French standard (RGS 1.0). I will provide an
>>>>> approximate translation of it:
>>>>>  
>>>>>  "One instance of an attribute organizationalUnitName MUST be present and
>>>>> MUST contain the identification of the entity.
>>>>>  This attribute MUST be structured according to ISO 6523.
>>>>>  
>>>>>  In France, the format that MUST be used is:
>>>>>  
>>>>>  - the ICD (International Code Designator) using four characters,
>>>>>  - the character "space", and
>>>>>  - the identification of the organisation up to 35 characters,
>>>>>  
>>>>>  As an example, for french organizations the format will be:
>>>>>  
>>>>>  ICD= 0002
>>>>>  the character "space",
>>>>>  the SIREN (9 characters) or SIRET number (14 characters) as given by the
>>>>> french INSEE organisation.
>>>>>  
>>>>>  If we follow this direction, then already issued certificates for french
>>>>> organisation would
>>>>>  already be conformant (in other words nothing would need to be changed).
>>>>>  
>>>>>  The changes that would be required in RFC 3739 are much more important
>>>>> than you say, starting with the abstract:
>>>>>  
>>>>>   
>>>>> 
>>>>>    This document forms a certificate profile, based on RFC 3280, for
>>>>>  
>>>>>    identity certificates issued to natural persons.
>>>>>       
>>>>>  continuing with :
>>>>>  
>>>>>   
>>>>>    -  The Qualified Certificate is issued to a natural person (living
>>>>>  
>>>>>       human being).
>>>>>  
>>>>>  continuing with :
>>>>>  
>>>>>   
>>>>>    Of these attributes, the subject field SHALL include at least one of
>>>>>  
>>>>>    the following:
>>>>>  
>>>>>  
>>>>>  
>>>>>       Choice   I:  commonName
>>>>>  
>>>>>       Choice  II:  givenName
>>>>>  
>>>>>       Choice III:  pseudonym
>>>>>       
>>>>>  etc...      
>>>>>  
>>>>>  The changes are so important that I wonder that the current proposal is
>>>>> the right way to proceed.
>>>>>  
>>>>>  A new RFC (or a new ETSI TS) dedicated to organisations be more
>>>>> appropriate.
>>>>>  
>>>>>  Organisations currently delivering certificates to human beings would be
>>>>> able to continue to refer to RFC 3739
>>>>>  and would not need to change their documentation in order to refer to the
>>>>> latest document
>>>>>  (please save our money and our forests !).
>>>>>  
>>>>>  Organisations that will deliver QCs to organisation units would be able
>>>>> to refer to a new RFC or a new ETSI TS.
>>>>>  
>>>>>  Denis
>>>>>  
>>>>>  
>>>>>  
>>>>>>  
>>>>>> Denis,
>>>>>> 
>>>>>> The content of the organisationIdentifier is an interesting question. But
>>>>>> it can be done separate to the discussion of the need for an update of
>>>>>> 3739.
>>>>>> The organisationIdentifier is already defined in X.520, so we have no
>>>>>> power over it. It is an unstructured string, much like serialNumber is,
>>>>>> except it is not limited to PrintableString which is a good thing.
>>>>>> 
>>>>>> What we need to agree on in the case of 3739 is simply to remove the
>>>>>> requirement that any particular set of attributes must provide a unique
>>>>>> identity, and simply accept that the unique identity is provided by the
>>>>>> complete set of any attributes.
>>>>>> 
>>>>>> /Stefan
>>>>>> 
>>>>>> 
>>>>>> On 5/30/13 4:00 PM, "Denis" 
>>>>>>   wrote:
>>>>>> 
>>>>>>  
>>>>>>>  
>>>>>>>  Stefan,
>>>>>>> 
>>>>>>> Thank you for raising the issue to the list.
>>>>>>> However, at the time the document was written, there was no mistake.
>>>>>>> 
>>>>>>> In France, nobody may get a certificate representing a company or an
>>>>>>> organization.
>>>>>>> Thus a QC cannot be issued to an organization.
>>>>>>> 
>>>>>>> However, a certificate could be issued to a department within an
>>>>>>> organisation.
>>>>>>> Thus identifying the department within the organisation (as well as the
>>>>>>> organisation of course) is necessary.
>>>>>>> In other words, using only an organisation identifier is insufficient.
>>>>>>> 
>>>>>>> The point which should be discussed on the list is the content of
>>>>>>> proposed "organisationIdentifier".
>>>>>>> It would be interesting to know what you propose for it in principle,
>>>>>>> before issuing a diff document.
>>>>>>> 
>>>>>>> Denis
>>>>>>> :
>>>>>>>  
>>>>>>>  
>>>>>>> Most of what got defined in RFC 3739 was good.
>>>>>>> 
>>>>>>> It is a very highly deployed standard in the EU.
>>>>>>> At the time, EU defined Qualified Certificates as something that was
>>>>>>> only
>>>>>>> issued to a natural person.
>>>>>>> 
>>>>>>> However, there is one requirement of RFC 3739 that was doomed to fail
>>>>>>> given enough time.
>>>>>>> And that is the required list of attributes in section 3.1.2.
>>>>>>> 
>>>>>>> In particular this sentence:
>>>>>>> "Other attributes MAY also be present; however, the use of other
>>>>>>>     attributes MUST NOT be necessary to distinguish one subject name
>>>>>>> from
>>>>>>>     another subject name.  That is, the attributes listed above are
>>>>>>> sufficient to ensure unique subject names."
>>>>>>> 
>>>>>>> Yes, I wrote that. And I fully admit my mistake.
>>>>>>> 
>>>>>>> In particular two things have happened that makes this requirement plain
>>>>>>> wrong and obsolete.
>>>>>>> 
>>>>>>> 1) EU has now concluded that QC can be issued not only to people, but to
>>>>>>> organisations.
>>>>>>> 2) X.520 has defined a new attribute for organisationIdentifier
>>>>>>> 
>>>>>>> That attribute is much more suitable to use for an organisation unique
>>>>>>> identifier rather than serialNumber. Especially if the cert includes
>>>>>>> information about both a person and an organisation.
>>>>>>> So the organisationIdentifier attribute may very well be necessary to
>>>>>>> achieve uniqueness in many cases.
>>>>>>> 
>>>>>>> It is nether very future proof to assume that serialNumber will be used
>>>>>>> forever.
>>>>>>> There are other more suitable attributes that you may want at times.
>>>>>>> 
>>>>>>> As an example, there is a local Swedish attribute for national Swedish
>>>>>>> ID
>>>>>>> numbers used in many Swedish PKI deployments. They will never fit the
>>>>>>> attribute requirement of RFC 3739.
>>>>>>> 
>>>>>>> ETSI is currently making interop profiles for QC that are not natural
>>>>>>> persons.
>>>>>>> But the EU QC profile EN 319 412-5 relies on RFC 3739.
>>>>>>> 
>>>>>>> This has created a deadlock where the interop profile will have to
>>>>>>> violate
>>>>>>> RFC 3739, unless RFC 3739 is updated.
>>>>>>> 
>>>>>>> I will initiate an effort to create an update RFC that opens up this
>>>>>>> requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
>>>>>>> update document.
>>>>>>> 
>>>>>>> I raise the issue here to get feedback. This probably has to go as a
>>>>>>> private submission, but as this list is still open, we can always
>>>>>>> discuss
>>>>>>> the issue here.
>>>>>>> 
>>>>>>> /Stefan
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> pkix mailing list
>>>>>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>>>>>  
>>>>>>>  
>>>>>>> _______________________________________________
>>>>>>> pkix mailing list
>>>>>>> pkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix
>>>>>>>  
>>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>   
>>>  
>>>  
>>>  
>>>  
>>   
>  
>  



--B_3453711920_54636606
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


Hi Denis,

The new profiles decided for Qualified Certificates decided in the ET=
SI ESI work group does not fit within the current set of attributes listed i=
n RFC 3739.

The legal person profile does not fit a=
s it uses the organisationIdentifier attribute instead of serialNumber.
The web server certificate profile does not fit either as it aligns wi=
th the CAB forum certificate profile which relies on the SubjectAltName exte=
nsion for uniqueness.

The serialNumber is not desir=
able for organisation unique identifiers as this attribute is used for natur=
al person unique identifiers in certificates issued to a natural person that=
 is associated with an organisation.
So in certificates issued to =
a natural person that is associated with an organisation and where you need =
a unique identifier both for the person and the organisation, then you need =
different attributes for these unique identifiers.
This is why the=
 organizationIdentifier was added to X.520.

Thus us=
ing serial number for organisation unique identifiers in certificate issued =
to legal persons will be very confusing.

I'v checke=
d through RFC 3739 and find nothing that prevents this RFC from being used f=
or a legal person.
Yes, there are some text in the scoping of the =
standard that declares the intent of the standard to support natural persons=
, but there are no technical definitions that would prevent the document fro=
m being used for legal person certificate, except the attribute list.
<=
div>
This is why I propose to do an update that;
  1. =
opens up the current attribute requirements
  2. Clarifies the scope to i=
nclude certificates issued to legal persons.

/S=
tefan


From: <=
/span> Denis <denis.ietf@free.fr&=
gt;
Date:  Tuesday, June 4, 2013 7:=
18 PM
To:  Stefan Santesson <stefan@aaa-sec.com>
Cc:  <pkix@ietf.o=
rg>
Subject:  Re: [pkix] Upd=
ate need to RFC 3739


  
    
  
  

    
Stefan,

      

      A short reply.

      

      RFC 3739 is a QC (for natural persons).

      

      There is plenty of room for a RFC or an ETSI TS dedicated to QC
      for organisational units under the responsibility of a legal
      person.

      

      Thus an update of RFC 3739 is not needed, 

      unless you have other arguments that have not yet been disclosed.
=

      

      You said: "EU has proposed", but the reality is that EU MS have
      not yet agreed.

      

      Denis

      

      P.S. Please save our trees !

      :

    

    
=

      
Denis,

      


      

      
I have limited time right now.

      


      

      
Since the organizationIdentifier is simply a string, you can
        set it to any string value.

      
It will then be understood as an arbitrary identifier unless
        you use some mechanism to further contrain the format.

      
A typical use of this attribute I foresee is an identifier
        from a national company registry. But that is not mandated.

      


      

      
OranizationalUnitName is a bit different, as it is a name of
        an organisational unit.

      


      

      
EU has proposed to allow legal person and web server
        certificates to be issued as QC. Neither will fit the narrow
        attribute list of RFC 3739.

      
ETSI is creating cert profiles for it in the 319 412 series.
      


      

      
This will require an update of RFC 3739.

      


      

      
/Stefan

      


      

      


      

      


      

      
        
From:  Denis <denis.ietf@free.fr>

          Date:  Tuesday, June 4,
          2013 6:45 PM

          To:  Stefan Santesson
          <st=
efan@aaa-sec.com>

          Cc:  <pkix@ietf.org>

          Subject:  Re: [pkix]
          Update need to RFC 3739

        

        


        

        

          

            
            

              
Stefan,

                

                Thank you for the link.

                

                The definition is:

                

                organizationIdentifier ATTRIBUTE ::=3D { 

                  WITH SYNTAX       =
;        UnboundedDirectoryString 

                  EQUALITY MATCHING RULE    caseIgnoreM=
atch 

                  SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsM=
atch 

                  SINGLE VALUE      &nbs=
p;       TRUE 

                  ID        &n=
bsp;            =
   id-at-organizationIdentifier
                } 

                

                This structure is insufficient, since it is too wide
                open (it is not a structured field). 

                The second question will be whether using organisationIdentifier would
                  more appropriate or not than using organizationalUnitName.

                

                The second point is that the only currently valid text
                is the EU Directive from 1999.

                

                You seem to anticipate some changes. However at the
                present time, no change has been agreed by the EU MS.

                

                There is a proposed regulation currently being
                discussed. I am not keen to make change in anticipation
                of a text 

                which has not yet been approved and which is not even
                public anymore.

                

                Finally, you mention that there are other changes are
                needed, but I omitted to provide a rational.

                

                Denis

                

              

              

                
                


                

                
If we want the new QC profiles of EU to confirm to
                  RFC3739, then RFC 3739 must be updated.

                
That is not only caused by this attribute.

                


                

                
/Stefan

                


                

                
                  
From:
                     Denis <denis.ietf@free.fr>

                    Date: 
                    Tuesday, June 4, 2013 5:01 PM

                    To:  Stefan
                    Santesson <stefan@aaa-sec.com>

                    Cc:  <pkix@ietf.org>

                    Subject:  Re:
                    [pkix] Update need to RFC 3739

                  

                  


                  

                  

                    

                      
                      

                        
Stefan,

                          

                          The latest version published at
                          
                          http://www.x500standard.com/index.ph=
p?n=3DIg.LatestAvail.

                          
                          
                          
                          
                          
                          
                          is: ISO/IEC 9594-6:2008

                          

                          I could not find organisationIdentifier in it.
                            

                          Would you be able indicate your source and
                          copy the text ?

                          

                          Nevertheless, I wonder whether using a new
                          attribute is really necessary.

                          

                          In France, we have defined a French standard
                          (RGS 1.0). I will provide an approximate
                          translation of it:

                          

                          "One instance of an attribute
                          organizationalUnitName MUST be present and
                          MUST contain the identification of the entity.
                          

                          This attribute MUST be structured according to
                          ISO 6523.

                          

                          In France, the format that MUST be used is:

                          

                          - the ICD (International Code
                            Designator) using four characters,

                          - the character "space", and

                          - the identification of the organisation up to
                          35 characters,

                          

                          As an example, for french organizations the
                          format will be:

                          

                          ICD=3D 0002

                          the character "space",

                          the SIREN (9 characters) or SIRET number (14
                          characters) as given by the french INSEE
                          organisation.

                          

                          If we follow this direction, then already
                          issued certificates for french organisation
                          would 

                          already be conformant (in other words nothing
                          would need to be changed).

                          

                          The changes that would be required in RFC 3739
                          are much more important than you say, starting
                          with the abstract:

                          

                          
                          
   This document form=
s a
                              certificate profile, based on RFC 3280,
                              for

                          
   identity certifica=
tes
                              issued to natural persons.<=
/p>
                          
                          
                          
                          
                          
                          

                          continuing with :

                          

                          
                          
   -  The
                              Qualified Certificate is issued to a
                              natural person (living

                          
      =
human being).

                          

                          continuing with :

                          

                          
                          
   Of
                            these attributes, the subject field SHALL
                            include at least one of

                          
   the
                            following:

                          
 

                          
      Choice   I:  commonName

                          
      Choice  II:  givenName

                          
      Choice
                            III:  pseudonym

                          
                          
                          
                          
                          
                          

                          etc...
                          
                          
                          
                          
                          
                          

                          

                          The changes are so important that I wonder
                          that the current proposal is the right way to
                          proceed.

                          

                          A new RFC (or a new ETSI TS) dedicated to
                          organisations be more appropriate.

                          

                          Organisations currently delivering
                          certificates to human beings would be able to
                          continue to refer to RFC 3739 

                          and would not need to change their
                          documentation in order to refer to the latest
                          document 

                          (please save our money and our forests !).

                          

                          Organisations that will deliver QCs to
                          organisation units would be able to refer to a
                          new RFC or a new ETSI TS.

                          

                          Denis

                          

                        

                        

                          
Denis,

The content of the organisationIdentifier is an interesting question. But
it can be done separate to the discussion of the need for an update of
3739.
The organisationIdentifier is already defined in X.520, so we have no
power over it. It is an unstructured string, much like serialNumber is,
except it is not limited to PrintableString which is a good thing.

What we need to agree on in the case of 3739 is simply to remove the
requirement that any particular set of attributes must provide a unique
identity, and simply accept that the unique identity is provided by the
complete set of any attributes.

/Stefan


On 5/30/13 4:00 PM, "Denis" <denis.ietf@free.fr> wro=
te:



                          

                            
 Stefan,

Thank you for raising the issue to the list.
However, at the time the document was written, there was no mistake.

In France, nobody may get a certificate representing a company or an
organization.
Thus a QC cannot be issued to an organization.

However, a certificate could be issued to a department within an
organisation.
Thus identifying the department within the organisation (as well as the
organisation of course) is necessary.
In other words, using only an organisation identifier is insufficient.

The point which should be discussed on the list is the content of
proposed "organisationIdentifier".
It would be interesting to know what you propose for it in principle,
before issuing a diff document.

Denis
:


                            

                              
Most of what got defined in RFC =
3739 was good.

It is a very highly deployed standard in the EU.
At the time, EU defined Qualified Certificates as something that was
only
issued to a natural person.

However, there is one requirement of RFC 3739 that was doomed to fail
given enough time.
And that is the required list of attributes in section 3.1.2.

In particular this sentence:
"Other attributes MAY also be present; however, the use of other
    attributes MUST NOT be necessary to distinguish one subject name
from
    another subject name.  That is, the attributes listed above are
sufficient to ensure unique subject names."

Yes, I wrote that. And I fully admit my mistake.

In particular two things have happened that makes this requirement plain
wrong and obsolete.

1) EU has now concluded that QC can be issued not only to people, but to
organisations.
2) X.520 has defined a new attribute for organisationIdentifier

That attribute is much more suitable to use for an organisation unique
identifier rather than serialNumber. Especially if the cert includes
information about both a person and an organisation.
So the organisationIdentifier attribute may very well be necessary to
achieve uniqueness in many cases.

It is nether very future proof to assume that serialNumber will be used
forever.
There are other more suitable attributes that you may want at times.

As an example, there is a local Swedish attribute for national Swedish
ID
numbers used in many Swedish PKI deployments. They will never fit the
attribute requirement of RFC 3739.

ETSI is currently making interop profiles for QC that are not natural
persons.
But the EU QC profile EN 319 412-5 relies on RFC 3739.

This has created a deadlock where the interop profile will have to
violate
RFC 3739, unless RFC 3739 is updated.

I will initiate an effort to create an update RFC that opens up this
requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:)
update document.

I raise the issue here to get feedback. This probably has to go as a
private submission, but as this list is still open, we can always
discuss
the issue here.

/Stefan


_______________________________________________
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix

                            

                            
__________________________________=
_____________
pkix mailing list
pkix@ietf.orghttps://www.ietf.=
org/mailman/listinfo/pkix

                          

                        

                        

                      

                    

                  

                 

              

            

          

        

      
    

    

  


--B_3453711920_54636606--



From turners@ieca.com  Mon Jun 10 07:26:31 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7684521F93F8 for ; Mon, 10 Jun 2013 07:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.188
X-Spam-Level: 
X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P1VRDNap8W3 for ; Mon, 10 Jun 2013 07:26:26 -0700 (PDT)
Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.159.26]) by ietfa.amsl.com (Postfix) with ESMTP id 48CB921F93E5 for ; Mon, 10 Jun 2013 07:26:26 -0700 (PDT)
Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 2B6D7814C5F3E; Mon, 10 Jun 2013 09:26:19 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 1E6AD814C5F09 for ; Mon, 10 Jun 2013 09:26:19 -0500 (CDT)
Received: from [173.73.135.101] (port=63096 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Um33B-0005ek-IX for pkix@ietf.org; Mon, 10 Jun 2013 09:26:25 -0500
Message-ID: <51B5E211.2010500@ieca.com>
Date: Mon, 10 Jun 2013 10:26:25 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: pkix@ietf.org
References: <20130610043117.23438.86835.idtracker@ietfa.amsl.com>
In-Reply-To: <20130610043117.23438.86835.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [173.73.135.101]:63096
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 9
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-07.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jun 2013 14:26:31 -0000

This version address my concerns and I'll be issuing the IETF LC shortly.

spt

On 6/10/13 12:31 AM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
>
> 	Title           : Enrollment over Secure Transport
> 	Author(s)       : Max Pritikin
>                            Peter E. Yee
>                            Dan Harkins
> 	Filename        : draft-ietf-pkix-est-07.txt
> 	Pages           : 48
> 	Date            : 2013-06-09
>
> Abstract:
>     This document profiles certificate enrollment for clients using
>     Certificate Management over CMS (CMC) messages over a secure
>     transport.  This profile, called Enrollment over Secure Transport
>     (EST), describes a simple yet functional certificate management
>     protocol targeting Public Key Infrastructure (PKI) clients that need
>     to acquire client certificates and associated Certification Authority
>     (CA) certificate(s).  It also supports client-generated public/
>     private key pairs as well as key pairs generated by the CA.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pkix-est
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-pkix-est-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-est-07
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>

From iesg-secretary@ietf.org  Mon Jun 10 07:45:20 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF89A21F84B6; Mon, 10 Jun 2013 07:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.483
X-Spam-Level: 
X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d0aPwTDyMoM; Mon, 10 Jun 2013 07:45:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6383221F8BE6; Mon, 10 Jun 2013 07:45:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.50
Sender: 
Message-ID: <20130610144518.18776.77082.idtracker@ietfa.amsl.com>
Date: Mon, 10 Jun 2013 07:45:18 -0700
Cc: pkix@ietf.org
Subject: [pkix] Last Call:  (Enrollment over Secure	Transport) to Proposed Standard
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jun 2013 14:45:20 -0000

The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Enrollment over Secure Transport'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple yet functional certificate management
   protocol targeting Public Key Infrastructure (PKI) clients that need
   to acquire client certificates and associated Certification Authority
   (CA) certificate(s).  It also supports client-generated public/
   private key pairs as well as key pairs generated by the CA.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-est/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-est/ballot/


No IPR declarations have been submitted directly on this I-D.



From housley@vigilsec.com  Mon Jun 10 11:45:14 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B4421F8EC3; Mon, 10 Jun 2013 11:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UgtfUYwLhcq; Mon, 10 Jun 2013 11:45:09 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id C16ED21F91AB; Mon, 10 Jun 2013 11:45:08 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 2E453F24072; Mon, 10 Jun 2013 14:45:23 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ceJRf+0LtkET; Mon, 10 Jun 2013 14:44:24 -0400 (EDT)
Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 69DE6F2406E; Mon, 10 Jun 2013 14:45:22 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: <20130610144518.18776.77082.idtracker@ietfa.amsl.com>
Date: Mon, 10 Jun 2013 14:45:06 -0400
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20130610144518.18776.77082.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.1085)
Cc: IETF PKIX 
Subject: Re: [pkix] Last Call:  (Enrollment over Secure Transport) to Proposed Standard
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jun 2013 18:45:14 -0000

I have read the document, I a support publication on the standards track.

Russ


On Jun 10, 2013, at 10:45 AM, The IESG wrote:

> 
> The IESG has received a request from the Public-Key Infrastructure
> (X.509) WG (pkix) to consider the following document:
> - 'Enrollment over Secure Transport'
>   as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-06-24. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document profiles certificate enrollment for clients using
>   Certificate Management over CMS (CMC) messages over a secure
>   transport.  This profile, called Enrollment over Secure Transport
>   (EST), describes a simple yet functional certificate management
>   protocol targeting Public Key Infrastructure (PKI) clients that need
>   to acquire client certificates and associated Certification Authority
>   (CA) certificate(s).  It also supports client-generated public/
>   private key pairs as well as key pairs generated by the CA.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-pkix-est/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-pkix-est/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 


From sm@resistor.net  Wed Jun 12 00:59:54 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0650821F9BF4 for ; Wed, 12 Jun 2013 00:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.491
X-Spam-Level: 
X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heEADKy-rsNO for ; Wed, 12 Jun 2013 00:59:53 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1F921F9A17 for ; Wed, 12 Jun 2013 00:59:46 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5C7xaHl007240; Wed, 12 Jun 2013 00:59:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371023980; bh=RxMXVZFT/KCNaMlmZbCS95wOuOB4QO14tSAN1AFEBMY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hEg8eqUcFmzCGeUQUDSmZ4hqBSNauIrOnG1b4KngCwV59jBp5GNSjLbIxTrB+pKSn vlMJPpf5QDEcJeb3/Sg4vmJI1/mxSORrvzB8SYk3fRHxGWkH48jdzEm/NBeMhnUTal jLVxzBrKnvHWIWTW5ZuQOVPD/cyVU2ac3NsY/KUw=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1371023980; i=@resistor.net; bh=RxMXVZFT/KCNaMlmZbCS95wOuOB4QO14tSAN1AFEBMY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OvFr1seA6qeurPCnVYVB/kqlKdMGQC1c/liYf8opzTpLQRnVGdp4BNzDvhhdLQn/d FIJjfXlW4XpX34Hi6ulsuvTbQRUua/Yw+PdoL5ubdxa0KTBHImR9EDYNxeYEHPvRr+ UYtUEjMkipvW9Bp34MbKOBxdsD2Jjyx40nySQcT4=
Message-Id: <6.2.5.6.2.20130612000118.0ccd8670@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 12 Jun 2013 00:42:01 -0700
To: Sean Turner 
From: SM 
In-Reply-To: <51B7AF06.4060708@ieca.com>
References: <20130610144518.18776.77082.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130611000605.0b853d00@resistor.net> <51B7AF06.4060708@ieca.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: pkix@ietf.org
Subject: Re: [pkix] Last Call:  (Enrollment over Secure Transport) to Proposed Standard
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jun 2013 07:59:54 -0000

Hi Sean,
At 16:13 11-06-2013, Sean Turner wrote:
>This bit I don't agree with.  PKCS#10 is the way most PKI 
>enrollments occur.  RFC 2986, which is where PKCS#10 is documented, 
>is updated by RFC 5967 because the draft that contained the 
>media-type registration was obsoleted.
>
>This draft is a nod to the fact that PKCS#10 is the way it's done 
>and it's one via the web (not email) with TLS as the secure 
>transport (not S/MIME/CMS).  The kicker here is that it's actually 
>been implemented and not just by the authors.
>
>As for the TLS version, well I'm hoping 1.1 will be overtaken by 
>events in short order but that compromise has been worked out and 
>documented in a number of drafts.

Thanks for the feedback.  I am ok with the draft.

In Section 3.6.2:

   "When the EST client Implicit TA database is used to validate the EST
    server certificate, the client MUST check the URI "against the
    server's identity as presented in the server's Certificate message"
    (HTTP Over TLS Section 3.1 "Server Identity" [RFC2818] and
    [RFC6125])"

I would use RFC 6125 only, specifically the URI-ID (see Section 3 of 
RFC 6125 for the discussion).

In Section 4.3.2:

   "When rejecting a request, the server MUST specify either an HTTP 4xx
    error or an HTTP 5xx error."

I would be more specific about the HTTP code or defer to RFC 2616 to 
catch the possible error conditions.  I'll adapt some suggested text 
from RFC 6712:

   A server MUST answer with a suitable 4xx or 5xx HTTP error code
   when a problem occurs.

In Section 6, I suggest dropping the RFC 2119 key words for the IANA paperwork.

in Section 7, there is a typo:

   "It is RECOMMEND that EST servers not support this operation by default."

Regards,
-sm


From stefan.winter@restena.lu  Fri Jun 28 02:22:59 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706B521F9C87 for ; Fri, 28 Jun 2013 02:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDz3v1g9awwI for ; Fri, 28 Jun 2013 02:22:53 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF1D21F9C9B for ; Fri, 28 Jun 2013 02:22:30 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id EE7EE10580 for ; Fri, 28 Jun 2013 11:22:29 +0200 (CEST)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id DE95E1057F for ; Fri, 28 Jun 2013 11:22:29 +0200 (CEST)
Message-ID: <51CD55D5.2070206@restena.lu>
Date: Fri, 28 Jun 2013 11:22:29 +0200
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: pkix@ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TGANGHAOHQVBRNENNJAJ"
X-Virus-Scanned: ClamAV
Subject: [pkix] Registration of a new sAN:otherName (NAIRealm)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jun 2013 09:23:00 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2TGANGHAOHQVBRNENNJAJ
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

over in the RADIUS Extensions working group we are working on a
discovery mechanism for RADIUS/TLS authentication servers. The algorithm
makes use of DNS, -SEC is optional; in the absence of DNSSEC an X.509
certificate of the discovered server needs to yield information whether
it is authoritative for a NAI realm (i.e. "the 'domain' part of a
User-Name attribute, in the form of user@realm").

The discovery starts with a NAPTR for the service in question, and then
may traverse a set of SRVs or not, to eventually end up at an A/AAAA
record of the discovered hostname.

Determination of the authoritativeness needs to be a part of the
certificate; in a way analogous to SRVName. We cannot use SRVName
directly though, since a possible SRV record occurs in the middle of a
potentially untrusted lookup; if an attacker modified the initial NAPTR
response, he can divert further SRV resolution steps to his own server.

For that reason, we think we need a new sAN:otherName registration which
allows us to compare that realm part of a User-Name (the actual,
known-correct input to the algorithm) to the NAIRealm property of the
certificate of the server that came out of the discovery process.

In short:

1) Input: johndoe@myrealm.example

2) discovery algorithm yields output:
   please contact A.B.C.D:2083 with RADIUS/TLS

3) TLS handshake verification: does X.509 cert contain
   sAN:otherName:NAIRealm =3D=3D myrealm.example

I have a new draft rev of
https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ on
my disk, which registers otherName:NAIRealm just like RFC4985 did (in
fact, it is copy&paste :-) .

I noticed that I need an integer in the "otherName" registry; RFC4985
uses id-on-dnsSRV =3D 7; and I wonder who to approach and where to get my=

own integer for

     id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX??? }

from.

I appreciate any thoughts on the overall approach, and on the allocation
of that new integer.

Greetings,

Stefan Winter

--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473




------enig2TGANGHAOHQVBRNENNJAJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHNVdUACgkQ+jm90f8eFWZ6pgCfWOZGmHHiO5U/6FGfZUcACAVJ
b7gAn0UKsPZLR3Y108HgwIxEstWcrW7q
=a7qT
-----END PGP SIGNATURE-----

------enig2TGANGHAOHQVBRNENNJAJ--

From Johannes.Merkle@secunet.com  Fri Jun 28 06:08:57 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAD821F9C53 for ; Fri, 28 Jun 2013 06:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSzm2T3KtOPf for ; Fri, 28 Jun 2013 06:08:52 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 626DD21F87B7 for ; Fri, 28 Jun 2013 06:08:51 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BD1BC1A00BD; Fri, 28 Jun 2013 15:08:48 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SnFEjcPoHFeK; Fri, 28 Jun 2013 15:08:47 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 4DF941A00B6; Fri, 28 Jun 2013 15:08:47 +0200 (CEST)
Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jun 2013 15:08:47 +0200
Message-ID: <51CD8ADE.20505@secunet.com>
Date: Fri, 28 Jun 2013 15:08:46 +0200
From: Johannes Merkle 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stefan Santesson 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jun 2013 13:08:47.0080 (UTC) FILETIME=[9FD6CE80:01CE7400]
Cc: PKIX 
Subject: [pkix] PKIX closing down?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jun 2013 13:08:57 -0000

Stefan,

> But as PKIX is closing down, it must be done some place else.

This is not the first time I read this statement on this list, but could not find any information in the PKIX charter or
anywhere else on the IETF web site.

Is this decided already and, if yes, when will close PKIX down, and which WG will take over PKI standards?

Johannes


From stefan@aaa-sec.com  Fri Jun 28 06:54:35 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277C721F853A for ; Fri, 28 Jun 2013 06:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level: 
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4aO42Z-Q1uA for ; Fri, 28 Jun 2013 06:54:29 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id CDDD321F8517 for ; Fri, 28 Jun 2013 06:54:28 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2D10C79D691 for ; Fri, 28 Jun 2013 15:54:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nmDhA5bvccYE for ; Fri, 28 Jun 2013 15:54:23 +0200 (CEST)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E8A0779D6A6 for ; Fri, 28 Jun 2013 15:54:23 +0200 (CEST)
Received: (qmail 57457 invoked from network); 28 Jun 2013 13:54:22 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Jun 2013 13:54:22 -0000
User-Agent: Microsoft-MacOutlook/14.3.5.130515
Date: Fri, 28 Jun 2013 15:54:19 +0200
From: Stefan Santesson 
To: Johannes Merkle , Sean Turner 
Message-ID: 
Thread-Topic: PKIX closing down?
In-Reply-To: <51CD8ADE.20505@secunet.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: PKIX 
Subject: Re: [pkix] PKIX closing down?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jun 2013 13:54:35 -0000

Hi Johannes,

No WG will take over. The IESG will have to look at each request for work
and decide what to do.
Referring to Sean Turner, the security AD responsible for PKIX for details.

/Stefan

On 6/28/13 3:08 PM, "Johannes Merkle"  wrote:

>Stefan,
>
>> But as PKIX is closing down, it must be done some place else.
>
>This is not the first time I read this statement on this list, but could
>not find any information in the PKIX charter or
>anywhere else on the IETF web site.
>
>Is this decided already and, if yes, when will close PKIX down, and which
>WG will take over PKI standards?
>
>Johannes
>



From housley@vigilsec.com  Fri Jun 28 07:46:27 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8205A21F9BB2 for ; Fri, 28 Jun 2013 07:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.799
X-Spam-Level: 
X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy5RUDjvatva for ; Fri, 28 Jun 2013 07:46:22 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id AEB9221F9B89 for ; Fri, 28 Jun 2013 07:46:22 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E9702F24083; Fri, 28 Jun 2013 10:46:34 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id SbCZ8LqwTZWk; Fri, 28 Jun 2013 10:46:09 -0400 (EDT)
Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DE7CDF24078; Fri, 28 Jun 2013 10:46:33 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Russ Housley 
In-Reply-To: <51CD55D5.2070206@restena.lu>
Date: Fri, 28 Jun 2013 10:46:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <740637E6-019C-4F47-B1BB-9180D3A69612@vigilsec.com>
References: <51CD55D5.2070206@restena.lu>
To: Stefan Winter 
X-Pgp-Agent: GPGMail 1.4.1
X-Mailer: Apple Mail (2.1085)
Cc: pkix@ietf.org
Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jun 2013 14:46:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan:

I suggest that you write a one or two page I-D that specifies the =
proposed alt name, and then bring it to this mail list for review.

Russ



On Jun 28, 2013, at 5:22 AM, Stefan Winter wrote:

> Hello,
>=20
> over in the RADIUS Extensions working group we are working on a
> discovery mechanism for RADIUS/TLS authentication servers. The =
algorithm
> makes use of DNS, -SEC is optional; in the absence of DNSSEC an X.509
> certificate of the discovered server needs to yield information =
whether
> it is authoritative for a NAI realm (i.e. "the 'domain' part of a
> User-Name attribute, in the form of user@realm").
>=20
> The discovery starts with a NAPTR for the service in question, and =
then
> may traverse a set of SRVs or not, to eventually end up at an A/AAAA
> record of the discovered hostname.
>=20
> Determination of the authoritativeness needs to be a part of the
> certificate; in a way analogous to SRVName. We cannot use SRVName
> directly though, since a possible SRV record occurs in the middle of a
> potentially untrusted lookup; if an attacker modified the initial =
NAPTR
> response, he can divert further SRV resolution steps to his own =
server.
>=20
> For that reason, we think we need a new sAN:otherName registration =
which
> allows us to compare that realm part of a User-Name (the actual,
> known-correct input to the algorithm) to the NAIRealm property of the
> certificate of the server that came out of the discovery process.
>=20
> In short:
>=20
> 1) Input: johndoe@myrealm.example
>=20
> 2) discovery algorithm yields output:
>   please contact A.B.C.D:2083 with RADIUS/TLS
>=20
> 3) TLS handshake verification: does X.509 cert contain
>   sAN:otherName:NAIRealm =3D=3D myrealm.example
>=20
> I have a new draft rev of
> https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ =
on
> my disk, which registers otherName:NAIRealm just like RFC4985 did (in
> fact, it is copy&paste :-) .
>=20
> I noticed that I need an integer in the "otherName" registry; RFC4985
> uses id-on-dnsSRV =3D 7; and I wonder who to approach and where to get =
my
> own integer for
>=20
>     id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX??? }
>=20
> from.
>=20
> I appreciate any thoughts on the overall approach, and on the =
allocation
> of that new integer.
>=20
> Greetings,
>=20
> Stefan Winter
>=20
> --=20
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education =
Nationale et
> de la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>=20
> Tel: +352 424409 1
> Fax: +352 422473
>=20
>=20
>=20
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlHNobwACgkQiuTu0PWcEctBRwCgvXADytW9XvKgv1oywarNbiMQ
gxkAoNjkMH4+PPM9w/hEpVsv92Zx6zAL
=3DMJJp
-----END PGP SIGNATURE-----

From turners@ieca.com  Fri Jun 28 09:48:26 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9211221F8584 for ; Fri, 28 Jun 2013 09:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.863
X-Spam-Level: 
X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfq6JuShh0+t for ; Fri, 28 Jun 2013 09:48:20 -0700 (PDT)
Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.164.10]) by ietfa.amsl.com (Postfix) with ESMTP id 450B521F8206 for ; Fri, 28 Jun 2013 09:48:20 -0700 (PDT)
Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 30996AEF73AD2; Fri, 28 Jun 2013 11:48:14 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 203C6AEF73A66 for ; Fri, 28 Jun 2013 11:48:14 -0500 (CDT)
Received: from [173.73.135.86] (port=50984 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsbqH-0008OP-TB; Fri, 28 Jun 2013 11:48:13 -0500
Message-ID: <51CDBE4D.40309@ieca.com>
Date: Fri, 28 Jun 2013 12:48:13 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Stefan Santesson 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [173.73.135.86]:50984
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 9
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: PKIX 
Subject: Re: [pkix] PKIX closing down?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jun 2013 16:48:26 -0000

The WG will close after EST is published but the mailing list will live on.

spt

On 6/28/13 9:54 AM, Stefan Santesson wrote:
> Hi Johannes,
>
> No WG will take over. The IESG will have to look at each request for work
> and decide what to do.
> Referring to Sean Turner, the security AD responsible for PKIX for details.
>
> /Stefan
>
> On 6/28/13 3:08 PM, "Johannes Merkle"  wrote:
>
>> Stefan,
>>
>>> But as PKIX is closing down, it must be done some place else.
>>
>> This is not the first time I read this statement on this list, but could
>> not find any information in the PKIX charter or
>> anywhere else on the IETF web site.
>>
>> Is this decided already and, if yes, when will close PKIX down, and which
>> WG will take over PKI standards?
>>
>> Johannes
>>
>
>
>

From wwwrun@rfc-editor.org  Fri Jun 28 12:27:33 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E37021F9AD6 for ; Fri, 28 Jun 2013 12:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVYUgHXLA9Eb for ; Fri, 28 Jun 2013 12:27:32 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 18BEB21F9C49 for ; Fri, 28 Jun 2013 12:27:31 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 9B9FE62109; Fri, 28 Jun 2013 12:24:43 -0700 (PDT)
To: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com
From: RFC Errata System 
Message-Id: <20130628192443.9B9FE62109@rfc-editor.org>
Date: Fri, 28 Jun 2013 12:24:43 -0700 (PDT)
X-Mailman-Approved-At: Fri, 28 Jun 2013 13:47:10 -0700
Cc: pkix@ietf.org, rfc-editor@rfc-editor.org
Subject: [pkix] [Editorial Errata Reported] RFC5280 (3674)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Jun 2013 19:27:33 -0000

The following errata report has been submitted for RFC5280,
"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3674

--------------------------------------
Type: Editorial
Reported by: Piyush Jain 

Section: 6.3.3

Original Text
-------------
If the distribution point name is present in the IDP CRL extension and the distribution field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP.

Corrected Text
--------------
If the distribution point name is present in the IDP CRL extension and the distributionPoint field is present in the DP, then verify that one of the names in the IDP matches one of the names in the DP.

Notes
-----
Original text refers to the non existent field "distribution" in DP.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5280 (draft-ietf-pkix-rfc3280bis-11)
--------------------------------------
Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Publication Date    : May 2008
Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

From datapacrat@gmail.com  Fri Jun 28 18:06:13 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5621F99E7 for ; Fri, 28 Jun 2013 18:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.216
X-Spam-Level: 
X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.384,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KLTAVx+LW-n for ; Fri, 28 Jun 2013 18:06:12 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15D21F99AF for ; Fri, 28 Jun 2013 18:06:12 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id b12so2107311wgh.31 for ; Fri, 28 Jun 2013 18:06:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=f9BWKJR0/TeT4Lg8mzKV0diPhzunSGoSrNmlNBM4h1c=; b=sDoWap/wbMsb2UR4Z5nYGJHNuGlGn8NeqTcTQcJthaDMHsK41okWujuPBETnl9d2Sj an7gny3xsnH9MegIW8PX1nKUNbTo8YDtoH7oXQ5RKflOVMx7nXrU+WqmUZqJmkVq3q6P MJjh89TK+s1KRLU38WWKzTYidSEt8xFlIiigCRwWhpTOqhjd2CxEEykVMuSydZ7uzL7m iS6bRkSGqE4HWjMO1YIzY9oUrVahbiOwe2Du+a545gABeGRnmwBvnquveNyMuGa0blFF Wa+rKJaRb1zs0G7EqqtDWsiLRuAQiaqT9sfp03bAGDs8BBCqmeGB2/1bWRhOOBQvkpjR 0EWQ==
MIME-Version: 1.0
X-Received: by 10.180.88.68 with SMTP id be4mr4042779wib.29.1372467971581; Fri, 28 Jun 2013 18:06:11 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Fri, 28 Jun 2013 18:06:11 -0700 (PDT)
Date: Fri, 28 Jun 2013 21:06:11 -0400
Message-ID: 
From: DataPacRat 
To: pkix@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [pkix] Initial inquiry: Signed vCards
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 01:06:13 -0000

Over at vcarddav@ietf, I've started a discussion on extending the
current format to allow for cryptographically signed vCards, to allow
for various forms of distributed, ad-hoc identity authentication.

Would pkix be the appropriate place to discuss the cryptographic and
security aspects of such signed vCards? If not, might I ask for a
recommendation of a better place for such a discussion?



Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

From datapacrat@gmail.com  Fri Jun 28 18:44:19 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF3B21F9DAB for ; Fri, 28 Jun 2013 18:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.28
X-Spam-Level: 
X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.320,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbVp70NCWj-a for ; Fri, 28 Jun 2013 18:44:18 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6B89F21F9DC6 for ; Fri, 28 Jun 2013 18:44:18 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w57so1734401wes.1 for ; Fri, 28 Jun 2013 18:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RZsk0aVnH8C1mIqseb0J2hwJny/DQvypR8xJSVEV1sg=; b=b8pTQDr8taJXiEdordUGDA+aojzPw2MgaLwTEV8bulMPLMP8LgYTJoXlRmY8ZvP0N4 h1DKBbSGgH4tZKMUlci700wB3trZ5r9RoodyK5qxDw+Z1XvPOAIrjGtP1ofnBDPS1HaX 6O/6DFLbZsrDxM6a0cwFKKCF9TVumc+5VZZqXNt6CQPjaTm2cvQtI2bIqBuVWwMrCxZ6 ibpHJu4bgfU05wYDKq4WxMcO8eQDlzy+WWx335tVnGEB8B9nXwA0VJ3wEv6j9WL6gOIP W22uhyhwbeNA11DyliOsNWGNUEQpijthUKEBsVzyLBJu0ZuyNz0YZzvtueXN/sg1QO5T NV5A==
MIME-Version: 1.0
X-Received: by 10.194.47.167 with SMTP id e7mr11597952wjn.57.1372470257433; Fri, 28 Jun 2013 18:44:17 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Fri, 28 Jun 2013 18:44:17 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 28 Jun 2013 21:44:17 -0400
Message-ID: 
From: DataPacRat 
To: Ryan Hurst , pkix@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [pkix] Initial inquiry: Signed vCards
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 01:44:19 -0000

On Fri, Jun 28, 2013 at 9:30 PM, Ryan Hurst  wrote:
> On Jun 28, 2013, at 8:06 PM, DataPacRat  wrote:

>> Over at vcarddav@ietf, I've started a discussion on extending the
>> current format to allow for cryptographically signed vCards, to allow
>> for various forms of distributed, ad-hoc identity authentication.
>>
>> Would pkix be the appropriate place to discuss the cryptographic and
>> security aspects of such signed vCards? If not, might I ask for a
>> recommendation of a better place for such a discussion?

> Is there a vCard format in JSON? Have you looked at JWT?

There's a WG which is writing up a spec for jCard, a JSON-based
version of vCard. ( https://tools.ietf.org/wg/jcardcal/charters ) I'm
afraid that I don't know enough about JWT or JSON to say whether or
not they would be good solutions for the problem I'm working on. (Put
simply: allowing easy Bayesian analysis of the trustworthiness of such
cards, so that everybody and their grandmother can serve as ad-hoc
certificate authorities, without relying on any particular
third-parties at any stage.)

I am reasonably sure that an enhanced vCard could do the trick; and
there's at least one proposal on the drawing board which could be
implemented with experimental X-type nametags immediately, without
causing any disturbance to any other vCard-based applications. I don't
know whether that particular approach is the best one - after all,
anybody can create a cryptographic system which is secure from
themselves. So I'm hoping to evoke enough constructive criticism to be
reasonably sure that any obvious holes are plugged from the get-go.



Thank you for your time,
--
DataPacRat
"If knowledge can create problems, it is not through ignorance that we
can solve them." -- Isaac Asimov

From ryan.hurst@globalsign.com  Fri Jun 28 19:28:08 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5659B21F9E16 for ; Fri, 28 Jun 2013 19:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SPVbAMUctSB for ; Fri, 28 Jun 2013 19:28:07 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 871B621F9E1F for ; Fri, 28 Jun 2013 19:28:07 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id c10so5081384ieb.24 for ; Fri, 28 Jun 2013 19:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=adoflu3A+naKhloRm36bRs6MY2G6ADRNCZARwsay4TA=; b=HyMiOFRebADWTuDShCKujIK1NIj/Dce7Jx8sFOt9xlYNFl34cRaqUUDbkWjmsjnfZD zfMXCIIMvt1esarnRINjfkcHW7QBjdu+HJbS9/mckbTjlfaUca1m5E+rsYlq9dIceJEz K0CbVW1+eiwOITsWb/4wn2GoIvh7Wq5+f+/8o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=adoflu3A+naKhloRm36bRs6MY2G6ADRNCZARwsay4TA=; b=JGB5fGTQWJziZNqy4dWSrJffeakYvSYRY9lQVHS3bXL+ec7nET/hBgEfefIRuSHZwR aFejQSmHWOiBSo2Fk3vJDSPxoXiZDC+qhg+18slUJnPDeH9kd0T/OwBdu4XtOLcNXf9O e6l9f4pfIO7hF5ULFlt6v1zcu1EfM1GCveCHNMLdX7oR3vz6VwmtTnKpgpSOVuVCPV7v T5co9fQEmXYMDZOZPkGiaj6yHHN95apJWnSiEd60Ur5A5ecLmTo+Y+85NrnRNp0JFLIf j6oZbFhlcTvj2N2XmN4LLbtAS+SO40Vr7B7vGUkEw48g+P2fT9fPVIcLi+XW/VrqrKr5 y8Ew==
X-Received: by 10.50.79.231 with SMTP id m7mr6484595igx.40.1372472886988; Fri, 28 Jun 2013 19:28:06 -0700 (PDT)
Received: from RyanUltrabook (mobile-166-147-098-139.mycingular.net. [166.147.98.139]) by mx.google.com with ESMTPSA id nt6sm1597639igb.10.2013.06.28.19.28.04 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Jun 2013 19:28:05 -0700 (PDT)
From: "Ryan Hurst" 
To: "'DataPacRat'" , 
References:   
In-Reply-To: 
Date: Fri, 28 Jun 2013 19:24:51 -0700
Message-ID: <00f701ce746f$d7444310$85ccc930$@globalsign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH/t6SZxVTwIxMeiG6bYe5QvT8GYQJgcDv1AghY8emYxijuYA==
Content-Language: en-us
X-Gm-Message-State: ALoCoQlrcoZaeFn6PDviWOFdtF+CgBX3imtZCm7+F1UsNoG3PHxUlXD3Otka4ZGH3Sjb2HE7+Lvz
Subject: Re: [pkix] Initial inquiry: Signed vCards
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 02:28:08 -0000

Well for a jCard I would look at JWT.

You should look at www.Persona.org, it is essentially a JSON based PKI based
on JWT; if you were to look at a Persona subscriber certificate you would
see something that very much looks like a vCard (in JSON of course).

Ryan

-----Original Message-----
From: DataPacRat [mailto:datapacrat@gmail.com] 
Sent: Friday, June 28, 2013 6:44 PM
To: Ryan Hurst; pkix@ietf.org
Subject: Re: [pkix] Initial inquiry: Signed vCards

On Fri, Jun 28, 2013 at 9:30 PM, Ryan Hurst 
wrote:
> On Jun 28, 2013, at 8:06 PM, DataPacRat  wrote:

>> Over at vcarddav@ietf, I've started a discussion on extending the 
>> current format to allow for cryptographically signed vCards, to allow 
>> for various forms of distributed, ad-hoc identity authentication.
>>
>> Would pkix be the appropriate place to discuss the cryptographic and 
>> security aspects of such signed vCards? If not, might I ask for a 
>> recommendation of a better place for such a discussion?

> Is there a vCard format in JSON? Have you looked at JWT?

There's a WG which is writing up a spec for jCard, a JSON-based version of
vCard. ( https://tools.ietf.org/wg/jcardcal/charters ) I'm afraid that I
don't know enough about JWT or JSON to say whether or not they would be good
solutions for the problem I'm working on. (Put
simply: allowing easy Bayesian analysis of the trustworthiness of such
cards, so that everybody and their grandmother can serve as ad-hoc
certificate authorities, without relying on any particular third-parties at
any stage.)

I am reasonably sure that an enhanced vCard could do the trick; and there's
at least one proposal on the drawing board which could be implemented with
experimental X-type nametags immediately, without causing any disturbance to
any other vCard-based applications. I don't know whether that particular
approach is the best one - after all, anybody can create a cryptographic
system which is secure from themselves. So I'm hoping to evoke enough
constructive criticism to be reasonably sure that any obvious holes are
plugged from the get-go.



Thank you for your time,
--
DataPacRat
"If knowledge can create problems, it is not through ignorance that we can
solve them." -- Isaac Asimov


From datapacrat@gmail.com  Sat Jun 29 05:51:27 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6911E810A for ; Sat, 29 Jun 2013 05:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.326
X-Spam-Level: 
X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.274,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm6RCxiaxJ67 for ; Sat, 29 Jun 2013 05:51:26 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AF16A11E8103 for ; Sat, 29 Jun 2013 05:51:25 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id q58so1990323wes.19 for ; Sat, 29 Jun 2013 05:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WjfLFYg8ZprsRfuWaPTsuoYFh7r0qwre5RlW1lECXuo=; b=WozzVCTWiKYMV7edX89KmPY/MLJwotR0eU3XUXbNuck4ziLSIpWIjCI5a7t7yP5IDp Krx3bxk4Ammt6yPvfvp+psZ1dSqNjaj+N6AtwI4OTjElRy5d9nwILPv4cvc/sThtgple ojYLitpDwJkjgkq43/Cb5Zy2ZtbvK+XCXFZIPrCv+FLbBOa2eVJOF5JxpIzDgBSaknSM IgfVbC9IdqQJNKP6eFaDxm9udmOcVdMkWMkGZM0jEVbg389mFCtZerhwZbCjVb9iSpEY u4N8nZhPcs2ZB/A9kGlt+mZJF6UcSlm3mC5cXg2AKa+Pl2hYOgcPcS3/I9mhON0pJRkA 1+aA==
MIME-Version: 1.0
X-Received: by 10.180.36.36 with SMTP id n4mr6416475wij.0.1372510284798; Sat, 29 Jun 2013 05:51:24 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Sat, 29 Jun 2013 05:51:24 -0700 (PDT)
In-Reply-To: <00f701ce746f$d7444310$85ccc930$@globalsign.com>
References:    <00f701ce746f$d7444310$85ccc930$@globalsign.com>
Date: Sat, 29 Jun 2013 08:51:24 -0400
Message-ID: 
From: DataPacRat 
To: Ryan Hurst 
Content-Type: text/plain; charset=ISO-8859-1
Cc: pkix@ietf.org
Subject: Re: [pkix] Initial inquiry: Signed vCards
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 12:51:28 -0000

On Fri, Jun 28, 2013 at 10:24 PM, Ryan Hurst  wrote:
> On Fri, Jun 28, 2013 at 9:30 PM, Ryan Hurst 
> wrote:
>> On Jun 28, 2013, at 8:06 PM, DataPacRat  wrote:

>>>> Over at vcarddav@ietf, I've started a discussion on extending the
>>>> current format to allow for cryptographically signed vCards, to allow
>>>> for various forms of distributed, ad-hoc identity authentication.
>>>>
>>>> Would pkix be the appropriate place to discuss the cryptographic and
>>>> security aspects of such signed vCards? If not, might I ask for a
>>>> recommendation of a better place for such a discussion?
>
>>> Is there a vCard format in JSON? Have you looked at JWT?
>
>> There's a WG which is writing up a spec for jCard, a JSON-based version of
>> vCard. ( https://tools.ietf.org/wg/jcardcal/charters ) I'm afraid that I
>> don't know enough about JWT or JSON to say whether or not they would be good
>> solutions for the problem I'm working on. (Put
>> simply: allowing easy Bayesian analysis of the trustworthiness of such
>> cards, so that everybody and their grandmother can serve as ad-hoc
>> certificate authorities, without relying on any particular third-parties at
>> any stage.)
>>
>> I am reasonably sure that an enhanced vCard could do the trick; and there's
>> at least one proposal on the drawing board which could be implemented with
>> experimental X-type nametags immediately, without causing any disturbance to
>> any other vCard-based applications. I don't know whether that particular
>> approach is the best one - after all, anybody can create a cryptographic
>> system which is secure from themselves. So I'm hoping to evoke enough
>> constructive criticism to be reasonably sure that any obvious holes are
>> plugged from the get-go.

> Well for a jCard I would look at JWT.
>
> You should look at www.Persona.org, it is essentially a JSON based PKI based
> on JWT; if you were to look at a Persona subscriber certificate you would
> see something that very much looks like a vCard (in JSON of course).

The BrowserID protocol which persona.org is built on is, indeed,
potentially a good starting system to base my own solution on.
However, the current BrowserID spec has various shortcomings for my
purposes. At the very least, from what I've read so far, BrowserID's
"Identity" is centered on having an email address as the identifier
for a given user, while I am looking for a system which allows for
essentially any arbitrary string (eg, a domain under the user's
control, or a social media profile URL). BrowserID also seems to be
based on an identity assertion either being true or false, while I'm
trying to end up with a system that instead has a reliability level of
any truth-value between 0 and 1. (Well, more technically, using a
logarithmic measure using a unit called decibans, a truth-value that's
most likely to be an integer between -127 and 127.)

It's entirely possible that, if I can get a signed vCard format to
serve as an identity certificate (or some other method which
accomplishes that part of my goals), I'll try to get in touch with the
relevant people at Mozilla to see about extending (or forking)
BrowserID for the main application of the cryptosystem. At this stage,
I'm also willing to entertain any other ideas, suggestions, criticism,
and commentary.



Thank you for your time,
--
DataPacRat
"There is no such thing as luck; there is only adequate or inadequate
preparation to cope with a statistical universe. " -- Heinlein

From stefan@aaa-sec.com  Sat Jun 29 05:17:32 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1411E80F0 for ; Sat, 29 Jun 2013 05:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level: 
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v417iGdpBYmz for ; Sat, 29 Jun 2013 05:17:27 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9AC11E80E7 for ; Sat, 29 Jun 2013 05:17:26 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id CBB477ACF7E for ; Sat, 29 Jun 2013 14:17:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ts3qt8CwwoxI for ; Sat, 29 Jun 2013 14:17:24 +0200 (CEST)
Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2621F7ACF82 for ; Sat, 29 Jun 2013 14:17:24 +0200 (CEST)
Received: (qmail 37165 invoked from network); 29 Jun 2013 12:17:23 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Jun 2013 12:17:23 -0000
User-Agent: Microsoft-MacOutlook/14.3.5.130515
Date: Sat, 29 Jun 2013 14:17:15 +0200
From: Stefan Santesson 
To: RFC Errata System , , , , , , , , 
Message-ID: 
Thread-Topic: [Editorial Errata Reported] RFC5280 (3674)
In-Reply-To: <20130628192443.9B9FE62109@rfc-editor.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Mailman-Approved-At: Sat, 29 Jun 2013 06:07:52 -0700
Cc: pkix@ietf.org
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3674)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 12:17:32 -0000

This errata seems to be correct.

/Stefan


On 6/28/13 9:24 PM, "RFC Errata System"  wrote:

>The following errata report has been submitted for RFC5280,
>"Internet X.509 Public Key Infrastructure Certificate and Certificate
>Revocation List (CRL) Profile".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3674
>
>--------------------------------------
>Type: Editorial
>Reported by: Piyush Jain 
>
>Section: 6.3.3
>
>Original Text
>-------------
>If the distribution point name is present in the IDP CRL extension and
>the distribution field is present in the DP, then verify that one of the
>names in the IDP matches one of the names in the DP.
>
>Corrected Text
>--------------
>If the distribution point name is present in the IDP CRL extension and
>the distributionPoint field is present in the DP, then verify that one of
>the names in the IDP matches one of the names in the DP.
>
>Notes
>-----
>Original text refers to the non existent field "distribution" in DP.
>
>Instructions:
>-------------
>This errata is currently posted as "Reported". If necessary, please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party (IESG)
>can log in to change the status and edit the report, if necessary.
>
>--------------------------------------
>RFC5280 (draft-ietf-pkix-rfc3280bis-11)
>--------------------------------------
>Title               : Internet X.509 Public Key Infrastructure
>Certificate and Certificate Revocation List (CRL) Profile
>Publication Date    : May 2008
>Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R.
>Housley, W. Polk
>Category            : PROPOSED STANDARD
>Source              : Public-Key Infrastructure (X.509)
>Area                : Security
>Stream              : IETF
>Verifying Party     : IESG



From stefan@aaa-sec.com  Sat Jun 29 07:14:45 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB54621F9FF4 for ; Sat, 29 Jun 2013 07:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.951
X-Spam-Level: 
X-Spam-Status: No, score=-100.951 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_39=0.6, J_CHICKENPOX_45=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKwXG16iE50C for ; Sat, 29 Jun 2013 07:14:40 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6C321F9F95 for ; Sat, 29 Jun 2013 07:14:39 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id EBFBF7AE50F for ; Sat, 29 Jun 2013 16:14:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9JJ5MdCibLR1 for ; Sat, 29 Jun 2013 16:14:36 +0200 (CEST)
Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 86B607AE59E for ; Sat, 29 Jun 2013 16:14:36 +0200 (CEST)
Received: (qmail 74439 invoked from network); 29 Jun 2013 14:14:36 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Jun 2013 14:14:36 -0000
User-Agent: Microsoft-MacOutlook/14.3.5.130515
Date: Sat, 29 Jun 2013 16:14:33 +0200
From: Stefan Santesson 
To: Stefan Winter , 
Message-ID: 
Thread-Topic: [pkix] Registration of a new sAN:otherName (NAIRealm)
In-Reply-To: <51CD55D5.2070206@restena.lu>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 14:14:46 -0000

Hi,

I suspect you have made a misinterpretation of the service name SAN
defined in RFC 4985.

When you say:
"We cannot use SRVName
directly though, since a possible SRV record occurs in the middle of a
potentially untrusted lookup;"

Then I suspect you miss the whole pint with RFC 4985.

The whole point is the the SRV record from DNS is not, or may not be,
trusted. It's just used for lookup.
Once you found a potential service host through DNS lookup, you can verify
that it is authorised to actually provide this service using its
certificate.
What the service name defined in RFC 4985 provides is precisely this, a
means to authenticate that a particular server/host is actually authorised
to provide a particular service.

The assertion in the cert is not made by DNS, it is made by a
certification authority (CA) that you presumably trust to make this
assertion.
The similarity of name form used in the service name SAN is just to make
it easy to compare this name with information obtained from the DNS.

I could be missing something, but, following your draft the the example
given below, what prevents you from providing a service name SAN in
accordance with RFC 4985 with the value:

_radiustls.myrealm.example.com


This would provide an assertion independent of DNS, that this host is
authorised to provide RADIUS/TLS for the myrealm.example.com domain.

/Stefan


On 6/28/13 11:22 AM, "Stefan Winter"  wrote:

>Hello,
>
>over in the RADIUS Extensions working group we are working on a
>discovery mechanism for RADIUS/TLS authentication servers. The algorithm
>makes use of DNS, -SEC is optional; in the absence of DNSSEC an X.509
>certificate of the discovered server needs to yield information whether
>it is authoritative for a NAI realm (i.e. "the 'domain' part of a
>User-Name attribute, in the form of user@realm").
>
>The discovery starts with a NAPTR for the service in question, and then
>may traverse a set of SRVs or not, to eventually end up at an A/AAAA
>record of the discovered hostname.
>
>Determination of the authoritativeness needs to be a part of the
>certificate; in a way analogous to SRVName. We cannot use SRVName
>directly though, since a possible SRV record occurs in the middle of a
>potentially untrusted lookup; if an attacker modified the initial NAPTR
>response, he can divert further SRV resolution steps to his own server.
>
>For that reason, we think we need a new sAN:otherName registration which
>allows us to compare that realm part of a User-Name (the actual,
>known-correct input to the algorithm) to the NAIRealm property of the
>certificate of the server that came out of the discovery process.
>
>In short:
>
>1) Input: johndoe@myrealm.example
>
>2) discovery algorithm yields output:
>   please contact A.B.C.D:2083 with RADIUS/TLS
>
>3) TLS handshake verification: does X.509 cert contain
>   sAN:otherName:NAIRealm =3D=3D myrealm.example
>
>I have a new draft rev of
>https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ on
>my disk, which registers otherName:NAIRealm just like RFC4985 did (in
>fact, it is copy&paste :-) .
>
>I noticed that I need an integer in the "otherName" registry; RFC4985
>uses id-on-dnsSRV =3D 7; and I wonder who to approach and where to get my
>own integer for
>
>     id-on-nai OBJECT IDENTIFIER ::=3D { id-on XXX??? }
>
>from.
>
>I appreciate any thoughts on the overall approach, and on the allocation
>of that new integer.
>
>Greetings,
>
>Stefan Winter
>
>--=20
>Stefan WINTER
>Ingenieur de Recherche
>Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale et
>de la Recherche
>6, rue Richard Coudenhove-Kalergi
>L-1359 Luxembourg
>
>Tel: +352 424409 1
>Fax: +352 422473
>
>
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix



From ryan.hurst@globalsign.com  Sat Jun 29 12:26:48 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C942D21F9F97 for ; Sat, 29 Jun 2013 12:26:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level: 
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZwt4F2l0ssN for ; Sat, 29 Jun 2013 12:26:47 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9248D21F9F8C for ; Sat, 29 Jun 2013 12:26:47 -0700 (PDT)
Received: by mail-pa0-f49.google.com with SMTP id ld11so3616228pab.22 for ; Sat, 29 Jun 2013 12:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=ScT95Rb2V43gib6vMgNp3++fSwvcveeHm+W/MVkFU7c=; b=AZaT+HPygcXsJZXyrJmphiwkJHoOheV6/qQq5lrmcpYlsmQip0Od3lERogAFECNRgh RO865nNqUP8zsXBxj2FCgeUBEhV01BqkrNWa9gA7Nd4kJcwCXoFdwF3cdKbd+B/Sf2Pd CdTqJwX6QgoV/6ZFi55nYszBakZRYnDsejU7s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=ScT95Rb2V43gib6vMgNp3++fSwvcveeHm+W/MVkFU7c=; b=BK85vuwAsPJ8w9KvQe7ElC5X/D/UBJtErzt6WiqQ4SUh38Gz8PhzkE2LsA3Pg8NqPf /b2+gf0F1vmagVc28+CyXIZp2DMGNTnEvtCQfFvMCgtaskDI5YgeMbAQC0630rSUBr2B fXXOS56Bofk8nDrmu1MhHRkMy+FM7msSdGqec8IqoF+tn8Twk7FPAKROjY8z7guUOT16 6u7SpJDnrRxchNUlOWZv9EhkNHavuYPdEPkgkb+qqaNXp5ZTicEPenlZ9l4DsmYen+lF fzmup9PWqhkRUOObA5tpvkZFe5s45SJqtVHt7PKkuqF57Tgvqwyx4k1VqKODDOzae8TM Z6yQ==
X-Received: by 10.66.155.230 with SMTP id vz6mr16978665pab.30.1372534005967; Sat, 29 Jun 2013 12:26:45 -0700 (PDT)
Received: from [192.168.1.14] ([50.46.254.134]) by mx.google.com with ESMTPSA id xz1sm15230525pab.5.2013.06.29.12.26.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Jun 2013 12:26:44 -0700 (PDT)
References:    <00f701ce746f$d7444310$85ccc930$@globalsign.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4DD049A3-21D4-4505-AB34-5632BBBE5C5E; protocol="application/pkcs7-signature"
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (10B329)
From: Ryan Hurst 
Date: Sat, 29 Jun 2013 12:26:41 -0700
To: DataPacRat 
X-Gm-Message-State: ALoCoQnj8c34oLTyDS0O9Z66yU12WGL8HNEgIWtbZTYxUhv9/xgjeYXGO+ismEvpkzdiADeB3zdE
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] Initial inquiry: Signed vCards
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 19:26:48 -0000

--Apple-Mail-4DD049A3-21D4-4505-AB34-5632BBBE5C5E
Content-Type: multipart/alternative;
	boundary=Apple-Mail-939C9E08-3882-411E-B4F8-168DD8892652
Content-Transfer-Encoding: 7bit


--Apple-Mail-939C9E08-3882-411E-B4F8-168DD8892652
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Also look at : http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-wi=
th-webfist.html?m=3D1

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: ryan.hurst@globalsign.com
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Jun 29, 2013, at 5:51 AM, DataPacRat  wrote:

> On Fri, Jun 28, 2013 at 10:24 PM, Ryan Hurst  w=
rote:
>> On Fri, Jun 28, 2013 at 9:30 PM, Ryan Hurst 
>> wrote:
>>> On Jun 28, 2013, at 8:06 PM, DataPacRat  wrote:
>=20
>>>>> Over at vcarddav@ietf, I've started a discussion on extending the
>>>>> current format to allow for cryptographically signed vCards, to allow
>>>>> for various forms of distributed, ad-hoc identity authentication.
>>>>>=20
>>>>> Would pkix be the appropriate place to discuss the cryptographic and
>>>>> security aspects of such signed vCards? If not, might I ask for a
>>>>> recommendation of a better place for such a discussion?
>>=20
>>>> Is there a vCard format in JSON? Have you looked at JWT?
>>=20
>>> There's a WG which is writing up a spec for jCard, a JSON-based version o=
f
>>> vCard. ( https://tools.ietf.org/wg/jcardcal/charters ) I'm afraid that I=

>>> don't know enough about JWT or JSON to say whether or not they would be g=
ood
>>> solutions for the problem I'm working on. (Put
>>> simply: allowing easy Bayesian analysis of the trustworthiness of such
>>> cards, so that everybody and their grandmother can serve as ad-hoc
>>> certificate authorities, without relying on any particular third-parties=
 at
>>> any stage.)
>>>=20
>>> I am reasonably sure that an enhanced vCard could do the trick; and ther=
e's
>>> at least one proposal on the drawing board which could be implemented wi=
th
>>> experimental X-type nametags immediately, without causing any disturbanc=
e to
>>> any other vCard-based applications. I don't know whether that particular=

>>> approach is the best one - after all, anybody can create a cryptographic=

>>> system which is secure from themselves. So I'm hoping to evoke enough
>>> constructive criticism to be reasonably sure that any obvious holes are
>>> plugged from the get-go.
>=20
>> Well for a jCard I would look at JWT.
>>=20
>> You should look at www.Persona.org, it is essentially a JSON based PKI ba=
sed
>> on JWT; if you were to look at a Persona subscriber certificate you would=

>> see something that very much looks like a vCard (in JSON of course).
>=20
> The BrowserID protocol which persona.org is built on is, indeed,
> potentially a good starting system to base my own solution on.
> However, the current BrowserID spec has various shortcomings for my
> purposes. At the very least, from what I've read so far, BrowserID's
> "Identity" is centered on having an email address as the identifier
> for a given user, while I am looking for a system which allows for
> essentially any arbitrary string (eg, a domain under the user's
> control, or a social media profile URL). BrowserID also seems to be
> based on an identity assertion either being true or false, while I'm
> trying to end up with a system that instead has a reliability level of
> any truth-value between 0 and 1. (Well, more technically, using a
> logarithmic measure using a unit called decibans, a truth-value that's
> most likely to be an integer between -127 and 127.)
>=20
> It's entirely possible that, if I can get a signed vCard format to
> serve as an identity certificate (or some other method which
> accomplishes that part of my goals), I'll try to get in touch with the
> relevant people at Mozilla to see about extending (or forking)
> BrowserID for the main application of the cryptosystem. At this stage,
> I'm also willing to entertain any other ideas, suggestions, criticism,
> and commentary.
>=20
>=20
>=20
> Thank you for your time,
> --
> DataPacRat
> "There is no such thing as luck; there is only adequate or inadequate
> preparation to cope with a statistical universe. " -- Heinlein

--Apple-Mail-939C9E08-3882-411E-B4F8-168DD8892652
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Also look at : =
http://www.onebigfluke.com/2013/06/bootstrapping-webfinge=
r-with-webfist.html?m=3D1

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
phone: 206-650-7=
926

Sent from my phone, please forgive the brevity.=


On Jun 29, 2013, at 5:51 AM, DataPacRat <datapacrat@gmail.com> wrote:
On Fri, Jun 28, 2013 at 10:24 P=
M, Ryan Hurst <ryan.hurst@gl=
obalsign.com> wrote:
On Fri=
, Jun 28, 2013 at 9:30 PM, Ryan Hurst <ryan.hurst@globalsign.com>
wrote:
On Jun 28, 2013, at 8:06 PM, DataPacRat &=
lt;datapacrat@gmail.com> wrot=
e:

Over at vcarddav@ietf, I've started a discussion on extending t=
he
current format to allow for cryptographically signed v=
Cards, to allow
for various forms of distributed, ad-hoc=
 identity authentication.
<=
/blockquote>

Would pkix b=
e the appropriate place to discuss the cryptographic and
security aspects of such signed vCards? If not, might I ask for a
recommendation of a better place for such a discussion?

Is there a vCard format in JSON? Have=
 you looked at JWT?

<=
blockquote type=3D"cite">There's a WG which is writing up a spec for j=
Card, a JSON-based version of
vCard. ( https://tools.ietf.org/wg/jcardcal/char=
ters ) I'm afraid that I
don't know enough about JWT o=
r JSON to say whether or not they would be good
solutions f=
or the problem I'm working on. (Put
simply: allowing easy B=
ayesian analysis of the trustworthiness of such
cards, so t=
hat everybody and their grandmother can serve as ad-hoc
ce=
rtificate authorities, without relying on any particular third-parties at
any stage.)

I am reasona=
bly sure that an enhanced vCard could do the trick; and there's
=
at least one proposal on the drawing board which could be implemented w=
ith
experimental X-type nametags immediately, without caus=
ing any disturbance to
any other vCard-based applications. I=
 don't know whether that particular
approach is the best o=
ne - after all, anybody can create a cryptographic
system w=
hich is secure from themselves. So I'm hoping to evoke enough
constructive criticism to be reasonably sure that any obvious holes are<=
/span>
plugged from the get-go.

Well for a jCard I would=
 look at JWT.
=

You should look at www.Persona.org, it is essentially a JSON based=
 PKI based
on JWT; if=
 you were to look at a Persona subscriber certificate you would
see something that very much look=
s like a vCard (in JSON of course).

=
The BrowserID protocol which persona.or=
g is built on is, indeed,
potentially a good starting sy=
stem to base my own solution on.
However, the current Browse=
rID spec has various shortcomings for my
purposes. At the ve=
ry least, from what I've read so far, BrowserID's
"Identity"=
 is centered on having an email address as the identifier
fo=
r a given user, while I am looking for a system which allows for
<=
span>essentially any arbitrary string (eg, a domain under the user's<=
br>control, or a social media profile URL). BrowserID also seems to be=

based on an identity assertion either being true or false, w=
hile I'm
trying to end up with a system that instead has a r=
eliability level of
any truth-value between 0 and 1. (Well, m=
ore technically, using a
logarithmic measure using a unit ca=
lled decibans, a truth-value that's
most likely to be an int=
eger between -127 and 127.)

It's entirely p=
ossible that, if I can get a signed vCard format to
serve as=
 an identity certificate (or some other method which
accompl=
ishes that part of my goals), I'll try to get in touch with the
relevant people at Mozilla to see about extending (or forking)BrowserID for the main application of the cryptosystem. At this stage=
,
I'm also willing to entertain any other ideas, suggestions=
, criticism,
and commentary.



Thank you for your time,
--
DataPacRat
"There is no such thing as lu=
ck; there is only adequate or inadequate
preparation to cope=
 with a statistical universe. " -- Heinlein
=

--Apple-Mail-939C9E08-3882-411E-B4F8-168DD8892652--

--Apple-Mail-4DD049A3-21D4-4505-AB34-5632BBBE5C5E
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFCjCCBQYw
ggPuoAMCAQICEhEhb640/F3CUxHuqwZT6bSC5TANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJC
RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h
bFNpZ24gMiBDQSAtIEcyMB4XDTEyMDEyMzE2MzY1OVoXDTE1MDEyMzE2MzY1OVowgZQxCzAJBgNV
BAYTAlVTMRYwFAYDVQQIEw1OZXcgSGFtc3BoaXJlMRMwEQYDVQQHEwpQb3J0c21vdXRoMRkwFwYD
VQQKExBHbG9iYWxTaWduLCBJbmMuMRMwEQYDVQQDEwpSeWFuIEh1cnN0MSgwJgYJKoZIhvcNAQkB
FhlyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAuAEkk72r5rBUAKG+tLpEksDgC/Z0/7PfZbTVAgH+Xzx+YzXHjCsWkLHtpojpkUSF2spHKtaf
02yO9GbXHt/K9pmzsKgxxz1YtdxsSRMlF1oGkQbXgzLuThsljRtZHIVbBlqW7LU9GeL9JneZtQWB
Z8QdtHmycjkdpVw8bBStvJ5ylfuXjI++lPAaT0OEgh+8kzBustF17Ad3AqwSq9qN0zmIBCr/qDZ2
2qDLd1MTLfZ0n/Y8iLIY6n50+QHsNwlDTGrTueYORV13SLpAMHoNWEm9ZbNOalt7FtNE93e3ULPf
+zbsQoPwNnpZlSUqMvPjC0fCUhRH/2jIIzv08i4P4wIDAQABo4IBjzCCAYswDgYDVR0PAQH/BAQD
AgWgME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n
bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAkBgNVHREEHTAbgRlyeWFuLmh1cnN0QGdsb2JhbHNp
Z24uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3NwZXJzb25hbHNpZ24yZzIu
Y3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDovL3NlY3VyZS5nbG9iYWxzaWdu
LmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0GA1UdDgQWBBRVohAntPy+9nlWKnFm
Jy1ekko84TAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTANBgkqhkiG9w0BAQUFAAOC
AQEAIUIuoSz3rnZn9yAReCA8wr0SNBWmHQSn6a0pPx9Dw3muL6bC21qQNLdEmoo4iWLcSo5TOGz3
ftnIW+3o2rQ3cq2SM5g1cquHN9P8TJ4pxiqJKWANdf1Xvotnb47pbuuamrK7UERsmwLrmeu5a6fy
tzjBYI1eTQtwB2C87zVOA8HOEENQWjDoOis2EqymwAUWWo366Qvbonj7L+5gyFy8f7aAT8VjZWub
yZuQ62XZ+7h3bwQhOpDMpGzizeaZhCtFCJcCoekIuVw9Kc5VZBGZYhZATCYLm3f3he8XoO0yj1gu
ccjhafUnTKJSTOy0wt8J0jt36wQHr/qv5xrPV8cr7DGCAuowggLmAgEBMGowVDELMAkGA1UEBhMC
QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u
YWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMAkGBSsOAwIaBQCgggFVMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYyOTE5MjY0M1owIwYJKoZI
hvcNAQkEMRYEFB3fpsco9yYI+fggRCXnsy6bWAgxMHkGCSsGAQQBgjcQBDFsMGowVDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMHsGCyqGSIb3DQEJEAILMWyg
ajBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv
YmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIEcyAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZI
hvcNAQEBBQAEggEAgJJzx5Yrx56joo4xzQYIEMA4Xww87pqeA/G5m+2efMPZHNkBj/G1dnoxfOS+
+/FWdka/Ol9eNvORGs+SqGt1QjQeFOGfkzZbYg2ldcc/6y4pOjcxH8JG6/naGKW/doj1DfwG3gkc
b4Ab2tFwVJI0OQCvBH/9wJDfdQ/LJobLcRRHPh8ggW4Ioouc1Kd9RsEvVPmzR9aDgwFMmYU5S9/E
l7Z1kk0w6KR8uUV+hzAhb5UaI5+gafObjNf86tW4OVtKU+mB4uw7ocD/PiClPFNjG7Wnl0cfW9RV
rXDzZjnShSWO6ZFOnr333kLMtcr3k+kbNIPG2H+iaCmzGb1IID610QAAAAAAAA==

--Apple-Mail-4DD049A3-21D4-4505-AB34-5632BBBE5C5E--

From datapacrat@gmail.com  Sat Jun 29 12:50:57 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94E21F9FFF for ; Sat, 29 Jun 2013 12:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.408
X-Spam-Level: 
X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4j3gTsrQdyS for ; Sat, 29 Jun 2013 12:50:56 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5905111E8187 for ; Sat, 29 Jun 2013 12:50:50 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id f11so2615978wgh.15 for ; Sat, 29 Jun 2013 12:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SaJ/JKQZ/vdWa2GPS4OTuCiUPVzchGdc0JsxrLUhJAc=; b=HpYj2Wyx4tiRhbxDJaiY/Vk9gbwv+dgdLNJCt5Nyql+a+cxQwpwoVp0y4VdZh3oHI4 b42EJWlVjbATu/yIVE+tvxlr/M9xgJtySEqqyGJUxKmaXHZAv40U1BTF+k6agOXBV6Rn WCtkCWZlmzbjWqC3z+jOofSwxBzUAv7wHKtN+S0zm+XE+tG5k+KW0LlbBHpxBYvOGeDi QBiHvdxMy5ZheyFsvDmMbFwrvdWEvdZ4lX5EesJ5jz/9Nb0Hhfk3jN6Z8TiZ+gGV6+VU 8Sw9iJCi8wseWGqs6KtMpnHOVXVWJD/TenVewCRzQJkoas2G/yWG0Qjtr6HjtsDifVgC gTrQ==
MIME-Version: 1.0
X-Received: by 10.180.24.163 with SMTP id v3mr1445191wif.29.1372535449537; Sat, 29 Jun 2013 12:50:49 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Sat, 29 Jun 2013 12:50:49 -0700 (PDT)
In-Reply-To: 
References:    <00f701ce746f$d7444310$85ccc930$@globalsign.com>  
Date: Sat, 29 Jun 2013 15:50:49 -0400
Message-ID: 
From: DataPacRat 
To: Ryan Hurst 
Content-Type: multipart/alternative; boundary=f46d04448075e9540704e0504f91
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] Initial inquiry: Signed vCards
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Jun 2013 19:50:57 -0000

--f46d04448075e9540704e0504f91
Content-Type: text/plain; charset=ISO-8859-1

The complete reliance on DKIM-signed emails makes using webfist as-is
unsuitable for my needs; but the peer-to-peer distributed exchange of
authentication hash-blobs is just about perfect, for that portion of the
overall system I'm hoping to end up with.


On Saturday, 29 June 2013, Ryan Hurst wrote:

> Also look at :
> http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html?m=1
>
> Ryan Hurst
> Chief Technology Officer
> GMO Globalsign
>
> twitter: @rmhrisk
> email: ryan.hurst@globalsign.com  'ryan.hurst@globalsign.com');>
> phone: 206-650-7926
>
> Sent from my phone, please forgive the brevity.
>
> On Jun 29, 2013, at 5:51 AM, DataPacRat  wrote:
>
> On Fri, Jun 28, 2013 at 10:24 PM, Ryan Hurst 
> wrote:
>
> On Fri, Jun 28, 2013 at 9:30 PM, Ryan Hurst 
>
> wrote:
>
> On Jun 28, 2013, at 8:06 PM, DataPacRat  wrote:
>
>
> Over at vcarddav@ietf, I've started a discussion on extending the
>
> current format to allow for cryptographically signed vCards, to allow
>
> for various forms of distributed, ad-hoc identity authentication.
>
>
> Would pkix be the appropriate place to discuss the cryptographic and
>
> security aspects of such signed vCards? If not, might I ask for a
>
> recommendation of a better place for such a discussion?
>
>
> Is there a vCard format in JSON? Have you looked at JWT?
>
>
> There's a WG which is writing up a spec for jCard, a JSON-based version of
>
> vCard. ( https://tools.ietf.org/wg/jcardcal/charters ) I'm afraid that I
>
> don't know enough about JWT or JSON to say whether or not they would be
> good
>
> solutions for the problem I'm working on. (Put
>
> simply: allowing easy Bayesian analysis of the trustworthiness of such
>
> cards, so that everybody and their grandmother can serve as ad-hoc
>
> certificate authorities, without relying on any particular third-parties at
>
> any stage.)
>
>
> I am reasonably sure that an enhanced vCard could do the trick; and there's
>
> at least one proposal on the drawing board which could be implemented with
>
> experimental X-type nametags immediately, without causing any disturbance
> to
>
> any other vCard-based applications. I don't know whether that particular
>
> approach is the best one - after all, anybody can create a cryptographic
>
>

-- 
Thank you for your time,
-- 
DataPacRat

--f46d04448075e9540704e0504f91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The complete=A0reliance on DKIM-signed emails makes using webfist as-is uns=
uitable for my needs; but the peer-to-peer=A0distributed exchange of authen=
tication hash-blobs is just about perfect, for that portion of the overall=
=A0system I'm hoping to end up with.



On Saturday, 29 June 2013, Ryan Hurst  wrote:
Also look at :=A0http://www.onebigfluke.com/=
2013/06/bootstrapping-webfinger-with-webfist.html?m=3D1


Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk


phone: 206-650-7926

Sent from my phone, pleas=
e forgive the brevity.

On Jun 29, 2013, at 5:51 A=
M, DataPacRat <datapacrat@gmail.com> wrote:



On Fri, Jun 28, 2013 at 10:24 PM, Ryan Hurst <ryan.hurst@g=
lobalsign.com> wrote:
On F=
ri, Jun 28, 2013 at 9:30 PM, Ryan Hurst <ryan.hurst@globalsign.com>


wrote:
=

On Jun 28, 2013, =
at 8:06 PM, DataPacRat <datapacrat@gmail.com> wrote:



Over at vc=
arddav@ietf, I've started a discussion on extending the


c=
urrent format to allow for cryptographically signed vCards, to allow=



for various forms of distributed, ad-hoc identity authenticatio=
n.



=



Would pkix be the appropriate place to discuss the cryptographic a=
nd


security aspects of such signed vCards? If not, might I ask for a<=
/span>


recommendation of a better place for such a discussion?
=




Is there a vCard format in JSON? Have you looked at J=
WT?


There's a WG which is writing up a spec for jCard, a JSON-=
based version of


vCard. ( https://tools.ietf.org/wg/jcardcal/=
charters ) I'm afraid that I


don't know enough about JWT or JSON to =
say whether or not they would be good
<=
blockquote type=3D"cite">
solutions for the =
problem I'm working on. (Put


simply: allowing easy Bayesian analysis of the trustworthiness of =
such

cards, so that everybody and their grandmother can serve as ad-hoc
certificate authorities, without relying on any particular=
 third-parties at


any stage.)



I am reasonably sure that an enhanced vCard=
 could do the trick; and there's
at least one propos=
al on the drawing board which could be implemented with


experimental X-type nametags immediately, without causing any dist=
urbance to

any other vCard-based applications. I don't know whether that par=
ticular
approach is the best one - after all, anybody ca=
n create a cryptographic



-- 
Thank you for your time,
-- 
DataPacRat


--f46d04448075e9540704e0504f91--

From pgut001@cs.auckland.ac.nz  Sun Jun 30 04:07:21 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385F721F9A75 for ; Sun, 30 Jun 2013 04:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reRaeUNUitW6 for ; Sun, 30 Jun 2013 04:07:15 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id A36E821F9A71 for ; Sun, 30 Jun 2013 04:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1372590436; x=1404126436; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qf/3ryIPj08qZwBxxFG676MOyth4DpakHOUcs+ynr/g=; b=AoqlDqdyesAuviAB5Y0ekxolKtVHcAGDB5q8lgltNGeEzv5/lEmY6p/K U0Rrgyf1Qy++8NhZ3/vp7l9vzugKAYohYXQO28VFIxpeWtWDHoSMWLdG2 M1h5c1msUArmVc4YhXnYhZpZxWmZWk8hp5d6coKTnP9kAXgBP6qCkiuhy I=;
X-IronPort-AV: E=Sophos;i="4.87,968,1363086000"; d="scan'208";a="196294371"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Jun 2013 23:07:12 +1200
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.214]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sun, 30 Jun 2013 23:07:12 +1200
From: Peter Gutmann 
To: RFC Errata System , Stefan Santesson , "pkix@ietf.org" 
Thread-Topic: [Editorial Errata Reported] RFC5280 (3674)
Thread-Index: Ac51gfhkY25h4OsIRVWAJUh1CH300w==
Date: Sun, 30 Jun 2013 11:07:12 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D7092A@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3674)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Jun 2013 11:07:21 -0000

Stefan Santesson  writes:=0A=
=0A=
>This errata seems to be correct.=0A=
=0A=
Not quite correct.  It repeatedly uses "errata" when it should be using=0A=
"erratum".  Should I file a corrigendum for this?=0A=
=0A=
Peter.=0A=

From stefan@aaa-sec.com  Sun Jun 30 05:29:43 2013
Return-Path: 
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E688C21F9B3E for ; Sun, 30 Jun 2013 05:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.816
X-Spam-Level: 
X-Spam-Status: No, score=-101.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo8rceuUzam6 for ; Sun, 30 Jun 2013 05:29:37 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9809621F9B3C for ; Sun, 30 Jun 2013 05:29:36 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9EA147BC984 for ; Sun, 30 Jun 2013 14:29:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8PIQUM6tIiYP for ; Sun, 30 Jun 2013 14:29:34 +0200 (CEST)
Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 65D497BC98A for ; Sun, 30 Jun 2013 14:29:34 +0200 (CEST)
Received: (qmail 1590 invoked from network); 30 Jun 2013 12:29:34 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Jun 2013 12:29:34 -0000
User-Agent: Microsoft-MacOutlook/14.3.5.130515
Date: Sun, 30 Jun 2013 14:29:30 +0200
From: Stefan Santesson 
To: Peter Gutmann , RFC Errata System , "pkix@ietf.org" 
Message-ID: 
Thread-Topic: [Editorial Errata Reported] RFC5280 (3674)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D7092A@uxcn10-2.UoA.auckland.ac.nz>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (3674)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Jun 2013 12:29:44 -0000

I don't think that is necessary. The comment here is probably sufficient.

/Stefan

On 6/30/13 1:07 PM, "Peter Gutmann"  wrote:

>Stefan Santesson  writes:
>
>>This errata seems to be correct.
>
>Not quite correct.  It repeatedly uses "errata" when it should be using
>"erratum".  Should I file a corrigendum for this?
>
>Peter.