about test server

["forward" <[e-mail]>]

Hi all:
I know this email list is not about SCEP. But I want to know where can I
find a test SCEP CA server.
Thanks very much!

Forward.li



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




Received: by above.proper.com (8.11.6/8.11.3) id g612OAG03674 for ietf-pkix-bks; Sun, 30 Jun 2002 19:24:10 -0700 (PDT)
Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by above.proper.com (8.11.6/8.11.3) with SMTP id g612O3w03666 for <[e-mail]>; Sun, 30 Jun 2002 19:24:09 -0700 (PDT)
Received: from unknown (HELO liyunfeng) (forward?li@218.6.192.143 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 Jul 2002 02:24:01 -0000
From: "forward" <[e-mail]>
To: <[e-mail]>
Subject: about test server
Date: Mon, 1 Jul 2002 10:23:29 +0800
Message-ID: <005901c220a6$4cf59ca0$b400a8c0@liyunfeng>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all:
I know this email list is not about SCEP. But I want to know where can I
find a test SCEP CA server.
Thanks very much!

Forward.li



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5SClS910283 for ietf-pkix-bks; Fri, 28 Jun 2002 05:47:28 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SClRw10272 for <[e-mail]>; Fri, 28 Jun 2002 05:47:27 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA16896; Fri, 28 Jun 2002 14:51:12 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002062814464456:232 ; Fri, 28 Jun 2002 14:46:44 +0200 
Message-ID: <[e-mail]>
Date: Fri, 28 Jun 2002 14:46:43 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-warranty-extn-01
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/06/2002 14:46:44, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 28/06/2002 14:47:18, Serialize complete at 28/06/2002 14:47:18
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,
 
> Denis:
> 
> > > [REVISED TEXT:]  A relying party may obtain compensation from a CA
> > depending
> > > on the conditions for such compensation expressed in either the CA's
> > > Certificate Policy or the CA's insurance policy, or both.
> >
> >I believe that Russ said that the CA's insurance policy was included in the
> >CA's Certificate Policy. The "or" is not appropriate.
> 
> That depends on the structure of the policy.  The CA might self-insure for
> small claims, and have an insurance policy for larger ones.

I disagree: what is important is what is visible for the relying parties.
Self-insurance or back up insurance is a level of detail that is internal to
the CA. This does not have to be visible to the relying party. The "or" is
still not appropriate.

Denis
 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5S4gsW20341 for ietf-pkix-bks; Thu, 27 Jun 2002 21:42:54 -0700 (PDT)
Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5S4grw20333 for <[e-mail]>; Thu, 27 Jun 2002 21:42:53 -0700 (PDT)
Received: from unknown (HELO liyunfeng) (forward?li@218.6.192.143 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Jun 2002 04:42:57 -0000
From: "forward" <[e-mail]>
To: "'Max Pritikin'" <[e-mail]>
Cc: <[e-mail]>
Subject: rere: Question about SCEP!
Date: Fri, 28 Jun 2002 12:42:24 +0800
Message-ID: <004101c21e5e$360ebd90$b400a8c0@liyunfeng>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5S4grw20335
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Pritikin
Last night , I find the reason. The reason is that CISCO2600 calculate
the MD5 'fingerprint' just on the raw PKCS#10 message before it
calculate the signature in PKCS#10. 
Thanks. 

-----ÓʼþÔ­¼þ-----
·¢¼þÈË: Max Pritikin [mailto:[e-mail]] 
·¢ËÍʱ¼ä: 2002Äê6ÔÂ28ÈÕ 1:49
ÊÕ¼þÈË: forward; [e-mail]
Ö÷Ìâ: RE: Question about SCEP!


(responding to the '[e-mail]' mailing list)

MD5 is a one-way hash algorithm that takes any length of data and
produces a
128 bit "fingerprint" or "message digest". Pass the entire PKCS#10 into
your
MD5 function(s) to produce this 128 bit fingerprint and display it to
the
user.

The user can then tell the administrator this 128 bit fingerprint (out
of
band) such that the certificate request can be authenticated at the
server
by the administrator.

It doesn't sounds like this is your problem though. You indicate that
the
response is rejected by the Cisco 2600?

> In my SCEP server, I can decrypt and decode PKCSReq and can get the
> PKCS#10 then generate certificate for CISCO's router. The server
> generate the CertRep message and send it to CISCO2600. However the
> CISCO2600 tell me that it verify the massage failed.

This sounds like a configuration problem on your 2600. You may wish to
compare the behavior of the 2600 (using the same configuration) against
an
alternate SCEP server (one that is known to work with IOS).

	- Max

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of forward
> Sent: Thursday, June 27, 2002 5:32 AM
> To: [e-mail]
> Subject: Question about SCEP!
>
>
>
> Hi:
> I want to ask a question about SCEP. In SCEP there is a sentence " To
> prevent a "man-in-the-middle" attack, an MD5 'fingerprint' generated
on
> the PKCS#10(before PKCS#7 enveloping and signing ) must be compared
> out-of-band between the server and end entity". However I don't know
how
> the cisco's SCEP client calculate the MD5 'fingerprint'.
> In my SCEP server, I can decrypt and decode PKCSReq and can get the
> PKCS#10 then generate certificate for CISCO's router. The server
> generate the CertRep message and send it to CISCO2600. However the
> CISCO2600 tell me that it verify the massage failed.
> Can anybody tell me the reason?
> Thanks!
>
> Forward.li
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: by above.proper.com (8.11.6/8.11.3) id g5S2r4713617 for ietf-pkix-bks; Thu, 27 Jun 2002 19:53:04 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5S2qmw13536 for <[e-mail]>; Thu, 27 Jun 2002 19:53:02 -0700 (PDT)
Received: from [10.0.1.2] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA26477; Thu, 27 Jun 2002 22:52:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100304b9417edb80f5@[10.0.1.2]>
In-Reply-To: <002301c21dd6$9c4d6580$b400a8c0@liyunfeng>
References: <002301c21dd6$9c4d6580$b400a8c0@liyunfeng>
Date: Thu, 27 Jun 2002 22:52:19 -0400
To: "forward" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Question about SCEP!
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>?
>Hi:
>I want to ask a question about SCEP. In SCEP there is a sentence " To
>prevent a "man-in-the-middle" attack, an MD5 'fingerprint' generated on
>the PKCS#10(before PKCS#7 enveloping and signing ) must be compared
>out-of-band between the server and end entity". However I don't know how
>the cisco's SCEP client calculate the MD5 'fingerprint'.
>In my SCEP server, I can decrypt and decode PKCSReq and can get the
>PKCS#10 then generate certificate for CISCO's router. The server
>generate the CertRep message and send it to CISCO2600. However the
>CISCO2600 tell me that it verify the massage failed.
>Can anybody tell me the reason?
>Thanks!
>
>Forward.li
>

SCEP is not a PKIX protocol, so this is not the right forum in which 
to ask your question.

I suggest you contact someone at Cisco.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5S16Na06762 for ietf-pkix-bks; Thu, 27 Jun 2002 18:06:23 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5S16Mw06751 for <[e-mail]>; Thu, 27 Jun 2002 18:06:22 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 Jun 2002 01:06:00 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id VAA16006; Thu, 27 Jun 2002 21:06:25 -0400 (EDT)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5S14OL10737; Thu, 27 Jun 2002 21:04:24 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <NGMD68AX>; Thu, 27 Jun 2002 18:06:22 -0700
Message-ID: <[e-mail]>
From: "Yee, Peter" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-acmc-01.txt
Date: Thu, 27 Jun 2002 18:14:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I've just gotten around to writing up my responses to your input
on ACRMF and ACMC.  Thank you for taking the time to read both
documents. Your input is valued.

 >Comments on drafts "Attribute Certificate Request Message Format" and
 >"Attribute Certificate Management Messages over CMS" (March 2002)

 >The two drafts are very technical, hard to read, inter-related and do
 >not have sufficient explanations to allow a rapid and easy understanding
for
 >everyone. It can be observed that no comment has been sent up to now on
 >acmc.

I'll grant you that they are very technical and perhaps hard to read.
I'll see what I can do to include more explanatory text in the next draft.
As for the number of comments that have come up regards ACMC, I fail to
see a direct correlation.  And in truth, I have received supportive
correspondence on ACMC from several parties who simply didn't post to
the list.

 >It is assumed that managing ACs is as simple as managing PKCs and thus
that
 >protocols able to manage PKCs, with a few modifications, will be able to
 >manage ACs. This assumption is incorrect.

I respectfully disagree.  While the combination of ACMC/ACRMF may not be
sufficient for all management aspects of ACs, I think that they and the
paradigm they espouse have their places.

I think that there will be situations where PKCs and ACs are issued together
as part of an overall enrollment process.  I think that there are other
situations where the PKCs and the ACs will be managed independently by
different authorities.  The architecture needs the flexibility to support
both situations.

 >The way ACs are managed is very different from the way PKCs are managed
and
 >for that reason it is not believed that extending CRMF and CMC is the
right
 >way. Whether some extension to CMP would be able to do the job better will
 >not be discussed either. The problem is that is that we have a solution
 >without requirements, so it is hard to say whether or not the solution
fits
 >the requirements.

 >It would be appropriate to write of the requirements first, so that we can
 >all understand how a proposal would fit these requirements.

Sometimes you think the requirements are clear -- as you did with the
attribute
certificate policy work.  It's also true that when extending an existing 
framework, one assumes that the underlying requirements that built the
framework still hold true.

 >Before looking into some of these requirements, it is important to
 >understand the major differences with a PKC.

 >When a PKC is requested, a template of the PKC is provided together with
 >registration information. From that request, a *single *certificate will
be
 >created later on, and will be given back to the requester and/or placed in
a
 >repository.

 >When an attribute (beware, *not* an AC) is registered, that attribute is
 >provided together with registration information. No AC is created from
that
 >request. The registration information consists of two main components:

 >   - the definition of the attribute itself, together with some
 >     constraints that apply to it (see later) and the revocation
 >     conditions for that attribute.

 >   - the way to link the "to-be-created-ACs" with an entity, most of
 >     the time by linking it to a PKC. In that case providing the PKC is
 >     not always sufficient since the subject DN may not be explicit
 >     enough and thus information (or some link) from the CA that has
 >     created the PKC may be necessary.

In your discussion, I don't see a mechanism for revoking an attribute.  Are
you proposing another form of revocation list or status protocol that is
related to single attributes?  I would rather avoid such creating of a new
mechanism, as I see no indication that the current ones are inadequate.

Both linkages are supported in ACRMF -- either the IssuerSerial pair is
used or a DN (GeneralNames, really) is given.

 >Attribute registration is usually not done by the end user that will
 >become ultimately the AC holder. Various attributes can be registered.
Some
 >attributes may be registered with some constraints like, the validity
period
 >of ACs that may be issued later on; how revocation will be handled, if
 >handled for that attribute; restrictions that will apply to that attribute
 >like target controls. Note that this operation is not necessary done
 >remotely using a protocol, so it is not mandatory to support a protocol
for
 >it.

I do not think that the means by which the AA determines the appropriate
values for each of the attributes should not be part of this protocol.  In
my
view this would be analogous to bundling PKC enrollment with identity
vetting.  We recognize that identity vetting has many components,
potentially including face-to-face interaction with an RA.  The AA (or the
RA working with the AA) faces a similar situation.  Some attribute values
may be readily at hand (perhaps in a local account management database).
Some attribute values may involve coordination or information gathering
(perhaps a credit check).  Other attribute values may require time
(perhaps waiting for a check to clear).  The latency between the AC
request and the AC issuance will depend on these factors (and other
ones too).  Breaking the process into separate attribute registration steps
followed by a AC issuance step does not seem to be a general model.

 >Most users will be unable to specify the details of an AC and this will
 >either be done locally at the level of the AA or remotely by using
protocols
 >dedicated to managers only. The job of these managers is to make life easy
 >for certificate holders. They will define AC templates so that ACs can
later
 >on be created upon request from the AC holders by using these templates.
 >Some grouping of attributes will need to be done to fulfill a job or to
 >perform a set of operations. The AC holder will thus only need to know the
 >references of these various templates that will be tailored to match their
 >jobs. In some cases, end-users will make the definition themselves and
then
 >will use the reference of these definitions to get an AC.

ACMC and ACRMF work fine for either managers, knowledgeable users (often
called ARAs), or certain 3rd parties that are requesting ACs.

 >This means that AC will be obtained by providing a reference whose details
 >are already known to the AA.

We support this -- the ACMC Attribute Modification Handling Control
Attribute
allows attribute certificates to be issued against a specified policy or
profile.  Conceptually, this usage can be mapped to your templates.

 >As a summary, the following three basic functions are identified:

 >   1) Attribute registration (no AC is produced). This can be invoked
 >      several times. This function is optional since it can be done
 >      locally.

 >   2) AC template definition (a reference for a template is produced,
 >      but no AC is produced). This function can be done locally or
 >      remotely.

 >   3) AC acquisition (an AC is produced based on a template reference).

ACMC and ACRMF are designed to handle #3.  #1 and #2 are outside of the
scope of what I'm trying to do.  Others are welcome to "fill in the blanks" 
for those situations where they are needed.  I argue that there are
situations where ACMC/ACRMF is sufficient.

 >Additional functions are needed since the second function may be performed
 >by managers while the third one will be performed by AC holders:

 >  - list the AC templates for a given entity (for an AC holder or
 >    a manager),

Again, this isn't the realm of ACMC and ACRMF.  Another protocol is
welcome to step up to the plate on this.  In any case, I'm not sure how AC
templates are bound against a given entity.  If you're referring to
attribute
certificates already issued, then some sort of directory search may suffice
(depends on the latitude of use of these templates, joined directories,
etc.).
If you mean prior to AC issuance (which is what I suspect), well, that's 
definitely beyond the scope of what I'm looking to do.  As noted, these may
be handled as a local function.

 >  - list the AC templates for a set of entities (for a manager only).

Again, out of scope for ACMC/ACRMF.

 >Note: This assumes that the AA already "know" the attribute type.
 >If not, a registration function to register new attributes would be
needed.

Sure.  And that's another local or remote function.

 >Once an AC has been obtained, it may be necessary to revoke it (if this is
 >allowed). However, the revocation requests is not for an AC, but either
for
 >an attribute or an AC template. This means that all ACs containing this
 >attribute or produced using that template have to be revoked. This may be
 >for one entity or for all entities using that attribute or that AC
template.
 >Since the requester (which may not be the AC holder) does not necessarily
 >know all the AC s that have been issued, it cannot indicated the serial
 >numbers of these ACs and thus let the AA find out how many and which ACs
 >need to be revoked. This is fairly different from the ways PKCs are
 >requested to be revoked.

I have to disagree with you on this one.  Let's take an example.  I have an
AC that permits me to make purchases on behalf of the company up to the
$10,000 level.  Now, because of a change in responsibilities, my level is
being reduced to $5,000.  At that point, the AC I have allowing me to
make $10,000 purchases is going to revoked.  Period.  I have no idea why
the AC template would be revoked -- what does my loss of authority have
to do with anyone else using a similar type of AC?  And since I'm not
really concerned about attribute registration, the revocation
(deregistration?)
of attributes is outside of the scope of ACMC/ACRMF.

Re-reading your paragraph above, I think we're looking at attributes in a
fundamentally different way.  You seem to think that an attribute is
registered, and then can be issued in attribute certificates to multiple
users.  And that an attribute may need to be revoked, causing the
revocation of all certificates incorporating that attribute.  That's not at
all
what I was thinking.  There may be many attribute certificates with a
specific attribute type, but the need to revoke is tied to a specific
attribute
certificate and its attributes, not to the set of all attributes
certificates
containing a specific attribute (either type or type/value/conditions).

Finally, I'll note that even if you do use an attribute revocation scheme
instead of an attribute certificate revocation scheme, you still have to
revoke an affected AC and (potentially) issue a new one minus the
stricken attribute.  ACMC/ACRMF can be used to do this.

 >This description provides an hint on how an attribute revocation request
 >should be handled. This is fairly different from the current proposal
which
 >is only able to revoke an AC by providing an AA name and a serial number.
 >While useful in some cases, this is certainly insufficient.

The mechanism you offered can be used with in conjunction with other
mechanisms to work on pretty much any need for revocation.  I think that I
see
where you're going, but I believe that in only providing AA name/serial 
number, I haven't changed the problem; I've only changed where the list of 
certificates to be revoked is assembled.  You seem to propose that the AA
could do this. I've pushed list assembly to an entity that could be
logically
outside of the AA (the ARA or some other management entity).

 >Since an AC is created for an AC holder and upon request from an AC
holder,
 >it is given back to the requester. In most protocols ACs are "pushed"
 >towards an application or are provided attached to some signed data.
 >Otherwise, the reference of the certificate is "pushed" by the AC holder
and
 >the AA may then provide the AC upon request. When that function is useful,
 >it would be interesting to use an LDAP schema so that LDAP can be used for
 >ACs, rather than a new dedicated protocol.

 >Hereafter are a few comments on the two proposals.
 >
 >ACRMF is an "Attribute Certificate Request Message Format". It combines
two
 >functions mentioned earlier: the AC template definition function and the
AC
 >acquisition function. However, as indicated above, these functions should
be
 >separated.

I'm not a believer in the AC template school.  If you wish to argue that
ACRMF
contains a template, I'll agree that it contains one, generic template that
can
be used to generate any attribute certificate (given a set of attributes, 
etc.). I view ACRMF as part of the AC acquisition function.  Period.  If you
insist on an AC template function, I think that it belongs in a separate 
protocol.  Again, many situations are handled by ACMC/ACRMF.

 >"Attribute Certificate Management Messages over CMS" - ACMC - fails to
 >clearly present the functions that are supported. It is necessary to
 >maintain open at the same time three other documents to be able to
 >understand that document: [CMCbis], [ACRMF] and [CRMF]. Before going into
 >the details, it would be most useful to express the functions that are
 >supported.

Fair enough.  I will endeavor to make it clear functions ACMC supports.

 >In section 3.6, GetCert is mentioned to be sufficient for attribute
 >certificates while it only supports AC retrieval based upon the issuer
name
 >and the AC serial number. This function is insufficient and should be
 >supported using LDAP.

I did not say that Get Cert was sufficient.  I said that the issuer name
and serial number combination was sufficient to retrieve an attribute
certificate.  I didn't say that it was the only way or what everyone might
desire.  The second paragraph suggests that there are other needs.  I'm
simply saying that if you do have the issuer name/AC serial number, the
existing Get Cert is available.  I don't want to replicate LDAP within
ACMC.

 >In section 3.8. the revoke request control attribute allows to revoke an
 >attribute certificate, while it has been mentioned that this is
 >insufficient.

I suppose we just disagree on this point.

 >In section 4.1. attributes can be added but this is again insufficient:
 >attributes with restrictions may need to be added. As an example,
extensions
 >like target Controls may be appropriate.

I'm not sure I follow you -- are you saying we need extensions (using the AC
extension mechanism) that control attributes?  Or that the attributes need
to specify controls (generically? or attribute-specifically?)  If the former
case, I think you've got a mess brewing if you want to try to tie extensions
to specific attributes.  If the latter case, and attribute-specifically, I
would say that's a question of attribute definition.  If generically, then
you're talking about something that needs to be handled at the
X.509 AC syntax and semantics; these would then percolate into
ACMC/ACRMF.

 >CONCLUSION

 >We first need to agree on a set of requirements before discussing the
 >details of any proposal. It might be appropriate to write an
 >Informational RFC to specify these requirements.

I see no need to write a requirements document at this point.  The PKIX
chairs
will let us all know if they think otherwise.

The mechanisms provided by ACMC/ACRMF are needed, but I will try to add
more explanation about the scope.  I will try to make it clear what is
covered
and what is not covered.  This should leave plenty of room for a companion
document addressing some of your concerns.  The need for that companion
document is breaking much more new ground.  Maybe a requirements
document is appropriate for that effort. Again, the PKIX chairs will let us
know....

 >Denis

						-Peter


Received: by above.proper.com (8.11.6/8.11.3) id g5RKZr828748 for ietf-pkix-bks; Thu, 27 Jun 2002 13:35:53 -0700 (PDT)
Received: from zetnet.co.uk ([e-mail] [194.247.47.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RKZqw28736 for <[e-mail]>; Thu, 27 Jun 2002 13:35:52 -0700 (PDT)
Received: from zetnet.co.uk (bts-0265.dialup.zetnet.co.uk [194.247.49.9]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g5RKZi201034; Thu, 27 Jun 2002 21:35:44 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jun 2002 21:36:11 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pr-tsa-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----

[e-mail] 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           : Policy Requirements for Time-Stamping Authorities
>         Author(s)       : D. Pinkas, N. Pope, J. Ross
>         Filename        : draft-ietf-pkix-pr-tsa-01.txt
>         Pages           : 39
>         Date            : 26-Jun-02
>
> This document specifies policy requirements relating to the 
> operation of Time-stamping Authorities (TSAs). It defines policy 
> requirements on the operation and management practices of TSAs such 
> that subscribers and relying parties may have confidence in the 
> operation of the time-stamping services.
> The contents of this Informational RFC is technically equivalent to
> ETSI TS 102 023 V1.2.1 (2002-06) [TS 102023]. The ETSI TS is under
> the ETSI Copyright (C). Individual copies of this ETSI deliverable
> can be downloaded from http://www.etsi.org
> This document is an Internet-Draft and is NOT offered in accordance
> with Section 10 of RFC 2026, and the authors do not provide the IETF
> with any rights other than to publish as an Internet-Draft.

Since this draft concerns policy requirements for an Internet Standards
Track protocol (TSP, i.e. RFC 3161), it should be part of the Internet
Standards Process. RFC 2026 is clear about that meaning that it MUST be
subject to Section 10.

(It is possible for documents that are not part of the Internet Standards
Process to be published as Informational RFCs without being subject to
Section 10, as described in RFC 2026 Section 4.2.2, but that should be
reserved for documents that have no direct relation to any Standards Track
protocols.)

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPRuFKTkCAxeYt5gVAQGdGAgArPgv9ofw/vNjVcYpmXqrdeO3/rH0Lt3C
MqQfW7okdvNLuKItst9oevoe2MNTcyYOGu/Uh71kY3AJnEHqInSy4sqZ/lJuos3z
uSQD3CjLEJWnOBG8SX7JyAEPvliqqaCTG+qHRtA1C9+t51Pmhq8UmqVFvTq3wSNl
Tphnx5k7COKg4OvKHGE4k9K0AqXy7ARXZDc1Jy7VEesj51k/RhafVY+S/OAfImct
4LL+kafCIMO+89U4eLkapdsz/HJ/GjC5iwcvA5Clpyla/36st5R/vtme4gCI0HT9
y5gma9c02baXI2VUg0QeS7ey/x8qnAiJ77zUkCrRTxmZFwcNFgJNPw==
=i/YN
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RHMhK17363 for ietf-pkix-bks; Thu, 27 Jun 2002 10:22:43 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5RHMfw17359 for <[e-mail]>; Thu, 27 Jun 2002 10:22:41 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Jun 2002 17:22:18 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA06319; Thu, 27 Jun 2002 13:22:39 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5RHKdN23270; Thu, 27 Jun 2002 13:20:39 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZTSB2>; Thu, 27 Jun 2002 13:22:37 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.28]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZTSBG; Thu, 27 Jun 2002 13:22:34 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 27 Jun 2002 13:22:30 -0400
Subject: Re: draft-ietf-pkix-warranty-extn-01
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

> > [REVISED TEXT:]  A relying party may obtain compensation from a CA 
> depending
> > on the conditions for such compensation expressed in either the CA's
> > Certificate Policy or the CA's insurance policy, or both.
>
>I believe that Russ said that the CA's insurance policy was included in the
>CA's Certificate Policy. The "or" is not appropriate.

That depends on the structure of the policy.  The CA might self-insure for 
small claims, and have an insurance policy for larger ones.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RFVFT04741 for ietf-pkix-bks; Thu, 27 Jun 2002 08:31:15 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RFVDw04726 for <[e-mail]>; Thu, 27 Jun 2002 08:31:13 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <NYBKZ2FL>; Thu, 27 Jun 2002 11:30:59 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David Chadwick'" <[e-mail]>, Tom Gindin <[e-mail]>
Cc: Laurence Lundblade <[e-mail]>, [e-mail]
Subject: RE: DN comparison
Date: Thu, 27 Jun 2002 11:30:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21DEF.A329CC90"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

------_=_NextPart_001_01C21DEF.A329CC90
Content-Type: text/plain

David, fyi I have asked Erik/Hoyt to initiate a DR to clarify the meaning 
of corresponding. I agree we can process that in the Sept mtg.

-----Original Message-----
From: David Chadwick [mailto:[e-mail]]
Sent: Thursday, June 27, 2002 10:35 AM
To: Tom Gindin
Cc: Laurence Lundblade; [e-mail]
Subject: Re: DN comparison




Tom Gindin wrote:
> 
>       David:
> 
>       Corresponding's normal English meaning is not "in the same order as"
> but either "in agreement or conformity with" or "similar or analogous to".

Or "matching" as well in my dictionary. I would have thought that to
match something you would have to be in the same order. 1 3 5 does not
match 5 3 1 does it?

> Neither of these meanings is notably closer to "in the same order as" than
> to "having the same structure".  While I know that X.500 databases are
> tree-structured and so RDN order is crucial to finding entries in them, I
> do not think that matching certificate subjects based on an
order-dependent
> rule is more useful than doing so on a structure-dependent rule (i.e. one
> which considers that the order of distinct attribute types such as L and O
> is irrelevant). 

This is where we have another semantic drift. Stucture rules in X.500
are the part of the schema that determine the ordering of RDNs in a DN.
So the structure of a DN and the ordering of RDNs in a DN are
essentially the same thing.

Thus the ordering of L and O attribute types is almost always relevant
in a DN, since a DN is a SEQUENCE of RDNs, which implies ordering. The
only exception is if they are in the same RDN (which comprises a SET of
attribute types, in which case no order exists). 

> Nobody else has thought that this wording was particularly
> clear, even though it appears in an X.500 standard and X.500 implies a
tree
> structure.

I have never had a problem with the wording, probably because I helped
to write it. You often need someone not intimately involved with a
standard to be able to pick up its ambiguities and lack of clarity. So
if you can suggest some alternative wording I will take it to the next
X.500 in September for consideration.

regards

David



> 
>             Tom Gindin
> 
> David Chadwick <[e-mail]>@mail.imc.org on 06/26/2002
> 07:19:38 PM
> 
> Sent by:    [e-mail]
> 
> To:    Laurence Lundblade <[e-mail]>
> cc:    [e-mail]
> Subject:    Re: DN comparison
> 
> Sorry for being late in on this, but here's my two penneth.
> 
> Laurence Lundblade wrote:
> >
> > What I want to know is how to compare DN's (subject with issuer). I
found
> > all the stuff about the string processing in 2459 and am happy to see
> > that's reasonably dealt with. What I can't find is whether the order of
> > RDN's or the order of the parts of the RDN's matter or not. Also I
> haven't
> > been able to determine if the grouping of parts in RDN's matter or not.
> >
> > To be specific, which of these are the same in these DN's?
> >   1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)
> 
> Illegal DN. YOu are not allowed to have the same attribute type twice in
> an RDN
> 
> >   2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
> >   3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)
> 
> Illegal DN
> 
> >   4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)
> >
> > RDN's are in (). I would think/hope they're all the same.
> 
> Sorry. None of them are the same. The reason is that ordering is
> important, just as in DNS names.
> 
> Also, to clear up the confusion over the word "corresponding". Once you
> know that RDN ordering is important within a DN (a DN is a SEQUENCE of
> RDNs), then the meaning of corresponding also becomes clear. It has the
> normal English meaning that the nth RDN in one DN corresponds with the
> nth RDN in another DN. Its that simple.
> 
> David
> 
> >From reading the
> > source, it looks like OpenSSL doesn't care about the grouping of RDN's,
> but
> > does care about the order.
> >
> > And more of a standard question, how should I have found the answer to
> this
> > question? From my current perspective it seems an addition to RFC-3280
> > would be helpful.
> >
> > LL
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

------_=_NextPart_001_01C21DEF.A329CC90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: DN comparison</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David, fyi I have asked Erik/Hoyt to initiate a DR to =
clarify the meaning </FONT>
<BR><FONT SIZE=3D2>of corresponding. I agree we can process that in the =
Sept mtg.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David Chadwick [<A =
HREF=3D"mailto:[e-mail]">mailto:d.w.chadwick@salford.a=
c.uk</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, June 27, 2002 10:35 AM</FONT>
<BR><FONT SIZE=3D2>To: Tom Gindin</FONT>
<BR><FONT SIZE=3D2>Cc: Laurence Lundblade; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: DN comparison</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Tom Gindin wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
David:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Corresponding's normal English meaning is not &quot;in the same order =
as&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; but either &quot;in agreement or conformity =
with&quot; or &quot;similar or analogous to&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>Or &quot;matching&quot; as well in my dictionary. I =
would have thought that to</FONT>
<BR><FONT SIZE=3D2>match something you would have to be in the same =
order. 1 3 5 does not</FONT>
<BR><FONT SIZE=3D2>match 5 3 1 does it?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Neither of these meanings is notably closer to =
&quot;in the same order as&quot; than</FONT>
<BR><FONT SIZE=3D2>&gt; to &quot;having the same structure&quot;.&nbsp; =
While I know that X.500 databases are</FONT>
<BR><FONT SIZE=3D2>&gt; tree-structured and so RDN order is crucial to =
finding entries in them, I</FONT>
<BR><FONT SIZE=3D2>&gt; do not think that matching certificate subjects =
based on an order-dependent</FONT>
<BR><FONT SIZE=3D2>&gt; rule is more useful than doing so on a =
structure-dependent rule (i.e. one</FONT>
<BR><FONT SIZE=3D2>&gt; which considers that the order of distinct =
attribute types such as L and O</FONT>
<BR><FONT SIZE=3D2>&gt; is irrelevant). </FONT>
</P>

<P><FONT SIZE=3D2>This is where we have another semantic drift. =
Stucture rules in X.500</FONT>
<BR><FONT SIZE=3D2>are the part of the schema that determine the =
ordering of RDNs in a DN.</FONT>
<BR><FONT SIZE=3D2>So the structure of a DN and the ordering of RDNs in =
a DN are</FONT>
<BR><FONT SIZE=3D2>essentially the same thing.</FONT>
</P>

<P><FONT SIZE=3D2>Thus the ordering of L and O attribute types is =
almost always relevant</FONT>
<BR><FONT SIZE=3D2>in a DN, since a DN is a SEQUENCE of RDNs, which =
implies ordering. The</FONT>
<BR><FONT SIZE=3D2>only exception is if they are in the same RDN (which =
comprises a SET of</FONT>
<BR><FONT SIZE=3D2>attribute types, in which case no order exists). =
</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Nobody else has thought that this wording was =
particularly</FONT>
<BR><FONT SIZE=3D2>&gt; clear, even though it appears in an X.500 =
standard and X.500 implies a tree</FONT>
<BR><FONT SIZE=3D2>&gt; structure.</FONT>
</P>

<P><FONT SIZE=3D2>I have never had a problem with the wording, probably =
because I helped</FONT>
<BR><FONT SIZE=3D2>to write it. You often need someone not intimately =
involved with a</FONT>
<BR><FONT SIZE=3D2>standard to be able to pick up its ambiguities and =
lack of clarity. So</FONT>
<BR><FONT SIZE=3D2>if you can suggest some alternative wording I will =
take it to the next</FONT>
<BR><FONT SIZE=3D2>X.500 in September for consideration.</FONT>
</P>

<P><FONT SIZE=3D2>regards</FONT>
</P>

<P><FONT SIZE=3D2>David</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; Tom Gindin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Chadwick =
&lt;[e-mail]&gt;@mail.imc.org on 06/26/2002</FONT>
<BR><FONT SIZE=3D2>&gt; 07:19:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sent by:&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp; Laurence Lundblade =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; cc:&nbsp;&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp; Re: DN =
comparison</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sorry for being late in on this, but here's my =
two penneth.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Laurence Lundblade wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What I want to know is how to compare DN's =
(subject with issuer). I found</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; all the stuff about the string processing =
in 2459 and am happy to see</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that's reasonably dealt with. What I can't =
find is whether the order of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; RDN's or the order of the parts of the =
RDN's matter or not. Also I</FONT>
<BR><FONT SIZE=3D2>&gt; haven't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; been able to determine if the grouping of =
parts in RDN's matter or not.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To be specific, which of these are the =
same in these DN's?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; 1) (O=3Dfish-tacos, OU=3Dfish, =
OU=3Dhalibut), (CO=3Dmexico,ST=3Dbaja)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Illegal DN. YOu are not allowed to have the =
same attribute type twice in</FONT>
<BR><FONT SIZE=3D2>&gt; an RDN</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; 2) (O=3Dfish-tacos, =
OU=3Dfish), (OU=3Dhalibut), (CO=3Dmexico), (ST=3Dbaja)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; 3) =
(OU=3Dhalibut,O=3Dfish-tacos, OU=3Dfish) (ST=3Dbaja,CO=3Dmexico)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Illegal DN</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; 4) (CO=3Dmexico), (ST=3Dbaja), =
(OU=3Dhalibut), (O=3Dfish-tacos, OU=3Dfish)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; RDN's are in (). I would think/hope =
they're all the same.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sorry. None of them are the same. The reason is =
that ordering is</FONT>
<BR><FONT SIZE=3D2>&gt; important, just as in DNS names.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also, to clear up the confusion over the word =
&quot;corresponding&quot;. Once you</FONT>
<BR><FONT SIZE=3D2>&gt; know that RDN ordering is important within a DN =
(a DN is a SEQUENCE of</FONT>
<BR><FONT SIZE=3D2>&gt; RDNs), then the meaning of corresponding also =
becomes clear. It has the</FONT>
<BR><FONT SIZE=3D2>&gt; normal English meaning that the nth RDN in one =
DN corresponds with the</FONT>
<BR><FONT SIZE=3D2>&gt; nth RDN in another DN. Its that simple.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From reading the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; source, it looks like OpenSSL doesn't care =
about the grouping of RDN's,</FONT>
<BR><FONT SIZE=3D2>&gt; but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; does care about the order.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; And more of a standard question, how =
should I have found the answer to</FONT>
<BR><FONT SIZE=3D2>&gt; this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; question? From my current perspective it =
seems an addition to RFC-3280</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; would be helpful.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; LL</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; ************************************************=
*****************</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David W. Chadwick, BSc PhD</FONT>
<BR><FONT SIZE=3D2>&gt; Professor of Information Systems =
Security</FONT>
<BR><FONT SIZE=3D2>&gt; IS Institute, University of Salford, Salford M5 =
4WT</FONT>
<BR><FONT SIZE=3D2>&gt; Tel: [phone]&nbsp; Fax [phone] =
532930</FONT>
<BR><FONT SIZE=3D2>&gt; Mobile: [phone]</FONT>
<BR><FONT SIZE=3D2>&gt; Email: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Home Page:&nbsp; <A =
HREF=3D"http://www.salford.ac.uk/its024/chadwick.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/chadwick.htm</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; Research Projects: <A =
HREF=3D"http://sec.isi.salford.ac.uk" =
TARGET=3D"_blank">http://sec.isi.salford.ac.uk</A></FONT>
<BR><FONT SIZE=3D2>&gt; Understanding X.500:&nbsp; <A =
HREF=3D"http://www.salford.ac.uk/its024/X500.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/X500.htm</A></FONT>
<BR><FONT SIZE=3D2>&gt; X.500/LDAP Seminars: <A =
HREF=3D"http://www.salford.ac.uk/its024/seminars.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/seminars.htm</A></FONT=
>
<BR><FONT SIZE=3D2>&gt; Entrust key validation string: =
MLJ9-DU5T-HV8J</FONT>
<BR><FONT SIZE=3D2>&gt; PGP Key ID is 0xBC238DE5</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
*****************************************************************</FONT>=

</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT =
SIZE=3D2>***************************************************************=
**</FONT>
</P>

<P><FONT SIZE=3D2>David W. Chadwick, BSc PhD</FONT>
<BR><FONT SIZE=3D2>Professor of Information Systems Security</FONT>
<BR><FONT SIZE=3D2>IS Institute, University of Salford, Salford M5 =
4WT</FONT>
<BR><FONT SIZE=3D2>Tel: [phone]&nbsp; Fax [phone] =
532930</FONT>
<BR><FONT SIZE=3D2>Mobile: [phone]</FONT>
<BR><FONT SIZE=3D2>Email: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Home Page:&nbsp; <A =
HREF=3D"http://www.salford.ac.uk/its024/chadwick.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/chadwick.htm</A></FONT=
>
<BR><FONT SIZE=3D2>Research Projects: <A =
HREF=3D"http://sec.isi.salford.ac.uk" =
TARGET=3D"_blank">http://sec.isi.salford.ac.uk</A></FONT>
<BR><FONT SIZE=3D2>Understanding X.500:&nbsp; <A =
HREF=3D"http://www.salford.ac.uk/its024/X500.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/X500.htm</A></FONT>
<BR><FONT SIZE=3D2>X.500/LDAP Seminars: <A =
HREF=3D"http://www.salford.ac.uk/its024/seminars.htm" =
TARGET=3D"_blank">http://www.salford.ac.uk/its024/seminars.htm</A></FONT=
>
<BR><FONT SIZE=3D2>Entrust key validation string: MLJ9-DU5T-HV8J</FONT>
<BR><FONT SIZE=3D2>PGP Key ID is 0xBC238DE5</FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
**</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C21DEF.A329CC90--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5REXpo08417 for ietf-pkix-bks; Thu, 27 Jun 2002 07:33:51 -0700 (PDT)
Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5REXow08404 for <[e-mail]>; Thu, 27 Jun 2002 07:33:50 -0700 (PDT)
Received: from salford.ac.uk ([80.5.217.146]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 27 Jun 2002 15:33:50 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jun 2002 15:34:38 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: Laurence Lundblade <[e-mail]>, [e-mail]
Subject: Re: DN comparison
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------E72662C8C52006FA5B797B7E"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------E72662C8C52006FA5B797B7E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Tom Gindin wrote:
> 
>       David:
> 
>       Corresponding's normal English meaning is not "in the same order as"
> but either "in agreement or conformity with" or "similar or analogous to".

Or "matching" as well in my dictionary. I would have thought that to
match something you would have to be in the same order. 1 3 5 does not
match 5 3 1 does it?

> Neither of these meanings is notably closer to "in the same order as" than
> to "having the same structure".  While I know that X.500 databases are
> tree-structured and so RDN order is crucial to finding entries in them, I
> do not think that matching certificate subjects based on an order-dependent
> rule is more useful than doing so on a structure-dependent rule (i.e. one
> which considers that the order of distinct attribute types such as L and O
> is irrelevant). 

This is where we have another semantic drift. Stucture rules in X.500
are the part of the schema that determine the ordering of RDNs in a DN.
So the structure of a DN and the ordering of RDNs in a DN are
essentially the same thing.

Thus the ordering of L and O attribute types is almost always relevant
in a DN, since a DN is a SEQUENCE of RDNs, which implies ordering. The
only exception is if they are in the same RDN (which comprises a SET of
attribute types, in which case no order exists). 

> Nobody else has thought that this wording was particularly
> clear, even though it appears in an X.500 standard and X.500 implies a tree
> structure.

I have never had a problem with the wording, probably because I helped
to write it. You often need someone not intimately involved with a
standard to be able to pick up its ambiguities and lack of clarity. So
if you can suggest some alternative wording I will take it to the next
X.500 in September for consideration.

regards

David



> 
>             Tom Gindin
> 
> David Chadwick <[e-mail]>@mail.imc.org on 06/26/2002
> 07:19:38 PM
> 
> Sent by:    [e-mail]
> 
> To:    Laurence Lundblade <[e-mail]>
> cc:    [e-mail]
> Subject:    Re: DN comparison
> 
> Sorry for being late in on this, but here's my two penneth.
> 
> Laurence Lundblade wrote:
> >
> > What I want to know is how to compare DN's (subject with issuer). I found
> > all the stuff about the string processing in 2459 and am happy to see
> > that's reasonably dealt with. What I can't find is whether the order of
> > RDN's or the order of the parts of the RDN's matter or not. Also I
> haven't
> > been able to determine if the grouping of parts in RDN's matter or not.
> >
> > To be specific, which of these are the same in these DN's?
> >   1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)
> 
> Illegal DN. YOu are not allowed to have the same attribute type twice in
> an RDN
> 
> >   2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
> >   3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)
> 
> Illegal DN
> 
> >   4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)
> >
> > RDN's are in (). I would think/hope they're all the same.
> 
> Sorry. None of them are the same. The reason is that ordering is
> important, just as in DNS names.
> 
> Also, to clear up the confusion over the word "corresponding". Once you
> know that RDN ordering is important within a DN (a DN is a SEQUENCE of
> RDNs), then the meaning of corresponding also becomes clear. It has the
> normal English meaning that the nth RDN in one DN corresponds with the
> nth RDN in another DN. Its that simple.
> 
> David
> 
> >From reading the
> > source, it looks like OpenSSL doesn't care about the grouping of RDN's,
> but
> > does care about the order.
> >
> > And more of a standard question, how should I have found the answer to
> this
> > question? From my current perspective it seems an addition to RFC-3280
> > would be helpful.
> >
> > LL
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------E72662C8C52006FA5B797B7E
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------E72662C8C52006FA5B797B7E--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RE6N628896 for ietf-pkix-bks; Thu, 27 Jun 2002 07:06:23 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RE6Lw28886 for <[e-mail]>; Thu, 27 Jun 2002 07:06:21 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA13248; Thu, 27 Jun 2002 16:09:01 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002062716043457:113 ; Thu, 27 Jun 2002 16:04:34 +0200 
Message-ID: <[e-mail]>
Date: Thu, 27 Jun 2002 16:04:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-warranty-extn-01
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 27/06/2002 16:04:34, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 27/06/2002 16:05:07, Serialize complete at 27/06/2002 16:05:07
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice,

> Hello folks,
> 
> Further to my note to this list yesterday - On further reflection, I think
> that my previous proposed text may not be the best way to proceed.  In this
> message, I offer an alternative.  This may be preferable because it allows
> CAs to offer basic per-transaction protection, yet it does not prevent this
> protection from being augmented by a transaction specific insurance policy
> when it is needed.
 
> Rather than moving the text from the third paragraph of section 2 to the
> Introduction, I suggest leaving the text in section 2 as it is, but add the
> following to the Introduction, at the end of the third paragraph:
> [EXISTING TEXT]"Alternatively a CA may provide extended liability coverage
> for the use of the certificate.  Usually, the subscriber pays for the
> extended warranty coverage.  In turn, subscribers are covered by an
> appropriately drafted insurance policy.  The certificate warranty is backed
> by an insurance policy issued by a licensed insurance company, which results
> in a financial backing that is far greater than that of the CA.  This extra
> financial backing provides a further element of confidence necessary to
> encourage the use of certificates in commerce.

> [REVISED TEXT:]  A relying party may obtain compensation from a CA depending
> on the conditions for such compensation expressed in either the CA's
> Certificate Policy or the CA's insurance policy, or both.  

I believe that Russ said that the CA's insurance policy was included in the
CA's Certificate Policy. The "or" is not appropriate. 

> Where the relying
> party is also a subscriber to the CA, then the terms and conditions of the
> insurance policy cover the relying party.  When the relying party is not a
> subscriber to the CA, however, then the relying party is likely to seek
> compensation from the subscriber in the event of harm resulting from relying
> on a certificate.  

"compensation from the subscriber" or "from the CA" ?
I believe the later only.

> If the subscriber cannot provide compensation, then the
> relying party is likely to turn to the CA for compensation.

I disagree: the subscriber is not guilty when the fault is on the CA.

> Evidence of an extended warranty, provided through the certificate extension, 
> will give the relying party confidence that compensation is possible, and will 
> therefore enhance trust in the process.  

I wonder if trust will be enhanced. If the compensation, is the same for all
certificates issued by the CA then the proposed extension is not needed: the
CA's Certificate Policy which will include the CA's insurance policy will be
enough. If it is different and, for example, there are three levels, then
using three different CP OIDs will be also sufficient. I still doubt about
the real need of such an extension where, anyway, there is a need to read
the policy details to discover the conditions to get advantage of the
guarantee. It is usually in in grey characters on a grey background and will
tell the conditions under which the garantee will and will not be granted.

> Risk for a non-subscriber relying party may
> be reduced by the presence of a warranty extension with an explicit warranty
> stated.  The warranty extension allows this aspect of risk management to be
> automated.  There are different warranty models.  As described in section 2,
> this certificate extension provides a mechanism for the aggregated model and
> the per-transaction model, as a base; if the value of the base is exceeded,
> then the relying party may either seek additional coverage or accept the
> difference as residual (and known) risk."

Interresting, but quite different from the position of the EU Directive
which specifies in the certificate the "limits on the value of transactions
for which the certificate can be used, if applicable". If the limit is
exceeded, there is no guaranty whatsoever. I would believe that this level
of detail will be specified in the terms of the guaranty, which anyway need
to be read.

Denis

> Alice
> 
> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     [phone]
> Cell:         613-291-0331


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RCWFP29735 for ietf-pkix-bks; Thu, 27 Jun 2002 05:32:15 -0700 (PDT)
Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5RCWEw29726 for <[e-mail]>; Thu, 27 Jun 2002 05:32:14 -0700 (PDT)
Received: from unknown (HELO liyunfeng) (forward?li@218.6.192.143 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Jun 2002 12:32:13 -0000
From: "forward" <[e-mail]>
To: <[e-mail]>
Subject: Question about SCEP!
Date: Thu, 27 Jun 2002 20:31:43 +0800
Message-ID: <002301c21dd6$9c4d6580$b400a8c0@liyunfeng>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi:
I want to ask a question about SCEP. In SCEP there is a sentence " To
prevent a "man-in-the-middle" attack, an MD5 'fingerprint' generated on
the PKCS#10(before PKCS#7 enveloping and signing ) must be compared
out-of-band between the server and end entity". However I don't know how
the cisco's SCEP client calculate the MD5 'fingerprint'. 
In my SCEP server, I can decrypt and decode PKCSReq and can get the
PKCS#10 then generate certificate for CISCO's router. The server
generate the CertRep message and send it to CISCO2600. However the
CISCO2600 tell me that it verify the massage failed.
Can anybody tell me the reason?
Thanks!

Forward.li



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RC0qV21783 for ietf-pkix-bks; Thu, 27 Jun 2002 05:00:52 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RC0ow21775 for <[e-mail]>; Thu, 27 Jun 2002 05:00:50 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5RC0Vg5209370; Thu, 27 Jun 2002 08:00:31 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5RC0Tm72276; Thu, 27 Jun 2002 08:00:29 -0400
Importance: Normal
Sensitivity: 
Subject: Re: DN comparison
To: David Chadwick <[e-mail]>
Cc: Laurence Lundblade <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 27 Jun 2002 08:00:27 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/27/2002 08:00:29 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      David:

      Corresponding's normal English meaning is not "in the same order as"
but either "in agreement or conformity with" or "similar or analogous to".
Neither of these meanings is notably closer to "in the same order as" than
to "having the same structure".  While I know that X.500 databases are
tree-structured and so RDN order is crucial to finding entries in them, I
do not think that matching certificate subjects based on an order-dependent
rule is more useful than doing so on a structure-dependent rule (i.e. one
which considers that the order of distinct attribute types such as L and O
is irrelevant).  Nobody else has thought that this wording was particularly
clear, even though it appears in an X.500 standard and X.500 implies a tree
structure.

            Tom Gindin

David Chadwick <[e-mail]>@mail.imc.org on 06/26/2002
07:19:38 PM

Sent by:    [e-mail]


To:    Laurence Lundblade <[e-mail]>
cc:    [e-mail]
Subject:    Re: DN comparison



Sorry for being late in on this, but here's my two penneth.

Laurence Lundblade wrote:
>
> What I want to know is how to compare DN's (subject with issuer). I found
> all the stuff about the string processing in 2459 and am happy to see
> that's reasonably dealt with. What I can't find is whether the order of
> RDN's or the order of the parts of the RDN's matter or not. Also I
haven't
> been able to determine if the grouping of parts in RDN's matter or not.
>
> To be specific, which of these are the same in these DN's?
>   1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)

Illegal DN. YOu are not allowed to have the same attribute type twice in
an RDN

>   2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
>   3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)

Illegal DN

>   4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)
>
> RDN's are in (). I would think/hope they're all the same.

Sorry. None of them are the same. The reason is that ordering is
important, just as in DNS names.

Also, to clear up the confusion over the word "corresponding". Once you
know that RDN ordering is important within a DN (a DN is a SEQUENCE of
RDNs), then the meaning of corresponding also becomes clear. It has the
normal English meaning that the nth RDN in one DN corresponds with the
nth RDN in another DN. Its that simple.

David


>From reading the
> source, it looks like OpenSSL doesn't care about the grouping of RDN's,
but
> does care about the order.
>
> And more of a standard question, how should I have found the answer to
this
> question? From my current perspective it seems an addition to RFC-3280
> would be helpful.
>
> LL

--
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RAh1F01987 for ietf-pkix-bks; Thu, 27 Jun 2002 03:43:01 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RAh0w01980 for <[e-mail]>; Thu, 27 Jun 2002 03:43:01 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09852; Thu, 27 Jun 2002 06:42:17 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pr-tsa-01.txt
Date: Thu, 27 Jun 2002 06:42:17 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Policy Requirements for Time-Stamping Authorities
	Author(s)	: D. Pinkas, N. Pope, J. Ross
	Filename	: draft-ietf-pkix-pr-tsa-01.txt
	Pages		: 39
	Date		: 26-Jun-02
	
This document specifies policy requirements relating to the 
operation of Time-stamping Authorities (TSAs). It defines policy 
requirements on the operation and management practices of TSAs such 
that subscribers and relying parties may have confidence in the 
operation of the time-stamping services.
The contents of this Informational RFC is technically equivalent to
ETSI TS 102 023 V1.2.1 (2002-06) [TS 102023]. The ETSI TS is under 
the ETSI Copyright (C). Individual copies of this ETSI deliverable 
can be downloaded from http://www.etsi.org
This document is an Internet-Draft and is NOT offered in accordance 
with Section 10 of RFC 2026, and the authors do not provide the IETF
with any rights other than to publish as an Internet-Draft.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pr-tsa-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pr-tsa-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pr-tsa-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pr-tsa-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5QNJ2p05411 for ietf-pkix-bks; Wed, 26 Jun 2002 16:19:02 -0700 (PDT)
Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QNItw05407 for <[e-mail]>; Wed, 26 Jun 2002 16:19:01 -0700 (PDT)
Received: from salford.ac.uk ([80.5.216.144]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 27 Jun 2002 00:18:54 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Jun 2002 00:19:38 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Laurence Lundblade <[e-mail]>
CC: [e-mail]
Subject: Re: DN comparison
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------49F09AD366CF36E72707C72F"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------49F09AD366CF36E72707C72F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry for being late in on this, but here's my two penneth.

Laurence Lundblade wrote:
>
> What I want to know is how to compare DN's (subject with issuer). I found
> all the stuff about the string processing in 2459 and am happy to see
> that's reasonably dealt with. What I can't find is whether the order of
> RDN's or the order of the parts of the RDN's matter or not. Also I haven't
> been able to determine if the grouping of parts in RDN's matter or not.
> 
> To be specific, which of these are the same in these DN's?
>   1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)

Illegal DN. YOu are not allowed to have the same attribute type twice in
an RDN

>   2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
>   3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)

Illegal DN

>   4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)
> 
> RDN's are in (). I would think/hope they're all the same. 

Sorry. None of them are the same. The reason is that ordering is
important, just as in DNS names.

Also, to clear up the confusion over the word "corresponding". Once you
know that RDN ordering is important within a DN (a DN is a SEQUENCE of
RDNs), then the meaning of corresponding also becomes clear. It has the
normal English meaning that the nth RDN in one DN corresponds with the
nth RDN in another DN. Its that simple.

David


>From reading the
> source, it looks like OpenSSL doesn't care about the grouping of RDN's, but
> does care about the order.
> 
> And more of a standard question, how should I have found the answer to this
> question? From my current perspective it seems an addition to RFC-3280
> would be helpful.
> 
> LL

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------49F09AD366CF36E72707C72F
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------49F09AD366CF36E72707C72F--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5Q6lm508394 for ietf-pkix-bks; Tue, 25 Jun 2002 23:47:48 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz ([130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q6lkw08386 for <[e-mail]>; Tue, 25 Jun 2002 23:47:46 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g5Q6lM42029713; Wed, 26 Jun 2002 18:47:22 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA85012; Wed, 26 Jun 2002 18:47:17 +1200 (NZST) (sender [e-mail])
Date: Wed, 26 Jun 2002 18:47:17 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Basic Constrains and Key Usage processing
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" <[e-mail]> writes:

>In your experience, do implementors of IPSEC or TLS receive much slack if they
>are not "strict in what they generate"?

I can't really comment on IPsec (although I've heard that a year or two back
some of the certs being used made the ones mentioned in the style guide seem
like canon in comparison), but for SSL/TLS the rule is that you do what the
browser does (that is, whatever it takes to make Netscape and MSIE work),
whether the spec says so or not.  See for example Netscape's encoding bug for
RSA-wrapped keys (fixed in TLS), which everyone copied, or their DSA sig
formatting bug which Netscape justify by citing installed base and MS argue
against by citing standards non-compliance.

OTOH it isn't just Netscape, MSIE at one point would generate packets of up to
64K (allowed max is 16K) and everyone just broke their code to handle this.
Since browsers are universally used, any failure by the browser to interoperate
with X is seen as a bug in X rather than a bug in the browser.  I guess you
could generalise that to say that the rule for SSL/TLS implementations is that
you follow the de facto semi-standard of Netscape and to a lesser extent MSIE,
and finally fall back to what the RFC says (X.509 is no different, see below).

Once nice thing about RFC 2246 is that in several locations it actually tells
you about widely-occurring browser problems/bugs to allow you to add
workarounds.  RFC 2440 does this as well.

>Should not CAs that mention the PKIX brand be held to a similar standard?

You mean breaking their code/certs to be compatible with other broken
certs/code? :-).  Actually that's already happened, look at the issue with MS
reversing the handling of the critical flag a few years back, all the CAs broke
their certs to be bug-compatible.

The problem is that PKIX (I'll generalise here and call it "X.509", since
that's the buzzword the masses are familiar with, which in practice has been
diluted to the point where it means "anything but PGP and SPKI") isn't a brand
in the legal sense, so there's no enforceability attached to it.  I really
don't know how to address this issue, perhaps make "X.509" a TM/service mark
like "Designed for Windows" (or whatever the phrase is) and then have someone
slapping people who use it without passing some compliance test.  At the moment
X.509 is like the League of Nations, lots of good intentions and zero
enforcement power, so everyone can be a member while still doing pretty much
whatever they please.

The intent of my previous message was just to point out that working from a
viewpoint of "In my reality, things work like this" isn't very useful when
everyone else's reality differs from yours (I think that's the approach that
lead to OSI :-).  One possible solution would be to have some sort of minimum
compliance check like RSA's S/MIME interop test, where you send in a signed,
encrypted message and get back the same.  If you can do that, you've got 99% of
the required functionality right... come to think of it, the one place where
you really don't hear much about interop problems is S/MIME (assuming you stick
to v2 and don't try any of the fancy stuff in v3, I was pleasantly surprised to
find that I could interoperate the first time with Messenger and Outlook, which
certainly wasn't the case with Navigator and IE).  Maybe PKIX needs a similar
"You must be at least this compliant to call yourself X.509" test.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5PHv4h05484 for ietf-pkix-bks; Tue, 25 Jun 2002 10:57:04 -0700 (PDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PHv3w05480 for <[e-mail]>; Tue, 25 Jun 2002 10:57:03 -0700 (PDT)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5PHuhxN010652 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 Jun 2002 10:56:44 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.82]) by magus.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5PHueF8020158; Tue, 25 Jun 2002 10:56:41 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 25 Jun 2002 10:56:40 -0700
To: Stephen Kent <[e-mail]>
From: Laurence Lundblade <[e-mail]>
Subject: Re: Basic Constrains and Key Usage processing
Cc: [e-mail]
In-Reply-To: <p0510030db93e4d8ca045@[128.89.88.34]>
References: <[e-mail]> <1024959823.6417.1704.camel@wjm> <[e-mail]> <1024959823.6417.1704.camel@wjm> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:56 PM 6/25/2002 -0400, Stephen Kent wrote:
>At 9:32 AM -0700 6/25/02, Laurence Lundblade wrote:
>>At 07:18 PM 6/24/2002 -0400, Stephen Kent wrote:
>>
>>....
>>
>>So I'm guess I'm unclear what the intent of PKIX is for TLS/SSL in the 
>>past, present and future.
>
>PKIX provides a set of standards intended to support a wide range of 
>Internet protocols that are PKI-enabled. However, it is up to each 
>protocol to specify the extent to which it makes use of the PKIX standards.
>
>For example, S/MIME has been very good about this, but SSL/TLS and IPsec 
>have not, although an ID was just released 
>(draft-ietf-ipsec-pki-profile-00.txt) that is an attempt at this for IPsec 
>(more properly IKE).
>
>...
>
>Does that answer your question?

It is very clear. Thanks very much for that explanation.

It does seem possible and useful to build a cert chainer that can be 
configured to work either in SSL mode or in PKIX mode so I won't give up 
entirely.

LL



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5PGvoc04186 for ietf-pkix-bks; Tue, 25 Jun 2002 09:57:50 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PGvnw04182 for <[e-mail]>; Tue, 25 Jun 2002 09:57:49 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA10240; Tue, 25 Jun 2002 12:57:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030db93e4d8ca045@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <1024959823.6417.1704.camel@wjm> <[e-mail]> <1024959823.6417.1704.camel@wjm> <[e-mail]>
Date: Tue, 25 Jun 2002 12:56:06 -0400
To: Laurence Lundblade <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Basic Constrains and Key Usage processing
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:32 AM -0700 6/25/02, Laurence Lundblade wrote:
>At 07:18 PM 6/24/2002 -0400, Stephen Kent wrote:
>
>>We had all these discussions a long time ago. The PKIX documents do 
>>not make concessions for legacy designs; they set standards for 
>>what should be done going forward.
>
>My goal is to build a cert chaining engine that works with real 
>world SSL/TLS cert chains and is also modern, going forward and 
>standards compliant. In particular I'd like it to be reusable with 
>other applications.
>
>My vague impression is that PKIX related to this and TLS, hence my 
>questions here. Now, I've just done a look around to see if there 
>was some other ID or RFC that was specific to X.509 and TLS and have 
>found nothing.
>
>So I'm guess I'm unclear what the intent of PKIX is for TLS/SSL in 
>the past, present and future.

PKIX provides a set of standards intended to support a wide range of 
Internet protocols that are PKI-enabled. However, it is up to each 
protocol to specify the extent to which it makes use of the PKIX 
standards.

For example, S/MIME has been very good about this, but SSL/TLS and 
IPsec have not, although an ID was just released 
(draft-ietf-ipsec-pki-profile-00.txt) that is an attempt at this for 
IPsec (more properly IKE).

SSL/TLS is especially problematic. SSL was not developed in the IETF 
and the specification for what SSL does with certs is not part of SSL 
(or TLS), but is the domain of HTTPS.  HTTPS is not an IETF standard, 
and the only IETF publication I recall on HTTPS is an expired ID from 
1999! HTTPS behavior is essentially whatever is implemented in 
browsers, and because there is essentially a duopoly for browsers, 
this is an especially bad area to try to relate to PKIX standards.

So, it is quite likely that if you build an engine that mimics what 
browsers do re cert processing, it will not be PKIX complaint. If you 
then use this engine for other PKI-enavbled applications, you will be 
imposing on them the idiosyncrasies of a largely undocumented 
protocol that was not the subject of an open standards process.

Does that answer your question?

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g5PGX6m03463 for ietf-pkix-bks; Tue, 25 Jun 2002 09:33:06 -0700 (PDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PGX5w03456 for <[e-mail]>; Tue, 25 Jun 2002 09:33:05 -0700 (PDT)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5PGWjxN006459 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 Jun 2002 09:32:45 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.82]) by magus.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5PGWgF8014074; Tue, 25 Jun 2002 09:32:43 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 25 Jun 2002 09:32:41 -0700
To: Stephen Kent <[e-mail]>, [e-mail]
From: Laurence Lundblade <[e-mail]>
Subject: Re: Basic Constrains and Key Usage processing
In-Reply-To: <p05100319b93d585302f1@[128.89.88.34]>
References: <1024959823.6417.1704.camel@wjm> <[e-mail]> <1024959823.6417.1704.camel@wjm>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:18 PM 6/24/2002 -0400, Stephen Kent wrote:

>We had all these discussions a long time ago. The PKIX documents do not 
>make concessions for legacy designs; they set standards for what should be 
>done going forward.

My goal is to build a cert chaining engine that works with real world 
SSL/TLS cert chains and is also modern, going forward and standards 
compliant. In particular I'd like it to be reusable with other applications.

My vague impression is that PKIX related to this and TLS, hence my 
questions here. Now, I've just done a look around to see if there was some 
other ID or RFC that was specific to X.509 and TLS and have found nothing.

So I'm guess I'm unclear what the intent of PKIX is for TLS/SSL in the 
past, present and future.

Thanks, LL





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5PFIL327480 for ietf-pkix-bks; Tue, 25 Jun 2002 08:18:21 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PFIJw27475 for <[e-mail]>; Tue, 25 Jun 2002 08:18:19 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA08365; Tue, 25 Jun 2002 11:17:59 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b93e37b07da5@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 25 Jun 2002 11:11:04 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Basic Constrains and Key Usage processing
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

We are producing standards that we want vendors to follow. This is 
not an academic exercise. We have good reasons for why we have 
adopted conventions that differ from what vendors have done, and 
these reasons have been documented. So, the goal is to get vendors to 
do the right thing, not to accommodate vendor choices that may have 
been made because of lack of foresight, lack of a transition strategy 
re backwards compatibility, proprietary advantage, ....

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5PEgVL26269 for ietf-pkix-bks; Tue, 25 Jun 2002 07:42:31 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PEgJw26254 for <[e-mail]>; Tue, 25 Jun 2002 07:42:20 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g5PEfgg09310; Tue, 25 Jun 2002 10:41:42 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 25 Jun 2002 10:40:23 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Basic Constrains and Key Usage processing
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms01FC7873ED0C58C35C84E360"
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms01FC7873ED0C58C35C84E360
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

In your experience, do implementors of IPSEC or TLS receive much slack
if they are not "strict in what they generate"?   Should not CAs that
mention the PKIX brand be held to a similar standard?

Dave



Peter Gutmann wrote:
> 
> Stephen Kent <[e-mail]> writes:
> 
> >We had all these discussions a long time ago. The PKIX documents do not make
> >concessions for legacy designs; they set standards for what should be done
> >going forward.
> 
> The original message, however, requested guidelines on what would work with
> real-world implementations, not what standards require to move forward.  The
> problem with many PKIX documents is that they describe an ideal situation which
> doesn't exist in reality.  As a result, it's possible to create implementations
> which are PKIX-compliant, or which work in the real world, but not both.  A
> recent example of this (which happens to relate to the use of the keyUsage
> extension) results in fully PKIX-compliant implementations rejecting a
> significant number of real-world certs because they're not PKIX compliant.
> Since these problems aren't even noticed by the majority of cert-handling
> implementations, the logical corollary is that said majority of implementations
> are similarly not PKIX-compliant.  I don't know how many hacked-up versions of
> my code exist out there where users have had to disable various checks to get
> it to process certs, because the other option, telling a CA that the certs
> they're issuing aren't standards-compliant, is largely an exercise in futility
> (this is used to advantage by a number of European CAs, since in order to
> handle their certs you need to buy the CA's proprietary software).
> 
> This difference between standards and real life was the motivation for the
> creation of the X.509 style guide, and why in RFC drafts I always include
> sections telling readers that although the standard may say X, in practice
> everyone seems to do Y instead, and that implementors should be prepared for
> this.  I guess I need to update the style guide a bit, it's been laying dormat
> for awhile.
> 
> Peter.
--------------ms01FC7873ED0C58C35C84E360
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIOhgYJKoZIhvcNAQcCoIIOdzCCDnMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DIkwggQxMIIDmqADAgECAgMDOtQwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVMxGDAW
BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAd
BgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwHhcNMDIwNDI1MTQ1ODQyWhcNMDUwNDI1
MTQ1ODQyWjB3MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEQMA4GA1UECxMHTlNBL0NTUzEgMB4GA1UEAxMXS2Vt
cC5EYXZpZC5QLjA1MTQxMDE0MDQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOrsDFPo
087+VZ15OuyrJedIwjkRXWrtqRBzEpkk6Ct+Bkn/uiKzLn7AZ5IxbGDnZvjbvmEzPYkA/tm8
ng0IVxNpKEjdw7O1TbNLnwLSDkckcmq8AzW6se/Dm5nZ7l3ggVx8XuYifnr9E163atD9JxjR
nVM1vcPx262lVck4wTXrAgMBAAGjggHcMIIB2DAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgw
FoAU7BNbvCGMZpsKi38HXyWwFPkQ9ZswHQYDVR0OBBYEFIs+vTwgtAcXc7Wa3lN5TOdFB2v4
MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsFMCAGA1UdEQQZMBeBFWRwa2VtcEBtaXNzaS5uY3Nj
Lm1pbDCBjwYDVR0SBIGHMIGEhoGBbGRhcDovL2VtYWlsLWRzLTMuYzNwa2kuY2hhbWIuZGlz
YS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBFTUFJTCUyMENBLTMlMmNvdSUzZFBLSSUy
Y291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTMIG5BgNVHR8EgbEw
ga4wgauggaiggaWGgaJsZGFwOi8vZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9j
biUzZERPRCUyMENMQVNTJTIwMyUyMEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2RE
b0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVyZXZvY2F0
aW9ubGlzdDtiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEA0kEbsqISaLdMPsBZSuefbL8k2fU2
V6nAVrq890J8s7Sf2vlm+Z9SkRqo+KebaeHRCS8Pg5S8YhxRHz6jmvGV9+CqOBhJp/DsW2Iu
tHXUMy46iPxLQfFT75LIjOAGXk929TSgnqk/3ygIVP6/E+6culxD7hTKh4FFa/Dto/V4T6ww
ggQbMIIDhKADAgECAgETMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQK
Ew9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQD
ExNEb0QgQ0xBU1MgMyBSb290IENBMB4XDTAwMDgxMTE3NDUyOVoXDTA2MDgxMDE3NDUyOVow
ZDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAO98vchr6/EuN4Vw2h1ovziIBzOml88LKtiNQxMFN07J
V04JFR2kZtuOxlCcvNnL2fXv9lRG4teiwqBldt36ekVY/1LDkW6xDecvHnS4BuJhQPnmMdnu
HF47TwK7O/bxvevAKpKeS1/sw1wuyKJN9Bi7jezH36gY+CdT9VwfP4QJAgMBAAGjggHeMIIB
2jAdBgNVHQ4EFgQU7BNbvCGMZpsKi38HXyWwFPkQ9ZswDgYDVR0PAQH/BAQDAgGGMA8GA1Ud
EwEB/wQFMAMBAf8wDAYDVR0kBAUwA4ABADAfBgNVHSMEGDAWgBRsnKXwXI9tQY3EFzuQV8IP
o81t/jAwBgNVHSAEKTAnMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsK
MIGDBgNVHRIEfDB6hnhsZGFwOi8vZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERv
RCUyMENMQVNTJTIwMyUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNk
VS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVMwgbAGA1UdHwSBqDCBpTCBoqCBn6CBnIaBmWxk
YXA6Ly9kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwQ0xBU1MlMjAzJTIw
Um9vdCUyMENBJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVu
dCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0B
AQUFAAOBgQAmpY01OHZr/vRBJsgxGUX7diGsCGrzYM1C0fhrJknH4L7Lm61Nt1bSZ4/obHjl
QxBQyDx9ovISBAi//TVUd1UKbdqNW7Inso2enmK9beG9eK5M0ZfEdj3S0UxmJAgRXSgVsnE7
xzP3uZ1/mJx++gSwcpd+/NPBVJNjFJPf8RvL4DCCBDEwggOaoAMCAQICAwM61jANBgkqhkiG
9w0BAQUFADBkMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0Et
MzAeFw0wMjA0MjUxNDU5NDZaFw0wNTA0MjUxNDU5NDZaMHcxCzAJBgNVBAYTAlVTMRgwFgYD
VQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRAwDgYD
VQQLEwdOU0EvQ1NTMSAwHgYDVQQDExdLZW1wLkRhdmlkLlAuMDUxNDEwMTQwNDCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApfaxUWfMcxUPKtb9p7FeItF5DkWiDmO8i0uiC0VpUPoz
t+9gx4pUo4lOeqcSGMRfFwv7llBtPte7NqtbDefDW2tIFIzzFrv07VPrq0MNCo6rRK/IGCK/
Zmrf/UOfx8Hzvn6dIF+S9YktXZsFpbtJT49v6+E2nmKLpO7OCtW582kCAwEAAaOCAdwwggHY
MA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTsE1u8IYxmmwqLfwdfJbAU+RD1mzAdBgNV
HQ4EFgQUYrtZ7SslM3nXtC47SpLr4YEu02AwFgYDVR0gBA8wDTALBglghkgBZQIBCwUwIAYD
VR0RBBkwF4EVZHBrZW1wQG1pc3NpLm5jc2MubWlsMIGPBgNVHRIEgYcwgYSGgYFsZGFwOi8v
ZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERPRCUyMENMQVNTJTIwMyUy
MEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVy
bm1lbnQlMmNjJTNkVVMwgbkGA1UdHwSBsTCBrjCBq6CBqKCBpYaBomxkYXA6Ly9lbWFpbC1k
cy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRE9EJTIwQ0xBU1MlMjAzJTIwRU1BSUwl
MjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy
Y2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUF
AAOBgQDIzhLKkB3qMsN45svSI+hEJN0hjuhiz7hGNFOUco1YnyoyfwvShlJHrl85ptr9mt/L
hMuLunqBCS2tfTKTLWAK9RjR20MRI7evK0qu/OxpxfMI9TFPwHPXSOINrgILbIVvuwOkIYcm
IBcfD2OReXE7+WcRoZDUjZGD4X+80lIm4jGCAcUwggHBAgEBMGswZDELMAkGA1UEBhMCVVMx
GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kx
HzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMCAwM61DAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDYyNTE0NDAyM1ow
IwYJKoZIhvcNAQkEMRYEFEAWTF13ZV8z6E9GJT+NpIwAl977MFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0G
CCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAQ76mPXwWNRomWh3C4//fVvXf5W8YInkh
S4dBvF+EwiQmpDXQPFYyYIAhXQwUYqPC8MpAMgZ6StchBxMddr+FlvTpVv3pepVzrbZ4DQEx
uBELqNlF6wX6OMBHXq14op4LmyxmHIG1m8pPDikY54dkE75TBT9s3tFrZVTCmx91ZRQ=
--------------ms01FC7873ED0C58C35C84E360--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5P8TnD27058 for ietf-pkix-bks; Tue, 25 Jun 2002 01:29:49 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5P8Tlw27054 for <[e-mail]>; Tue, 25 Jun 2002 01:29:48 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g5P8TO42001862; Tue, 25 Jun 2002 20:29:24 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA503780; Tue, 25 Jun 2002 20:29:22 +1200 (NZST) (sender [e-mail])
Date: Tue, 25 Jun 2002 20:29:22 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Basic Constrains and Key Usage processing
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>We had all these discussions a long time ago. The PKIX documents do not make
>concessions for legacy designs; they set standards for what should be done
>going forward.

The original message, however, requested guidelines on what would work with
real-world implementations, not what standards require to move forward.  The
problem with many PKIX documents is that they describe an ideal situation which
doesn't exist in reality.  As a result, it's possible to create implementations
which are PKIX-compliant, or which work in the real world, but not both.  A
recent example of this (which happens to relate to the use of the keyUsage
extension) results in fully PKIX-compliant implementations rejecting a
significant number of real-world certs because they're not PKIX compliant.
Since these problems aren't even noticed by the majority of cert-handling
implementations, the logical corollary is that said majority of implementations
are similarly not PKIX-compliant.  I don't know how many hacked-up versions of
my code exist out there where users have had to disable various checks to get
it to process certs, because the other option, telling a CA that the certs
they're issuing aren't standards-compliant, is largely an exercise in futility
(this is used to advantage by a number of European CAs, since in order to
handle their certs you need to buy the CA's proprietary software).

This difference between standards and real life was the motivation for the
creation of the X.509 style guide, and why in RFC drafts I always include
sections telling readers that although the standard may say X, in practice
everyone seems to do Y instead, and that implementors should be prepared for
this.  I guess I need to update the style guide a bit, it's been laying dormat
for awhile.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5P5wdM13929 for ietf-pkix-bks; Mon, 24 Jun 2002 22:58:39 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5P5wcw13923 for <[e-mail]>; Mon, 24 Jun 2002 22:58:38 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 24 Jun 2002 22:52:11 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 24 Jun 2002 22:52:11 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <MV9MG1BM>; Mon, 24 Jun 2002 22:58:22 -0700
Content-return: allowed
Date: Mon, 24 Jun 2002 22:58:21 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Question about revocationTime in OCSP
To: "'? ??'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="KS_C_5601-1987"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If you are using a CRL, you do know the revocation time - it is
in the CRL.

If you are not using a CRL, whoever provides you the revocation
data MUST give you the revocation times associated with each
certificate revoked.

Hope this helps,
Regards,
Ambarish


---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, June 24, 2002 7:40 PM
> To: [e-mail]
> Subject: Question about revocationTime in OCSP
> 
> 
> 
> Hi,
> 
> OCSP server know that the certificate revoked.
> 
> But, OCSP server doesn't know the revoked time when the 
> certification has been revoked.
> 
> How to be set 'revocationTime' in ocsp response ?
> 
> Could anyone help me?
> 
> Thanks.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5P2d3C08668 for ietf-pkix-bks; Mon, 24 Jun 2002 19:39:03 -0700 (PDT)
Received: from stdout ([61.74.133.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5P2d1w08658 for <[e-mail]>; Mon, 24 Jun 2002 19:39:02 -0700 (PDT)
Received: from [61.74.133.139] (helo=tom) by stdout with smtp (Exim 3.35 #1 (Debian)) id 17Mg2g-0008Bj-00 for <[e-mail]>; Tue, 25 Jun 2002 11:26:54 +0900
Message-ID: <001801c21bf1$95047200$8b854a3d@tom>
From: "=?euc-kr?B?waQgsea3xA==?=" <[e-mail]>
To: <[e-mail]>
Subject: Question about revocationTime in OCSP
Date: Tue, 25 Jun 2002 11:39:51 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g5P2d2w08665
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

OCSP server know that the certificate revoked.

But, OCSP server doesn't know the revoked time when the certification has been revoked.

How to be set 'revocationTime' in ocsp response ?

Could anyone help me?

Thanks.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ONe9Y01679 for ietf-pkix-bks; Mon, 24 Jun 2002 16:40:09 -0700 (PDT)
Received: from wjm.homelinux.com (213-145-172-14.dd.nextgentel.com [213.145.172.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ONe7w01675 for <[e-mail]>; Mon, 24 Jun 2002 16:40:08 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by wjm.homelinux.com (Postfix) with ESMTP id C01E082F84; Tue, 25 Jun 2002 01:40:09 +0200 (CEST)
Subject: Re: Basic Constrains and Key Usage processing
From: Bill Middleton <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
In-Reply-To: <p05100319b93d585302f1@[128.89.88.34]>
References: <[e-mail]> <1024959823.6417.1704.camel@wjm>  <p05100319b93d585302f1@[128.89.88.34]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 25 Jun 2002 01:40:09 +0200
Message-Id: <1024962009.6417.1723.camel@wjm>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent kindly pointed out:
> We had all these discussions a long time ago. The PKIX documents do 
> not make concessions for legacy designs; they set standards for what 
> should be done going forward.

I understand.  I'll refer to the archives.  Just to clarify, my
reference should have been to openssl, not modssl. Further, I did not
intend to open a can of worms, neither slight your efforts.  I look
forward to a review of the discussion via the archive.


Thanks again,

Bill
PS - I would be glad to have URL's in private email to what any of you
consider to be good discussion related to the topic.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ONKSF00588 for ietf-pkix-bks; Mon, 24 Jun 2002 16:20:28 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ONKRw00579 for <[e-mail]>; Mon, 24 Jun 2002 16:20:27 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA26680; Mon, 24 Jun 2002 19:19:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100319b93d585302f1@[128.89.88.34]>
In-Reply-To: <1024959823.6417.1704.camel@wjm>
References: <[e-mail]> <1024959823.6417.1704.camel@wjm>
Date: Mon, 24 Jun 2002 19:18:39 -0400
To: Bill Middleton <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Basic Constrains and Key Usage processing
Cc: Laurence Lundblade <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:03 AM +0200 6/25/02, Bill Middleton wrote:
>On Mon, 2002-06-24 at 19:14, Laurence Lundblade wrote:
>>
>>  Continuing on with a cert chain processing implementation I have some
>>  questions about BasicConstraints and KeyUsage.
>
>It  seems to me that your intent here is to assert  definition on the
>critical boolean, especially when used in BasicConstraints, via defining
>what it is not. Modssl (www.modssl.org) documentation warns gravely
>about using the Critical option, due to the unpredictable reaction of
>any given client implementation.  RFC2459 says that it can inhibit
>interoperability, but still insists that all CA certificates have
>BasicConstraints critical.
>
>Perhaps Critical can be defined in this manner, but in light of the
>number of V1 roots which are still "out there", not to mention some v3
>CA's, it does seem to be something of an exercise in futility.  I do see
>the utility of critical on some fields and extensions , but arguing
>about it on BasicConstraints and KeyUsage seems overkill.  No?
>
>
>
>Thanks,
>
>Bill Middleton

Folks,

We had all these discussions a long time ago. The PKIX documents do 
not make concessions for legacy designs; they set standards for what 
should be done going forward.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ON3iI29723 for ietf-pkix-bks; Mon, 24 Jun 2002 16:03:44 -0700 (PDT)
Received: from wjm.homelinux.com (213-145-172-14.dd.nextgentel.com [213.145.172.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ON3gw29718 for <[e-mail]>; Mon, 24 Jun 2002 16:03:42 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by wjm.homelinux.com (Postfix) with ESMTP id 7480F82F84; Tue, 25 Jun 2002 01:03:43 +0200 (CEST)
Subject: Re: Basic Constrains and Key Usage processing
From: Bill Middleton <[e-mail]>
To: Laurence Lundblade <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 25 Jun 2002 01:03:43 +0200
Message-Id: <1024959823.6417.1704.camel@wjm>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2002-06-24 at 19:14, Laurence Lundblade wrote:
> 
> Continuing on with a cert chain processing implementation I have some 
> questions about BasicConstraints and KeyUsage.

It  seems to me that your intent here is to assert  definition on the
critical boolean, especially when used in BasicConstraints, via defining
what it is not. Modssl (www.modssl.org) documentation warns gravely
about using the Critical option, due to the unpredictable reaction of
any given client implementation.  RFC2459 says that it can inhibit
interoperability, but still insists that all CA certificates have
BasicConstraints critical.

Perhaps Critical can be defined in this manner, but in light of the
number of V1 roots which are still "out there", not to mention some v3
CA's, it does seem to be something of an exercise in futility.  I do see
the utility of critical on some fields and extensions , but arguing
about it on BasicConstraints and KeyUsage seems overkill.  No?



Thanks,

Bill Middleton







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OICB817512 for ietf-pkix-bks; Mon, 24 Jun 2002 11:12:11 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5OIC9w17508 for <[e-mail]>; Mon, 24 Jun 2002 11:12:09 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Jun 2002 18:11:50 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA01079 for <[e-mail]>; Mon, 24 Jun 2002 14:12:11 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5OIACu00427 for <[e-mail]>; Mon, 24 Jun 2002 14:10:12 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZSB4W>; Mon, 24 Jun 2002 14:12:10 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.31]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZSB44; Mon, 24 Jun 2002 14:12:05 -0400
From: "Housley, Russ" <[e-mail]>
To: Laurence Lundblade <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 24 Jun 2002 14:12:02 -0400
Subject: Re: Basic Constrains and Key Usage processing
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Laurence:

>Continuing on with a cert chain processing implementation I have some 
>questions about BasicConstraints and KeyUsage.
>
>Essentially, is the following correct?
>
>- Assume the cert being processed is not the leaf / end of the chain 
>(i.e., it is trusted for out-of-band reasons or intermediate)
>
>- If BasicConstraints is present, is critical, the CA boolean is true, AND 
>KeyUsage is present, critical and does NOT assert KeyCertSign, then there 
>is an error. (The issuer has erred and made the BasicConstraints and 
>KeyUsage extensions inconsistent).

The path you describe is not valid, but the mistake might not belong to the 
issuer.  The intermediate entity could have two certificates, one for 
validating CRL signatures and one for validating certificate signatures.

>- If the KeyUsage extension is present, is critical and does NOT include 
>KeyCertSign, then there is an error. (The issuer does not intend this cert 
>to be used for signing other certs and is expressing this desire in the 
>KeyUsage extension).

Correct. If the keyCertSign bit is not asserted in a critical KeyUsage 
extension, then the public key cannot be used to validate signatures on 
certificates.

>- If BasicConstraints is present, is critical and the CA boolean is NOT 
>true, then there is an error. (The issuer does not intend this cert to be 
>used for signing other certs and is expressing this desire in the 
>BasicConstraints extension).

Correct.  If the cA bit is not asserted in a critical BasicConstraints 
extension, then the public key cannot be used to validate signatures on 
certificates.

>- There is no error for all other combinations of KeyUsage and 
>BasicConstraints - their presence/absence, their criticality, their values.
>
>It is important that this implementation process cert chains out in the 
>world today (SSL chains in particular) correctly, and the way it seems 
>best to do this is to ignore anything that isn't marked critical.

I am not going to comment about certification paths that do not conform to 
RFC 2459 or RFC 3280.  I think that is what you mean by "out in the world 
today."

>Also, I couldn't find anything in RFC 3280 that requires BasicConstraints 
>to be present if KeyUsage is present. That is the issuer seems to have two 
>ways to indicate that a cert should or should not be used to sign other 
>certs. Is one preferred?

In the discussion of KeyUsage, RFC 3280 says:

       ... If the
       keyCertSign bit is asserted, then the cA bit in the basic
       constraints extension (section 4.2.1.10) MUST also be asserted.

In the discussion of BasicConstraints, RFC 3280 says:

    ... If the cA boolean is not asserted, then the keyCertSign bit in
    the key usage extension MUST NOT be asserted.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OHLhw15326 for ietf-pkix-bks; Mon, 24 Jun 2002 10:21:43 -0700 (PDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OHLUw15308 for <[e-mail]>; Mon, 24 Jun 2002 10:21:42 -0700 (PDT)
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5OHLVxN024137 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 24 Jun 2002 10:21:31 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.82]) by crowley.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5OHLTtn016133 for <[e-mail]>; Mon, 24 Jun 2002 10:21:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 24 Jun 2002 10:14:20 -0700
To: [e-mail]
From: Laurence Lundblade <[e-mail]>
Subject: Basic Constrains and Key Usage processing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Continuing on with a cert chain processing implementation I have some 
questions about BasicConstraints and KeyUsage.

Essentially, is the following correct?

- Assume the cert being processed is not the leaf / end of the chain (i.e., 
it is trusted for out-of-band reasons or intermediate)

- If BasicConstraints is present, is critical, the CA boolean is true, AND 
KeyUsage is present, critical and does NOT assert KeyCertSign, then there 
is an error. (The issuer has erred and made the BasicConstraints and 
KeyUsage extensions inconsistent).

- If the KeyUsage extension is present, is critical and does NOT include 
KeyCertSign, then there is an error. (The issuer does not intend this cert 
to be used for signing other certs and is expressing this desire in the 
KeyUsage extension).

- If BasicConstraints is present, is critical and the CA boolean is NOT 
true, then there is an error. (The issuer does not intend this cert to be 
used for signing other certs and is expressing this desire in the 
BasicConstraints extension).

- There is no error for all other combinations of KeyUsage and 
BasicConstraints - their presence/absence, their criticality, their values.

It is important that this implementation process cert chains out in the 
world today (SSL chains in particular) correctly, and the way it seems best 
to do this is to ignore anything that isn't marked critical.

Also, I couldn't find anything in RFC 3280 that requires BasicConstraints 
to be present if KeyUsage is present. That is the issuer seems to have two 
ways to indicate that a cert should or should not be used to sign other 
certs. Is one preferred?

Thanks, and again hopefully I'm not missing obvious things.

LL



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5L0iYt03332 for ietf-pkix-bks; Thu, 20 Jun 2002 17:44:34 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L0iWn03309 for <[e-mail]>; Thu, 20 Jun 2002 17:44:32 -0700 (PDT)
Received: from [12.159.173.142] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA22862 for <[e-mail]>; Thu, 20 Jun 2002 20:44:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1 (Unverified)
Message-Id: <p05100301b93826d7b4cb@[12.159.173.142]>
Date: Thu, 20 Jun 2002 20:44:48 -0400
To: Pkix <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: slides for Yokohama
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housely wins the award for being the first person to submit a 
copy of his slides for the PKIX meeting that will occur next month in 
Japan.

In expect slides copies from the rest of you slackers very soon :-)


Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KEqEM13021 for ietf-pkix-bks; Thu, 20 Jun 2002 07:52:14 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KEqCn13015 for <[e-mail]>; Thu, 20 Jun 2002 07:52:12 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5KEq8e8063660; Thu, 20 Jun 2002 10:52:08 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5KEq6L122622; Thu, 20 Jun 2002 10:52:06 -0400
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-05.txt
To: Bill Middleton <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 20 Jun 2002 10:52:04 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/20/2002 10:52:06 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Bill:

      Thanks for your comments.  Responses below.

            Tom Gindin

Bill Middleton <[e-mail]>@mail.imc.org on 06/20/2002 10:10:04
AM

Sent by:    [e-mail]


To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail], [e-mail]
Subject:    Re: I-D ACTION:draft-ietf-pkix-pi-05.txt



On Thu, 2002-06-20 at 14:09, Tom Gindin wrote:
>       We are actually adding permanent identifier to GeneralName rather
> than to SubjectAlternativeName, although the expected major use is within
> SubjectAlternativeName.  If any field in a certificate changes, the
> certificate as a whole is considered invalid, so moving this field to a
> separate extension would not make it any more useful.

I'm not convinced that this is the case yet.  It wasn't clear that your
proposal regarded GeneralName from reading it, but even so, what you
propose is quite significant.  A "perennial" or perpetual field in the
certificate _will_ be quite useful, I believe, but perhaps it
does justify it's own extension.  I believe a dedicated extension
would also lend to better interoperability between
CAs, as well, once it's accepted.  I can imagine, however, that
getting a new extension accepted is more challenging, yes?

[TG] I see your point about clarity, since the abstract and the first half
of the introduction make the field sound as if it were intended solely for
use within SubjectAltName.  Section 2 does define it within the GeneralName
structure, but the second sentence of the second paragraph might be better
worded (by replacing "in SubjectAltName" by something more like "whose most
common use is in SubjectAltName").  The abstract could also include a
reference to use of PI in other uses of GeneralName, if it's worthwhile.
The difficulty of getting a new extension accepted is not an issue - get a
new OTHER-NAME form accepted is roughly as difficult.  I don't know why
using a dedicated extension would lead to better interoperability between
CA's than using OTHER-NAME.  The only interoperability advantage which I
can see to a dedicated extension is that it would have its own criticality
flag, but this should be balanced against losing the use of the field for
access control.

>       Also, the syntax of PI does not permit an e-mail address to be
used.
> Of course, it is legal to put an e-mail address into the value field
while
> giving an identifier type, but it would be more natural to use the e-mail
> variant of GeneralName.

If it is legal, then confusion could, and probably will, occur.  That
was my only contention.  That said, the authentication possibilities of
this proposal (embedding permanent username or employee ID numbers) is
especially tantalizing, and I do like the concept, even if a new
extension is not the way to go with it.

[TG] A CA could put an RFC-2253 compliant LDAP form of a DN in a value as
easily as an e-mail address.  That is equally far from our recommended use.
Perhaps we should have given examples of appropriate uses within the draft.

Thanks for your reply, Tom.


Bill





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KEA7911011 for ietf-pkix-bks; Thu, 20 Jun 2002 07:10:07 -0700 (PDT)
Received: from wjm.homelinux.com (213-145-172-14.dd.nextgentel.com [213.145.172.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KEA5n11007 for <[e-mail]>; Thu, 20 Jun 2002 07:10:05 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by wjm.homelinux.com (Postfix) with ESMTP id D3DBC82F83; Thu, 20 Jun 2002 16:10:04 +0200 (CEST)
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-05.txt
From: Bill Middleton <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 20 Jun 2002 16:10:04 +0200
Message-Id: <1024582204.6417.40.camel@wjm>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2002-06-20 at 14:09, Tom Gindin wrote:
>       We are actually adding permanent identifier to GeneralName rather
> than to SubjectAlternativeName, although the expected major use is within
> SubjectAlternativeName.  If any field in a certificate changes, the
> certificate as a whole is considered invalid, so moving this field to a
> separate extension would not make it any more useful.

I'm not convinced that this is the case yet.  It wasn't clear that your 
proposal regarded GeneralName from reading it, but even so, what you
propose is quite significant.  A "perennial" or perpetual field in the
certificate _will_ be quite useful, I believe, but perhaps it 
does justify it's own extension.  I believe a dedicated extension
would also lend to better interoperability between
CAs, as well, once it's accepted.  I can imagine, however, that 
getting a new extension accepted is more challenging, yes?


>       Also, the syntax of PI does not permit an e-mail address to be used.
> Of course, it is legal to put an e-mail address into the value field while
> giving an identifier type, but it would be more natural to use the e-mail
> variant of GeneralName. 

If it is legal, then confusion could, and probably will, occur.  That
was my only contention.  That said, the authentication possibilities of 
this proposal (embedding permanent username or employee ID numbers) is 
especially tantalizing, and I do like the concept, even if a new
extension is not the way to go with it.


Thanks for your reply, Tom.


Bill




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KCARb06631 for ietf-pkix-bks; Thu, 20 Jun 2002 05:10:27 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KCAPn06627 for <[e-mail]>; Thu, 20 Jun 2002 05:10:25 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5KC9ke8028628; Thu, 20 Jun 2002 08:09:46 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5KC9iL40096; Thu, 20 Jun 2002 08:09:44 -0400
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-05.txt
To: Bill Middleton <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 20 Jun 2002 08:09:47 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/20/2002 08:09:44 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Bill:

      We are actually adding permanent identifier to GeneralName rather
than to SubjectAlternativeName, although the expected major use is within
SubjectAlternativeName.  If any field in a certificate changes, the
certificate as a whole is considered invalid, so moving this field to a
separate extension would not make it any more useful.  In the current
draft, we try to point out several uses.  The non-repudiation and audit
uses are essentially similar, and would probably work equally well no
matter where a PI was put in the certificate.  The access control use uses
this field to represent a user, and putting PI into GeneralName permits an
access control subsystem to use GeneralName to represent a user, using PI
when desired and some other GeneralName form such as DN or E-mail when PI
is not desired.
      Also, the syntax of PI does not permit an e-mail address to be used.
Of course, it is legal to put an e-mail address into the value field while
giving an identifier type, but it would be more natural to use the e-mail
variant of GeneralName. Our expectation for typical PI's not issued by the
CA is that the most common values will be ID's already assigned to a user
by the organization responsible for the value in IdentifierType such as
account ID's, employee ID's, citizen ID's (a large fraction of the
discussion centered on these), and the like.

            Tom Gindin


Bill Middleton <[e-mail]>@mail.imc.org on 06/19/2002 09:19:49
PM

Sent by:    [e-mail]


To:    [e-mail]
cc:    [e-mail]
Subject:    Re: I-D ACTION:draft-ietf-pkix-pi-05.txt



Hello list members.  I join your company as a X.509 neophyte,
but with high hopes to learn more, and possibly say something
sensible, eventually.

To that end, in this reply, I'd like to raise a couple
of issues with the announcement/proposal below, partially edited:

On Tue, 2002-06-18 at 13:27, [e-mail] wrote:
> This document define a new form of name, called permanent
> identifier, that may be included in the subjectAltName extension
> of a public key certificate issued to an entity.
> The permanent identifier is an optional feature that may be used
> by a CA to indicate that the certificate relates to the same
> entity even if the name or the affiliation of that entity stored
> in the subject or another name form in the subjectAltName extension
> has changed.

I can see a certain motivation for this, of course, especially
in the case of a marriage-related name-change.  However, I
submit that this proposal will ambiguate (or be ambiguated by)
the currently acceptable and practiced subjectAltName
values.  What if, for example, the permanent
identifier is to be an email address?  Perhaps thats not the
best argument against it, but the currently-defined uses
and intents for subjectAltName seem to me to
preclude its use as a perpetual entity.

If the CA wishes to give the possibility of perpetuity in the
face of altering the Subject DN, then the CA should
encode the  identifier in a DN component which they
will not allow to be changed, yes?

Regards,

Bill Middleton
[e-mail]









Received: by above.proper.com (8.11.6/8.11.3) id g5K1K0G17595 for ietf-pkix-bks; Wed, 19 Jun 2002 18:20:00 -0700 (PDT)
Received: from wjm.homelinux.com (213-145-172-14.dd.nextgentel.com [213.145.172.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K1Jvn17591 for <[e-mail]>; Wed, 19 Jun 2002 18:19:58 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by wjm.homelinux.com (Postfix) with ESMTP id AC03F82F83; Thu, 20 Jun 2002 03:19:49 +0200 (CEST)
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-05.txt
From: Bill Middleton <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 20 Jun 2002 03:19:49 +0200
Message-Id: <1024535989.6416.22.camel@wjm>
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello list members.  I join your company as a X.509 neophyte,
but with high hopes to learn more, and possibly say something
sensible, eventually.

To that end, in this reply, I'd like to raise a couple
of issues with the announcement/proposal below, partially edited:

On Tue, 2002-06-18 at 13:27, [e-mail] wrote:
> This document define a new form of name, called permanent 
> identifier, that may be included in the subjectAltName extension 
> of a public key certificate issued to an entity.
> The permanent identifier is an optional feature that may be used 
> by a CA to indicate that the certificate relates to the same 
> entity even if the name or the affiliation of that entity stored 
> in the subject or another name form in the subjectAltName extension 
> has changed.

I can see a certain motivation for this, of course, especially
in the case of a marriage-related name-change.  However, I 
submit that this proposal will ambiguate (or be ambiguated by)
the currently acceptable and practiced subjectAltName 
values.  What if, for example, the permanent 
identifier is to be an email address?  Perhaps thats not the
best argument against it, but the currently-defined uses
and intents for subjectAltName seem to me to
preclude its use as a perpetual entity.

If the CA wishes to give the possibility of perpetuity in the 
face of altering the Subject DN, then the CA should 
encode the  identifier in a DN component which they 
will not allow to be changed, yes?

Regards,

Bill Middleton
[e-mail]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IK01t15043 for ietf-pkix-bks; Tue, 18 Jun 2002 13:00:01 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IK00n15026 for <[e-mail]>; Tue, 18 Jun 2002 13:00:00 -0700 (PDT)
Received: from mail4.magma.ca (mail4.magma.ca [206.191.0.222]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g5IK0HRH019626; Tue, 18 Jun 2002 16:00:18 -0400 (EDT)
Received: from asturgeonpc (ottawa-dial-64-26-139-212.d-ip.magma.ca [64.26.139.212]) by mail4.magma.ca (Magma's Mail Server) with SMTP id g5IJxs2J022297; Tue, 18 Jun 2002 15:59:55 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: draft-ietf-pkix-warranty-extn-01
Date: Tue, 18 Jun 2002 16:10:17 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello folks,

Further to my note to this list yesterday - On further reflection, I think
that my previous proposed text may not be the best way to proceed.  In this
message, I offer an alternative.  This may be preferable because it allows
CAs to offer basic per-transaction protection, yet it does not prevent this
protection from being augmented by a transaction specific insurance policy
when it is needed.

Rather than moving the text from the third paragraph of section 2 to the
Introduction, I suggest leaving the text in section 2 as it is, but add the
following to the Introduction, at the end of the third paragraph:
[EXISTING TEXT]"Alternatively a CA may provide extended liability coverage
for the use of the certificate.  Usually, the subscriber pays for the
extended warranty coverage.  In turn, subscribers are covered by an
appropriately drafted insurance policy.  The certificate warranty is backed
by an insurance policy issued by a licensed insurance company, which results
in a financial backing that is far greater than that of the CA.  This extra
financial backing provides a further element of confidence necessary to
encourage the use of certificates in commerce.
[REVISED TEXT:]  A relying party may obtain compensation from a CA depending
on the conditions for such compensation expressed in either the CA's
Certificate Policy or the CA's insurance policy, or both.  Where the relying
party is also a subscriber to the CA, then the terms and conditions of the
insurance policy cover the relying party.  When the relying party is not a
subscriber to the CA, however, then the relying party is likely to seek
compensation from the subscriber in the event of harm resulting from relying
on a certificate.  If the subscriber cannot provide compensation, then the
relying party is likely to turn to the CA for compensation.  Evidence of an
extended warranty, provided through the certificate extension, will give the
relying party confidence that compensation is possible, and will therefore
enhance trust in the process.  Risk for a non-subscriber relying party may
be reduced by the presence of a warranty extension with an explicit warranty
stated.  The warranty extension allows this aspect of risk management to be
automated.  There are different warranty models.  As described in section 2,
this certificate extension provides a mechanism for the aggregated model and
the per-transaction model, as a base; if the value of the base is exceeded,
then the relying party may either seek additional coverage or accept the
difference as residual (and known) risk."


Alice


Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IJxMH15009 for ietf-pkix-bks; Tue, 18 Jun 2002 12:59:22 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IJxLn15005 for <[e-mail]>; Tue, 18 Jun 2002 12:59:21 -0700 (PDT)
Received: from Chokhani ([12.91.133.10]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020618195915.FNZF19182.mtiwmhc21.worldnet.att.net@Chokhani>; Tue, 18 Jun 2002 19:59:15 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Christopher S. Francis'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Attribute Certificate Policy
Date: Tue, 18 Jun 2002 16:00:35 -0400
Message-ID: <008501c21702$cf9f9230$8700a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The old RFC is 2527.  The new one is about to get an RFC number (may
already have one), but is on PKIX web page as ID

-----Original Message-----
From: Christopher S. Francis [mailto:[e-mail]] 
Sent: Tuesday, June 18, 2002 3:49 PM
To: Santosh Chokhani; 'Housley, Russ'
Cc: [e-mail]
Subject: RE: Attribute Certificate Policy


Can someone please point me to the location of the "CP and CPS
Framework"?  

Is this part of X.509 or is it in a separate document.  I'm looking at
X.509 now and I'm not finding it.  I've seen ANSI X9.79-1 (PKI Practices
and Policy Framework).  Is that what you're talking about?

Chris
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Santosh Chokhani
Sent: Tuesday, June 18, 2002 1:23 PM
To: 'Housley, Russ'
Cc: [e-mail]
Subject: RE: Attribute Certificate Policy


Russ:

I agree that the addition will be straightforward.  I think it will be
more than few sentences though depending on the guidance we want to give
in the areas of validating the privileges (attributes) and conditions
under which they should be revoked.  The good news is that it does not
impact most of the technical and non-technical security controls.  But,
it may also impact the Legal Sections also.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, June 18, 2002 8:50 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Attribute Certificate Policy


Santosh:

This is a good point, but it would be a very straightforward addition.
In fact, given the current existence of subjectDirectoryAttributes, it
should probably be included now.

Russ


At 06:04 PM 6/17/2002 -0400, Santosh Chokhani wrote:
>Russ:
>
>Also, the CP and CPS Framework does not address the issues surrounding 
>validating and revoking the attributes.  It is very much identity 
>oriented.
>
>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]]
>On Behalf Of Housley, Russ
>Sent: Monday, June 17, 2002 2:15 PM
>To: [e-mail]; [e-mail]
>Cc: pkix
>Subject: Re: Attribute Certificate Policy
>
>
>
>All:
>
>Sharon pointed me to the part of X.509 that prohibits the use of the 
>certificatePolicies extension in attribute certificates.  I would 
>rather
>
>work with the X.509 community to remove this restriction than define a 
>new extension with the same syntax and semantics.
>
>Russ
>
>
> >> > I really dislike this draft.  Since it is written by two people 
> >> > that I respect, I feel obligated to voice my concerns.
> >>
> >> > If I wrote down everything that causes me concern in this draft, 
> >> > then the resulting message would be longer than the draft itself.

> >> > For this reason, I will stick to the major concerns.
> >>
> >> > MAJOR CONCERN 1
> >>
> >> > I see no value in adding a acPolicies extension to a PKC that 
> >> > includes the subjectDirectoryAttributes extension.  The current 
> >> > policy extension
> >> already
> >> > handles the whole PKC, including the content of the 
> >> > subjectDirectoryAttributes extension.  Two policy-related 
> >> > extensions in a single PKC provides no value to the replying 
> >> > party.
> >>
> >>I would agree that this is debatable. Attributes contained in PKCs 
> >>MUST be verified at the time of registration, but nothing would 
> >>prevent a CA to do more and to revoke a PKC if an attribute is no 
> >>more
>
> >>correct. This could be in the CP and the CPS may it is not directly 
> >>machine readable. Hence why it might be interresting to say more. An

> >>alternative would be for PKCs to keep the CP extension but to allow 
> >>to
>
> >>support more qualifiers.
> >
> >There seem to be three cases to discuss:
> >         a)  the attribute is long-lived and unlikely to change,
> >         b)  the attribute is long-lived and likely to change, and
> >         c)  the attribute is short-lived.
> >
> >I think that your reply only addresses the first case (a).  I assume 
> >that short validity periods will be used when the attribute fits into

> >one of
>
> >the other two cases (b and c).
> >
> >So, in the first case, you are using a policy qualifier (yuck) to 
> >tell the relying party that the issuer does not expect the attribute 
> >to change
>but
> >that periodic checks will be made just to make sure that everything 
> >is
>as
> >expected.  If an unexpected condition is discovered, then the
>certificate
> >will be revoked.  I find it hard to believe that the same frequency
>will
> >be needed for each attribute that might appear in the 
> >subjectDirectoryAttributes extension.
> >
> >> > MAJOR CONCERN 2
> >>
> >> > Why define a new extension?  Why not simply include the
> >> certificatePolicies
> >> > extension in an attribute certificate?  The two extensions have
> >> exactly the
> >> > same syntax.  I believe that they have the same semantics too.
> >>
> >>Not exactly. As indicated above, attributes contained in PKCs MUST 
> >>be verified at the time of registration, but nothing would prevent a

> >>CA to do more and to revoke a PKC if an attribute is no more 
> >>correct. This information is certainly of some interest for a 
> >>relying party. The AA should have a way to indicate this, but since 
> >>an AC does not contain a CP extension, this is the reason why a new 
> >>extension has been created.
> >
> >I see nothing in X.509 that prohibits the use of the 
> >certificatePolicies extension in an attribute certificate. (There is 
> >one place where it
>says
> >"CA", but if that were replaced with "issuer".)  Maybe I missed
>something ...
> >
> >> > MAJOR CONCERN 3
> >> >
> >> > Why do we need more qualifiers?  The draft RECOMMENDS that policy

> >> > information consist of an object identifier, then it defines a 
> >> > pile
>
> >> > of qualifiers.  Further, the information that is contained in the

> >> > qualifiers is of very little interest to the relying party.  It 
> >> > is useful to the issuer.  Why can't the issuer keep this 
> >> > information in a private database.  Everything that the issuer 
> >> > knows about the subject/holder need not appear in the 
> >> > certificate.
> >>
> >>As indicated above, it is useful for relying parties that may get 
> >>more
>
> >>information, e.g. confidence about the freshness of the attributes.
> >
> >I do not see it.  You are saying that the relying party will reject 
> >an attribute certificate in the following situation:
> >
> >         1)  the AA has a valid PKC
> >         2)  the subject has a valid PKC
> >         3)  the subject has a valid AC
> >         4)  the AC was issued under an acceptable policy
> >         5)  the AC policy qualifier indicates periodic checks that
> >                 are weekly, but the relying party would like more
> >                 frequent checks
> >
> >X.509 says:
> >
> >         The optional qualifiers are not used in the certification 
> > path processing
> >         procedure, but relevant qualifiers are provided as an output
>of
> > that process
> >         to the certificate using application to assist in 
> > determining whether a valid
> >         path is appropriate for the particular transaction.
> >
> >RFC 3280 says:
> >
> >         Optional qualifiers, which MAY be present, are not expected 
> > to
>change
> >         the definition of the policy.
> >
> >Your use of qualifier does meet the limits imposed by these 
> >documents; however, I think that there is a mismatch between the 
> >single value in
>the
> >policy qualifier and the potential for more than one attribute in the

> >subjectDirectoryAttributes extension or the AC.
> >
> >Using separate ACs for each attribute would solve this problem, but 
> >that seems to impose way too much overhead and complexity.
> >
> >>  > MAJOR CONCERN 4
> >> >
> >> > Can we use the AuthorityInfoAccess extension to point to the 
> >> > issuer's repository?  I think it would be straightforward to 
> >> > define
>
> >> > an access
> >> method
> >> > that meets this objective.  Perhaps this is a matter of taste, 
> >> > but it
> >> seems
> >> > to meet the stated requirement of providing a pointer to the 
> >> > issuer's repository that otherwise requires the information to be

> >> > extracted
> >> from the
> >> > CP or CPS.
> >>
> >>RFC 3280 states:
> >>
> >>    The authority information access extension indicates how to 
> >> access
>CA
> >>    information and services for the issuer of the certificate in
>which
> >>    the extension appears.
> >>
> >>I do not consider an AA to be a CA and I would not like that we 
> >>introduce some confusion between a CA and an AA, hence why this 
> >>extension has not been created. From RFC 3281: Attribute Authority, 
> >>the entity that issues the AC, synonymous in this specification with

> >>"AC issuer".
> >
> >An AA is not a CA.  In fact, RFC 3281 says that they are not allowed 
> >to have the same distinguished name.
> >
> >Perhaps I am misunderstanding this whole section of the document, by 
> >I thought that you want a URI that points to the issuer's repository.
>The
> >justification provided is that you want to be able to pass a pointer 
> >to
>
> >the certificate (either PKC or AC) rather than pass the certificate 
> >itself.  Clearly, the certificate is already available to the to
>extract
> >the URI in the first place.
> >
> >> > MAJOR CONCERN 5
> >> >
> >> > The PKIX working group does not assign object identifiers in the 
> >> > id-ce arc.  This are is owned by the editor of X.509.
> >> >
> >> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29
}
> >>
> >>Thanks. Nobody is perfect.
> >
> >I certainly make mistakes too.  That is why I value peer review.
> >
> >> > MAJOR CONCERN 6
> >> >
> >> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in 
> >> > this
>
> >> > document.  The closest that I could find is a requirement that 
> >> > the AA
> >> "make
> >> > sure that the policy applies to all the attributes."  Without 
> >> > appropriate MUST statements, I do not see how a useful service is

> >> > being provided
> >> to the
> >> > replying party.
> >>
> >>It is the very first draft, so yet unpolished.
> >
> >Apparently sharing my first four major concerns has not altered your 
> >thinking. So, we can expect a second draft with little change?
> >
> >Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IJmpX14790 for ietf-pkix-bks; Tue, 18 Jun 2002 12:48:51 -0700 (PDT)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IJmon14786 for <[e-mail]>; Tue, 18 Jun 2002 12:48:50 -0700 (PDT)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id PAA31374; Tue, 18 Jun 2002 15:48:39 -0400
From: "Christopher S. Francis" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 18 Jun 2002 19:48:39 UT
Subject: RE: Attribute Certificate Policy
Date: Tue, 18 Jun 2002 15:48:39 -0400
MIME-Version: 1.0
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0079_01C216DF.97C9D460"
Importance: Normal
In-Reply-To: <004001c216ec$be5af480$8700a8c0@Chokhani>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0079_01C216DF.97C9D460
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Can someone please point me to the location of the "CP and CPS
Framework"?  

Is this part of X.509 or is it in a separate document.  I'm looking at
X.509 now and I'm not finding it.  I've seen ANSI X9.79-1 (PKI Practices
and Policy Framework).  Is that what you're talking about?

Chris
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Santosh Chokhani
Sent: Tuesday, June 18, 2002 1:23 PM
To: 'Housley, Russ'
Cc: [e-mail]
Subject: RE: Attribute Certificate Policy


Russ:

I agree that the addition will be straightforward.  I think it will be
more than few sentences though depending on the guidance we want to give
in the areas of validating the privileges (attributes) and conditions
under which they should be revoked.  The good news is that it does not
impact most of the technical and non-technical security controls.  But,
it may also impact the Legal Sections also.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, June 18, 2002 8:50 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Attribute Certificate Policy


Santosh:

This is a good point, but it would be a very straightforward addition.
In
fact, given the current existence of subjectDirectoryAttributes, it
should
probably be included now.

Russ


At 06:04 PM 6/17/2002 -0400, Santosh Chokhani wrote:
>Russ:
>
>Also, the CP and CPS Framework does not address the issues surrounding
>validating and revoking the attributes.  It is very much identity
>oriented.
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]
>On Behalf Of Housley, Russ
>Sent: Monday, June 17, 2002 2:15 PM
>To: [e-mail]; [e-mail]
>Cc: pkix
>Subject: Re: Attribute Certificate Policy
>
>
>
>All:
>
>Sharon pointed me to the part of X.509 that prohibits the use of the
>certificatePolicies extension in attribute certificates.  I would
>rather
>
>work with the X.509 community to remove this restriction than define a
>new extension with the same syntax and semantics.
>
>Russ
>
>
> >> > I really dislike this draft.  Since it is written by two people
> >> > that I respect, I feel obligated to voice my concerns.
> >>
> >> > If I wrote down everything that causes me concern in this draft,
> >> > then the resulting message would be longer than the draft itself.

> >> > For this reason, I will stick to the major concerns.
> >>
> >> > MAJOR CONCERN 1
> >>
> >> > I see no value in adding a acPolicies extension to a PKC that
> >> > includes the subjectDirectoryAttributes extension.  The current
> >> > policy extension
> >> already
> >> > handles the whole PKC, including the content of the
> >> > subjectDirectoryAttributes extension.  Two policy-related
> >> > extensions in a single PKC provides no value to the replying
> >> > party.
> >>
> >>I would agree that this is debatable. Attributes contained in PKCs
> >>MUST be verified at the time of registration, but nothing would
> >>prevent a CA to do more and to revoke a PKC if an attribute is no
> >>more
>
> >>correct. This could be in the CP and the CPS may it is not directly
> >>machine readable. Hence why it might be interresting to say more. An

> >>alternative would be for PKCs to keep the CP extension but to allow
> >>to
>
> >>support more qualifiers.
> >
> >There seem to be three cases to discuss:
> >         a)  the attribute is long-lived and unlikely to change,
> >         b)  the attribute is long-lived and likely to change, and
> >         c)  the attribute is short-lived.
> >
> >I think that your reply only addresses the first case (a).  I assume
> >that short validity periods will be used when the attribute fits into

> >one of
>
> >the other two cases (b and c).
> >
> >So, in the first case, you are using a policy qualifier (yuck) to
> >tell the relying party that the issuer does not expect the attribute
> >to change
>but
> >that periodic checks will be made just to make sure that everything
> >is
>as
> >expected.  If an unexpected condition is discovered, then the
>certificate
> >will be revoked.  I find it hard to believe that the same frequency
>will
> >be needed for each attribute that might appear in the
> >subjectDirectoryAttributes extension.
> >
> >> > MAJOR CONCERN 2
> >>
> >> > Why define a new extension?  Why not simply include the
> >> certificatePolicies
> >> > extension in an attribute certificate?  The two extensions have
> >> exactly the
> >> > same syntax.  I believe that they have the same semantics too.
> >>
> >>Not exactly. As indicated above, attributes contained in PKCs MUST
> >>be verified at the time of registration, but nothing would prevent a

> >>CA to do more and to revoke a PKC if an attribute is no more
> >>correct. This information is certainly of some interest for a
> >>relying party. The AA should have a way to indicate this, but since
> >>an AC does not contain a CP extension, this is the reason why a new
> >>extension has been created.
> >
> >I see nothing in X.509 that prohibits the use of the
> >certificatePolicies extension in an attribute certificate. (There is
> >one place where it
>says
> >"CA", but if that were replaced with "issuer".)  Maybe I missed
>something ...
> >
> >> > MAJOR CONCERN 3
> >> >
> >> > Why do we need more qualifiers?  The draft RECOMMENDS that policy
> >> > information consist of an object identifier, then it defines a
> >> > pile
>
> >> > of qualifiers.  Further, the information that is contained in the
> >> > qualifiers is of very little interest to the relying party.  It
> >> > is useful to the issuer.  Why can't the issuer keep this
> >> > information in a private database.  Everything that the issuer
> >> > knows about the subject/holder need not appear in the
> >> > certificate.
> >>
> >>As indicated above, it is useful for relying parties that may get
> >>more
>
> >>information, e.g. confidence about the freshness of the attributes.
> >
> >I do not see it.  You are saying that the relying party will reject
> >an attribute certificate in the following situation:
> >
> >         1)  the AA has a valid PKC
> >         2)  the subject has a valid PKC
> >         3)  the subject has a valid AC
> >         4)  the AC was issued under an acceptable policy
> >         5)  the AC policy qualifier indicates periodic checks that
> >                 are weekly, but the relying party would like more
> >                 frequent checks
> >
> >X.509 says:
> >
> >         The optional qualifiers are not used in the certification
> > path processing
> >         procedure, but relevant qualifiers are provided as an output
>of
> > that process
> >         to the certificate using application to assist in
> > determining whether a valid
> >         path is appropriate for the particular transaction.
> >
> >RFC 3280 says:
> >
> >         Optional qualifiers, which MAY be present, are not expected
> > to
>change
> >         the definition of the policy.
> >
> >Your use of qualifier does meet the limits imposed by these
> >documents; however, I think that there is a mismatch between the
> >single value in
>the
> >policy qualifier and the potential for more than one attribute in the
> >subjectDirectoryAttributes extension or the AC.
> >
> >Using separate ACs for each attribute would solve this problem, but
> >that seems to impose way too much overhead and complexity.
> >
> >>  > MAJOR CONCERN 4
> >> >
> >> > Can we use the AuthorityInfoAccess extension to point to the
> >> > issuer's repository?  I think it would be straightforward to
> >> > define
>
> >> > an access
> >> method
> >> > that meets this objective.  Perhaps this is a matter of taste,
> >> > but it
> >> seems
> >> > to meet the stated requirement of providing a pointer to the
> >> > issuer's repository that otherwise requires the information to be

> >> > extracted
> >> from the
> >> > CP or CPS.
> >>
> >>RFC 3280 states:
> >>
> >>    The authority information access extension indicates how to
> >> access
>CA
> >>    information and services for the issuer of the certificate in
>which
> >>    the extension appears.
> >>
> >>I do not consider an AA to be a CA and I would not like that we
> >>introduce some confusion between a CA and an AA, hence why this
> >>extension has not been created. From RFC 3281: Attribute Authority,
> >>the entity that issues the AC, synonymous in this specification with

> >>"AC issuer".
> >
> >An AA is not a CA.  In fact, RFC 3281 says that they are not allowed
> >to have the same distinguished name.
> >
> >Perhaps I am misunderstanding this whole section of the document, by
> >I thought that you want a URI that points to the issuer's repository.
>The
> >justification provided is that you want to be able to pass a pointer
> >to
>
> >the certificate (either PKC or AC) rather than pass the certificate
> >itself.  Clearly, the certificate is already available to the to
>extract
> >the URI in the first place.
> >
> >> > MAJOR CONCERN 5
> >> >
> >> > The PKIX working group does not assign object identifiers in the
> >> > id-ce arc.  This are is owned by the editor of X.509.
> >> >
> >> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29
}
> >>
> >>Thanks. Nobody is perfect.
> >
> >I certainly make mistakes too.  That is why I value peer review.
> >
> >> > MAJOR CONCERN 6
> >> >
> >> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in
> >> > this
>
> >> > document.  The closest that I could find is a requirement that
> >> > the AA
> >> "make
> >> > sure that the policy applies to all the attributes."  Without
> >> > appropriate MUST statements, I do not see how a useful service is

> >> > being provided
> >> to the
> >> > replying party.
> >>
> >>It is the very first draft, so yet unpolished.
> >
> >Apparently sharing my first four major concerns has not altered your
> >thinking. So, we can expect a second draft with little change?
> >
> >Russ

------=_NextPart_000_0079_01C216DF.97C9D460
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKLDCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy
MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL
uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj
zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw
RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t
L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD
gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h
U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1
E3LnQDGa07LEq+dWvovj+xUwggSBMIID6qADAgECAhBL+Lru2gVCM7zbuuZ1D4mXMA0GCSqGSIb3
DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ
bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAxMTAwMDAw
MFoXDTAyMTAxMTIzNTk1OVowggElMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs
bCBTZXJ2aWNlMRwwGgYDVQQDFBNDaHJpc3RvcGhlciBGcmFuY2lzMS0wKwYJKoZIhvcNAQkBFh5j
aHJpcy5mcmFuY2lzQHdldHN0b25ldGVjaC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
ANg3xsY0J0sn5rrCxNPxU+tqjuCcsuRrht/7D8CmFRQgDJqowNr/0+BrCmFExVHoz5eYDdA3NVG0
9K7EJvHvCciaH5nzYGQj04wNgm1x1fptc+SUJItl0ukdCARLtTx5rK8IxJMffZ5/xqDMdTjqMNd2
u4rGNVKe68hy9BlExOZtAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4G
C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE
BAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy
bDANBgkqhkiG9w0BAQQFAAOBgQAtCSiygnhDGR2g2YqPjjvz3i3hrjl5g1uDOL/sW5zT8QSeOVUR
xzsEafMzvo/oYbM14vh55u+/3e+VJVghAyB0Y5Eszltz/+JXGON8548hT4r6xGPWjT91IZNo/ZEn
UQdCUyCbOJ1IJLkiKDd3PBL029KfQ/6L+BFzYeZT02OmtDGCAzgwggM0AgEBMIHhMIHMMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj
cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBL+Lru2gVCM7zbuuZ1D4mXMAkGBSsOAwIaBQCg
ggGsMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDYxODE5NDgy
OVowIwYJKoZIhvcNAQkEMRYEFAnUyBT/N1xi7Un+phl6vQg08IB/MFgGCSqGSIb3DQEJDzFLMEkw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO
AwIaMAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy
aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw
RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25h
IE5vdCBWYWxpZGF0ZWQCEEv4uu7aBUIzvNu65nUPiZcwDQYJKoZIhvcNAQEBBQAEgYB7AYku7thO
EADkhZPZc9X/gF3XLjezvK94+01xblJB2zAJwJ9k+D/6eF1os4FFwaPxPmjGHjB/XjGP7ngrqzz1
SyQMFQfOJ09/HE/PMzdBpy9amekVO8eS7hlHBaQw/I+F8f7lclO1Dl1GbOsCB6lt1JDaKXl6Vai2
8ODm61dTpAAAAAAAAA==

------=_NextPart_000_0079_01C216DF.97C9D460--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IHLQi06025 for ietf-pkix-bks; Tue, 18 Jun 2002 10:21:26 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IHLPn06021 for <[e-mail]>; Tue, 18 Jun 2002 10:21:25 -0700 (PDT)
Received: from Chokhani ([12.91.133.202]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020618172116.JKXX5116.mtiwmhc23.worldnet.att.net@Chokhani>; Tue, 18 Jun 2002 17:21:16 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Attribute Certificate Policy
Date: Tue, 18 Jun 2002 13:22:37 -0400
Message-ID: <004001c216ec$be5af480$8700a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

I agree that the addition will be straightforward.  I think it will be
more than few sentences though depending on the guidance we want to give
in the areas of validating the privileges (attributes) and conditions
under which they should be revoked.  The good news is that it does not
impact most of the technical and non-technical security controls.  But,
it may also impact the Legal Sections also.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Tuesday, June 18, 2002 8:50 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Attribute Certificate Policy


Santosh:

This is a good point, but it would be a very straightforward addition.
In 
fact, given the current existence of subjectDirectoryAttributes, it
should 
probably be included now.

Russ


At 06:04 PM 6/17/2002 -0400, Santosh Chokhani wrote:
>Russ:
>
>Also, the CP and CPS Framework does not address the issues surrounding
>validating and revoking the attributes.  It is very much identity 
>oriented.
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]
>On Behalf Of Housley, Russ
>Sent: Monday, June 17, 2002 2:15 PM
>To: [e-mail]; [e-mail]
>Cc: pkix
>Subject: Re: Attribute Certificate Policy
>
>
>
>All:
>
>Sharon pointed me to the part of X.509 that prohibits the use of the
>certificatePolicies extension in attribute certificates.  I would 
>rather
>
>work with the X.509 community to remove this restriction than define a
>new extension with the same syntax and semantics.
>
>Russ
>
>
> >> > I really dislike this draft.  Since it is written by two people
> >> > that I respect, I feel obligated to voice my concerns.
> >>
> >> > If I wrote down everything that causes me concern in this draft,
> >> > then the resulting message would be longer than the draft itself.

> >> > For this reason, I will stick to the major concerns.
> >>
> >> > MAJOR CONCERN 1
> >>
> >> > I see no value in adding a acPolicies extension to a PKC that
> >> > includes the subjectDirectoryAttributes extension.  The current 
> >> > policy extension
> >> already
> >> > handles the whole PKC, including the content of the
> >> > subjectDirectoryAttributes extension.  Two policy-related 
> >> > extensions in a single PKC provides no value to the replying 
> >> > party.
> >>
> >>I would agree that this is debatable. Attributes contained in PKCs
> >>MUST be verified at the time of registration, but nothing would 
> >>prevent a CA to do more and to revoke a PKC if an attribute is no 
> >>more
>
> >>correct. This could be in the CP and the CPS may it is not directly
> >>machine readable. Hence why it might be interresting to say more. An

> >>alternative would be for PKCs to keep the CP extension but to allow 
> >>to
>
> >>support more qualifiers.
> >
> >There seem to be three cases to discuss:
> >         a)  the attribute is long-lived and unlikely to change,
> >         b)  the attribute is long-lived and likely to change, and
> >         c)  the attribute is short-lived.
> >
> >I think that your reply only addresses the first case (a).  I assume
> >that short validity periods will be used when the attribute fits into

> >one of
>
> >the other two cases (b and c).
> >
> >So, in the first case, you are using a policy qualifier (yuck) to
> >tell the relying party that the issuer does not expect the attribute 
> >to change
>but
> >that periodic checks will be made just to make sure that everything
> >is
>as
> >expected.  If an unexpected condition is discovered, then the
>certificate
> >will be revoked.  I find it hard to believe that the same frequency
>will
> >be needed for each attribute that might appear in the
> >subjectDirectoryAttributes extension.
> >
> >> > MAJOR CONCERN 2
> >>
> >> > Why define a new extension?  Why not simply include the
> >> certificatePolicies
> >> > extension in an attribute certificate?  The two extensions have
> >> exactly the
> >> > same syntax.  I believe that they have the same semantics too.
> >>
> >>Not exactly. As indicated above, attributes contained in PKCs MUST
> >>be verified at the time of registration, but nothing would prevent a

> >>CA to do more and to revoke a PKC if an attribute is no more 
> >>correct. This information is certainly of some interest for a 
> >>relying party. The AA should have a way to indicate this, but since 
> >>an AC does not contain a CP extension, this is the reason why a new 
> >>extension has been created.
> >
> >I see nothing in X.509 that prohibits the use of the
> >certificatePolicies extension in an attribute certificate. (There is 
> >one place where it
>says
> >"CA", but if that were replaced with "issuer".)  Maybe I missed
>something ...
> >
> >> > MAJOR CONCERN 3
> >> >
> >> > Why do we need more qualifiers?  The draft RECOMMENDS that policy
> >> > information consist of an object identifier, then it defines a 
> >> > pile
>
> >> > of qualifiers.  Further, the information that is contained in the
> >> > qualifiers is of very little interest to the relying party.  It 
> >> > is useful to the issuer.  Why can't the issuer keep this 
> >> > information in a private database.  Everything that the issuer 
> >> > knows about the subject/holder need not appear in the 
> >> > certificate.
> >>
> >>As indicated above, it is useful for relying parties that may get
> >>more
>
> >>information, e.g. confidence about the freshness of the attributes.
> >
> >I do not see it.  You are saying that the relying party will reject
> >an attribute certificate in the following situation:
> >
> >         1)  the AA has a valid PKC
> >         2)  the subject has a valid PKC
> >         3)  the subject has a valid AC
> >         4)  the AC was issued under an acceptable policy
> >         5)  the AC policy qualifier indicates periodic checks that
> >                 are weekly, but the relying party would like more
> >                 frequent checks
> >
> >X.509 says:
> >
> >         The optional qualifiers are not used in the certification
> > path processing
> >         procedure, but relevant qualifiers are provided as an output
>of
> > that process
> >         to the certificate using application to assist in
> > determining whether a valid
> >         path is appropriate for the particular transaction.
> >
> >RFC 3280 says:
> >
> >         Optional qualifiers, which MAY be present, are not expected
> > to
>change
> >         the definition of the policy.
> >
> >Your use of qualifier does meet the limits imposed by these
> >documents; however, I think that there is a mismatch between the 
> >single value in
>the
> >policy qualifier and the potential for more than one attribute in the
> >subjectDirectoryAttributes extension or the AC.
> >
> >Using separate ACs for each attribute would solve this problem, but
> >that seems to impose way too much overhead and complexity.
> >
> >>  > MAJOR CONCERN 4
> >> >
> >> > Can we use the AuthorityInfoAccess extension to point to the
> >> > issuer's repository?  I think it would be straightforward to 
> >> > define
>
> >> > an access
> >> method
> >> > that meets this objective.  Perhaps this is a matter of taste,
> >> > but it
> >> seems
> >> > to meet the stated requirement of providing a pointer to the
> >> > issuer's repository that otherwise requires the information to be

> >> > extracted
> >> from the
> >> > CP or CPS.
> >>
> >>RFC 3280 states:
> >>
> >>    The authority information access extension indicates how to
> >> access
>CA
> >>    information and services for the issuer of the certificate in
>which
> >>    the extension appears.
> >>
> >>I do not consider an AA to be a CA and I would not like that we
> >>introduce some confusion between a CA and an AA, hence why this 
> >>extension has not been created. From RFC 3281: Attribute Authority, 
> >>the entity that issues the AC, synonymous in this specification with

> >>"AC issuer".
> >
> >An AA is not a CA.  In fact, RFC 3281 says that they are not allowed
> >to have the same distinguished name.
> >
> >Perhaps I am misunderstanding this whole section of the document, by
> >I thought that you want a URI that points to the issuer's repository.
>The
> >justification provided is that you want to be able to pass a pointer
> >to
>
> >the certificate (either PKC or AC) rather than pass the certificate
> >itself.  Clearly, the certificate is already available to the to
>extract
> >the URI in the first place.
> >
> >> > MAJOR CONCERN 5
> >> >
> >> > The PKIX working group does not assign object identifiers in the
> >> > id-ce arc.  This are is owned by the editor of X.509.
> >> >
> >> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29
}
> >>
> >>Thanks. Nobody is perfect.
> >
> >I certainly make mistakes too.  That is why I value peer review.
> >
> >> > MAJOR CONCERN 6
> >> >
> >> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in
> >> > this
>
> >> > document.  The closest that I could find is a requirement that
> >> > the AA
> >> "make
> >> > sure that the policy applies to all the attributes."  Without
> >> > appropriate MUST statements, I do not see how a useful service is

> >> > being provided
> >> to the
> >> > replying party.
> >>
> >>It is the very first draft, so yet unpolished.
> >
> >Apparently sharing my first four major concerns has not altered your
> >thinking. So, we can expect a second draft with little change?
> >
> >Russ



Received: by above.proper.com (8.11.6/8.11.3) id g5IF9as29150 for ietf-pkix-bks; Tue, 18 Jun 2002 08:09:36 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IF9Yn29139 for <[e-mail]>; Tue, 18 Jun 2002 08:09:35 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA25546; Tue, 18 Jun 2002 17:13:18 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061817081713:660 ; Tue, 18 Jun 2002 17:08:17 +0200 
Message-ID: <[e-mail]>
Date: Tue, 18 Jun 2002 17:08:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Attribute Certificate Policy -- Repository Reference
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/06/2002 17:08:17, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/06/2002 17:08:38, Serialize complete at 18/06/2002 17:08:38
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

At this time the agreement would be to have an extension valid for both 
PKCs and ACs to indicate possible repository references for the certificate.

If we call that document "Useful extensions for PKCs and ACs" then it may
still be in the same document. I would prefer to limit the number of RFCs,
if possible.

So let us first agree on the technical concepts and decide later on how 
to present/package them.

Denis

 
> Denis:
> 
> Given this agreement, perhaps the best course of action is to separate the
> two mechanisms into separate documents.
> 
> Russ
> 
> At 04:37 PM 6/18/2002 +0200, Denis Pinkas wrote:
> >Russ,
> >
> > > In this message, I address only one of my concerns.
> >
> >(text deleted)
> >
> > > >You can get the AC from the protocol. If there is a thin client, the
> > > >thin client will not verify the AC and build the certificate chain to
> > verify
> > > >the AC. If a fat client was doing it, then he could get the uri, if the
> > > >meaning of authority information access extension was extended to
> > cover AAs
> > > >(which is not the case today). So the proposal is to include the
> > location in
> > > >the AC itself.
> >
> > > I think that I understand your goal better, but I do not see what this has
> > > to do with AC policy.
> >
> >The document was targeted to support ACs, but in order to have a short
> >title, the title and the abstract did not reflected this. So looking at
> >the title, you are quite right. We could change the title, but ...
> >
> > > I would prefer to specify a mechanism that works equally well for PKCs and
> > > ACs.  Using the same mechanism for both certificate types is a win for thin
> > > clients.
> >
> >  ... I have nothing against your suggestion. This kind of extension would
> >work quite nice for both PKCs and ACs.
> >
> >Denis
> >
> > > Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IEtt427329 for ietf-pkix-bks; Tue, 18 Jun 2002 07:55:55 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5IEtrn27324 for <[e-mail]>; Tue, 18 Jun 2002 07:55:53 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Jun 2002 14:55:40 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA29580 for <[e-mail]>; Tue, 18 Jun 2002 10:55:54 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5IEruI15779 for <[e-mail]>; Tue, 18 Jun 2002 10:53:56 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZP8NX>; Tue, 18 Jun 2002 10:55:52 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.5]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZP8NV; Tue, 18 Jun 2002 10:55:49 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 18 Jun 2002 10:44:14 -0400
Subject: Re: Attribute Certificate Policy -- Repository Reference
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

Given this agreement, perhaps the best course of action is to separate the 
two mechanisms into separate documents.

Russ


At 04:37 PM 6/18/2002 +0200, Denis Pinkas wrote:
>Russ,
>
> > In this message, I address only one of my concerns.
>
>(text deleted)
>
> > >You can get the AC from the protocol. If there is a thin client, the
> > >thin client will not verify the AC and build the certificate chain to 
> verify
> > >the AC. If a fat client was doing it, then he could get the uri, if the
> > >meaning of authority information access extension was extended to 
> cover AAs
> > >(which is not the case today). So the proposal is to include the 
> location in
> > >the AC itself.
>
> > I think that I understand your goal better, but I do not see what this has
> > to do with AC policy.
>
>The document was targeted to support ACs, but in order to have a short
>title, the title and the abstract did not reflected this. So looking at
>the title, you are quite right. We could change the title, but ...
>
> > I would prefer to specify a mechanism that works equally well for PKCs and
> > ACs.  Using the same mechanism for both certificate types is a win for thin
> > clients.
>
>  ... I have nothing against your suggestion. This kind of extension would
>work quite nice for both PKCs and ACs.
>
>Denis
>
> > Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IEcJn26672 for ietf-pkix-bks; Tue, 18 Jun 2002 07:38:19 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IEcHn26668 for <[e-mail]>; Tue, 18 Jun 2002 07:38:18 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA21386; Tue, 18 Jun 2002 16:42:00 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061816364904:648 ; Tue, 18 Jun 2002 16:36:49 +0200 
Message-ID: <[e-mail]>
Date: Tue, 18 Jun 2002 16:37:28 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Attribute Certificate Policy -- Repository Reference
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/06/2002 16:36:49, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/06/2002 16:37:20, Serialize complete at 18/06/2002 16:37:20
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> In this message, I address only one of my concerns.

(text deleted)

> >You can get the AC from the protocol. If there is a thin client, the
> >thin client will not verify the AC and build the certificate chain to verify
> >the AC. If a fat client was doing it, then he could get the uri, if the
> >meaning of authority information access extension was extended to cover AAs
> >(which is not the case today). So the proposal is to include the location in
> >the AC itself.
 
> I think that I understand your goal better, but I do not see what this has
> to do with AC policy.

The document was targeted to support ACs, but in order to have a short
title, the title and the abstract did not reflected this. So looking at 
the title, you are quite right. We could change the title, but ...  
 
> I would prefer to specify a mechanism that works equally well for PKCs and
> ACs.  Using the same mechanism for both certificate types is a win for thin
> clients.

 ... I have nothing against your suggestion. This kind of extension would
work quite nice for both PKCs and ACs.

Denis
 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IET4L26344 for ietf-pkix-bks; Tue, 18 Jun 2002 07:29:04 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5IET2n26339 for <[e-mail]>; Tue, 18 Jun 2002 07:29:02 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Jun 2002 14:28:49 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA25723 for <[e-mail]>; Tue, 18 Jun 2002 10:29:03 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5IER5d11151 for <[e-mail]>; Tue, 18 Jun 2002 10:27:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZP78K>; Tue, 18 Jun 2002 10:29:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.5]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZP78F; Tue, 18 Jun 2002 10:28:57 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 18 Jun 2002 09:13:22 -0400
Subject: Attribute Certificate Policy -- Repository Reference
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

In this message, I address only one of my concerns.

> > >  > MAJOR CONCERN 4
>
> > > > Can we use the AuthorityInfoAccess extension to point to the issuer's
> > > > repository?  I think it would be straightforward to define an 
> access method
> > > > that meets this objective.  Perhaps this is a matter of taste, but 
> it seems
> > > > to meet the stated requirement of providing a pointer to the issuer's
> > > > repository that otherwise requires the information to be extracted 
> from the
> > > > CP or CPS.
>
> > >RFC 3280 states:
>
> > >    The authority information access extension indicates how to access CA
> > >    information and services for the issuer of the certificate in which
> > >    the extension appears.
>
> > >I do not consider an AA to be a CA and I would not like that we introduce
> > >some confusion between a CA and an AA, hence why this extension has 
> not been
> > >created. From RFC 3281: Attribute Authority, the entity that issues 
> the AC,
> > >synonymous in this specification with "AC issuer".
>
> > An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to
> > have the same distinguished name.
>
> > Perhaps I am misunderstanding this whole section of the document, by I
> > thought that you want a URI that points to the issuer's repository.
>
>Yes.
>
> > The justification provided is that you want to be able to pass a pointer
> > to the certificate (either PKC or AC) rather than pass the certificate
> > itself.  Clearly, the certificate is already available to the to extract
> > the URI in the first place.
>
>No. You can get the AC from the protocol. If there is a thin client, the
>thin client will not verify the AC and build the certificate chain to verify
>the AC. If a fat client was doing it, then he could get the uri, if the
>meaning of authority information access extension was extended to cover AAs
>(which is not the case today). So the proposal is to include the location in
>the AC itself.

I think that I understand your goal better, but I do not see what this has 
to do with AC policy.

I would prefer to specify a mechanism that works equally well for PKCs and 
ACs.  Using the same mechanism for both certificate types is a win for thin 
clients.

Russ
  


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ICoDW19850 for ietf-pkix-bks; Tue, 18 Jun 2002 05:50:13 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5ICoBn19846 for <[e-mail]>; Tue, 18 Jun 2002 05:50:11 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Jun 2002 12:49:58 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA11386 for <[e-mail]>; Tue, 18 Jun 2002 08:50:10 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5ICmB823927 for <[e-mail]>; Tue, 18 Jun 2002 08:48:11 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZP6DQ>; Tue, 18 Jun 2002 08:50:07 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZP6DN; Tue, 18 Jun 2002 08:50:00 -0400
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 18 Jun 2002 08:49:51 -0400
Subject: RE: Attribute Certificate Policy
In-Reply-To: <000001c2164a$e787c1a0$1600a8c0@Chokhani>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh:

This is a good point, but it would be a very straightforward addition.  In 
fact, given the current existence of subjectDirectoryAttributes, it should 
probably be included now.

Russ


At 06:04 PM 6/17/2002 -0400, Santosh Chokhani wrote:
>Russ:
>
>Also, the CP and CPS Framework does not address the issues surrounding
>validating and revoking the attributes.  It is very much identity
>oriented.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>On Behalf Of Housley, Russ
>Sent: Monday, June 17, 2002 2:15 PM
>To: [e-mail]; [e-mail]
>Cc: pkix
>Subject: Re: Attribute Certificate Policy
>
>
>
>All:
>
>Sharon pointed me to the part of X.509 that prohibits the use of the
>certificatePolicies extension in attribute certificates.  I would rather
>
>work with the X.509 community to remove this restriction than define a
>new
>extension with the same syntax and semantics.
>
>Russ
>
>
> >> > I really dislike this draft.  Since it is written by two people
> >> > that I respect, I feel obligated to voice my concerns.
> >>
> >> > If I wrote down everything that causes me concern in this draft,
> >> > then the resulting message would be longer than the draft itself.
> >> > For this reason, I will stick to the major concerns.
> >>
> >> > MAJOR CONCERN 1
> >>
> >> > I see no value in adding a acPolicies extension to a PKC that
> >> > includes the subjectDirectoryAttributes extension.  The current
> >> > policy extension
> >> already
> >> > handles the whole PKC, including the content of the
> >> > subjectDirectoryAttributes extension.  Two policy-related
> >> > extensions in a single PKC provides no value to the replying party.
> >>
> >>I would agree that this is debatable. Attributes contained in PKCs
> >>MUST be verified at the time of registration, but nothing would
> >>prevent a CA to do more and to revoke a PKC if an attribute is no more
>
> >>correct. This could be in the CP and the CPS may it is not directly
> >>machine readable. Hence why it might be interresting to say more. An
> >>alternative would be for PKCs to keep the CP extension but to allow to
>
> >>support more qualifiers.
> >
> >There seem to be three cases to discuss:
> >         a)  the attribute is long-lived and unlikely to change,
> >         b)  the attribute is long-lived and likely to change, and
> >         c)  the attribute is short-lived.
> >
> >I think that your reply only addresses the first case (a).  I assume
> >that
> >short validity periods will be used when the attribute fits into one of
>
> >the other two cases (b and c).
> >
> >So, in the first case, you are using a policy qualifier (yuck) to tell
> >the
> >relying party that the issuer does not expect the attribute to change
>but
> >that periodic checks will be made just to make sure that everything is
>as
> >expected.  If an unexpected condition is discovered, then the
>certificate
> >will be revoked.  I find it hard to believe that the same frequency
>will
> >be needed for each attribute that might appear in the
> >subjectDirectoryAttributes extension.
> >
> >> > MAJOR CONCERN 2
> >>
> >> > Why define a new extension?  Why not simply include the
> >> certificatePolicies
> >> > extension in an attribute certificate?  The two extensions have
> >> exactly the
> >> > same syntax.  I believe that they have the same semantics too.
> >>
> >>Not exactly. As indicated above, attributes contained in PKCs MUST be
> >>verified at the time of registration, but nothing would prevent a CA
> >>to do more and to revoke a PKC if an attribute is no more correct.
> >>This information is certainly of some interest for a relying party.
> >>The AA should have a way to indicate this, but since an AC does not
> >>contain a CP extension, this is the reason why a new extension has
> >>been created.
> >
> >I see nothing in X.509 that prohibits the use of the
> >certificatePolicies
> >extension in an attribute certificate. (There is one place where it
>says
> >"CA", but if that were replaced with "issuer".)  Maybe I missed
>something ...
> >
> >> > MAJOR CONCERN 3
> >> >
> >> > Why do we need more qualifiers?  The draft RECOMMENDS that policy
> >> > information consist of an object identifier, then it defines a pile
>
> >> > of qualifiers.  Further, the information that is contained in the
> >> > qualifiers is of very little interest to the relying party.  It is
> >> > useful to the issuer.  Why can't the issuer keep this information
> >> > in a private database.  Everything that the issuer knows about the
> >> > subject/holder need not appear in the certificate.
> >>
> >>As indicated above, it is useful for relying parties that may get more
>
> >>information, e.g. confidence about the freshness of the attributes.
> >
> >I do not see it.  You are saying that the relying party will reject an
> >attribute certificate in the following situation:
> >
> >         1)  the AA has a valid PKC
> >         2)  the subject has a valid PKC
> >         3)  the subject has a valid AC
> >         4)  the AC was issued under an acceptable policy
> >         5)  the AC policy qualifier indicates periodic checks that
> >                 are weekly, but the relying party would like more
> >                 frequent checks
> >
> >X.509 says:
> >
> >         The optional qualifiers are not used in the certification path
> > processing
> >         procedure, but relevant qualifiers are provided as an output
>of
> > that process
> >         to the certificate using application to assist in determining
> > whether a valid
> >         path is appropriate for the particular transaction.
> >
> >RFC 3280 says:
> >
> >         Optional qualifiers, which MAY be present, are not expected to
>change
> >         the definition of the policy.
> >
> >Your use of qualifier does meet the limits imposed by these documents;
> >however, I think that there is a mismatch between the single value in
>the
> >policy qualifier and the potential for more than one attribute in the
> >subjectDirectoryAttributes extension or the AC.
> >
> >Using separate ACs for each attribute would solve this problem, but
> >that
> >seems to impose way too much overhead and complexity.
> >
> >>  > MAJOR CONCERN 4
> >> >
> >> > Can we use the AuthorityInfoAccess extension to point to the
> >> > issuer's repository?  I think it would be straightforward to define
>
> >> > an access
> >> method
> >> > that meets this objective.  Perhaps this is a matter of taste, but
> >> > it
> >> seems
> >> > to meet the stated requirement of providing a pointer to the
> >> > issuer's repository that otherwise requires the information to be
> >> > extracted
> >> from the
> >> > CP or CPS.
> >>
> >>RFC 3280 states:
> >>
> >>    The authority information access extension indicates how to access
>CA
> >>    information and services for the issuer of the certificate in
>which
> >>    the extension appears.
> >>
> >>I do not consider an AA to be a CA and I would not like that we
> >>introduce some confusion between a CA and an AA, hence why this
> >>extension has not been created. From RFC 3281: Attribute Authority,
> >>the entity that issues the AC, synonymous in this specification with
> >>"AC issuer".
> >
> >An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to
> >have the same distinguished name.
> >
> >Perhaps I am misunderstanding this whole section of the document, by I
> >thought that you want a URI that points to the issuer's repository.
>The
> >justification provided is that you want to be able to pass a pointer to
>
> >the certificate (either PKC or AC) rather than pass the certificate
> >itself.  Clearly, the certificate is already available to the to
>extract
> >the URI in the first place.
> >
> >> > MAJOR CONCERN 5
> >> >
> >> > The PKIX working group does not assign object identifiers in the
> >> > id-ce arc.  This are is owned by the editor of X.509.
> >> >
> >> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
> >>
> >>Thanks. Nobody is perfect.
> >
> >I certainly make mistakes too.  That is why I value peer review.
> >
> >> > MAJOR CONCERN 6
> >> >
> >> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this
>
> >> > document.  The closest that I could find is a requirement that the
> >> > AA
> >> "make
> >> > sure that the policy applies to all the attributes."  Without
> >> > appropriate MUST statements, I do not see how a useful service is
> >> > being provided
> >> to the
> >> > replying party.
> >>
> >>It is the very first draft, so yet unpolished.
> >
> >Apparently sharing my first four major concerns has not altered your
> >thinking. So, we can expect a second draft with little change?
> >
> >Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IBRs915502 for ietf-pkix-bks; Tue, 18 Jun 2002 04:27:54 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IBRrn15497 for <[e-mail]>; Tue, 18 Jun 2002 04:27:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12974; Tue, 18 Jun 2002 07:27:13 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-05.txt
Date: Tue, 18 Jun 2002 07:27:13 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Internet X.509 Public Key Infrastructure Permanent 
                          Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-05.txt
	Pages		: 11
	Date		: 17-Jun-02
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pi-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pi-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pi-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pi-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IB0f012814 for ietf-pkix-bks; Tue, 18 Jun 2002 04:00:41 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IB0dn12809 for <[e-mail]>; Tue, 18 Jun 2002 04:00:39 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g5IB0LsR014028 for <[e-mail]>; Tue, 18 Jun 2002 23:00:21 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA17926 for [e-mail]; Tue, 18 Jun 2002 23:00:18 +1200 (NZST) (sender [e-mail])
Date: Tue, 18 Jun 2002 23:00:18 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Anyone from Thawte here?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is anyone from Thawte reading this list?  I've just noticed a rather serious
flaw in Thawte certs, but the web site expects me to phone South Africa in
order to talk to anyone about it.  

(It was much easier when I could just mail Mark and he'd fix it).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IAN2l08219 for ietf-pkix-bks; Tue, 18 Jun 2002 03:23:02 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IAN1n08211 for <[e-mail]>; Tue, 18 Jun 2002 03:23:01 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA31366; Tue, 18 Jun 2002 12:26:30 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061812211831:582 ; Tue, 18 Jun 2002 12:21:18 +0200 
Message-ID: <[e-mail]>
Date: Tue, 18 Jun 2002 12:22:05 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], pkix <[e-mail]>
Subject: Re: Attribute Certificate Policy
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/06/2002 12:21:18, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 18/06/2002 12:21:51, Serialize complete at 18/06/2002 12:21:51
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> > > MAJOR CONCERN 1
> >
> > > I see no value in adding a acPolicies extension to a PKC that includes the
> > > subjectDirectoryAttributes extension.  The current policy extension already
> > > handles the whole PKC, including the content of the
> > > subjectDirectoryAttributes extension.  Two policy-related extensions in a
> > > single PKC provides no value to the replying party.

> >I would agree that this is debatable. Attributes contained in PKCs MUST be
> >verified at the time of registration, but nothing would prevent a CA to do
> >more and to revoke a PKC if an attribute is no more correct. This could be
> >in the CP and the CPS may it is not directly machine readable. Hence why it
> >might be interresting to say more. An alternative would be for PKCs to keep
> >the CP extension but to allow to support more qualifiers.
 
> There seem to be three cases to discuss:
>          a)  the attribute is long-lived and unlikely to change,
>          b)  the attribute is long-lived and likely to change, and
>          c)  the attribute is short-lived.
 
> I think that your reply only addresses the first case (a).  I assume that
> short validity periods will be used when the attribute fits into one of the
> other two cases (b and c).

Correct.
 
> So, in the first case, you are using a policy qualifier (yuck) to tell the
> relying party that the issuer does not expect the attribute to change but
> that periodic checks will be made just to make sure that everything is as
> expected.  If an unexpected condition is discovered, then the certificate
> will be revoked.  

Correct.

> I find it hard to believe that the same frequency will be
> needed for each attribute that might appear in the
> subjectDirectoryAttributes extension.

Ideally one policy per attribute would be needed. For attributes included in
the subjectDirectoryAttributes extension from a PKC a common denominator
will have to be used.

For attributes included in an AC, the same applies but in that case an AC
may only include one or two atributes and thus the policy can be defined at
a finer level of granularity.

> > > MAJOR CONCERN 2

> > > Why define a new extension?  Why not simply include the certificatePolicies
> > > extension in an attribute certificate?  The two extensions have exactly the
> > > same syntax.  I believe that they have the same semantics too.

> >Not exactly. As indicated above, attributes contained in PKCs MUST be
> >verified at the time of registration, but nothing would prevent a CA to do
> >more and to revoke a PKC if an attribute is no more correct. This
> >information is certainly of some interest for a relying party. The AA should
> >have a way to indicate this, but since an AC does not contain a CP
> >extension, this is the reason why a new extension has been created.
 
> I see nothing in X.509 that prohibits the use of the certificatePolicies
> extension in an attribute certificate. (There is one place where it says
> "CA", but if that were replaced with "issuer".)  Maybe I missed something ...

You mentioned that Sharon noticed that the current ISO text precludes to use
the CP extension for ACs. The current RFC 3280, also precludes it.
 
Changing one word by another is an important change. I do not say that it
cannot be done, but I was not assuming such a change. 

The real issue is:

Should the notion of policy be supported at all in an AC ?
I believe that the answer is YES.

If so, then the next question is how. There were two alternatives:

  1) by changing both X.509 and RFC 3280, or
  2) by defining a new extension.

You would prefer the former choice. Since the ISO process is quite long,
I would prefer the IETF process.  

Chris and myself made the later choice.

Thenafter as soon as we say that regular checks can be made on the
attributes under a policy, a parameter is useful to indicate that frequency.
Hence the reason of at least a new qualifier, that is specific to attributes
included either in a PKC or an AC.

If we change X.509 this makes an addition that may take quite long. If the
IETF goes first, then ISO could add the PKIX addition later on and we would
not have to wait for the next ISO publication round. Of course, this does
not prevent discussions and co-ordination between the ISO SC6 and the PKIX
WGs.
 
> > > MAJOR CONCERN 3

> > > Why do we need more qualifiers?  The draft RECOMMENDS that policy
> > > information consist of an object identifier, then it defines a pile of
> > > qualifiers.  Further, the information that is contained in the qualifiers
> > > is of very little interest to the relying party.  It is useful to the
> > > issuer.  Why can't the issuer keep this information in a private
> > > database.  Everything that the issuer knows about the subject/holder need
> > > not appear in the certificate.

> >As indicated above, it is useful for relying parties that may get more
> >information, e.g. confidence about the freshness of the attributes.
 
> I do not see it.  You are saying that the relying party will reject an
> attribute certificate in the following situation:
 
>          1)  the AA has a valid PKC
>          2)  the subject has a valid PKC
>          3)  the subject has a valid AC
>          4)  the AC was issued under an acceptable policy
>          5)  the AC policy qualifier indicates periodic checks that
>                  are weekly, but the relying party would like more
>                  frequent checks

Yes, the last condition could lead to a reject.
 
> X.509 says: 
> 
> The optional qualifiers are not used in the certification path
> processing procedure, but relevant qualifiers are provided as 
> an output of that process to the certificate using application 
> to assist in determining whether a valid path is appropriate 
> for the particular transaction.
 
> RFC 3280 says:
> 
> Optional qualifiers, which MAY be present, are not expected to change
> the definition of the policy.
 
> Your use of qualifier does meet the limits imposed by these documents;
> however, I think that there is a mismatch between the single value in the
> policy qualifier and the potential for more than one attribute in the
> subjectDirectoryAttributes extension or the AC.

This may prevent some attribute grouping, either in the
subjectDirectoryAttributes extension from a PKC or in an AC.
 
> Using separate ACs for each attribute would solve this problem, but that
> seems to impose way too much overhead and complexity.

This is one way to solve the problem.
 
> >  > MAJOR CONCERN 4

> > > Can we use the AuthorityInfoAccess extension to point to the issuer's
> > > repository?  I think it would be straightforward to define an access method
> > > that meets this objective.  Perhaps this is a matter of taste, but it seems
> > > to meet the stated requirement of providing a pointer to the issuer's
> > > repository that otherwise requires the information to be extracted from the
> > > CP or CPS.

> >RFC 3280 states:

> >    The authority information access extension indicates how to access CA
> >    information and services for the issuer of the certificate in which
> >    the extension appears.

> >I do not consider an AA to be a CA and I would not like that we introduce
> >some confusion between a CA and an AA, hence why this extension has not been
> >created. From RFC 3281: Attribute Authority, the entity that issues the AC,
> >synonymous in this specification with "AC issuer".
 
> An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to
> have the same distinguished name.
 
> Perhaps I am misunderstanding this whole section of the document, by I
> thought that you want a URI that points to the issuer's repository.  

Yes.

> The justification provided is that you want to be able to pass a pointer 
> to the certificate (either PKC or AC) rather than pass the certificate
> itself.  Clearly, the certificate is already available to the to extract
> the URI in the first place.

No. You can get the AC from the protocol. If there is a thin client, the
thin client will not verify the AC and build the certificate chain to verify
the AC. If a fat client was doing it, then he could get the uri, if the
meaning of authority information access extension was extended to cover AAs
(which is not the case today). So the proposal is to include the location in
the AC itself.
 
> > > MAJOR CONCERN 5
> > >
> > > The PKIX working group does not assign object identifiers in the id-ce
> > > arc.  This are is owned by the editor of X.509.
> > >
> > >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }

> >Thanks. Nobody is perfect.
 
> I certainly make mistakes too.  That is why I value peer review.
 
> > > MAJOR CONCERN 6
> > >
> > > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this
> > > document.  The closest that I could find is a requirement that the AA "make
> > > sure that the policy applies to all the attributes."  Without appropriate
> > > MUST statements, I do not see how a useful service is being provided to the
> > > replying party.

> >It is the very first draft, so yet unpolished.
 
> Apparently sharing my first four major concerns has not altered your
> thinking. So, we can expect a second draft with little change?

At this time, the only changes I see would be to change some shall and must
into SHALL and MUST.

I do not think it is necessary to make these changes now. The purpose of
sending this draft was to trigger a discussion before the Yokohama meeting
and at the Yokohama meeting.

I will certainly be interested to have a discussion on that topic before the
PKIX WG meeting in Yokohama. I will be there from the Monday. Unfortunately,
Chris will not be there.

Denis

> 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HM31s03091 for ietf-pkix-bks; Mon, 17 Jun 2002 15:03:01 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HM30n03087 for <[e-mail]>; Mon, 17 Jun 2002 15:03:00 -0700 (PDT)
Received: from Chokhani ([12.91.134.140]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020617220248.EKIU19182.mtiwmhc21.worldnet.att.net@Chokhani>; Mon, 17 Jun 2002 22:02:48 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "'pkix'" <[e-mail]>
Subject: RE: Attribute Certificate Policy
Date: Mon, 17 Jun 2002 18:04:07 -0400
Message-ID: <000001c2164a$e787c1a0$1600a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

Also, the CP and CPS Framework does not address the issues surrounding
validating and revoking the attributes.  It is very much identity
oriented.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Housley, Russ
Sent: Monday, June 17, 2002 2:15 PM
To: [e-mail]; [e-mail]
Cc: pkix
Subject: Re: Attribute Certificate Policy



All:

Sharon pointed me to the part of X.509 that prohibits the use of the 
certificatePolicies extension in attribute certificates.  I would rather

work with the X.509 community to remove this restriction than define a
new 
extension with the same syntax and semantics.

Russ


>> > I really dislike this draft.  Since it is written by two people 
>> > that I respect, I feel obligated to voice my concerns.
>>
>> > If I wrote down everything that causes me concern in this draft, 
>> > then the resulting message would be longer than the draft itself.  
>> > For this reason, I will stick to the major concerns.
>>
>> > MAJOR CONCERN 1
>>
>> > I see no value in adding a acPolicies extension to a PKC that 
>> > includes the subjectDirectoryAttributes extension.  The current 
>> > policy extension
>> already
>> > handles the whole PKC, including the content of the 
>> > subjectDirectoryAttributes extension.  Two policy-related 
>> > extensions in a single PKC provides no value to the replying party.
>>
>>I would agree that this is debatable. Attributes contained in PKCs 
>>MUST be verified at the time of registration, but nothing would 
>>prevent a CA to do more and to revoke a PKC if an attribute is no more

>>correct. This could be in the CP and the CPS may it is not directly 
>>machine readable. Hence why it might be interresting to say more. An 
>>alternative would be for PKCs to keep the CP extension but to allow to

>>support more qualifiers.
>
>There seem to be three cases to discuss:
>         a)  the attribute is long-lived and unlikely to change,
>         b)  the attribute is long-lived and likely to change, and
>         c)  the attribute is short-lived.
>
>I think that your reply only addresses the first case (a).  I assume 
>that
>short validity periods will be used when the attribute fits into one of

>the other two cases (b and c).
>
>So, in the first case, you are using a policy qualifier (yuck) to tell 
>the
>relying party that the issuer does not expect the attribute to change
but 
>that periodic checks will be made just to make sure that everything is
as 
>expected.  If an unexpected condition is discovered, then the
certificate 
>will be revoked.  I find it hard to believe that the same frequency
will 
>be needed for each attribute that might appear in the 
>subjectDirectoryAttributes extension.
>
>> > MAJOR CONCERN 2
>>
>> > Why define a new extension?  Why not simply include the
>> certificatePolicies
>> > extension in an attribute certificate?  The two extensions have
>> exactly the
>> > same syntax.  I believe that they have the same semantics too.
>>
>>Not exactly. As indicated above, attributes contained in PKCs MUST be 
>>verified at the time of registration, but nothing would prevent a CA 
>>to do more and to revoke a PKC if an attribute is no more correct. 
>>This information is certainly of some interest for a relying party. 
>>The AA should have a way to indicate this, but since an AC does not 
>>contain a CP extension, this is the reason why a new extension has 
>>been created.
>
>I see nothing in X.509 that prohibits the use of the 
>certificatePolicies
>extension in an attribute certificate. (There is one place where it
says 
>"CA", but if that were replaced with "issuer".)  Maybe I missed
something ...
>
>> > MAJOR CONCERN 3
>> >
>> > Why do we need more qualifiers?  The draft RECOMMENDS that policy 
>> > information consist of an object identifier, then it defines a pile

>> > of qualifiers.  Further, the information that is contained in the 
>> > qualifiers is of very little interest to the relying party.  It is 
>> > useful to the issuer.  Why can't the issuer keep this information 
>> > in a private database.  Everything that the issuer knows about the 
>> > subject/holder need not appear in the certificate.
>>
>>As indicated above, it is useful for relying parties that may get more

>>information, e.g. confidence about the freshness of the attributes.
>
>I do not see it.  You are saying that the relying party will reject an
>attribute certificate in the following situation:
>
>         1)  the AA has a valid PKC
>         2)  the subject has a valid PKC
>         3)  the subject has a valid AC
>         4)  the AC was issued under an acceptable policy
>         5)  the AC policy qualifier indicates periodic checks that
>                 are weekly, but the relying party would like more
>                 frequent checks
>
>X.509 says:
>
>         The optional qualifiers are not used in the certification path
> processing
>         procedure, but relevant qualifiers are provided as an output
of 
> that process
>         to the certificate using application to assist in determining 
> whether a valid
>         path is appropriate for the particular transaction.
>
>RFC 3280 says:
>
>         Optional qualifiers, which MAY be present, are not expected to
change
>         the definition of the policy.
>
>Your use of qualifier does meet the limits imposed by these documents;
>however, I think that there is a mismatch between the single value in
the 
>policy qualifier and the potential for more than one attribute in the 
>subjectDirectoryAttributes extension or the AC.
>
>Using separate ACs for each attribute would solve this problem, but 
>that
>seems to impose way too much overhead and complexity.
>
>>  > MAJOR CONCERN 4
>> >
>> > Can we use the AuthorityInfoAccess extension to point to the 
>> > issuer's repository?  I think it would be straightforward to define

>> > an access
>> method
>> > that meets this objective.  Perhaps this is a matter of taste, but 
>> > it
>> seems
>> > to meet the stated requirement of providing a pointer to the 
>> > issuer's repository that otherwise requires the information to be 
>> > extracted
>> from the
>> > CP or CPS.
>>
>>RFC 3280 states:
>>
>>    The authority information access extension indicates how to access
CA
>>    information and services for the issuer of the certificate in
which
>>    the extension appears.
>>
>>I do not consider an AA to be a CA and I would not like that we 
>>introduce some confusion between a CA and an AA, hence why this 
>>extension has not been created. From RFC 3281: Attribute Authority, 
>>the entity that issues the AC, synonymous in this specification with 
>>"AC issuer".
>
>An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to
>have the same distinguished name.
>
>Perhaps I am misunderstanding this whole section of the document, by I
>thought that you want a URI that points to the issuer's repository.
The 
>justification provided is that you want to be able to pass a pointer to

>the certificate (either PKC or AC) rather than pass the certificate 
>itself.  Clearly, the certificate is already available to the to
extract 
>the URI in the first place.
>
>> > MAJOR CONCERN 5
>> >
>> > The PKIX working group does not assign object identifiers in the 
>> > id-ce arc.  This are is owned by the editor of X.509.
>> >
>> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
>>
>>Thanks. Nobody is perfect.
>
>I certainly make mistakes too.  That is why I value peer review.
>
>> > MAJOR CONCERN 6
>> >
>> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this

>> > document.  The closest that I could find is a requirement that the 
>> > AA
>> "make
>> > sure that the policy applies to all the attributes."  Without 
>> > appropriate MUST statements, I do not see how a useful service is 
>> > being provided
>> to the
>> > replying party.
>>
>>It is the very first draft, so yet unpolished.
>
>Apparently sharing my first four major concerns has not altered your
>thinking. So, we can expect a second draft with little change?
>
>Russ



Received: by above.proper.com (8.11.6/8.11.3) id g5HJJXc25475 for ietf-pkix-bks; Mon, 17 Jun 2002 12:19:33 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5HJJVn25469 for <[e-mail]>; Mon, 17 Jun 2002 12:19:31 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Jun 2002 19:19:20 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA15999; Mon, 17 Jun 2002 15:19:33 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5HJHZ809278; Mon, 17 Jun 2002 15:17:35 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZPSPW>; Mon, 17 Jun 2002 15:19:31 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZPSPT; Mon, 17 Jun 2002 15:19:27 -0400
From: "Housley, Russ" <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
Cc: [e-mail], pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 17 Jun 2002 15:19:23 -0400
Subject: RE: Attribute Certificate Policy
In-Reply-To: <[e-mail] m>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris:

>My primary motivation for starting down this path is that I strongly believe
>that a standardized mechanism is required to convey policy information in
>attribute certificates.  If the restriction on the use of
>certificatePolicies in attribute certificates could be removed, I would be
>in favor of that, but the last time I raised that issue, I didn't get very
>far.

I see no reason for two extensions with the same syntax and the same 
semantics.  I think others will agree.

>Defining a separate extension within the PKIX group seemed a reasonable
>first step.

Hopefully the discussion will determine if others agree with me.  If so, 
then we can make a request to the X.509 community.  So far, only three 
people have voiced an opinion either way.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HJ0pr23546 for ietf-pkix-bks; Mon, 17 Jun 2002 12:00:51 -0700 (PDT)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HJ0on23540 for <[e-mail]>; Mon, 17 Jun 2002 12:00:50 -0700 (PDT)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id PAA16907; Mon, 17 Jun 2002 15:00:49 -0400
From: "Christopher S. Francis" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: "pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 17 Jun 2002 19:00:49 UT
Subject: RE: Attribute Certificate Policy
Date: Mon, 17 Jun 2002 15:00:48 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

My primary motivation for starting down this path is that I strongly believe
that a standardized mechanism is required to convey policy information in
attribute certificates.  If the restriction on the use of
certificatePolicies in attribute certificates could be removed, I would be
in favor of that, but the last time I raised that issue, I didn't get very
far.

Defining a separate extension within the PKIX group seemed a reasonable
first step.

Chris

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Monday, June 17, 2002 2:15 PM
To: [e-mail]; [e-mail]
Cc: pkix
Subject: Re: Attribute Certificate Policy

All:

Sharon pointed me to the part of X.509 that prohibits the use of the
certificatePolicies extension in attribute certificates.  I would rather
work with the X.509 community to remove this restriction than define a new
extension with the same syntax and semantics.

Russ


>> > I really dislike this draft.  Since it is written by two people that I
>> > respect, I feel obligated to voice my concerns.
>>
>> > If I wrote down everything that causes me concern in this draft, then
the
>> > resulting message would be longer than the draft itself.  For this
reason,
>> > I will stick to the major concerns.
>>
>> > MAJOR CONCERN 1
>>
>> > I see no value in adding a acPolicies extension to a PKC that includes
the
>> > subjectDirectoryAttributes extension.  The current policy extension
>> already
>> > handles the whole PKC, including the content of the
>> > subjectDirectoryAttributes extension.  Two policy-related extensions in
a
>> > single PKC provides no value to the replying party.
>>
>>I would agree that this is debatable. Attributes contained in PKCs MUST be
>>verified at the time of registration, but nothing would prevent a CA to do
>>more and to revoke a PKC if an attribute is no more correct. This could be
>>in the CP and the CPS may it is not directly machine readable. Hence why
it
>>might be interresting to say more. An alternative would be for PKCs to
keep
>>the CP extension but to allow to support more qualifiers.
>
>There seem to be three cases to discuss:
>         a)  the attribute is long-lived and unlikely to change,
>         b)  the attribute is long-lived and likely to change, and
>         c)  the attribute is short-lived.
>
>I think that your reply only addresses the first case (a).  I assume that
>short validity periods will be used when the attribute fits into one of
>the other two cases (b and c).
>
>So, in the first case, you are using a policy qualifier (yuck) to tell the
>relying party that the issuer does not expect the attribute to change but
>that periodic checks will be made just to make sure that everything is as
>expected.  If an unexpected condition is discovered, then the certificate
>will be revoked.  I find it hard to believe that the same frequency will
>be needed for each attribute that might appear in the
>subjectDirectoryAttributes extension.
>
>> > MAJOR CONCERN 2
>>
>> > Why define a new extension?  Why not simply include the
>> certificatePolicies
>> > extension in an attribute certificate?  The two extensions have
>> exactly the
>> > same syntax.  I believe that they have the same semantics too.
>>
>>Not exactly. As indicated above, attributes contained in PKCs MUST be
>>verified at the time of registration, but nothing would prevent a CA to do
>>more and to revoke a PKC if an attribute is no more correct. This
>>information is certainly of some interest for a relying party. The AA
should
>>have a way to indicate this, but since an AC does not contain a CP
>>extension, this is the reason why a new extension has been created.
>
>I see nothing in X.509 that prohibits the use of the certificatePolicies
>extension in an attribute certificate. (There is one place where it says
>"CA", but if that were replaced with "issuer".)  Maybe I missed something
...
>
>> > MAJOR CONCERN 3
>> >
>> > Why do we need more qualifiers?  The draft RECOMMENDS that policy
>> > information consist of an object identifier, then it defines a pile of
>> > qualifiers.  Further, the information that is contained in the
qualifiers
>> > is of very little interest to the relying party.  It is useful to the
>> > issuer.  Why can't the issuer keep this information in a private
>> > database.  Everything that the issuer knows about the subject/holder
need
>> > not appear in the certificate.
>>
>>As indicated above, it is useful for relying parties that may get more
>>information, e.g. confidence about the freshness of the attributes.
>
>I do not see it.  You are saying that the relying party will reject an
>attribute certificate in the following situation:
>
>         1)  the AA has a valid PKC
>         2)  the subject has a valid PKC
>         3)  the subject has a valid AC
>         4)  the AC was issued under an acceptable policy
>         5)  the AC policy qualifier indicates periodic checks that
>                 are weekly, but the relying party would like more
>                 frequent checks
>
>X.509 says:
>
>         The optional qualifiers are not used in the certification path
> processing
>         procedure, but relevant qualifiers are provided as an output of
> that process
>         to the certificate using application to assist in determining
> whether a valid
>         path is appropriate for the particular transaction.
>
>RFC 3280 says:
>
>         Optional qualifiers, which MAY be present, are not expected to
change
>         the definition of the policy.
>
>Your use of qualifier does meet the limits imposed by these documents;
>however, I think that there is a mismatch between the single value in the
>policy qualifier and the potential for more than one attribute in the
>subjectDirectoryAttributes extension or the AC.
>
>Using separate ACs for each attribute would solve this problem, but that
>seems to impose way too much overhead and complexity.
>
>>  > MAJOR CONCERN 4
>> >
>> > Can we use the AuthorityInfoAccess extension to point to the issuer's
>> > repository?  I think it would be straightforward to define an access
>> method
>> > that meets this objective.  Perhaps this is a matter of taste, but it
>> seems
>> > to meet the stated requirement of providing a pointer to the issuer's
>> > repository that otherwise requires the information to be extracted
>> from the
>> > CP or CPS.
>>
>>RFC 3280 states:
>>
>>    The authority information access extension indicates how to access CA
>>    information and services for the issuer of the certificate in which
>>    the extension appears.
>>
>>I do not consider an AA to be a CA and I would not like that we introduce
>>some confusion between a CA and an AA, hence why this extension has not
been
>>created. From RFC 3281: Attribute Authority, the entity that issues the
AC,
>>synonymous in this specification with "AC issuer".
>
>An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to
>have the same distinguished name.
>
>Perhaps I am misunderstanding this whole section of the document, by I
>thought that you want a URI that points to the issuer's repository.  The
>justification provided is that you want to be able to pass a pointer to
>the certificate (either PKC or AC) rather than pass the certificate
>itself.  Clearly, the certificate is already available to the to extract
>the URI in the first place.
>
>> > MAJOR CONCERN 5
>> >
>> > The PKIX working group does not assign object identifiers in the id-ce
>> > arc.  This are is owned by the editor of X.509.
>> >
>> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
>>
>>Thanks. Nobody is perfect.
>
>I certainly make mistakes too.  That is why I value peer review.
>
>> > MAJOR CONCERN 6
>> >
>> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this
>> > document.  The closest that I could find is a requirement that the AA
>> "make
>> > sure that the policy applies to all the attributes."  Without
appropriate
>> > MUST statements, I do not see how a useful service is being provided
>> to the
>> > replying party.
>>
>>It is the very first draft, so yet unpolished.
>
>Apparently sharing my first four major concerns has not altered your
>thinking. So, we can expect a second draft with little change?
>
>Russ



Received: by above.proper.com (8.11.6/8.11.3) id g5HIPq519956 for ietf-pkix-bks; Mon, 17 Jun 2002 11:25:52 -0700 (PDT)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HIPon19951 for <[e-mail]>; Mon, 17 Jun 2002 11:25:50 -0700 (PDT)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id OAA00868; Mon, 17 Jun 2002 14:25:44 -0400
From: "Christopher S. Francis" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: "pkix" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 17 Jun 2002 18:25:44 UT
Subject: RE: Attribute Certificate Policy
Date: Mon, 17 Jun 2002 14:25:44 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thanks for your comments.

I have one more thing to add to Denis' original reply.

Chris
...  snip
> MAJOR CONCERN 2

> Why define a new extension?  Why not simply include the
certificatePolicies
> extension in an attribute certificate?  The two extensions have exactly
the
> same syntax.  I believe that they have the same semantics too.

Not exactly. As indicated above, attributes contained in PKCs MUST be
verified at the time of registration, but nothing would prevent a CA to do
more and to revoke a PKC if an attribute is no more correct. This
information is certainly of some interest for a relying party. The AA should
have a way to indicate this, but since an AC does not contain a CP
extension, this is the reason why a new extension has been created.

[Chris Francis - WetStone Technologies] My first inclination was to simply
use the certificatePolicies extension in an attribute certificate.  A new
extension is useful though because it allows the extension to have the more
targeted purpose of capturing policy items related to binding of attributes
to identity (vs. binding of a public key to an identity).  It seemed that it
would be easier to get agreement on adding a new extension to cover
attributes rather than broadening the scope of the certificatePolicies
extension to allow for its use in attribute certificates.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HIGMO19743 for ietf-pkix-bks; Mon, 17 Jun 2002 11:16:22 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5HIGLn19739 for <[e-mail]>; Mon, 17 Jun 2002 11:16:21 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Jun 2002 18:16:10 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA08122; Mon, 17 Jun 2002 14:16:20 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5HIENJ29957; Mon, 17 Jun 2002 14:14:23 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZPR1W>; Mon, 17 Jun 2002 14:16:18 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZPR1R; Mon, 17 Jun 2002 14:16:10 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 17 Jun 2002 14:14:42 -0400
Subject: Re: Attribute Certificate Policy
In-Reply-To: <[e-mail] .com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

Sharon pointed me to the part of X.509 that prohibits the use of the 
certificatePolicies extension in attribute certificates.  I would rather 
work with the X.509 community to remove this restriction than define a new 
extension with the same syntax and semantics.

Russ


>> > I really dislike this draft.  Since it is written by two people that I
>> > respect, I feel obligated to voice my concerns.
>>
>> > If I wrote down everything that causes me concern in this draft, then the
>> > resulting message would be longer than the draft itself.  For this reason,
>> > I will stick to the major concerns.
>>
>> > MAJOR CONCERN 1
>>
>> > I see no value in adding a acPolicies extension to a PKC that includes the
>> > subjectDirectoryAttributes extension.  The current policy extension 
>> already
>> > handles the whole PKC, including the content of the
>> > subjectDirectoryAttributes extension.  Two policy-related extensions in a
>> > single PKC provides no value to the replying party.
>>
>>I would agree that this is debatable. Attributes contained in PKCs MUST be
>>verified at the time of registration, but nothing would prevent a CA to do
>>more and to revoke a PKC if an attribute is no more correct. This could be
>>in the CP and the CPS may it is not directly machine readable. Hence why it
>>might be interresting to say more. An alternative would be for PKCs to keep
>>the CP extension but to allow to support more qualifiers.
>
>There seem to be three cases to discuss:
>         a)  the attribute is long-lived and unlikely to change,
>         b)  the attribute is long-lived and likely to change, and
>         c)  the attribute is short-lived.
>
>I think that your reply only addresses the first case (a).  I assume that 
>short validity periods will be used when the attribute fits into one of 
>the other two cases (b and c).
>
>So, in the first case, you are using a policy qualifier (yuck) to tell the 
>relying party that the issuer does not expect the attribute to change but 
>that periodic checks will be made just to make sure that everything is as 
>expected.  If an unexpected condition is discovered, then the certificate 
>will be revoked.  I find it hard to believe that the same frequency will 
>be needed for each attribute that might appear in the 
>subjectDirectoryAttributes extension.
>
>> > MAJOR CONCERN 2
>>
>> > Why define a new extension?  Why not simply include the 
>> certificatePolicies
>> > extension in an attribute certificate?  The two extensions have 
>> exactly the
>> > same syntax.  I believe that they have the same semantics too.
>>
>>Not exactly. As indicated above, attributes contained in PKCs MUST be
>>verified at the time of registration, but nothing would prevent a CA to do
>>more and to revoke a PKC if an attribute is no more correct. This
>>information is certainly of some interest for a relying party. The AA should
>>have a way to indicate this, but since an AC does not contain a CP
>>extension, this is the reason why a new extension has been created.
>
>I see nothing in X.509 that prohibits the use of the certificatePolicies 
>extension in an attribute certificate. (There is one place where it says 
>"CA", but if that were replaced with "issuer".)  Maybe I missed something ...
>
>> > MAJOR CONCERN 3
>> >
>> > Why do we need more qualifiers?  The draft RECOMMENDS that policy
>> > information consist of an object identifier, then it defines a pile of
>> > qualifiers.  Further, the information that is contained in the qualifiers
>> > is of very little interest to the relying party.  It is useful to the
>> > issuer.  Why can't the issuer keep this information in a private
>> > database.  Everything that the issuer knows about the subject/holder need
>> > not appear in the certificate.
>>
>>As indicated above, it is useful for relying parties that may get more
>>information, e.g. confidence about the freshness of the attributes.
>
>I do not see it.  You are saying that the relying party will reject an 
>attribute certificate in the following situation:
>
>         1)  the AA has a valid PKC
>         2)  the subject has a valid PKC
>         3)  the subject has a valid AC
>         4)  the AC was issued under an acceptable policy
>         5)  the AC policy qualifier indicates periodic checks that
>                 are weekly, but the relying party would like more
>                 frequent checks
>
>X.509 says:
>
>         The optional qualifiers are not used in the certification path 
> processing
>         procedure, but relevant qualifiers are provided as an output of 
> that process
>         to the certificate using application to assist in determining 
> whether a valid
>         path is appropriate for the particular transaction.
>
>RFC 3280 says:
>
>         Optional qualifiers, which MAY be present, are not expected to change
>         the definition of the policy.
>
>Your use of qualifier does meet the limits imposed by these documents; 
>however, I think that there is a mismatch between the single value in the 
>policy qualifier and the potential for more than one attribute in the 
>subjectDirectoryAttributes extension or the AC.
>
>Using separate ACs for each attribute would solve this problem, but that 
>seems to impose way too much overhead and complexity.
>
>>  > MAJOR CONCERN 4
>> >
>> > Can we use the AuthorityInfoAccess extension to point to the issuer's
>> > repository?  I think it would be straightforward to define an access 
>> method
>> > that meets this objective.  Perhaps this is a matter of taste, but it 
>> seems
>> > to meet the stated requirement of providing a pointer to the issuer's
>> > repository that otherwise requires the information to be extracted 
>> from the
>> > CP or CPS.
>>
>>RFC 3280 states:
>>
>>    The authority information access extension indicates how to access CA
>>    information and services for the issuer of the certificate in which
>>    the extension appears.
>>
>>I do not consider an AA to be a CA and I would not like that we introduce
>>some confusion between a CA and an AA, hence why this extension has not been
>>created. From RFC 3281: Attribute Authority, the entity that issues the AC,
>>synonymous in this specification with "AC issuer".
>
>An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to 
>have the same distinguished name.
>
>Perhaps I am misunderstanding this whole section of the document, by I 
>thought that you want a URI that points to the issuer's repository.  The 
>justification provided is that you want to be able to pass a pointer to 
>the certificate (either PKC or AC) rather than pass the certificate 
>itself.  Clearly, the certificate is already available to the to extract 
>the URI in the first place.
>
>> > MAJOR CONCERN 5
>> >
>> > The PKIX working group does not assign object identifiers in the id-ce
>> > arc.  This are is owned by the editor of X.509.
>> >
>> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
>>
>>Thanks. Nobody is perfect.
>
>I certainly make mistakes too.  That is why I value peer review.
>
>> > MAJOR CONCERN 6
>> >
>> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this
>> > document.  The closest that I could find is a requirement that the AA 
>> "make
>> > sure that the policy applies to all the attributes."  Without appropriate
>> > MUST statements, I do not see how a useful service is being provided 
>> to the
>> > replying party.
>>
>>It is the very first draft, so yet unpolished.
>
>Apparently sharing my first four major concerns has not altered your 
>thinking. So, we can expect a second draft with little change?
>
>Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HI78p19441 for ietf-pkix-bks; Mon, 17 Jun 2002 11:07:08 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5HI76n19437 for <[e-mail]>; Mon, 17 Jun 2002 11:07:07 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Jun 2002 18:06:55 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA07078; Mon, 17 Jun 2002 14:07:06 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5HI59o28726; Mon, 17 Jun 2002 14:05:09 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZPQ0L>; Mon, 17 Jun 2002 14:07:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZPQ0J; Mon, 17 Jun 2002 14:06:58 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 17 Jun 2002 14:02:41 -0400
Subject: Re: Attribute Certificate Policy
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

> > I really dislike this draft.  Since it is written by two people that I
> > respect, I feel obligated to voice my concerns.
>
> > If I wrote down everything that causes me concern in this draft, then the
> > resulting message would be longer than the draft itself.  For this reason,
> > I will stick to the major concerns.
>
> > MAJOR CONCERN 1
>
> > I see no value in adding a acPolicies extension to a PKC that includes the
> > subjectDirectoryAttributes extension.  The current policy extension already
> > handles the whole PKC, including the content of the
> > subjectDirectoryAttributes extension.  Two policy-related extensions in a
> > single PKC provides no value to the replying party.
>
>I would agree that this is debatable. Attributes contained in PKCs MUST be
>verified at the time of registration, but nothing would prevent a CA to do
>more and to revoke a PKC if an attribute is no more correct. This could be
>in the CP and the CPS may it is not directly machine readable. Hence why it
>might be interresting to say more. An alternative would be for PKCs to keep
>the CP extension but to allow to support more qualifiers.

There seem to be three cases to discuss:
         a)  the attribute is long-lived and unlikely to change,
         b)  the attribute is long-lived and likely to change, and
         c)  the attribute is short-lived.

I think that your reply only addresses the first case (a).  I assume that 
short validity periods will be used when the attribute fits into one of the 
other two cases (b and c).

So, in the first case, you are using a policy qualifier (yuck) to tell the 
relying party that the issuer does not expect the attribute to change but 
that periodic checks will be made just to make sure that everything is as 
expected.  If an unexpected condition is discovered, then the certificate 
will be revoked.  I find it hard to believe that the same frequency will be 
needed for each attribute that might appear in the 
subjectDirectoryAttributes extension.

> > MAJOR CONCERN 2
>
> > Why define a new extension?  Why not simply include the certificatePolicies
> > extension in an attribute certificate?  The two extensions have exactly the
> > same syntax.  I believe that they have the same semantics too.
>
>Not exactly. As indicated above, attributes contained in PKCs MUST be
>verified at the time of registration, but nothing would prevent a CA to do
>more and to revoke a PKC if an attribute is no more correct. This
>information is certainly of some interest for a relying party. The AA should
>have a way to indicate this, but since an AC does not contain a CP
>extension, this is the reason why a new extension has been created.

I see nothing in X.509 that prohibits the use of the certificatePolicies 
extension in an attribute certificate. (There is one place where it says 
"CA", but if that were replaced with "issuer".)  Maybe I missed something ...

> > MAJOR CONCERN 3
> >
> > Why do we need more qualifiers?  The draft RECOMMENDS that policy
> > information consist of an object identifier, then it defines a pile of
> > qualifiers.  Further, the information that is contained in the qualifiers
> > is of very little interest to the relying party.  It is useful to the
> > issuer.  Why can't the issuer keep this information in a private
> > database.  Everything that the issuer knows about the subject/holder need
> > not appear in the certificate.
>
>As indicated above, it is useful for relying parties that may get more
>information, e.g. confidence about the freshness of the attributes.

I do not see it.  You are saying that the relying party will reject an 
attribute certificate in the following situation:

         1)  the AA has a valid PKC
         2)  the subject has a valid PKC
         3)  the subject has a valid AC
         4)  the AC was issued under an acceptable policy
         5)  the AC policy qualifier indicates periodic checks that
                 are weekly, but the relying party would like more
                 frequent checks

X.509 says:

         The optional qualifiers are not used in the certification path 
processing
         procedure, but relevant qualifiers are provided as an output of 
that process
         to the certificate using application to assist in determining 
whether a valid
         path is appropriate for the particular transaction.

RFC 3280 says:

         Optional qualifiers, which MAY be present, are not expected to change
         the definition of the policy.

Your use of qualifier does meet the limits imposed by these documents; 
however, I think that there is a mismatch between the single value in the 
policy qualifier and the potential for more than one attribute in the 
subjectDirectoryAttributes extension or the AC.

Using separate ACs for each attribute would solve this problem, but that 
seems to impose way too much overhead and complexity.

>  > MAJOR CONCERN 4
> >
> > Can we use the AuthorityInfoAccess extension to point to the issuer's
> > repository?  I think it would be straightforward to define an access method
> > that meets this objective.  Perhaps this is a matter of taste, but it seems
> > to meet the stated requirement of providing a pointer to the issuer's
> > repository that otherwise requires the information to be extracted from the
> > CP or CPS.
>
>RFC 3280 states:
>
>    The authority information access extension indicates how to access CA
>    information and services for the issuer of the certificate in which
>    the extension appears.
>
>I do not consider an AA to be a CA and I would not like that we introduce
>some confusion between a CA and an AA, hence why this extension has not been
>created. From RFC 3281: Attribute Authority, the entity that issues the AC,
>synonymous in this specification with "AC issuer".

An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to 
have the same distinguished name.

Perhaps I am misunderstanding this whole section of the document, by I 
thought that you want a URI that points to the issuer's repository.  The 
justification provided is that you want to be able to pass a pointer to the 
certificate (either PKC or AC) rather than pass the certificate 
itself.  Clearly, the certificate is already available to the to extract 
the URI in the first place.

> > MAJOR CONCERN 5
> >
> > The PKIX working group does not assign object identifiers in the id-ce
> > arc.  This are is owned by the editor of X.509.
> >
> >     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
>
>Thanks. Nobody is perfect.

I certainly make mistakes too.  That is why I value peer review.

> > MAJOR CONCERN 6
> >
> > The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this
> > document.  The closest that I could find is a requirement that the AA "make
> > sure that the policy applies to all the attributes."  Without appropriate
> > MUST statements, I do not see how a useful service is being provided to the
> > replying party.
>
>It is the very first draft, so yet unpolished.

Apparently sharing my first four major concerns has not altered your 
thinking. So, we can expect a second draft with little change?

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HGnSE16088 for ietf-pkix-bks; Mon, 17 Jun 2002 09:49:28 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HGnRn16084 for <[e-mail]>; Mon, 17 Jun 2002 09:49:27 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA38390; Mon, 17 Jun 2002 18:53:08 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061718482146:542 ; Mon, 17 Jun 2002 18:48:21 +0200 
Message-ID: <[e-mail]>
Date: Mon, 17 Jun 2002 18:48:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], pkix <[e-mail]>
Subject: Re: Attribute Certificate Policy
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/06/2002 18:48:21, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/06/2002 18:48:49, Serialize complete at 17/06/2002 18:48:49
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

First of all, thank you for taking the time to read this draft.
 
> Denis & Chris:
 
> I really dislike this draft.  Since it is written by two people that I
> respect, I feel obligated to voice my concerns.
 
> If I wrote down everything that causes me concern in this draft, then the
> resulting message would be longer than the draft itself.  For this reason,
> I will stick to the major concerns.
 
> MAJOR CONCERN 1
 
> I see no value in adding a acPolicies extension to a PKC that includes the
> subjectDirectoryAttributes extension.  The current policy extension already
> handles the whole PKC, including the content of the
> subjectDirectoryAttributes extension.  Two policy-related extensions in a
> single PKC provides no value to the replying party.

I would agree that this is debatable. Attributes contained in PKCs MUST be
verified at the time of registration, but nothing would prevent a CA to do
more and to revoke a PKC if an attribute is no more correct. This could be
in the CP and the CPS may it is not directly machine readable. Hence why it
might be interresting to say more. An alternative would be for PKCs to keep
the CP extension but to allow to support more qualifiers. 
 
> MAJOR CONCERN 2
 
> Why define a new extension?  Why not simply include the certificatePolicies
> extension in an attribute certificate?  The two extensions have exactly the
> same syntax.  I believe that they have the same semantics too.

Not exactly. As indicated above, attributes contained in PKCs MUST be
verified at the time of registration, but nothing would prevent a CA to do
more and to revoke a PKC if an attribute is no more correct. This
information is certainly of some interest for a relying party. The AA should
have a way to indicate this, but since an AC does not contain a CP
extension, this is the reason why a new extension has been created.

> MAJOR CONCERN 3
> 
> Why do we need more qualifiers?  The draft RECOMMENDS that policy
> information consist of an object identifier, then it defines a pile of
> qualifiers.  Further, the information that is contained in the qualifiers
> is of very little interest to the relying party.  It is useful to the
> issuer.  Why can't the issuer keep this information in a private
> database.  Everything that the issuer knows about the subject/holder need
> not appear in the certificate.

As indicated above, it is useful for relying parties that may get more
information, e.g. confidence about the freshness of the attributes.  
 
> MAJOR CONCERN 4
> 
> Can we use the AuthorityInfoAccess extension to point to the issuer's
> repository?  I think it would be straightforward to define an access method
> that meets this objective.  Perhaps this is a matter of taste, but it seems
> to meet the stated requirement of providing a pointer to the issuer's
> repository that otherwise requires the information to be extracted from the
> CP or CPS.

RFC 3280 states:

   The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. 

I do not consider an AA to be a CA and I would not like that we introduce
some confusion between a CA and an AA, hence why this extension has not been
created. From RFC 3281: Attribute Authority, the entity that issues the AC,
synonymous in this specification with "AC issuer".

> MAJOR CONCERN 5
> 
> The PKIX working group does not assign object identifiers in the id-ce
> arc.  This are is owned by the editor of X.509.
> 
>     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }

Thanks. Nobody is perfect.
 
> MAJOR CONCERN 6
> 
> The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this
> document.  The closest that I could find is a requirement that the AA "make
> sure that the policy applies to all the attributes."  Without appropriate
> MUST statements, I do not see how a useful service is being provided to the
> replying party.

It is the very first draft, so yet unpolished.

Denis
 
> Russ
> 
> At 09:36 AM 6/14/2002 +0200, Denis Pinkas wrote:
> 
> >On March 5, the following message was sent to the list by Christopher
> >Francis:
> >
> >"Is there a defined mechanism to specify something analogous to a
> >certificate policy in an attribute certificate ?
> >
> >In reviewing the PKIX AC profile, I see that the syntax of the
> >attributes field is defined by the AttributeType OID, but rather than
> >syntax per se, I'm looking for a way to specify the particular set of
> >policies, practices, and procedures that the attribute authority
> >was operating under when it issued the attribute certificate.
> >Seems like this would be important to relying parties."
> >
> >Several e-mails have then been exchanged on the list. As a result of
> >these exchanges, Chris and myself have undertaken the writing of a draft
> >to define an extension to support an Attribute Certificate Policy.
> >
> >The document is available from :
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt
> >
> >Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HGJwk15437 for ietf-pkix-bks; Mon, 17 Jun 2002 09:19:58 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5HGJun15433 for <[e-mail]>; Mon, 17 Jun 2002 09:19:56 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Jun 2002 16:19:45 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA23900; Mon, 17 Jun 2002 12:19:54 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5HGHv213087; Mon, 17 Jun 2002 12:17:57 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZPPCB>; Mon, 17 Jun 2002 12:19:53 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.17]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZPPB5; Mon, 17 Jun 2002 12:19:38 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 17 Jun 2002 12:19:35 -0400
Subject: Re: Attribute Certificate Policy
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis & Chris:

I really dislike this draft.  Since it is written by two people that I 
respect, I feel obligated to voice my concerns.

If I wrote down everything that causes me concern in this draft, then the 
resulting message would be longer than the draft itself.  For this reason, 
I will stick to the major concerns.

MAJOR CONCERN 1

I see no value in adding a acPolicies extension to a PKC that includes the 
subjectDirectoryAttributes extension.  The current policy extension already 
handles the whole PKC, including the content of the 
subjectDirectoryAttributes extension.  Two policy-related extensions in a 
single PKC provides no value to the replying party.

MAJOR CONCERN 2

Why define a new extension?  Why not simply include the certificatePolicies 
extension in an attribute certificate?  The two extensions have exactly the 
same syntax.  I believe that they have the same semantics too.

MAJOR CONCERN 3

Why do we need more qualifiers?  The draft RECOMMENDS that policy 
information consist of an object identifier, then it defines a pile of 
qualifiers.  Further, the information that is contained in the qualifiers 
is of very little interest to the relying party.  It is useful to the 
issuer.  Why can't the issuer keep this information in a private 
database.  Everything that the issuer knows about the subject/holder need 
not appear in the certificate.

MAJOR CONCERN 4

Can we use the AuthorityInfoAccess extension to point to the issuer's 
repository?  I think it would be straightforward to define an access method 
that meets this objective.  Perhaps this is a matter of taste, but it seems 
to meet the stated requirement of providing a pointer to the issuer's 
repository that otherwise requires the information to be extracted from the 
CP or CPS.

MAJOR CONCERN 5

The PKIX working group does not assign object identifiers in the id-ce 
arc.  This are is owned by the editor of X.509.

    id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }

MAJOR CONCERN 6

The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this 
document.  The closest that I could find is a requirement that the AA "make 
sure that the policy applies to all the attributes."  Without appropriate 
MUST statements, I do not see how a useful service is being provided to the 
replying party.

Russ

At 09:36 AM 6/14/2002 +0200, Denis Pinkas wrote:


>On March 5, the following message was sent to the list by Christopher
>Francis:
>
>"Is there a defined mechanism to specify something analogous to a
>certificate policy in an attribute certificate ?
>
>In reviewing the PKIX AC profile, I see that the syntax of the
>attributes field is defined by the AttributeType OID, but rather than
>syntax per se, I'm looking for a way to specify the particular set of
>policies, practices, and procedures that the attribute authority
>was operating under when it issued the attribute certificate.
>Seems like this would be important to relying parties."
>
>Several e-mails have then been exchanged on the list. As a result of
>these exchanges, Chris and myself have undertaken the writing of a draft
>to define an extension to support an Attribute Certificate Policy.
>
>The document is available from :
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt
>
>Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HD2LF04034 for ietf-pkix-bks; Mon, 17 Jun 2002 06:02:21 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HD2In04030 for <[e-mail]>; Mon, 17 Jun 2002 06:02:18 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <MZYNFRG3>; Mon, 17 Jun 2002 09:01:58 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: "Hoyt L. Kesterson II" <[e-mail]>, Erik Andersen <[e-mail]>, "'Laurence Lundblade'" <[e-mail]>, Bruce Stephens <[e-mail]>, [e-mail]
Subject: RE: DN comparison
Date: Mon, 17 Jun 2002 09:01:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C215FF.29623160"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

------_=_NextPart_001_01C215FF.29623160
Content-Type: text/plain

Tom I agree that it should be clarified in 501 and will follow up with 
Hoyt/Erik to get a DR started.

Thanks, 

Sharon

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Friday, June 14, 2002 6:00 PM
To: Sharon Boeyen
Cc: Hoyt L. Kesterson II; Erik Andersen; 'Laurence Lundblade'; Bruce
Stephens; [e-mail]
Subject: RE: DN comparison



      Sharon:

      Clearly, your answer among my alternatives is that treating
"corresponding" to mean "with the same set of attribute types" is
forbidden, even after making that interpretation workable by matching the
attribute type and relative position within occurrences of that type
instead of the attribute type alone.  The term "corresponding" does not
unambiguously mean "in the same position".  It could equally well mean
"matching the same criterion", and I was suggesting a criterion which would
give slightly more useful semantic results than the rule which is used for
directory lookup.
      I hope this will be an adequate explanation of why X.501needs to be
clarified.  If it isn't, somebody might implement an interpretation of the
matching rule similar to the one I suggested.

            Tom Gindin


Sharon Boeyen <[e-mail]> on 06/13/2002 09:41:36 AM

To:    Tom Gindin/Watson/IBM@IBMUS, Sharon Boeyen
       <[e-mail]>
cc:    "'Laurence Lundblade'" <[e-mail]>, Bruce Stephens
       <[e-mail]>, [e-mail], "Erik
       Andersen (E-mail)" <[e-mail]>
Subject:    RE: DN comparison


DNs are hierarchical names (again regardless of whether they appear in a
directory or not) and corresponding RDNs are RDNs that are in the same
position of that hierarchy (in the same position in the sequence of the
syntax).
The attribute types that happen to be used in RDNs are completely
irrelevant
from the standpoint of determining which RDNs are 'corresponding'. However,
the
attribute type&value pair(s) that appear within corresponding RDNs (in the
same element
of the SEQUENCE) must be the same. The order of those attribute type&value
pairs within
a specific multivalued RDN does not need to be the same, but the order of
RDNs in the DN
must be the same.

If that needs clarification, I'm sure we can add a note to 501 through a
defect
report. I copied Erik (the editor & ITU Rapporteur) and Hoyt (the ISO
Rapporteur and
DR registrar) to see if we can get the DR going.


Sharon


-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 4:26 PM
To: Sharon Boeyen
Cc: 'Laurence Lundblade'; Bruce Stephens; [e-mail]
Subject: RE: DN comparison






      Sharon:


      IMHO the thing which most needs to be clarified in this regard is not

in X.509 at all, but rather the term "corresponding RDN" in section 13.5.2
of X.501(and also in section 9.4).  Is the "corresponding RDN" of a given
RDN in the presented DN the RDN which occupies the same position or is it
the RDN which has the same set of attribute types (with a caveat about
attribute types which occur more than once in a DN)?  Until that's cleared
up, references to the matching rule may not make the responsibilities of an

implementor any clearer.
      Laurence's example with multiple occurrences of the OU attribute is
the closest I've seen to a plausible example in which re-ordering RDN's
could cause two DN's which really refer to different entities to match
inappropriately.  Following one of his hints, a similar and slightly
stronger example could be constructed with multiple occurrences of the DC
attribute as well (DC=com, DC=company, DC=fr vs. DC=fr, DC=company, DC=com
representing the quite legal DNS names fr.company.com and com.company.fr).
However, AFAIK nobody has shown an example in which re-ordering RDN's with
different attribute structures would do this.
      If I were to locate the "corresponding RDN" by a heuristic which said

that two RDN's correspond if they have the same set of attribute types and
if any of those attribute types occur more than once in a DN, the relative
position of the occurrence of the attribute type in each DN is the same, I
would not produce any obviously perverse results but I would match C=CA,
ST=ON, L=Ottawa, O=Entrust with C=CA, O=Entrust, ST=ON, L=Ottawa.  I think
that's why we need clarity as to whether this heuristic is required,
permitted, or forbidden as an interpretation of the term corresponding RDN
within distinguishedNameMatch.


            Tom Gindin





Sharon Boeyen <[e-mail]> on 06/12/2002 10:53:16 AM


To:    "'Laurence Lundblade'" <[e-mail]>, Tom
       Gindin/Watson/IBM@IBMUS, Bruce Stephens
       <[e-mail]>
cc:    [e-mail]
Subject:    RE: DN comparison





Just to close one loop in this discussion, I want to let you know that
although X.509
didn't have any specific text on this topic previously that is being
changed and the following
changes are being made in current working document. This ties the matching
of DNs in 509
to the X.501 matching rule and outlines where the matches occur. Note that
this applies
regardless of whether or not those DNs in certificates ever get
instantiated as directory
entries.





Here are the upcoming changes to X.509 on this topic:





1 The following text will be added to clause 7 of X.509:





The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.
X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the

issuer field of one certificate with the DN in the subject field of
another.





2 In clause 8.6.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The distributionPoint

component contains.":





If the certificate in question contains a cRLDistributionPoints extension
and the CRL contains an issuingDistributionPoint extension, at least one
name for the distribution point as indicated in the certificate shall match

a name for the distribution point as indicated in the CRL. Note that in
both the certificate and CRL there are default names that may apply to the
distribution point, namely the DN of the CRL issuer (found in the issuer
field of the CRL). Also, it may be the case that only the
nameRelativeToCRLIssuer field is present. In that case, a name comparison
would be done on the full DN, constructed by appending the value of the
nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.  If

the names being compared are DNs (as opposed to names of other forms within

the GeneralNames construct), the distinguishedNameMatch matching rule is
used to compare the two DNs for equality.






3 In clause 8.4.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The maximum field
specifies the lower bound ."





For the directoryName name form, a certificate is considered subordinate to

the base
(and therefore a candidate to be within the subtree) if the SEQUENCE of
RDNs, which forms the full DN in base, is identical to the initial SEQUENCE

of the same number of RDNs which forms the first part of the DN in the
subject field of the certificate. The DN in the subject field of the
certificate may have additional trailing RDNs in its sequence that do not
appear in the DN in base.





The distinguishedNameMatch matching rule is used to compare the value of
base  with the initial sequence of RDNs in the DN in the subject field of
the certificate.








-----Original Message-----
From: Laurence Lundblade [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [e-mail]
Subject: Re: DN comparison









At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:
>       Bruce:
>
>       I know, and I think many of us do, that a DN's original use is as
an
>index to an X.500 or LDAP entry, that these are tree-structured databases,


>and that DN's are defined in X.501 as ordered sets (or sequences) of
RDN's.
>However, I would like to see someone come up with a plausible example of
>two DN's which consist of different orderings of the same set of RDN's
>while referring to different entities.  Your point about directory access
>properties is valid, but is hardly relevant to a comparison of two
>different DN's.





In the DNS world order is pretty important as seen from my previous example


of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the
DNS world though I think because the parts of the domain name aren't
tagged. Given that hint how about this example?





(ou=finance)(ou=it)(o=moderatelyconfused)
(ou=it)(ou=finance)(o=moderatelyconfused)





IT can have it's own finance department and finance can have it's own IT
department.





On the parsing implementation side dealing with a SEQUENCE is easier than a


SET as someone already mentioned. Dunno about the server/CA side
implementation.





Didn't seem that anyone is seriously considering changing this, but the
fact that it could matter, that a change would complicate implementations a


little, and a change would add more confusion (let me personally serve as
an example of confusion :-), it seems a change would be very bad.





LL



------_=_NextPart_001_01C215FF.29623160
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: DN comparison</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Tom I agree that it should be clarified in 501 and will follow up with </FONT>
<BR><FONT SIZE=2>Hoyt/Erik to get a DR started.</FONT>
</P>

<P><FONT SIZE=2>Thanks, </FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Tom Gindin [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, June 14, 2002 6:00 PM</FONT>
<BR><FONT SIZE=2>To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>Cc: Hoyt L. Kesterson II; Erik Andersen; 'Laurence Lundblade'; Bruce</FONT>
<BR><FONT SIZE=2>Stephens; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: DN comparison</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sharon:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Clearly, your answer among my alternatives is that treating</FONT>
<BR><FONT SIZE=2>&quot;corresponding&quot; to mean &quot;with the same set of attribute types&quot; is</FONT>
<BR><FONT SIZE=2>forbidden, even after making that interpretation workable by matching the</FONT>
<BR><FONT SIZE=2>attribute type and relative position within occurrences of that type</FONT>
<BR><FONT SIZE=2>instead of the attribute type alone.&nbsp; The term &quot;corresponding&quot; does not</FONT>
<BR><FONT SIZE=2>unambiguously mean &quot;in the same position&quot;.&nbsp; It could equally well mean</FONT>
<BR><FONT SIZE=2>&quot;matching the same criterion&quot;, and I was suggesting a criterion which would</FONT>
<BR><FONT SIZE=2>give slightly more useful semantic results than the rule which is used for</FONT>
<BR><FONT SIZE=2>directory lookup.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I hope this will be an adequate explanation of why X.501needs to be</FONT>
<BR><FONT SIZE=2>clarified.&nbsp; If it isn't, somebody might implement an interpretation of the</FONT>
<BR><FONT SIZE=2>matching rule similar to the one I suggested.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom Gindin</FONT>
</P>
<BR>

<P><FONT SIZE=2>Sharon Boeyen &lt;[e-mail]&gt; on 06/13/2002 09:41:36 AM</FONT>
</P>

<P><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp; Tom Gindin/Watson/IBM@IBMUS, Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>cc:&nbsp;&nbsp;&nbsp; &quot;'Laurence Lundblade'&quot; &lt;[e-mail]&gt;, Bruce Stephens</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;, [e-mail], &quot;Erik</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Andersen (E-mail)&quot; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp; RE: DN comparison</FONT>
</P>
<BR>

<P><FONT SIZE=2>DNs are hierarchical names (again regardless of whether they appear in a</FONT>
<BR><FONT SIZE=2>directory or not) and corresponding RDNs are RDNs that are in the same</FONT>
<BR><FONT SIZE=2>position of that hierarchy (in the same position in the sequence of the</FONT>
<BR><FONT SIZE=2>syntax).</FONT>
<BR><FONT SIZE=2>The attribute types that happen to be used in RDNs are completely</FONT>
<BR><FONT SIZE=2>irrelevant</FONT>
<BR><FONT SIZE=2>from the standpoint of determining which RDNs are 'corresponding'. However,</FONT>
<BR><FONT SIZE=2>the</FONT>
<BR><FONT SIZE=2>attribute type&amp;value pair(s) that appear within corresponding RDNs (in the</FONT>
<BR><FONT SIZE=2>same element</FONT>
<BR><FONT SIZE=2>of the SEQUENCE) must be the same. The order of those attribute type&amp;value</FONT>
<BR><FONT SIZE=2>pairs within</FONT>
<BR><FONT SIZE=2>a specific multivalued RDN does not need to be the same, but the order of</FONT>
<BR><FONT SIZE=2>RDNs in the DN</FONT>
<BR><FONT SIZE=2>must be the same.</FONT>
</P>

<P><FONT SIZE=2>If that needs clarification, I'm sure we can add a note to 501 through a</FONT>
<BR><FONT SIZE=2>defect</FONT>
<BR><FONT SIZE=2>report. I copied Erik (the editor &amp; ITU Rapporteur) and Hoyt (the ISO</FONT>
<BR><FONT SIZE=2>Rapporteur and</FONT>
<BR><FONT SIZE=2>DR registrar) to see if we can get the DR going.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Sharon</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Tom Gindin [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, June 12, 2002 4:26 PM</FONT>
<BR><FONT SIZE=2>To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>Cc: 'Laurence Lundblade'; Bruce Stephens; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: DN comparison</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sharon:</FONT>
</P>
<BR>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMHO the thing which most needs to be clarified in this regard is not</FONT>
</P>

<P><FONT SIZE=2>in X.509 at all, but rather the term &quot;corresponding RDN&quot; in section 13.5.2</FONT>
<BR><FONT SIZE=2>of X.501(and also in section 9.4).&nbsp; Is the &quot;corresponding RDN&quot; of a given</FONT>
<BR><FONT SIZE=2>RDN in the presented DN the RDN which occupies the same position or is it</FONT>
<BR><FONT SIZE=2>the RDN which has the same set of attribute types (with a caveat about</FONT>
<BR><FONT SIZE=2>attribute types which occur more than once in a DN)?&nbsp; Until that's cleared</FONT>
<BR><FONT SIZE=2>up, references to the matching rule may not make the responsibilities of an</FONT>
</P>

<P><FONT SIZE=2>implementor any clearer.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Laurence's example with multiple occurrences of the OU attribute is</FONT>
<BR><FONT SIZE=2>the closest I've seen to a plausible example in which re-ordering RDN's</FONT>
<BR><FONT SIZE=2>could cause two DN's which really refer to different entities to match</FONT>
<BR><FONT SIZE=2>inappropriately.&nbsp; Following one of his hints, a similar and slightly</FONT>
<BR><FONT SIZE=2>stronger example could be constructed with multiple occurrences of the DC</FONT>
<BR><FONT SIZE=2>attribute as well (DC=com, DC=company, DC=fr vs. DC=fr, DC=company, DC=com</FONT>
<BR><FONT SIZE=2>representing the quite legal DNS names fr.company.com and com.company.fr).</FONT>
<BR><FONT SIZE=2>However, AFAIK nobody has shown an example in which re-ordering RDN's with</FONT>
<BR><FONT SIZE=2>different attribute structures would do this.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If I were to locate the &quot;corresponding RDN&quot; by a heuristic which said</FONT>
</P>

<P><FONT SIZE=2>that two RDN's correspond if they have the same set of attribute types and</FONT>
<BR><FONT SIZE=2>if any of those attribute types occur more than once in a DN, the relative</FONT>
<BR><FONT SIZE=2>position of the occurrence of the attribute type in each DN is the same, I</FONT>
<BR><FONT SIZE=2>would not produce any obviously perverse results but I would match C=CA,</FONT>
<BR><FONT SIZE=2>ST=ON, L=Ottawa, O=Entrust with C=CA, O=Entrust, ST=ON, L=Ottawa.&nbsp; I think</FONT>
<BR><FONT SIZE=2>that's why we need clarity as to whether this heuristic is required,</FONT>
<BR><FONT SIZE=2>permitted, or forbidden as an interpretation of the term corresponding RDN</FONT>
<BR><FONT SIZE=2>within distinguishedNameMatch.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom Gindin</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Sharon Boeyen &lt;[e-mail]&gt; on 06/12/2002 10:53:16 AM</FONT>
</P>
<BR>

<P><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp; &quot;'Laurence Lundblade'&quot; &lt;[e-mail]&gt;, Tom</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gindin/Watson/IBM@IBMUS, Bruce Stephens</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>cc:&nbsp;&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp; RE: DN comparison</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Just to close one loop in this discussion, I want to let you know that</FONT>
<BR><FONT SIZE=2>although X.509</FONT>
<BR><FONT SIZE=2>didn't have any specific text on this topic previously that is being</FONT>
<BR><FONT SIZE=2>changed and the following</FONT>
<BR><FONT SIZE=2>changes are being made in current working document. This ties the matching</FONT>
<BR><FONT SIZE=2>of DNs in 509</FONT>
<BR><FONT SIZE=2>to the X.501 matching rule and outlines where the matches occur. Note that</FONT>
<BR><FONT SIZE=2>this applies</FONT>
<BR><FONT SIZE=2>regardless of whether or not those DNs in certificates ever get</FONT>
<BR><FONT SIZE=2>instantiated as directory</FONT>
<BR><FONT SIZE=2>entries.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Here are the upcoming changes to X.509 on this topic:</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>1 The following text will be added to clause 7 of X.509:</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.</FONT>
<BR><FONT SIZE=2>X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the</FONT>
</P>

<P><FONT SIZE=2>issuer field of one certificate with the DN in the subject field of</FONT>
<BR><FONT SIZE=2>another.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>2 In clause 8.6.2.2, the following will be added as a new paragraph</FONT>
<BR><FONT SIZE=2>immediately following the paragraph that begins with &quot;The distributionPoint</FONT>
</P>

<P><FONT SIZE=2>component contains.&quot;:</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>If the certificate in question contains a cRLDistributionPoints extension</FONT>
<BR><FONT SIZE=2>and the CRL contains an issuingDistributionPoint extension, at least one</FONT>
<BR><FONT SIZE=2>name for the distribution point as indicated in the certificate shall match</FONT>
</P>

<P><FONT SIZE=2>a name for the distribution point as indicated in the CRL. Note that in</FONT>
<BR><FONT SIZE=2>both the certificate and CRL there are default names that may apply to the</FONT>
<BR><FONT SIZE=2>distribution point, namely the DN of the CRL issuer (found in the issuer</FONT>
<BR><FONT SIZE=2>field of the CRL). Also, it may be the case that only the</FONT>
<BR><FONT SIZE=2>nameRelativeToCRLIssuer field is present. In that case, a name comparison</FONT>
<BR><FONT SIZE=2>would be done on the full DN, constructed by appending the value of the</FONT>
<BR><FONT SIZE=2>nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.&nbsp; If</FONT>
</P>

<P><FONT SIZE=2>the names being compared are DNs (as opposed to names of other forms within</FONT>
</P>

<P><FONT SIZE=2>the GeneralNames construct), the distinguishedNameMatch matching rule is</FONT>
<BR><FONT SIZE=2>used to compare the two DNs for equality.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>3 In clause 8.4.2.2, the following will be added as a new paragraph</FONT>
<BR><FONT SIZE=2>immediately following the paragraph that begins with &quot;The maximum field</FONT>
<BR><FONT SIZE=2>specifies the lower bound .&quot;</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>For the directoryName name form, a certificate is considered subordinate to</FONT>
</P>

<P><FONT SIZE=2>the base</FONT>
<BR><FONT SIZE=2>(and therefore a candidate to be within the subtree) if the SEQUENCE of</FONT>
<BR><FONT SIZE=2>RDNs, which forms the full DN in base, is identical to the initial SEQUENCE</FONT>
</P>

<P><FONT SIZE=2>of the same number of RDNs which forms the first part of the DN in the</FONT>
<BR><FONT SIZE=2>subject field of the certificate. The DN in the subject field of the</FONT>
<BR><FONT SIZE=2>certificate may have additional trailing RDNs in its sequence that do not</FONT>
<BR><FONT SIZE=2>appear in the DN in base.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>The distinguishedNameMatch matching rule is used to compare the value of</FONT>
<BR><FONT SIZE=2>base&nbsp; with the initial sequence of RDNs in the DN in the subject field of</FONT>
<BR><FONT SIZE=2>the certificate.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Laurence Lundblade [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, June 12, 2002 10:39 AM</FONT>
<BR><FONT SIZE=2>To: Tom Gindin; Bruce Stephens</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: DN comparison</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bruce:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I know, and I think many of us do, that a DN's original use is as</FONT>
<BR><FONT SIZE=2>an</FONT>
<BR><FONT SIZE=2>&gt;index to an X.500 or LDAP entry, that these are tree-structured databases,</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;and that DN's are defined in X.501 as ordered sets (or sequences) of</FONT>
<BR><FONT SIZE=2>RDN's.</FONT>
<BR><FONT SIZE=2>&gt;However, I would like to see someone come up with a plausible example of</FONT>
<BR><FONT SIZE=2>&gt;two DN's which consist of different orderings of the same set of RDN's</FONT>
<BR><FONT SIZE=2>&gt;while referring to different entities.&nbsp; Your point about directory access</FONT>
<BR><FONT SIZE=2>&gt;properties is valid, but is hardly relevant to a comparison of two</FONT>
<BR><FONT SIZE=2>&gt;different DN's.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>In the DNS world order is pretty important as seen from my previous example</FONT>
</P>
<BR>

<P><FONT SIZE=2>of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the</FONT>
<BR><FONT SIZE=2>DNS world though I think because the parts of the domain name aren't</FONT>
<BR><FONT SIZE=2>tagged. Given that hint how about this example?</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>(ou=finance)(ou=it)(o=moderatelyconfused)</FONT>
<BR><FONT SIZE=2>(ou=it)(ou=finance)(o=moderatelyconfused)</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>IT can have it's own finance department and finance can have it's own IT</FONT>
<BR><FONT SIZE=2>department.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>On the parsing implementation side dealing with a SEQUENCE is easier than a</FONT>
</P>
<BR>

<P><FONT SIZE=2>SET as someone already mentioned. Dunno about the server/CA side</FONT>
<BR><FONT SIZE=2>implementation.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>Didn't seem that anyone is seriously considering changing this, but the</FONT>
<BR><FONT SIZE=2>fact that it could matter, that a change would complicate implementations a</FONT>
</P>
<BR>

<P><FONT SIZE=2>little, and a change would add more confusion (let me personally serve as</FONT>
<BR><FONT SIZE=2>an example of confusion :-), it seems a change would be very bad.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>LL</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C215FF.29623160--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HCZ5o02091 for ietf-pkix-bks; Mon, 17 Jun 2002 05:35:05 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HCZ4n02085 for <[e-mail]>; Mon, 17 Jun 2002 05:35:04 -0700 (PDT)
Received: from mail5.magma.ca (mail5.magma.ca [206.191.0.225]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g5HCZHRH005283; Mon, 17 Jun 2002 08:35:17 -0400 (EDT)
Received: from asturgeonpc (ottawa-dial-64-26-139-103.d-ip.magma.ca [64.26.139.103]) by mail5.magma.ca (Magma's Mail Server) with SMTP id g5HCYa63011047; Mon, 17 Jun 2002 08:34:57 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-extn-01
Date: Mon, 17 Jun 2002 08:45:16 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis and Russ,
Based on Russ' suggestion, I propose moving the text in the third paragraph
of section 2 to the Introduction, at the end of the paragraph beginning,
"Alternatively a CA ..." (and break this paragraph in half, as shown below),
and modifying that text, as shown below:

"Alternatively a CA may provide extended liability coverage for the use
  of the certificate.  Usually, the subscriber pays for the extended
  warranty coverage.  In turn, subscribers are covered by an
  appropriately drafted insurance policy.  The certificate warranty is
  backed by an insurance policy issued by a licensed insurance company,
  which results in a financial backing that is far greater than that of
  the CA.  This extra financial backing provides a further element of
  confidence necessary to encourage the use of certificates in commerce.
[NEW TEXT:]  There are different insurance models that may be applicable to
certification systems and electronic transactions, notably, aggregated and
per-transaction warranty.  With aggregation, claims are fulfilled until a
ceiling value is reached.  After that, no further claims are fulfilled.
With per-transaction, a ceiling value is imposed on each claim, but each
transaction is considered independently. This warranty extension is
appropriate for the aggregated warranty model.  While it is possible to
adopt an insurance model based on per-transaction warranty, or other model,
only the aggregated warranty model is addressed in this certificate
extension.

  A relying party may have redress from a CA depending on the conditions
  for such redress expressed in either the CA's Certificate Policy or the
  CA's insurance policy, or both.  Where the relying party and the
subscriber
  are the same entity, then the terms and conditions of the insurance policy
  clearly cover the entity; however, where the relying party is not a
  subscriber to the CA, then any redress will be available only through the
  conditions expressed in the CP and the CA's insurance policy, if any.
  Risk for a non-subscriber relying party may be reduced by the presence of
  a warranty extension with an explicit warranty stated.  The warranty
  extension in the process automates this aspect of risk management for the
  relying party (whether subscriber or non-subscriber)."



Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331




-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: June 14, 2002 5:35 PM
To: Housley, Russ
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: draft-ietf-pkix-warranty-extn-01


      Russ:

      My 2 cents worth is that for per-transaction warranties the warranty
would have to be incorporated in a CMS Signed Attribute (or an XMLDSIG
SignatureProperty), and the value of that attribute would have to be signed
by the carrier.  Even if its syntax had already been defined, IMHO it would
probably belong in a different draft than this one.

            Tom Gindin


"Housley, Russ" <[e-mail]>@mail.imc.org on 06/14/2002
08:05:40 AM

Sent by:    [e-mail]


To:    [e-mail], [e-mail]
cc:    [e-mail]
Subject:    RE: draft-ietf-pkix-warranty-extn-01



Denis & Alice:

I asked someone in the insurance field about this point.  I was told that
policies are written in the fashion supported by the model in the proposed
extension.  However, there are also policies written using the model that
Denis proposes. A warranty certificate extension seems appropriate in one
model, but not the other.  I do not think that it would be possible to
craft a warranty certificate extension for the model that Denis advocates.

In my opinion, it is not our role to impose specific insurance
model.  Rather, we should define standards that support the models that are

actually used.

I suggest that additional text be added to the Introduction that describes
the insurance models where this extension is useful.  Further, it should
point out that per-transaction insurance could be obtained, but that it is
not covered by this extension.

Russ


>[DP] COMMENT 5:
>You wrote:  The text says:  "Once the value of fulfilled claims reaches
the
>warranty currency amount,
>then no further claim will be fulfilled. "
>This is nice for the insurance company, but not for end-users !
>This is not going to work nicely, unless on-line warranty server is being
>used. In such a case the on-line warranty server could compute in
real-time
>the aggregated amount and then stop to offer the warranty when this amount
>is being reached.
>
>[AS] I agree this may be preferable to the insurance company, but you have
>to agree this is standard insurance-business practice!  Your point on
>aggregation is, I would say, outside the scope of the certificate.  It is
>similar to the health insurance scheme analogy - If I am insured for
health
>services up to a certain amount (and with a deductible, which hasn't been
>mentioned yet!), then if I submit a claim that is higher than that amount
>(e.g., annual physical is covered but I have two physicals in one year),
the
>insurance company will not reimburse above the amount insured.  From my
way
>of thinking, then, this does not need to be managed on-line.







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HBxmb28523 for ietf-pkix-bks; Mon, 17 Jun 2002 04:59:48 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HBxkn28517 for <[e-mail]>; Mon, 17 Jun 2002 04:59:46 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA33086 for <[e-mail]>; Mon, 17 Jun 2002 14:03:30 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061713583947:454 ; Mon, 17 Jun 2002 13:58:39 +0200 
Message-ID: <[e-mail]>
Date: Mon, 17 Jun 2002 13:59:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Certificate validation protocol
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/06/2002 13:58:39, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/06/2002 13:59:11, Serialize complete at 17/06/2002 13:59:11
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the list,

In the past there has been some proposals to support certificate validation,
like SCVP, or to extend some protocols, like OCSP v2.

In my opinion, these proposals do not support the DPV requirements
document and changes or extensions to these documents would not be
straightforward, nor easy. 

I have sketched a new protocol starting from the requirements rather 
than from an already defined protocol.

The documment is now available at the following address: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HBXOo26652 for ietf-pkix-bks; Mon, 17 Jun 2002 04:33:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HBXNn26648 for <[e-mail]>; Mon, 17 Jun 2002 04:33:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26767; Mon, 17 Jun 2002 07:32:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cvp-00.txt
Date: Mon, 17 Jun 2002 07:32:43 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Certificate Validation Protocol
	Author(s)	: D. Pinkas
	Filename	: draft-ietf-pkix-cvp-00.txt
	Pages		: 24
	Date		: 14-Jun-02
	
This document defines a protocol called Certificate Validation Protocol 
(CVP) that can be used to fully delegate the validation of a 
certificate to a CVP server, according to a set of rules called a 
validation policy.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cvp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cvp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cvp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cvp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EM0GA26093 for ietf-pkix-bks; Fri, 14 Jun 2002 15:00:16 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EM0En26087 for <[e-mail]>; Fri, 14 Jun 2002 15:00:14 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5EM0Bg5154128; Fri, 14 Jun 2002 18:00:11 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EM08G34132; Fri, 14 Jun 2002 18:00:08 -0400
Importance: Normal
Sensitivity: 
Subject: RE: DN comparison
To: Sharon Boeyen <[e-mail]>
Cc: "Hoyt L. Kesterson II" <[e-mail]>, "Erik Andersen" <[e-mail]>, "'Laurence Lundblade'" <[e-mail]>, Bruce Stephens <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 14 Jun 2002 18:00:16 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/14/2002 06:00:10 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Sharon:

      Clearly, your answer among my alternatives is that treating
"corresponding" to mean "with the same set of attribute types" is
forbidden, even after making that interpretation workable by matching the
attribute type and relative position within occurrences of that type
instead of the attribute type alone.  The term "corresponding" does not
unambiguously mean "in the same position".  It could equally well mean
"matching the same criterion", and I was suggesting a criterion which would
give slightly more useful semantic results than the rule which is used for
directory lookup.
      I hope this will be an adequate explanation of why X.501needs to be
clarified.  If it isn't, somebody might implement an interpretation of the
matching rule similar to the one I suggested.

            Tom Gindin


Sharon Boeyen <[e-mail]> on 06/13/2002 09:41:36 AM

To:    Tom Gindin/Watson/IBM@IBMUS, Sharon Boeyen
       <[e-mail]>
cc:    "'Laurence Lundblade'" <[e-mail]>, Bruce Stephens
       <[e-mail]>, [e-mail], "Erik
       Andersen (E-mail)" <[e-mail]>
Subject:    RE: DN comparison


DNs are hierarchical names (again regardless of whether they appear in a
directory or not) and corresponding RDNs are RDNs that are in the same
position of that hierarchy (in the same position in the sequence of the
syntax).
The attribute types that happen to be used in RDNs are completely
irrelevant
from the standpoint of determining which RDNs are 'corresponding'. However,
the
attribute type&value pair(s) that appear within corresponding RDNs (in the
same element
of the SEQUENCE) must be the same. The order of those attribute type&value
pairs within
a specific multivalued RDN does not need to be the same, but the order of
RDNs in the DN
must be the same.

If that needs clarification, I'm sure we can add a note to 501 through a
defect
report. I copied Erik (the editor & ITU Rapporteur) and Hoyt (the ISO
Rapporteur and
DR registrar) to see if we can get the DR going.


Sharon


-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 4:26 PM
To: Sharon Boeyen
Cc: 'Laurence Lundblade'; Bruce Stephens; [e-mail]
Subject: RE: DN comparison






      Sharon:


      IMHO the thing which most needs to be clarified in this regard is not

in X.509 at all, but rather the term "corresponding RDN" in section 13.5.2
of X.501(and also in section 9.4).  Is the "corresponding RDN" of a given
RDN in the presented DN the RDN which occupies the same position or is it
the RDN which has the same set of attribute types (with a caveat about
attribute types which occur more than once in a DN)?  Until that's cleared
up, references to the matching rule may not make the responsibilities of an

implementor any clearer.
      Laurence's example with multiple occurrences of the OU attribute is
the closest I've seen to a plausible example in which re-ordering RDN's
could cause two DN's which really refer to different entities to match
inappropriately.  Following one of his hints, a similar and slightly
stronger example could be constructed with multiple occurrences of the DC
attribute as well (DC=com, DC=company, DC=fr vs. DC=fr, DC=company, DC=com
representing the quite legal DNS names fr.company.com and com.company.fr).
However, AFAIK nobody has shown an example in which re-ordering RDN's with
different attribute structures would do this.
      If I were to locate the "corresponding RDN" by a heuristic which said

that two RDN's correspond if they have the same set of attribute types and
if any of those attribute types occur more than once in a DN, the relative
position of the occurrence of the attribute type in each DN is the same, I
would not produce any obviously perverse results but I would match C=CA,
ST=ON, L=Ottawa, O=Entrust with C=CA, O=Entrust, ST=ON, L=Ottawa.  I think
that's why we need clarity as to whether this heuristic is required,
permitted, or forbidden as an interpretation of the term corresponding RDN
within distinguishedNameMatch.


            Tom Gindin





Sharon Boeyen <[e-mail]> on 06/12/2002 10:53:16 AM


To:    "'Laurence Lundblade'" <[e-mail]>, Tom
       Gindin/Watson/IBM@IBMUS, Bruce Stephens
       <[e-mail]>
cc:    [e-mail]
Subject:    RE: DN comparison





Just to close one loop in this discussion, I want to let you know that
although X.509
didn't have any specific text on this topic previously that is being
changed and the following
changes are being made in current working document. This ties the matching
of DNs in 509
to the X.501 matching rule and outlines where the matches occur. Note that
this applies
regardless of whether or not those DNs in certificates ever get
instantiated as directory
entries.





Here are the upcoming changes to X.509 on this topic:





1 The following text will be added to clause 7 of X.509:





The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.
X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the

issuer field of one certificate with the DN in the subject field of
another.





2 In clause 8.6.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The distributionPoint

component contains.":





If the certificate in question contains a cRLDistributionPoints extension
and the CRL contains an issuingDistributionPoint extension, at least one
name for the distribution point as indicated in the certificate shall match

a name for the distribution point as indicated in the CRL. Note that in
both the certificate and CRL there are default names that may apply to the
distribution point, namely the DN of the CRL issuer (found in the issuer
field of the CRL). Also, it may be the case that only the
nameRelativeToCRLIssuer field is present. In that case, a name comparison
would be done on the full DN, constructed by appending the value of the
nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.  If

the names being compared are DNs (as opposed to names of other forms within

the GeneralNames construct), the distinguishedNameMatch matching rule is
used to compare the two DNs for equality.






3 In clause 8.4.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The maximum field
specifies the lower bound ."





For the directoryName name form, a certificate is considered subordinate to

the base
(and therefore a candidate to be within the subtree) if the SEQUENCE of
RDNs, which forms the full DN in base, is identical to the initial SEQUENCE

of the same number of RDNs which forms the first part of the DN in the
subject field of the certificate. The DN in the subject field of the
certificate may have additional trailing RDNs in its sequence that do not
appear in the DN in base.





The distinguishedNameMatch matching rule is used to compare the value of
base  with the initial sequence of RDNs in the DN in the subject field of
the certificate.








-----Original Message-----
From: Laurence Lundblade [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [e-mail]
Subject: Re: DN comparison









At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:
>       Bruce:
>
>       I know, and I think many of us do, that a DN's original use is as
an
>index to an X.500 or LDAP entry, that these are tree-structured databases,


>and that DN's are defined in X.501 as ordered sets (or sequences) of
RDN's.
>However, I would like to see someone come up with a plausible example of
>two DN's which consist of different orderings of the same set of RDN's
>while referring to different entities.  Your point about directory access
>properties is valid, but is hardly relevant to a comparison of two
>different DN's.





In the DNS world order is pretty important as seen from my previous example


of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the
DNS world though I think because the parts of the domain name aren't
tagged. Given that hint how about this example?





(ou=finance)(ou=it)(o=moderatelyconfused)
(ou=it)(ou=finance)(o=moderatelyconfused)





IT can have it's own finance department and finance can have it's own IT
department.





On the parsing implementation side dealing with a SEQUENCE is easier than a


SET as someone already mentioned. Dunno about the server/CA side
implementation.





Didn't seem that anyone is seriously considering changing this, but the
fact that it could matter, that a change would complicate implementations a


little, and a change would add more confusion (let me personally serve as
an example of confusion :-), it seems a change would be very bad.





LL





Received: by above.proper.com (8.11.6/8.11.3) id g5ELYpk24383 for ietf-pkix-bks; Fri, 14 Jun 2002 14:34:51 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ELYmn24378 for <[e-mail]>; Fri, 14 Jun 2002 14:34:48 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5ELYjg5168222; Fri, 14 Jun 2002 17:34:45 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5ELYgG84804; Fri, 14 Jun 2002 17:34:42 -0400
Importance: Normal
Sensitivity: 
Subject: RE: draft-ietf-pkix-warranty-extn-01
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 14 Jun 2002 17:34:49 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/14/2002 05:34:44 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Russ:

      My 2 cents worth is that for per-transaction warranties the warranty
would have to be incorporated in a CMS Signed Attribute (or an XMLDSIG
SignatureProperty), and the value of that attribute would have to be signed
by the carrier.  Even if its syntax had already been defined, IMHO it would
probably belong in a different draft than this one.

            Tom Gindin


"Housley, Russ" <[e-mail]>@mail.imc.org on 06/14/2002
08:05:40 AM

Sent by:    [e-mail]


To:    [e-mail], [e-mail]
cc:    [e-mail]
Subject:    RE: draft-ietf-pkix-warranty-extn-01



Denis & Alice:

I asked someone in the insurance field about this point.  I was told that
policies are written in the fashion supported by the model in the proposed
extension.  However, there are also policies written using the model that
Denis proposes. A warranty certificate extension seems appropriate in one
model, but not the other.  I do not think that it would be possible to
craft a warranty certificate extension for the model that Denis advocates.

In my opinion, it is not our role to impose specific insurance
model.  Rather, we should define standards that support the models that are

actually used.

I suggest that additional text be added to the Introduction that describes
the insurance models where this extension is useful.  Further, it should
point out that per-transaction insurance could be obtained, but that it is
not covered by this extension.

Russ


>[DP] COMMENT 5:
>You wrote:  The text says:  "Once the value of fulfilled claims reaches
the
>warranty currency amount,
>then no further claim will be fulfilled. "
>This is nice for the insurance company, but not for end-users !
>This is not going to work nicely, unless on-line warranty server is being
>used. In such a case the on-line warranty server could compute in
real-time
>the aggregated amount and then stop to offer the warranty when this amount
>is being reached.
>
>[AS] I agree this may be preferable to the insurance company, but you have
>to agree this is standard insurance-business practice!  Your point on
>aggregation is, I would say, outside the scope of the certificate.  It is
>similar to the health insurance scheme analogy - If I am insured for
health
>services up to a certain amount (and with a deductible, which hasn't been
>mentioned yet!), then if I submit a claim that is higher than that amount
>(e.g., annual physical is covered but I have two physicals in one year),
the
>insurance company will not reimburse above the amount insured.  From my
way
>of thinking, then, this does not need to be managed on-line.







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ECXvl02007 for ietf-pkix-bks; Fri, 14 Jun 2002 05:33:57 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5ECXun02001 for <[e-mail]>; Fri, 14 Jun 2002 05:33:56 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Jun 2002 12:33:47 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA18114; Fri, 14 Jun 2002 08:33:56 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5ECVw801269; Fri, 14 Jun 2002 08:31:58 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28Z3VFR>; Fri, 14 Jun 2002 08:33:55 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28Z3VFP; Fri, 14 Jun 2002 08:33:50 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 14 Jun 2002 08:05:40 -0400
Subject: RE: draft-ietf-pkix-warranty-extn-01
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis & Alice:

I asked someone in the insurance field about this point.  I was told that 
policies are written in the fashion supported by the model in the proposed 
extension.  However, there are also policies written using the model that 
Denis proposes. A warranty certificate extension seems appropriate in one 
model, but not the other.  I do not think that it would be possible to 
craft a warranty certificate extension for the model that Denis advocates.

In my opinion, it is not our role to impose specific insurance 
model.  Rather, we should define standards that support the models that are 
actually used.

I suggest that additional text be added to the Introduction that describes 
the insurance models where this extension is useful.  Further, it should 
point out that per-transaction insurance could be obtained, but that it is 
not covered by this extension.

Russ


>[DP] COMMENT 5:
>You wrote:  The text says:  "Once the value of fulfilled claims reaches the
>warranty currency amount,
>then no further claim will be fulfilled. "
>This is nice for the insurance company, but not for end-users !
>This is not going to work nicely, unless on-line warranty server is being
>used. In such a case the on-line warranty server could compute in real-time
>the aggregated amount and then stop to offer the warranty when this amount
>is being reached.
>
>[AS] I agree this may be preferable to the insurance company, but you have
>to agree this is standard insurance-business practice!  Your point on
>aggregation is, I would say, outside the scope of the certificate.  It is
>similar to the health insurance scheme analogy - If I am insured for health
>services up to a certain amount (and with a deductible, which hasn't been
>mentioned yet!), then if I submit a claim that is higher than that amount
>(e.g., annual physical is covered but I have two physicals in one year), the
>insurance company will not reimburse above the amount insured.  From my way
>of thinking, then, this does not need to be managed on-line.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EC6CV01224 for ietf-pkix-bks; Fri, 14 Jun 2002 05:06:12 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EC6Bn01220 for <[e-mail]>; Fri, 14 Jun 2002 05:06:11 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5EC65g5120098; Fri, 14 Jun 2002 08:06:06 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EC64I98442; Fri, 14 Jun 2002 08:06:04 -0400
Importance: Normal
Sensitivity: 
Subject: Re: PI: 04: Alphanumeric Identifier Match
To: "Manger, James H" <[e-mail]>
Cc: pkix <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 14 Jun 2002 08:06:05 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/14/2002 08:06:05 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      James:

      The matching rule is a new one, and does not currently have an OID.
The elimination of control characters is intended particularly so that
horizontal tab will be ignored.  Most control characters will never appear
in such a value, of course.
      In English, the only characters which should be compared using this
rule are upper-case letters, lower-case letters, and digits.  Among others,
period and underscore, as well as hyphen, should be omitted from the
comparison.  The reason we did not go into detail on what constitutes each
character class was that this can become a complex subject in an
internationalized environment.  For Latin alphabet languages, the C
expression ispunct(ch) | iscntrl (ch) | isspace(ch) is an adequate summary
of what was omitted, although it might be easier to define it as
!isalnum(ch).
      I'll try to prepare better wording for this.  A first try would be to
replace the "stripping text" (from "by stripping" up to the semicolon) by
"by including only digits and alphabetic characters".  We'll probably need
to run this past some I18N specialist to see whether that's reasonable for
languages with diacritical marks and for ideographic ones.  I'd be willing
to not cover ideographic languages if it is not feasible to do so, but
there should be a form for languages with diacritical marks.  If they need
a separate rule, that's OK too.

            Tom Gindin

"Manger, James H" <[e-mail]>@mail.imc.org on
06/13/2002 10:46:08 PM

Sent by:    [e-mail]


To:    pkix <[e-mail]>
cc:
Subject:    PI: 04: Alphanumeric Identifier Match



Is the Alphanumeric Identifier Match described in the Permanent Identifier
draft a new rule, or is it specified elsewhere?
[draft-ietf-pkix-pi-04.txt,
line 201, section 2, page 4]

It looks like a good default rule for matching string identifiers.
However,
the text is not specific about exactly which characters are considered
control characters, spaces and punctuation marks.  Excluding all characters
for which either of the standard C functions isspace() or ispunct() return
true might be a reasonable way to define the rule (I am not sure if
excluding control characters is sensible).  It should be clear that minus
signs must be excluded.


> ----------
> From:            Denis Pinkas [SMTP:[e-mail]]
> Sent:            Friday, 14 June 2002 12:30 am
> Subject:         Re: WG Last Call: Permanent Identifier
>
             ..
> The revised draft has been placed on the IETF server and is available
> from:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-04.txt
>







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5E7b4q05471 for ietf-pkix-bks; Fri, 14 Jun 2002 00:37:04 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E7b2n05462 for <[e-mail]>; Fri, 14 Jun 2002 00:37:02 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA29904 for <[e-mail]>; Fri, 14 Jun 2002 09:40:42 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061409363913:210 ; Fri, 14 Jun 2002 09:36:39 +0200 
Message-ID: <[e-mail]>
Date: Fri, 14 Jun 2002 09:36:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Attribute Certificate Policy
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 14/06/2002 09:36:39, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 14/06/2002 09:37:01, Serialize complete at 14/06/2002 09:37:01
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On March 5, the following message was sent to the list by Christopher
Francis:

"Is there a defined mechanism to specify something analogous to a
certificate policy in an attribute certificate ? 

In reviewing the PKIX AC profile, I see that the syntax of the
attributes field is defined by the AttributeType OID, but rather than
syntax per se, I'm looking for a way to specify the particular set of
policies, practices, and procedures that the attribute authority
was operating under when it issued the attribute certificate.  
Seems like this would be important to relying parties."

Several e-mails have then been exchanged on the list. As a result of
these exchanges, Chris and myself have undertaken the writing of a draft 
to define an extension to support an Attribute Certificate Policy.

The document is available from :
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5E3mir18549 for ietf-pkix-bks; Thu, 13 Jun 2002 20:48:44 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E3mgn18545 for <[e-mail]>; Thu, 13 Jun 2002 20:48:42 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g5E3lr1g001744; Fri, 14 Jun 2002 15:47:53 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA124012; Fri, 14 Jun 2002 15:47:52 +1200 (NZST) (sender [e-mail])
Date: Fri, 14 Jun 2002 15:47:52 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSA policy ID
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>FYI, the document Policy Requirements for Time-Stamping Authorities (
>http://www.imc.org/draft-ietf-pkix-pr-tsa) identifies one policy and assigns
>one OID for it. If you believe that you can meet the requirements of that
>policy, then you can use that OID. If one of these requirements is not met,
>then you shall not use it and use your own definition. The content of the
>above document may help you to describe your own policy.

I've also got a policy OID, "Anything that arrives, we sign" (derived from the
'snooze editorial policy, "Anything that arrives, we print") which a number of
TSAs seem to be using.  The OID is 1 3 6 1 4 1 3029 54 11940 54.

Peter.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5E2lP117461 for ietf-pkix-bks; Thu, 13 Jun 2002 19:47:25 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E2lNn17457 for <[e-mail]>; Thu, 13 Jun 2002 19:47:24 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA14737 for <[e-mail]>; Fri, 14 Jun 2002 12:47:21 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdJ3NvC_; Fri Jun 14 12:46:55 2002
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA07901 for <[e-mail]>; Fri, 14 Jun 2002 12:46:53 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0ouN._; Fri Jun 14 12:46:17 2002
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA06735 for <[e-mail]>; Fri, 14 Jun 2002 12:46:16 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id <M62DVCPJ>; Fri, 14 Jun 2002 12:46:18 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: pkix <[e-mail]>
Subject: PI: 04: Alphanumeric Identifier Match
Date: Fri, 14 Jun 2002 12:46:08 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is the Alphanumeric Identifier Match described in the Permanent Identifier
draft a new rule, or is it specified elsewhere?  [draft-ietf-pkix-pi-04.txt,
line 201, section 2, page 4]

It looks like a good default rule for matching string identifiers.  However,
the text is not specific about exactly which characters are considered
control characters, spaces and punctuation marks.  Excluding all characters
for which either of the standard C functions isspace() or ispunct() return
true might be a reasonable way to define the rule (I am not sure if
excluding control characters is sensible).  It should be clear that minus
signs must be excluded.


> ----------
> From:	Denis Pinkas [SMTP:[e-mail]]
> Sent:	Friday, 14 June 2002 12:30 am
> Subject:	Re: WG Last Call: Permanent Identifier
> 
	..
> The revised draft has been placed on the IETF server and is available
> from:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-04.txt
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DH8qn02087 for ietf-pkix-bks; Thu, 13 Jun 2002 10:08:52 -0700 (PDT)
Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DH8pn02082 for <[e-mail]>; Thu, 13 Jun 2002 10:08:52 -0700 (PDT)
Received: from mail4.magma.ca (mail4.magma.ca [206.191.0.222]) by mx2.magma.ca (Magma's Mail Server) with ESMTP id g5DH8mpZ003523; Thu, 13 Jun 2002 13:08:48 -0400 (EDT)
Received: from asturgeonpc (ottawa-dial-64-26-163-220.d-ip.magma.ca [64.26.163.220]) by mail4.magma.ca (Magma's Mail Server) with SMTP id g5DH8gmX012708; Thu, 13 Jun 2002 13:08:44 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Pkix" <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-extn-01
Date: Thu, 13 Jun 2002 13:18:53 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
I had not yet responded to your, as always, insightful comments, because I
have been mulling them over, and consulting with colleagues.  But since you
ask ...

COMMENT 1:
You wrote:
It is very questionable whether the implicit insurance model is appropriate.
The text says: " Usually, the subscriber pays for the extended warranty
coverage". The major issue is whether a subscriber pays a flat price that is
included in the price of the certificate or a price that is per insured
transaction which would be paid by the relying party. Implicitly the first
choice is being made but this choice is questionable.

[AS] Seems to me it would be very difficult, if not impossible, to charge a
per-transaction fee to a relying party in any scenario simply because the
relying party may not be known to the other parties in the transaction.  It
is possible, for example, to have anonymity or at least pseudo-anonymity in
transactions, and if that were the case, how could a relying party be
charged in any effective manner?
That point aside, the warranty extension does explicitly apply to a fee to
the subscriber, or to the CA - it is not necessarily charged to the
subscriber.  (The CA may decide to absorb the cost of insurance itself on
behalf of its customers; this is a distinct possibility in a competitive
environment.)  If the warranty extension is present and populated by other
than NULL, then the CA is providing a warranty, either base or extended.
Who pays for it is, for the purposes of the warranty extension, irrelevant
because this point will be addressed in the terms and conditions.  One
assumes that a subscriber, on subscribing to the CA's service, will be
informed of the warranty T&C including whether or not there is a fee to the
subscriber.  The syntax in the proposed extension really does not imply or
dictate a fee regime.

COMMENT 2:
You wrote:
It seems difficult to be able to take benefit of a warranty without proving
that there is a real damage. However, this would imply to disclose the
details of the transaction or the details of the damage. This is conflicting
with privacy considerations.
End-users may be willing to disclose the amount of transaction that has been
guaranteed, but without providing the details. This does not seem possible
with that approach.
Another approach would be to obtain a warranty from a server to which only
the amount that is wished to be guaranteed would be disclosed. A signed
warranty would then be given.

[AS] Juergen's comments on this point, and your response:
[JB] Why should it be a privacy problem? In paper-world you are already
forced to disclose details on your damage if you want to get a refund
from an insurance. If you want money, you have to tell why.
>
[DP] Not necessarily. I have to tell how much. A good example is a payment
guaranteed by a smartcard. An inquiry is made for a certain amount of money
and the warranty is granted for that amount. You do not have to tell which
goods have been purchased.
>
[JB] Why is it necessary to object against this procedure when it is about
electronic transactions?
>
[DP] See above.

[JB] How can a warranty server solve the problem that someone is forced to
tell details about transactions if he wants to take benefit of a warranty?
>
[DP] The amount can be guaranteed for a given date, irrespective of the
nature
of the goods or the service being purchased.

[AS] With respect to privacy, isn't this addressed in the exchange above?
In some cases, it may be necessary to disclose transaction details, just as
in the paper world it is necessary to disclose pertinent information in
order to submit an insurance claim.  In other cases, the warranty may simply
be for a certain amount of money, usually a small-ish amount, and for this
amount, it is sufficient only to show that there was injury or damage (e.g.,
a transaction not completed), even without absolute proof.  This is
certainly the case in the paper world; for example, most credit card
companies accept their customer's claim of not having made a particular
transaction, if it is not too big.

COMMENT 3:
You wrote:  WarrantyData contains:
       tcURL                TermsAndConditionsURL OPTIONAL
"WarrantyData is defined as a URL that points to the terms and conditions of
the warranty.  The URL is provided using the TermsAndConditionsURL type,
which is an IA5 string."
In this document the warranty is said to be given by the CA. RFC 3280
states:
"   The CPS Pointer qualifier contains a pointer to a Certification
    Practice Statement (CPS) published by the CA.  The pointer is in
    the form of a URI."
The Certification Practice Statement contains all the conditions, including
the terms and conditions of the warranty. So this extension is not needed as
soon as the CPS Pointer qualifier is being used.
However, these terms and conditions of the warranty are only human being
understandable, but not machine processable and this means that applications
will not be able to know how to take benefit of the terms and conditions of
the warranty. In particular is there a need to prove that the revocation
status of the certificate has been checked ? When this is the case, the
application should know whether an OCSP check, a DPV check or another kind
of check is needed. There is no information to be able to know this.

[AS] The T&C may not necessarily be contained in the CPS; it may be a
separate document.  This is likely to be true in particular when the fee is
charged to the subscriber.  Then it would be a part of the subscriber
agreement or RPA.  Wherever they are, the warranty information needs to be
human-readable and need not necessarily be machine-processable, except to
the extent that they form part of the certificate (thus the standard ASN.1
format).  What is important is that the certificate users are aware of and
understand the T&C of the warranty.  The need to check revocation status of
the certificate applies to the certificate generally, and is not specific to
the warranty extension, and therefore need not be addressed within the
warranty extension.  The I-D states that the validity period of the warranty
will, in the vast majority of cases, be the same as the validity period of
the certificate, in which case the NULL option is selected.  In the rare
cases when the validity periods are different, it is obvious although
unstated in the I-D that the validity period of the warranty will be shorter
than that of the certificate itself (since a warranty will not apply to an
expired certificate).

COMMENT 4:
You wrote:
Normally claims about a warranty have to be presented a few days or weeks
after the damage. Insurance company do not take into account claims that are
too old. There is no indication for that time period in the document.
Would such a time period be indicated, the next point would be to make sure
that the damage really took place at that time. Going in that direction
would once again make necessary to disclose the details of the transaction
and also to place in the time scale that transaction. The use of a
time-stamp tokens would solve this last problem, but there would be a much
simpler solution: the use of a on-line warranty server. The date included in
the signed warranty would be the date of the transaction.

[AS] Again, I believe this information would more usefully be contained in
the T&C, not in the certificate and the warranty extension.  This is similar
to health insurance schemes, which tell the subscriber about deadlines for
submission of claims in the booklet the subscriber receives on joining the
scheme.
A time-stamp is a good idea, but, again, this is not a requirement unique to
the warranty extension.
Previous comments on privacy, concerning disclosing details of transactions,
also apply here.

COMMENT 5:
You wrote:  The text says:  "Once the value of fulfilled claims reaches the
warranty currency amount,
then no further claim will be fulfilled. "
This is nice for the insurance company, but not for end-users !
This is not going to work nicely, unless on-line warranty server is being
used. In such a case the on-line warranty server could compute in real-time
the aggregated amount and then stop to offer the warranty when this amount
is being reached.

[AS] I agree this may be preferable to the insurance company, but you have
to agree this is standard insurance-business practice!  Your point on
aggregation is, I would say, outside the scope of the certificate.  It is
similar to the health insurance scheme analogy - If I am insured for health
services up to a certain amount (and with a deductible, which hasn't been
mentioned yet!), then if I submit a claim that is higher than that amount
(e.g., annual physical is covered but I have two physicals in one year), the
insurance company will not reimburse above the amount insured.  From my way
of thinking, then, this does not need to be managed on-line.

COMMENT 6:
You wrote:  In the comments on the previous version, it has been mentioned
that a similar extension has already been defined in ETSI TS 101 862. This
extension takes advantage of the qcStatement defined in RFC 3039 and
specifies a statement regarding limits on the value of transactions.
This optional statement contains:
- an identifier of this statement (represented by an OID);
- a monetary value expressing the limit on the value of transactions.
This statement is a statement by the issuer which imposes a limitation on
the value of transaction for which this certificate can be used to the
specified amount (MonetaryValue), according to the Directive 1999/93/EC of
the European Parliament and of the Council of 13 December 1999 on a
Community framework for electronic signatures, as implemented in the law of
the country specified in the issuer field of this certificate.
In fact the Directive is requiring (in Annex I) a field to specify "limits
on the value of transactions for which the certificate can be used, if
applicable". The reason for that field is specified in these terms:
"The certification-service-provider shall not be liable for damage arising
from use of a qualified certificate which exceeds the limitations placed on
it".
The text does *not* say: "The certification-service-provider *shall be*
liable for damage arising from use of a qualified certificate which *meets*
the limitations placed on it".
So it is more a *disclaimer of warranty* extension rather than a warranty.
If the proposal was for a warranty disclaimer extension, then it would be
more appropriate.
A much better title and abstract would be:
         Warranty Disclaimer Certificate Extension
  This document describes a certificate extension to explicitly state a
warranty disclaimer from the Certificate Authority (CA) for a certificate
containing the extension.

[AS] There is a substantive link between a qc and the warranty extension in
the sense that providing a warranty may enhance trust in the certificate and
the transactions in which it is used, which of course is the primary motive
of the qc as expressed in the EU Directive and specified in RFC 3039.  The
qc statement, represented by an OID, takes decision-making out of the
warranty-extension setting.  If the OID incorporates an established limit,
then when present this is the limit guaranteed.  This is a "warranty" up to
a specified value, and a "disclaimer" above that limit.  The intent is to
provide a warranty, and not to "disclaim" it, but to set a limit on it.  In
that sense, then, it is a warranty extension and not a warranty disclaimer
extension.  This may be a matter of whether the glass is half-empty or
half-full.

COMMENT 7:
You wrote: The security consideration section states:
" The procedures and practices employed by the CA MUST ensure that the
  correct values for the warranty are inserted in each certificate that is
  issued."
Since this extension is optional, the MUST statement is not appropriate.

[AS]  What is optional is using the extension itself.  IF it is used, then
it must be used properly.  The option is in its use, not in how to use its
parameters.  If you think it would make this more clear, then we could add a
statement at the start of the Security Considerations to the effect that the
extension is optional, but that if it is used, then the syntax and structure
must be used in accordance with the parameters set out in this document.

Your CONCLUSION:
The current proposal is missing to address several aspects which are even
not being discussed in the security considerations section. The first
impression is that this field is useful, but once a closer look is given,
the warranty is really a fake one. Of course it is well known that
warranties are to be well advertised by insurance companies, but never
granted because you have not seen a small sentence at the back of the
contract in small gray characters on a gray background.
Such "small" sentences are:
- the conditions to get advantage of the warranty (i.e. what needs to be
presented, like transaction details and certificate status check),
- the time before which the claims have to be presented.
A major issue which is not mentioned at all is the problem of the privacy of
the transaction.
As indicated above, there are many dangers to include such an extension and
such dangers are not advertised, even in the security considerations
section. When they will be, it will then be questionable whether the
advantages of such an extension will be worth the disadvantages.
Should this extension be maintained, it is proposed to transform it into a
Warranty Disclaimer Certificate Extension. This would indicate the
transaction amount above which there is no warranty at all.

[AS] The point of the extension is to avoid that common misperception of
"the fine print".  The warranty extension serves to show users immediately
in the certificate, first, that there is a warranty, and, second, what the
T&C pertaining to that warranty are, exactly how to find them and how to use
them.  This should be much more beneficial to the user community than having
no reference whatsoever to the existence of a warranty, and having to rely
instead on combing through all the sections of a CPS to find out whether or
not a warranty is given.
Again, several of the points you mention will be found, in the extension
(e.g., validity period = NULL), then in the certificate (validity period),
or in the T&C which may be the RPA, other subscriber agreement, or CPS, and
to which the RP or subscriber is directed from the extension.
The warranty extension is optional.  It will be beneficial to those CAs and
their insurers that wish to take advantage of it, and explicitly offer a
warranty to their subscribers.

Thank you again for your detailed and thoughtful comments.  Sorry to take so
long to respond - the old grey cells needed time to absorb it all!

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Denis Pinkas
Sent: June 13, 2002 9:22 AM
To: [e-mail]
Cc: Pkix
Subject: Re: draft-ietf-pkix-warranty-extn-01


Alice,

> Suggest we revise the draft to add the explanatory note, with the proper
> reference to ISO IS 4217.  This should clarify this matter.  Given that
the
> ISO standard provides an international interpretation for monetary codes,
it
> would be prudent to adhere to that standard.  (I assume there is a
revision
> to this 1995 standard in the works, to address the common European
> currency.)

The currency coding for the euro is:  EUR (978).

Denis

BTW, I have not seen yet a response to my comments on this document.

> It might be helpful as well to add a short appendix that provides a
complete
> example of use of the warranty extension.
>
> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     [phone]
> Cell:         613-291-0331
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Housley, Russ
> Sent: June 3, 2002 11:41 AM
> To: Tom Gindin
> Cc: Juergen Brauckmann; [e-mail]; Pkix
> Subject: Re: draft-ietf-pkix-warranty-extn-01
>
> Tom:
>
> I am not arguing against explanatory text, but I am suggesting that we not
> invent another means of describing monetary values.
>
> Russ
>
> At 11:37 AM 6/3/2002 -0400, Tom Gindin wrote:
>
> >       Russ:
> >
> >       Since this structure is specified in an ISO standard, but it seems
> to
> >be fairly subject to misunderstanding, I would still recommend putting in
> >the sentence I suggested below ("The actual monetary value in the named
> >currency unit, when amtExp10 is present, is amount divided by 10 to the
> >(amtExp10) power".).  There is clearly nothing to be done about the
format
> >specification or even the field name.  IMHO, that field name is more
> >naturally interpreted in Juergen's way than otherwise.
> >
> >             Tom Gindin
> >
> >
> >"Housley, Russ" <[e-mail]> on 06/03/2002 11:29:12 AM
> >
> >To:    Tom Gindin/Watson/IBM@IBMUS
> >cc:    Juergen Brauckmann <[e-mail]>,
> >        [e-mail], Pkix <[e-mail]>
> >Subject:    Re: draft-ietf-pkix-warranty-extn-01
> >
> >
> >Tom & Juergen:
> >
> >This form of representing monetary values was not invented by the authors
> >of this specification.  I it is used many different places, and it is
> >specified in   ISO 4217 [1].
> >
> >Russ
> >
> >
> >[1]     ISO. Codes for the Representation of Currencies and
> >            Funds," ISO 4217. 1995.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DEU8i21926 for ietf-pkix-bks; Thu, 13 Jun 2002 07:30:08 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DEU6n21922 for <[e-mail]>; Thu, 13 Jun 2002 07:30:06 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA30042; Thu, 13 Jun 2002 16:33:47 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061316295949:116 ; Thu, 13 Jun 2002 16:29:59 +0200 
Message-ID: <[e-mail]>
Date: Thu, 13 Jun 2002 16:29:51 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>, Tim Polk <[e-mail]>, Stephen Kent <[e-mail]>
Subject: Re: WG Last Call: Permanent Identifier
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 16:29:59, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 16:30:07, Serialize complete at 13/06/2002 16:30:07
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the co-chairs and to the list,

During the last call period on the Permannet Identifier draft, comments 
from Russ Housley have been received. The co-editors have taken into
consideration these comments. 

Russ Housley received a private copy and has confirmed that all issues he
posted to the mail list have been addressed.

The revised draft has been placed on the IETF server and is available from:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-04.txt

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DDg4I19386 for ietf-pkix-bks; Thu, 13 Jun 2002 06:42:04 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDfqn19364 for <[e-mail]>; Thu, 13 Jun 2002 06:41:52 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <MZYN1K68>; Thu, 13 Jun 2002 09:41:37 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, Sharon Boeyen <[e-mail]>
Cc: "'Laurence Lundblade'" <[e-mail]>, Bruce Stephens <[e-mail]>, [e-mail], "Erik Andersen (E-mail)" <[e-mail]>
Subject: RE: DN comparison
Date: Thu, 13 Jun 2002 09:41:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212E0.09906EF0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

------_=_NextPart_001_01C212E0.09906EF0
Content-Type: text/plain

DNs are hierarchical names (again regardless of whether they appear in a 
directory or not) and corresponding RDNs are RDNs that are in the same 
position of that hierarchy (in the same position in the sequence of the
syntax).
The attribute types that happen to be used in RDNs are completely irrelevant

from the standpoint of determining which RDNs are 'corresponding'. However,
the 
attribute type&value pair(s) that appear within corresponding RDNs (in the
same element
of the SEQUENCE) must be the same. The order of those attribute type&value
pairs within 
a specific multivalued RDN does not need to be the same, but the order of
RDNs in the DN
must be the same. 
 
If that needs clarification, I'm sure we can add a note to 501 through a
defect 
report. I copied Erik (the editor & ITU Rapporteur) and Hoyt (the ISO
Rapporteur and 
DR registrar) to see if we can get the DR going. 

Sharon

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 4:26 PM
To: Sharon Boeyen
Cc: 'Laurence Lundblade'; Bruce Stephens; [e-mail]
Subject: RE: DN comparison



      Sharon:

      IMHO the thing which most needs to be clarified in this regard is not
in X.509 at all, but rather the term "corresponding RDN" in section 13.5.2
of X.501(and also in section 9.4).  Is the "corresponding RDN" of a given
RDN in the presented DN the RDN which occupies the same position or is it
the RDN which has the same set of attribute types (with a caveat about
attribute types which occur more than once in a DN)?  Until that's cleared
up, references to the matching rule may not make the responsibilities of an
implementor any clearer.
      Laurence's example with multiple occurrences of the OU attribute is
the closest I've seen to a plausible example in which re-ordering RDN's
could cause two DN's which really refer to different entities to match
inappropriately.  Following one of his hints, a similar and slightly
stronger example could be constructed with multiple occurrences of the DC
attribute as well (DC=com, DC=company, DC=fr vs. DC=fr, DC=company, DC=com
representing the quite legal DNS names fr.company.com and com.company.fr).
However, AFAIK nobody has shown an example in which re-ordering RDN's with
different attribute structures would do this.
      If I were to locate the "corresponding RDN" by a heuristic which said
that two RDN's correspond if they have the same set of attribute types and
if any of those attribute types occur more than once in a DN, the relative
position of the occurrence of the attribute type in each DN is the same, I
would not produce any obviously perverse results but I would match C=CA,
ST=ON, L=Ottawa, O=Entrust with C=CA, O=Entrust, ST=ON, L=Ottawa.  I think
that's why we need clarity as to whether this heuristic is required,
permitted, or forbidden as an interpretation of the term corresponding RDN
within distinguishedNameMatch.

            Tom Gindin


Sharon Boeyen <[e-mail]> on 06/12/2002 10:53:16 AM

To:    "'Laurence Lundblade'" <[e-mail]>, Tom
       Gindin/Watson/IBM@IBMUS, Bruce Stephens
       <[e-mail]>
cc:    [e-mail]
Subject:    RE: DN comparison


Just to close one loop in this discussion, I want to let you know that
although X.509
didn't have any specific text on this topic previously that is being
changed and the following
changes are being made in current working document. This ties the matching
of DNs in 509
to the X.501 matching rule and outlines where the matches occur. Note that
this applies
regardless of whether or not those DNs in certificates ever get
instantiated as directory
entries.


Here are the upcoming changes to X.509 on this topic:


1 The following text will be added to clause 7 of X.509:


The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.
X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the
issuer field of one certificate with the DN in the subject field of
another.


2 In clause 8.6.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The distributionPoint
component contains.":


If the certificate in question contains a cRLDistributionPoints extension
and the CRL contains an issuingDistributionPoint extension, at least one
name for the distribution point as indicated in the certificate shall match
a name for the distribution point as indicated in the CRL. Note that in
both the certificate and CRL there are default names that may apply to the
distribution point, namely the DN of the CRL issuer (found in the issuer
field of the CRL). Also, it may be the case that only the
nameRelativeToCRLIssuer field is present. In that case, a name comparison
would be done on the full DN, constructed by appending the value of the
nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.  If
the names being compared are DNs (as opposed to names of other forms within
the GeneralNames construct), the distinguishedNameMatch matching rule is
used to compare the two DNs for equality.



3 In clause 8.4.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The maximum field
specifies the lower bound ."


For the directoryName name form, a certificate is considered subordinate to
the base
(and therefore a candidate to be within the subtree) if the SEQUENCE of
RDNs, which forms the full DN in base, is identical to the initial SEQUENCE
of the same number of RDNs which forms the first part of the DN in the
subject field of the certificate. The DN in the subject field of the
certificate may have additional trailing RDNs in its sequence that do not
appear in the DN in base.


The distinguishedNameMatch matching rule is used to compare the value of
base  with the initial sequence of RDNs in the DN in the subject field of
the certificate.





-----Original Message-----
From: Laurence Lundblade [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [e-mail]
Subject: Re: DN comparison






At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:
>       Bruce:
>
>       I know, and I think many of us do, that a DN's original use is as
an
>index to an X.500 or LDAP entry, that these are tree-structured databases,

>and that DN's are defined in X.501 as ordered sets (or sequences) of
RDN's.
>However, I would like to see someone come up with a plausible example of
>two DN's which consist of different orderings of the same set of RDN's
>while referring to different entities.  Your point about directory access
>properties is valid, but is hardly relevant to a comparison of two
>different DN's.


In the DNS world order is pretty important as seen from my previous example

of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the
DNS world though I think because the parts of the domain name aren't
tagged. Given that hint how about this example?


(ou=finance)(ou=it)(o=moderatelyconfused)
(ou=it)(ou=finance)(o=moderatelyconfused)


IT can have it's own finance department and finance can have it's own IT
department.


On the parsing implementation side dealing with a SEQUENCE is easier than a

SET as someone already mentioned. Dunno about the server/CA side
implementation.


Didn't seem that anyone is seriously considering changing this, but the
fact that it could matter, that a change would complicate implementations a

little, and a change would add more confusion (let me personally serve as
an example of confusion :-), it seems a change would be very bad.


LL




------_=_NextPart_001_01C212E0.09906EF0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: DN comparison</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>DNs are hierarchical names (again regardless of whether they appear in a </FONT>
<BR><FONT SIZE=2>directory or not) and corresponding RDNs are RDNs that are in the same </FONT>
<BR><FONT SIZE=2>position of that hierarchy (in the same position in the sequence of the syntax).</FONT>
<BR><FONT SIZE=2>The attribute types that happen to be used in RDNs are completely irrelevant </FONT>
<BR><FONT SIZE=2>from the standpoint of determining which RDNs are 'corresponding'. However, the </FONT>
<BR><FONT SIZE=2>attribute type&amp;value pair(s) that appear within corresponding RDNs (in the same element</FONT>
<BR><FONT SIZE=2>of the SEQUENCE) must be the same. The order of those attribute type&amp;value pairs within </FONT>
<BR><FONT SIZE=2>a specific multivalued RDN does not need to be the same, but the order of RDNs in the DN</FONT>
<BR><FONT SIZE=2>must be the same. </FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>If that needs clarification, I'm sure we can add a note to 501 through a defect </FONT>
<BR><FONT SIZE=2>report. I copied Erik (the editor &amp; ITU Rapporteur) and Hoyt (the ISO Rapporteur and </FONT>
<BR><FONT SIZE=2>DR registrar) to see if we can get the DR going. </FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Tom Gindin [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, June 12, 2002 4:26 PM</FONT>
<BR><FONT SIZE=2>To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>Cc: 'Laurence Lundblade'; Bruce Stephens; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: RE: DN comparison</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sharon:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMHO the thing which most needs to be clarified in this regard is not</FONT>
<BR><FONT SIZE=2>in X.509 at all, but rather the term &quot;corresponding RDN&quot; in section 13.5.2</FONT>
<BR><FONT SIZE=2>of X.501(and also in section 9.4).&nbsp; Is the &quot;corresponding RDN&quot; of a given</FONT>
<BR><FONT SIZE=2>RDN in the presented DN the RDN which occupies the same position or is it</FONT>
<BR><FONT SIZE=2>the RDN which has the same set of attribute types (with a caveat about</FONT>
<BR><FONT SIZE=2>attribute types which occur more than once in a DN)?&nbsp; Until that's cleared</FONT>
<BR><FONT SIZE=2>up, references to the matching rule may not make the responsibilities of an</FONT>
<BR><FONT SIZE=2>implementor any clearer.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Laurence's example with multiple occurrences of the OU attribute is</FONT>
<BR><FONT SIZE=2>the closest I've seen to a plausible example in which re-ordering RDN's</FONT>
<BR><FONT SIZE=2>could cause two DN's which really refer to different entities to match</FONT>
<BR><FONT SIZE=2>inappropriately.&nbsp; Following one of his hints, a similar and slightly</FONT>
<BR><FONT SIZE=2>stronger example could be constructed with multiple occurrences of the DC</FONT>
<BR><FONT SIZE=2>attribute as well (DC=com, DC=company, DC=fr vs. DC=fr, DC=company, DC=com</FONT>
<BR><FONT SIZE=2>representing the quite legal DNS names fr.company.com and com.company.fr).</FONT>
<BR><FONT SIZE=2>However, AFAIK nobody has shown an example in which re-ordering RDN's with</FONT>
<BR><FONT SIZE=2>different attribute structures would do this.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If I were to locate the &quot;corresponding RDN&quot; by a heuristic which said</FONT>
<BR><FONT SIZE=2>that two RDN's correspond if they have the same set of attribute types and</FONT>
<BR><FONT SIZE=2>if any of those attribute types occur more than once in a DN, the relative</FONT>
<BR><FONT SIZE=2>position of the occurrence of the attribute type in each DN is the same, I</FONT>
<BR><FONT SIZE=2>would not produce any obviously perverse results but I would match C=CA,</FONT>
<BR><FONT SIZE=2>ST=ON, L=Ottawa, O=Entrust with C=CA, O=Entrust, ST=ON, L=Ottawa.&nbsp; I think</FONT>
<BR><FONT SIZE=2>that's why we need clarity as to whether this heuristic is required,</FONT>
<BR><FONT SIZE=2>permitted, or forbidden as an interpretation of the term corresponding RDN</FONT>
<BR><FONT SIZE=2>within distinguishedNameMatch.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tom Gindin</FONT>
</P>
<BR>

<P><FONT SIZE=2>Sharon Boeyen &lt;[e-mail]&gt; on 06/12/2002 10:53:16 AM</FONT>
</P>

<P><FONT SIZE=2>To:&nbsp;&nbsp;&nbsp; &quot;'Laurence Lundblade'&quot; &lt;[e-mail]&gt;, Tom</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gindin/Watson/IBM@IBMUS, Bruce Stephens</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>cc:&nbsp;&nbsp;&nbsp; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject:&nbsp;&nbsp;&nbsp; RE: DN comparison</FONT>
</P>
<BR>

<P><FONT SIZE=2>Just to close one loop in this discussion, I want to let you know that</FONT>
<BR><FONT SIZE=2>although X.509</FONT>
<BR><FONT SIZE=2>didn't have any specific text on this topic previously that is being</FONT>
<BR><FONT SIZE=2>changed and the following</FONT>
<BR><FONT SIZE=2>changes are being made in current working document. This ties the matching</FONT>
<BR><FONT SIZE=2>of DNs in 509</FONT>
<BR><FONT SIZE=2>to the X.501 matching rule and outlines where the matches occur. Note that</FONT>
<BR><FONT SIZE=2>this applies</FONT>
<BR><FONT SIZE=2>regardless of whether or not those DNs in certificates ever get</FONT>
<BR><FONT SIZE=2>instantiated as directory</FONT>
<BR><FONT SIZE=2>entries.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Here are the upcoming changes to X.509 on this topic:</FONT>
</P>
<BR>

<P><FONT SIZE=2>1 The following text will be added to clause 7 of X.509:</FONT>
</P>
<BR>

<P><FONT SIZE=2>The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.</FONT>
<BR><FONT SIZE=2>X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the</FONT>
<BR><FONT SIZE=2>issuer field of one certificate with the DN in the subject field of</FONT>
<BR><FONT SIZE=2>another.</FONT>
</P>
<BR>

<P><FONT SIZE=2>2 In clause 8.6.2.2, the following will be added as a new paragraph</FONT>
<BR><FONT SIZE=2>immediately following the paragraph that begins with &quot;The distributionPoint</FONT>
<BR><FONT SIZE=2>component contains.&quot;:</FONT>
</P>
<BR>

<P><FONT SIZE=2>If the certificate in question contains a cRLDistributionPoints extension</FONT>
<BR><FONT SIZE=2>and the CRL contains an issuingDistributionPoint extension, at least one</FONT>
<BR><FONT SIZE=2>name for the distribution point as indicated in the certificate shall match</FONT>
<BR><FONT SIZE=2>a name for the distribution point as indicated in the CRL. Note that in</FONT>
<BR><FONT SIZE=2>both the certificate and CRL there are default names that may apply to the</FONT>
<BR><FONT SIZE=2>distribution point, namely the DN of the CRL issuer (found in the issuer</FONT>
<BR><FONT SIZE=2>field of the CRL). Also, it may be the case that only the</FONT>
<BR><FONT SIZE=2>nameRelativeToCRLIssuer field is present. In that case, a name comparison</FONT>
<BR><FONT SIZE=2>would be done on the full DN, constructed by appending the value of the</FONT>
<BR><FONT SIZE=2>nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.&nbsp; If</FONT>
<BR><FONT SIZE=2>the names being compared are DNs (as opposed to names of other forms within</FONT>
<BR><FONT SIZE=2>the GeneralNames construct), the distinguishedNameMatch matching rule is</FONT>
<BR><FONT SIZE=2>used to compare the two DNs for equality.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>3 In clause 8.4.2.2, the following will be added as a new paragraph</FONT>
<BR><FONT SIZE=2>immediately following the paragraph that begins with &quot;The maximum field</FONT>
<BR><FONT SIZE=2>specifies the lower bound .&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=2>For the directoryName name form, a certificate is considered subordinate to</FONT>
<BR><FONT SIZE=2>the base</FONT>
<BR><FONT SIZE=2>(and therefore a candidate to be within the subtree) if the SEQUENCE of</FONT>
<BR><FONT SIZE=2>RDNs, which forms the full DN in base, is identical to the initial SEQUENCE</FONT>
<BR><FONT SIZE=2>of the same number of RDNs which forms the first part of the DN in the</FONT>
<BR><FONT SIZE=2>subject field of the certificate. The DN in the subject field of the</FONT>
<BR><FONT SIZE=2>certificate may have additional trailing RDNs in its sequence that do not</FONT>
<BR><FONT SIZE=2>appear in the DN in base.</FONT>
</P>
<BR>

<P><FONT SIZE=2>The distinguishedNameMatch matching rule is used to compare the value of</FONT>
<BR><FONT SIZE=2>base&nbsp; with the initial sequence of RDNs in the DN in the subject field of</FONT>
<BR><FONT SIZE=2>the certificate.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Laurence Lundblade [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, June 12, 2002 10:39 AM</FONT>
<BR><FONT SIZE=2>To: Tom Gindin; Bruce Stephens</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: DN comparison</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bruce:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I know, and I think many of us do, that a DN's original use is as</FONT>
<BR><FONT SIZE=2>an</FONT>
<BR><FONT SIZE=2>&gt;index to an X.500 or LDAP entry, that these are tree-structured databases,</FONT>
</P>

<P><FONT SIZE=2>&gt;and that DN's are defined in X.501 as ordered sets (or sequences) of</FONT>
<BR><FONT SIZE=2>RDN's.</FONT>
<BR><FONT SIZE=2>&gt;However, I would like to see someone come up with a plausible example of</FONT>
<BR><FONT SIZE=2>&gt;two DN's which consist of different orderings of the same set of RDN's</FONT>
<BR><FONT SIZE=2>&gt;while referring to different entities.&nbsp; Your point about directory access</FONT>
<BR><FONT SIZE=2>&gt;properties is valid, but is hardly relevant to a comparison of two</FONT>
<BR><FONT SIZE=2>&gt;different DN's.</FONT>
</P>
<BR>

<P><FONT SIZE=2>In the DNS world order is pretty important as seen from my previous example</FONT>
</P>

<P><FONT SIZE=2>of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the</FONT>
<BR><FONT SIZE=2>DNS world though I think because the parts of the domain name aren't</FONT>
<BR><FONT SIZE=2>tagged. Given that hint how about this example?</FONT>
</P>
<BR>

<P><FONT SIZE=2>(ou=finance)(ou=it)(o=moderatelyconfused)</FONT>
<BR><FONT SIZE=2>(ou=it)(ou=finance)(o=moderatelyconfused)</FONT>
</P>
<BR>

<P><FONT SIZE=2>IT can have it's own finance department and finance can have it's own IT</FONT>
<BR><FONT SIZE=2>department.</FONT>
</P>
<BR>

<P><FONT SIZE=2>On the parsing implementation side dealing with a SEQUENCE is easier than a</FONT>
</P>

<P><FONT SIZE=2>SET as someone already mentioned. Dunno about the server/CA side</FONT>
<BR><FONT SIZE=2>implementation.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Didn't seem that anyone is seriously considering changing this, but the</FONT>
<BR><FONT SIZE=2>fact that it could matter, that a change would complicate implementations a</FONT>
</P>

<P><FONT SIZE=2>little, and a change would add more confusion (let me personally serve as</FONT>
<BR><FONT SIZE=2>an example of confusion :-), it seems a change would be very bad.</FONT>
</P>
<BR>

<P><FONT SIZE=2>LL</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C212E0.09906EF0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DDMLV17182 for ietf-pkix-bks; Thu, 13 Jun 2002 06:22:21 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDMJn17176 for <[e-mail]>; Thu, 13 Jun 2002 06:22:20 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA22454; Thu, 13 Jun 2002 15:25:53 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061315215499:89 ; Thu, 13 Jun 2002 15:21:54 +0200 
Message-ID: <[e-mail]>
Date: Thu, 13 Jun 2002 15:21:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: Pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 15:21:55, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 15:22:12, Serialize complete at 13/06/2002 15:22:12
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice,
 
> Suggest we revise the draft to add the explanatory note, with the proper
> reference to ISO IS 4217.  This should clarify this matter.  Given that the
> ISO standard provides an international interpretation for monetary codes, it
> would be prudent to adhere to that standard.  (I assume there is a revision
> to this 1995 standard in the works, to address the common European
> currency.)

The currency coding for the euro is:  EUR (978).

Denis

BTW, I have not seen yet a response to my comments on this document.

> It might be helpful as well to add a short appendix that provides a complete
> example of use of the warranty extension.
> 
> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     [phone]
> Cell:         613-291-0331
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Housley, Russ
> Sent: June 3, 2002 11:41 AM
> To: Tom Gindin
> Cc: Juergen Brauckmann; [e-mail]; Pkix
> Subject: Re: draft-ietf-pkix-warranty-extn-01
> 
> Tom:
> 
> I am not arguing against explanatory text, but I am suggesting that we not
> invent another means of describing monetary values.
> 
> Russ
> 
> At 11:37 AM 6/3/2002 -0400, Tom Gindin wrote:
> 
> >       Russ:
> >
> >       Since this structure is specified in an ISO standard, but it seems
> to
> >be fairly subject to misunderstanding, I would still recommend putting in
> >the sentence I suggested below ("The actual monetary value in the named
> >currency unit, when amtExp10 is present, is amount divided by 10 to the
> >(amtExp10) power".).  There is clearly nothing to be done about the format
> >specification or even the field name.  IMHO, that field name is more
> >naturally interpreted in Juergen's way than otherwise.
> >
> >             Tom Gindin
> >
> >
> >"Housley, Russ" <[e-mail]> on 06/03/2002 11:29:12 AM
> >
> >To:    Tom Gindin/Watson/IBM@IBMUS
> >cc:    Juergen Brauckmann <[e-mail]>,
> >        [e-mail], Pkix <[e-mail]>
> >Subject:    Re: draft-ietf-pkix-warranty-extn-01
> >
> >
> >Tom & Juergen:
> >
> >This form of representing monetary values was not invented by the authors
> >of this specification.  I it is used many different places, and it is
> >specified in   ISO 4217 [1].
> >
> >Russ
> >
> >
> >[1]     ISO. Codes for the Representation of Currencies and
> >            Funds," ISO 4217. 1995.
> >
> >
> >At 05:16 PM 5/31/2002 -0400, Tom Gindin wrote:
> >
> >
> > >       Juergen:
> > >
> > >       This depends on the interpretation of the text.  There are two
> ways
> > >to resolve this.  Either the amtExp10 field should have a different range
> > >(perhaps (-6..MAX)) or amtExp10 is to be interpreted as a resolution
> > >exponent only, so the actual value is amount / 10**amtExp10.  The example
> > >points towards the second option.
> > >       If the second of these options is to be taken, the wording must
> > >change.  I suggest adding after the sentence defining amtExp10 an extra
> > >sentence as follows: "The actual monetary value in the named currency
> >unit,
> > >when amtExp10 is present, is amount divided by 10 to the (amtExp10)
> >power".
> > >Anyway, why is this value an exponent base 10?  Not that long ago, one of
> > >the world's principal hard currencies had two minor units, 1/20 and
> 1/240,
> > >and I'm not sure there aren't some similar cases still around.  It could
> >be
> > >called minorUnitDivisor and the value would just be amount /
> > >minorUnitDivisor.
> > >
> > >             Tom Gindin
> > >
> > >
> > >Juergen Brauckmann <[e-mail]>@mail.imc.org on 05/31/2002
> > >09:15:27 AM
> > >
> > >Sent by:    [e-mail]
> > >
> > >
> > >To:    [e-mail]
> > >cc:    Pkix <[e-mail]>
> > >Subject:    Re: draft-ietf-pkix-warranty-extn-01
> > >
> > >
> > >
> > >Hi.
> > >
> > >How should extendedWarranty be used? Perhaps you can give an example?
> > >
> > >Format of the currency field in CurrencyAmount: There is at least one
> > >standard ("ETSI qualified certificate profile") I know of which
> > >recommends use of a PrintableString and the alphabetic code from ISO
> > >4217.
> > >
> > >The example in chapter 2.2 is wrong:
> > >  "$48,525.50 (in US dollars) is represented as:
> > >      currency =      840
> > >      amount   =  4852550
> > >      amtExp10 =        2"
> > >
> > >That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
> > >say that amtExp10 is -2, but you cannot do that because it has to be >=
> > >0.
> > >
> > >Regards,
> > >    Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DCasW15450 for ietf-pkix-bks; Thu, 13 Jun 2002 05:36:54 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DCaqn15445 for <[e-mail]>; Thu, 13 Jun 2002 05:36:52 -0700 (PDT)
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g5DCaqRH011138; Thu, 13 Jun 2002 08:36:52 -0400 (EDT)
Received: from asturgeonpc (ottawa-dial-64-26-139-154.d-ip.magma.ca [64.26.139.154]) by mail3.magma.ca (Magma's Mail Server) with SMTP id g5DCaZhr018703; Thu, 13 Jun 2002 08:36:36 -0400 (EDT)
Reply-To: <[e-mail]>
From: "Alice Sturgeon" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: "Juergen Brauckmann" <[e-mail]>, "Pkix" <[e-mail]>
Subject: RE: draft-ietf-pkix-warranty-extn-01
Date: Thu, 13 Jun 2002 08:46:46 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Suggest we revise the draft to add the explanatory note, with the proper
reference to ISO IS 4217.  This should clarify this matter.  Given that the
ISO standard provides an international interpretation for monetary codes, it
would be prudent to adhere to that standard.  (I assume there is a revision
to this 1995 standard in the works, to address the common European
currency.)
It might be helpful as well to add a short appendix that provides a complete
example of use of the warranty extension.

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     [phone]
Cell:         613-291-0331




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Housley, Russ
Sent: June 3, 2002 11:41 AM
To: Tom Gindin
Cc: Juergen Brauckmann; [e-mail]; Pkix
Subject: Re: draft-ietf-pkix-warranty-extn-01


Tom:

I am not arguing against explanatory text, but I am suggesting that we not
invent another means of describing monetary values.

Russ

At 11:37 AM 6/3/2002 -0400, Tom Gindin wrote:

>       Russ:
>
>       Since this structure is specified in an ISO standard, but it seems
to
>be fairly subject to misunderstanding, I would still recommend putting in
>the sentence I suggested below ("The actual monetary value in the named
>currency unit, when amtExp10 is present, is amount divided by 10 to the
>(amtExp10) power".).  There is clearly nothing to be done about the format
>specification or even the field name.  IMHO, that field name is more
>naturally interpreted in Juergen's way than otherwise.
>
>             Tom Gindin
>
>
>"Housley, Russ" <[e-mail]> on 06/03/2002 11:29:12 AM
>
>To:    Tom Gindin/Watson/IBM@IBMUS
>cc:    Juergen Brauckmann <[e-mail]>,
>        [e-mail], Pkix <[e-mail]>
>Subject:    Re: draft-ietf-pkix-warranty-extn-01
>
>
>Tom & Juergen:
>
>This form of representing monetary values was not invented by the authors
>of this specification.  I it is used many different places, and it is
>specified in   ISO 4217 [1].
>
>Russ
>
>
>[1]     ISO. Codes for the Representation of Currencies and
>            Funds," ISO 4217. 1995.
>
>
>At 05:16 PM 5/31/2002 -0400, Tom Gindin wrote:
>
>
> >       Juergen:
> >
> >       This depends on the interpretation of the text.  There are two
ways
> >to resolve this.  Either the amtExp10 field should have a different range
> >(perhaps (-6..MAX)) or amtExp10 is to be interpreted as a resolution
> >exponent only, so the actual value is amount / 10**amtExp10.  The example
> >points towards the second option.
> >       If the second of these options is to be taken, the wording must
> >change.  I suggest adding after the sentence defining amtExp10 an extra
> >sentence as follows: "The actual monetary value in the named currency
>unit,
> >when amtExp10 is present, is amount divided by 10 to the (amtExp10)
>power".
> >Anyway, why is this value an exponent base 10?  Not that long ago, one of
> >the world's principal hard currencies had two minor units, 1/20 and
1/240,
> >and I'm not sure there aren't some similar cases still around.  It could
>be
> >called minorUnitDivisor and the value would just be amount /
> >minorUnitDivisor.
> >
> >             Tom Gindin
> >
> >
> >Juergen Brauckmann <[e-mail]>@mail.imc.org on 05/31/2002
> >09:15:27 AM
> >
> >Sent by:    [e-mail]
> >
> >
> >To:    [e-mail]
> >cc:    Pkix <[e-mail]>
> >Subject:    Re: draft-ietf-pkix-warranty-extn-01
> >
> >
> >
> >Hi.
> >
> >How should extendedWarranty be used? Perhaps you can give an example?
> >
> >Format of the currency field in CurrencyAmount: There is at least one
> >standard ("ETSI qualified certificate profile") I know of which
> >recommends use of a PrintableString and the alphabetic code from ISO
> >4217.
> >
> >The example in chapter 2.2 is wrong:
> >  "$48,525.50 (in US dollars) is represented as:
> >      currency =      840
> >      amount   =  4852550
> >      amtExp10 =        2"
> >
> >That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
> >say that amtExp10 is -2, but you cannot do that because it has to be >=
> >0.
> >
> >Regards,
> >    Juergen



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBe9C12471 for ietf-pkix-bks; Thu, 13 Jun 2002 04:40:09 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBe7n12467 for <[e-mail]>; Thu, 13 Jun 2002 04:40:07 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5DBe2g5147194; Thu, 13 Jun 2002 07:40:02 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DBe1I124596; Thu, 13 Jun 2002 07:40:01 -0400
Importance: Normal
Sensitivity: 
Subject: RE: DN comparison
To: Sharon Boeyen <[e-mail]>
Cc: "'Laurence Lundblade'" <[e-mail]>, Bruce Stephens <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 12 Jun 2002 16:26:14 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/13/2002 07:40:01 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Sharon:

      IMHO the thing which most needs to be clarified in this regard is not
in X.509 at all, but rather the term "corresponding RDN" in section 13.5.2
of X.501(and also in section 9.4).  Is the "corresponding RDN" of a given
RDN in the presented DN the RDN which occupies the same position or is it
the RDN which has the same set of attribute types (with a caveat about
attribute types which occur more than once in a DN)?  Until that's cleared
up, references to the matching rule may not make the responsibilities of an
implementor any clearer.
      Laurence's example with multiple occurrences of the OU attribute is
the closest I've seen to a plausible example in which re-ordering RDN's
could cause two DN's which really refer to different entities to match
inappropriately.  Following one of his hints, a similar and slightly
stronger example could be constructed with multiple occurrences of the DC
attribute as well (DC=com, DC=company, DC=fr vs. DC=fr, DC=company, DC=com
representing the quite legal DNS names fr.company.com and com.company.fr).
However, AFAIK nobody has shown an example in which re-ordering RDN's with
different attribute structures would do this.
      If I were to locate the "corresponding RDN" by a heuristic which said
that two RDN's correspond if they have the same set of attribute types and
if any of those attribute types occur more than once in a DN, the relative
position of the occurrence of the attribute type in each DN is the same, I
would not produce any obviously perverse results but I would match C=CA,
ST=ON, L=Ottawa, O=Entrust with C=CA, O=Entrust, ST=ON, L=Ottawa.  I think
that's why we need clarity as to whether this heuristic is required,
permitted, or forbidden as an interpretation of the term corresponding RDN
within distinguishedNameMatch.

            Tom Gindin


Sharon Boeyen <[e-mail]> on 06/12/2002 10:53:16 AM

To:    "'Laurence Lundblade'" <[e-mail]>, Tom
       Gindin/Watson/IBM@IBMUS, Bruce Stephens
       <[e-mail]>
cc:    [e-mail]
Subject:    RE: DN comparison


Just to close one loop in this discussion, I want to let you know that
although X.509
didn't have any specific text on this topic previously that is being
changed and the following
changes are being made in current working document. This ties the matching
of DNs in 509
to the X.501 matching rule and outlines where the matches occur. Note that
this applies
regardless of whether or not those DNs in certificates ever get
instantiated as directory
entries.


Here are the upcoming changes to X.509 on this topic:


1 The following text will be added to clause 7 of X.509:


The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.
X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the
issuer field of one certificate with the DN in the subject field of
another.


2 In clause 8.6.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The distributionPoint
component contains.":


If the certificate in question contains a cRLDistributionPoints extension
and the CRL contains an issuingDistributionPoint extension, at least one
name for the distribution point as indicated in the certificate shall match
a name for the distribution point as indicated in the CRL. Note that in
both the certificate and CRL there are default names that may apply to the
distribution point, namely the DN of the CRL issuer (found in the issuer
field of the CRL). Also, it may be the case that only the
nameRelativeToCRLIssuer field is present. In that case, a name comparison
would be done on the full DN, constructed by appending the value of the
nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.  If
the names being compared are DNs (as opposed to names of other forms within
the GeneralNames construct), the distinguishedNameMatch matching rule is
used to compare the two DNs for equality.



3 In clause 8.4.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The maximum field
specifies the lower bound ."


For the directoryName name form, a certificate is considered subordinate to
the base
(and therefore a candidate to be within the subtree) if the SEQUENCE of
RDNs, which forms the full DN in base, is identical to the initial SEQUENCE
of the same number of RDNs which forms the first part of the DN in the
subject field of the certificate. The DN in the subject field of the
certificate may have additional trailing RDNs in its sequence that do not
appear in the DN in base.


The distinguishedNameMatch matching rule is used to compare the value of
base  with the initial sequence of RDNs in the DN in the subject field of
the certificate.





-----Original Message-----
From: Laurence Lundblade [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [e-mail]
Subject: Re: DN comparison






At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:
>       Bruce:
>
>       I know, and I think many of us do, that a DN's original use is as
an
>index to an X.500 or LDAP entry, that these are tree-structured databases,

>and that DN's are defined in X.501 as ordered sets (or sequences) of
RDN's.
>However, I would like to see someone come up with a plausible example of
>two DN's which consist of different orderings of the same set of RDN's
>while referring to different entities.  Your point about directory access
>properties is valid, but is hardly relevant to a comparison of two
>different DN's.


In the DNS world order is pretty important as seen from my previous example

of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the
DNS world though I think because the parts of the domain name aren't
tagged. Given that hint how about this example?


(ou=finance)(ou=it)(o=moderatelyconfused)
(ou=it)(ou=finance)(o=moderatelyconfused)


IT can have it's own finance department and finance can have it's own IT
department.


On the parsing implementation side dealing with a SEQUENCE is easier than a

SET as someone already mentioned. Dunno about the server/CA side
implementation.


Didn't seem that anyone is seriously considering changing this, but the
fact that it could matter, that a change would complicate implementations a

little, and a change would add more confusion (let me personally serve as
an example of confusion :-), it seems a change would be very bad.


LL






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBR6O12053 for ietf-pkix-bks; Thu, 13 Jun 2002 04:27:06 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBR5n12049 for <[e-mail]>; Thu, 13 Jun 2002 04:27:05 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07611; Thu, 13 Jun 2002 07:26:30 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-wlan-extns-00.txt
Date: Thu, 13 Jun 2002 07:26:29 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Wireless LAN Certificate Extensions
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-wlan-extns-00.txt
	Pages		: 6
	Date		: 12-Jun-02
	
This document defines two EAP extended key usage values and a
certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-wlan-extns-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-wlan-extns-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-wlan-extns-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-wlan-extns-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBR1X12047 for ietf-pkix-bks; Thu, 13 Jun 2002 04:27:01 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBR0n12043 for <[e-mail]>; Thu, 13 Jun 2002 04:27:00 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07594; Thu, 13 Jun 2002 07:26:25 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-00.txt
Date: Thu, 13 Jun 2002 07:26:24 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Attribute Certificate Policies Extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-00.txt
	Pages		: 8
	Date		: 12-Jun-02
	
This document describes a certificate extension to explicitly state the 
attribute certificate policies that apply to the attributes contained 
in the certificate containing that extension.

It also defines two certificate extensions that may be used to indicate 
the location of the public or private repositories where the 
certificate is being stored.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-acpolicies-extn-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-acpolicies-extn-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBQod12041 for ietf-pkix-bks; Thu, 13 Jun 2002 04:26:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBQnn12036 for <[e-mail]>; Thu, 13 Jun 2002 04:26:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07562; Thu, 13 Jun 2002 07:26:14 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-04.txt
Date: Thu, 13 Jun 2002 07:26:14 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Internet X.509 Public Key Infrastructure Permanent 
                          Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-04.txt
	Pages		: 10
	Date		: 12-Jun-02
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pi-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pi-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pi-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pi-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D8VnG27383 for ietf-pkix-bks; Thu, 13 Jun 2002 01:31:49 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D8Vmn27379 for <[e-mail]>; Thu, 13 Jun 2002 01:31:48 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA10744; Thu, 13 Jun 2002 10:35:24 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061310311305:39 ; Thu, 13 Jun 2002 10:31:13 +0200 
Message-ID: <[e-mail]>
Date: Thu, 13 Jun 2002 10:31:12 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Hui Lai <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: TSA policy ID
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 10:31:13, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 10:31:44, Serialize complete at 13/06/2002 10:31:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hui,

> Hi Denis,
> 
>         If we define our own policy, what OID should we use? Could we just
> pick any un-registered OID ?

Certainly not.

You may get some guidance in the annex from the Permanent Identifier draft: 
http://www.imc.org/draft-ietf-pkix-pi

The Chinese University of Hong Kong would need to get on OID.

Denis 

> But It seems that there is unique interpretation on individual number in
> each OID. Could you tell me more?
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, June 13, 2002 2:37 PM
> To: Hui Lai
> Cc: '[e-mail]'
> Subject: Re: TSA policy ID
> 
> >
> > Hi,
> >         According to RFC 3161,  TSAPolicyID must be included.
> 
> > I have no idea on what it means?
> 
> > How could I find out what OID should be used for my TSA ?
> 
> The Chinese University of Hong Kong may define its own policy and may
> then use an OID to identity it.
> 
> FYI, the document Policy Requirements for Time-Stamping Authorities
> (http://www.imc.org/draft-ietf-pkix-pr-tsa) identifies one policy and
> assigns one OID for it. If you believe that you can meet the requirements of
> that policy, then you can use that OID. If one of these requirements is not
> met, then you shall not use it and use your own definition. The content of
> the above document may help you to describe your own policy.
> 
> Denis
> 
> > Could anyone help me?
> >
> > Thanks,
> >
> > Stern Lai
> > Open Secure Time-stamping Platform
> > Information Technology Services Centre
> > The Chinese University of Hong Kong


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D8NtX26634 for ietf-pkix-bks; Thu, 13 Jun 2002 01:23:55 -0700 (PDT)
Received: from servere.csc.cuhk.edu.hk (servere.itsc.cuhk.edu.hk [137.189.29.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D8Nsn26630 for <[e-mail]>; Thu, 13 Jun 2002 01:23:54 -0700 (PDT)
Received: by servere.itsc.cuhk.edu.hk with Internet Mail Service (5.5.2653.19) id <2A3SJS37>; Thu, 13 Jun 2002 16:23:53 +0800
Message-ID: <[e-mail]>
From: Hui Lai <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: TSA policy ID
Date: Thu, 13 Jun 2002 16:23:51 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis,

	If we define our own policy, what OID should we use? Could we just
pick any un-registered OID ?
But It seems that there is unique interpretation on individual number in
each OID. Could you tell me more? 


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, June 13, 2002 2:37 PM
To: Hui Lai
Cc: '[e-mail]'
Subject: Re: TSA policy ID


> 
> Hi,
>         According to RFC 3161,  TSAPolicyID must be included. 

> I have no idea on what it means?

> How could I find out what OID should be used for my TSA ?

The Chinese University of Hong Kong may define its own policy and may 
then use an OID to identity it.

FYI, the document Policy Requirements for Time-Stamping Authorities
(http://www.imc.org/draft-ietf-pkix-pr-tsa) identifies one policy and
assigns one OID for it. If you believe that you can meet the requirements of
that policy, then you can use that OID. If one of these requirements is not
met, then you shall not use it and use your own definition. The content of
the above document may help you to describe your own policy.

Denis

> Could anyone help me?
> 
> Thanks,
> 
> Stern Lai
> Open Secure Time-stamping Platform
> Information Technology Services Centre
> The Chinese University of Hong Kong


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D6b8T09131 for ietf-pkix-bks; Wed, 12 Jun 2002 23:37:08 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D6b6n09120 for <[e-mail]>; Wed, 12 Jun 2002 23:37:06 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA15406; Thu, 13 Jun 2002 08:40:40 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002061308365141:7 ; Thu, 13 Jun 2002 08:36:51 +0200 
Message-ID: <[e-mail]>
Date: Thu, 13 Jun 2002 08:36:50 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Hui Lai <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: TSA policy ID
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 08:36:51, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 13/06/2002 08:37:02, Serialize complete at 13/06/2002 08:37:02
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Hi,
>         According to RFC 3161,  TSAPolicyID must be included. 

> I have no idea on what it means?

> How could I find out what OID should be used for my TSA ?

The Chinese University of Hong Kong may define its own policy and may 
then use an OID to identity it.

FYI, the document Policy Requirements for Time-Stamping Authorities
(http://www.imc.org/draft-ietf-pkix-pr-tsa) identifies one policy and
assigns one OID for it. If you believe that you can meet the requirements of
that policy, then you can use that OID. If one of these requirements is not
met, then you shall not use it and use your own definition. The content of
the above document may help you to describe your own policy.

Denis

> Could anyone help me?
> 
> Thanks,
> 
> Stern Lai
> Open Secure Time-stamping Platform
> Information Technology Services Centre
> The Chinese University of Hong Kong


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2uS926916 for ietf-pkix-bks; Wed, 12 Jun 2002 19:56:28 -0700 (PDT)
Received: from servere.csc.cuhk.edu.hk (servere.itsc.cuhk.edu.hk [137.189.29.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2uQn26912 for <[e-mail]>; Wed, 12 Jun 2002 19:56:27 -0700 (PDT)
Received: by servere.itsc.cuhk.edu.hk with Internet Mail Service (5.5.2653.19) id <2A3SJRRD>; Thu, 13 Jun 2002 10:56:30 +0800
Message-ID: <[e-mail]>
From: Hui Lai <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: TSA policy ID
Date: Thu, 13 Jun 2002 10:56:27 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="big5"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
	According to RFC 3161,  TSAPolicyID must be included. I have no idea
on what it means?
How could I find out what OID should be used for my TSA ?

Could anyone help me? 

Thanks,	

Stern Lai
Open Secure Time-stamping Platform
Information Technology Services Centre
The Chinese University of Hong Kong



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2YXW26476 for ietf-pkix-bks; Wed, 12 Jun 2002 19:34:33 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2YVn26472 for <[e-mail]>; Wed, 12 Jun 2002 19:34:31 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g5D2Y3EJ002395; Thu, 13 Jun 2002 14:34:03 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA09651; Thu, 13 Jun 2002 14:34:01 +1200 (NZST) (sender [e-mail])
Date: Thu, 13 Jun 2002 14:34:01 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: CMP Discussion References
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carlisle Adams <[e-mail]> writes:

>I have no idea.  The authors that were doing that draft have let it expire and
>no one else has yet volunteered to take this on.

Given the problems with the cmp-t draft and the fact that it doesn't do
anything which isn't already done in RFC 2068 (and 2068 has the benefit of
extensive real-world implementation experience and research going into it), is
there any actual need for cmp-t?  In other words since 2068 is a better-
designed, very widely-implemented superset of cmp-t, why not just let cmp-t
lapse?

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D0iYX24326 for ietf-pkix-bks; Wed, 12 Jun 2002 17:44:34 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D0iWn24321 for <[e-mail]>; Wed, 12 Jun 2002 17:44:32 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g5D0iSg09070; Wed, 12 Jun 2002 17:44:28 -0700 (PDT)
Received: from rsasecurity.com (eskarina.eng.x509.com [10.7.33.45]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g5D0iSt24476; Wed, 12 Jun 2002 17:44:28 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 12 Jun 2002 17:36:12 -0700
From: Marc Branchaud <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian Hunter <[e-mail]>
CC: [e-mail]
Subject: Re: Delta CRL and CRL entries
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe CRL5 would contain no mention of the certificate, and that 
merely archiving the base CRLs would not be enough for you to retain 
proof that the cert was temporarily suspended.  The reason is simply 
because the suspension period was contained entirely within the validity 
period of base CRL1.  In other words, the base CRLs did not have a fine 
enough granularity to capture what happened to the certificate.

Note that the problem also exists with the delta CRLs.  That is, a cert 
could be suspended and reinstated within the lifetime of a single delta 
CRL, and the world would be none the wiser (unless the CA published some 
kind of emergency-CRL before the notAfter time of the delta CRL).

I think you're stuck archiving the delta CRLs, at least to the extent 
that the deltas contain information that isn't shown in the base CRLs.

		M.


Brian Hunter wrote:
> Hello,
> 
> I was hoping that someone could clarify this for me.
> 
> In the context of a DPV service, I have been trying to decide what CRLs must be
> saved in order to archive sufficient information such that a future query to the
> server can provide the same status result as the original request for the same
> certificate.  Obviously, I could archive all CRLs and delta CRLs (and OCSP) that
> have been used, but I would like to be able to throw away as many as possible
> but still be able to find the same result or justify my original result.
> 
> My question is, can a certificate appear on the same CRL more than once, with
> different revocation reasons?  e.g. certificateHold and removeFromCRL.  I don't
> find that 5.1.2.6 in RFC 3280 clearly states that this is not possible.
> 
> My question is based on the following situation:
> 
>         CRL1                        CRL5
> |-----------------------------||----------------------------------|
> 
>      d CRL2      d CRL3     d CRL4
>    |--------||----------||----------|
>      b=1         b=1         b=1
>   ^       ^
>   |       |
>  Hold     |
>       removeFromCRL
>   
> 
> Where d = delta
>       b = basis for delta CRL
> 
> My scenario is, the certificateHold is first recorded in CRL2.  CRL3 includes
> the removeFromCRL entry and CRL4 must also.  What would (or could) CRL5
> contain?  Would it contain:
>   1-nothing
>   2-removeFromCRL, or
>   3-certificateHold and removeFromCRL?
> 
> My concern is that if the case is 1 or 2, then storing complete CRLs would not
> contain all status changes to certificates.  That is, if I validated based on
> CRL2 but only stored CRL1 and CRL5, I could never prove that my validation was
> correct in saying "suspended" at that given moment.  I originally thought that
> storing all complete CRLs would be sufficient but this could prove me wrong.
> 
> Thanks for any help and sorry for the long example.
> 
> Brian
> 





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CL0kD19152 for ietf-pkix-bks; Wed, 12 Jun 2002 14:00:46 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5CL0in19148 for <[e-mail]>; Wed, 12 Jun 2002 14:00:45 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Jun 2002 21:00:40 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA03075 for <[e-mail]>; Wed, 12 Jun 2002 17:00:46 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5CKwnl10482 for <[e-mail]>; Wed, 12 Jun 2002 16:58:49 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZN0HR>; Wed, 12 Jun 2002 17:00:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.4]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZN0HN; Wed, 12 Jun 2002 17:00:40 -0400
From: "Housley, Russ" <[e-mail]>
To: Brian Hunter <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 12 Jun 2002 16:47:59 -0400
Subject: Re: Delta CRL and CRL entries
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Brian:

I would expect a revoked (or suspended) certificate to appear only once on 
a CRL.  However, I could not find any text to support (or to refute) this 
position.  I looked in RFC 3280 and the 4th Edition of X.509.

Russ

At 06:18 PM 6/12/2002 +0200, Brian Hunter wrote:

>Hello,
>
>I was hoping that someone could clarify this for me.
>
>In the context of a DPV service, I have been trying to decide what CRLs 
>must be
>saved in order to archive sufficient information such that a future query 
>to the
>server can provide the same status result as the original request for the same
>certificate.  Obviously, I could archive all CRLs and delta CRLs (and 
>OCSP) that
>have been used, but I would like to be able to throw away as many as possible
>but still be able to find the same result or justify my original result.
>
>My question is, can a certificate appear on the same CRL more than once, with
>different revocation reasons?  e.g. certificateHold and removeFromCRL.  I 
>don't
>find that 5.1.2.6 in RFC 3280 clearly states that this is not possible.
>
>My question is based on the following situation:
>
>         CRL1                        CRL5
>|-----------------------------||----------------------------------|
>
>      d CRL2      d CRL3     d CRL4
>    |--------||----------||----------|
>      b=1         b=1         b=1
>   ^       ^
>   |       |
>  Hold     |
>       removeFromCRL
>
>
>Where d = delta
>       b = basis for delta CRL
>
>My scenario is, the certificateHold is first recorded in CRL2.  CRL3 includes
>the removeFromCRL entry and CRL4 must also.  What would (or could) CRL5
>contain?  Would it contain:
>   1-nothing
>   2-removeFromCRL, or
>   3-certificateHold and removeFromCRL?
>
>My concern is that if the case is 1 or 2, then storing complete CRLs would not
>contain all status changes to certificates.  That is, if I validated based on
>CRL2 but only stored CRL1 and CRL5, I could never prove that my validation was
>correct in saying "suspended" at that given moment.  I originally thought that
>storing all complete CRLs would be sufficient but this could prove me wrong.
>
>Thanks for any help and sorry for the long example.
>
>Brian


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGI5t05268 for ietf-pkix-bks; Wed, 12 Jun 2002 09:18:05 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGI4n05262 for <[e-mail]>; Wed, 12 Jun 2002 09:18:04 -0700 (PDT)
Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id SAA27232 for <[e-mail]>; Wed, 12 Jun 2002 18:17:59 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 12 Jun 2002 18:18:14 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Delta CRL and CRL entries
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I was hoping that someone could clarify this for me.

In the context of a DPV service, I have been trying to decide what CRLs must be
saved in order to archive sufficient information such that a future query to the
server can provide the same status result as the original request for the same
certificate.  Obviously, I could archive all CRLs and delta CRLs (and OCSP) that
have been used, but I would like to be able to throw away as many as possible
but still be able to find the same result or justify my original result.

My question is, can a certificate appear on the same CRL more than once, with
different revocation reasons?  e.g. certificateHold and removeFromCRL.  I don't
find that 5.1.2.6 in RFC 3280 clearly states that this is not possible.

My question is based on the following situation:

        CRL1                        CRL5
|-----------------------------||----------------------------------|

     d CRL2      d CRL3     d CRL4
   |--------||----------||----------|
     b=1         b=1         b=1
  ^       ^
  |       |
 Hold     |
      removeFromCRL
  

Where d = delta
      b = basis for delta CRL

My scenario is, the certificateHold is first recorded in CRL2.  CRL3 includes
the removeFromCRL entry and CRL4 must also.  What would (or could) CRL5
contain?  Would it contain:
  1-nothing
  2-removeFromCRL, or
  3-certificateHold and removeFromCRL?

My concern is that if the case is 1 or 2, then storing complete CRLs would not
contain all status changes to certificates.  That is, if I validated based on
CRL2 but only stored CRL1 and CRL5, I could never prove that my validation was
correct in saying "suspended" at that given moment.  I originally thought that
storing all complete CRLs would be sufficient but this could prove me wrong.

Thanks for any help and sorry for the long example.

Brian


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CFMCe02926 for ietf-pkix-bks; Wed, 12 Jun 2002 08:22:12 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CFM7n02921 for <[e-mail]>; Wed, 12 Jun 2002 08:22:07 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <MV254Z1V>; Wed, 12 Jun 2002 11:22:04 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: Peter Gutmann <[e-mail]>, "'Mikhail Blinov'" <[e-mail]>
Cc: [e-mail]
Subject: RE: CMP Discussion References
Date: Wed, 12 Jun 2002 11:22:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21224.E7D258C0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

------_=_NextPart_001_01C21224.E7D258C0
Content-Type: text/plain

Hi,

I have no idea.  The authors that were doing that draft have let it expire
and no one else has yet volunteered to take this on.

Carlisle.


> ----------
> From: 	Mikhail Blinov[SMTP:[e-mail]]
> Sent: 	Wednesday, June 12, 2002 9:14 AM
> To: 	Peter Gutmann; [e-mail]
> Cc: 	[e-mail]
> Subject: 	Re: CMP Discussion References
> 
> So.
> I appreciate the humour of Peter but seriously
> what's happened with the CMPv2 transport mapping ?
> 
> Michael
> 
> ----- Original Message ----- 
> From: "Peter Gutmann" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, June 10, 2002 11:39 AM
> Subject: Re: CMP Discussion References
> 
> 
> > "Mikhail Blinov" <[e-mail]> writes:
> > 
> > >The CMPv2 Spec does not address the transport issues. So what is the
> standard
> > >mapping of the CMPv2 to TCP/IP at present?
> > 
> > RFC 2068 :-).
> > 
> > Peter.
> > 
> 

------_=_NextPart_001_01C21224.E7D258C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: CMP Discussion References</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I have no =
idea.&nbsp; The authors that were doing that draft have let it expire =
and no one else has yet volunteered to take this on.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Mikhail =
Blinov[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, June 12, 2002 9:14 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Peter Gutmann; =
[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: CMP Discussion References</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I appreciate the humour of Peter but =
seriously</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">what's happened with the CMPv2 =
transport mapping ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Michael</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: &quot;Peter Gutmann&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
&lt;[e-mail]&gt;; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Monday, June 10, 2002 11:39 =
AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: CMP Discussion =
References</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;Mikhail Blinov&quot; =
&lt;[e-mail]&gt; writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;The CMPv2 Spec does not =
address the transport issues. So what is the standard</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;mapping of the CMPv2 to =
TCP/IP at present?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; RFC 2068 :-).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Peter.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C21224.E7D258C0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CErXE02061 for ietf-pkix-bks; Wed, 12 Jun 2002 07:53:33 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CErVn02057 for <[e-mail]>; Wed, 12 Jun 2002 07:53:31 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <MV254YN2>; Wed, 12 Jun 2002 10:53:17 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Laurence Lundblade'" <[e-mail]>, Tom Gindin <[e-mail]>, Bruce Stephens <[e-mail]>
Cc: [e-mail]
Subject: RE: DN comparison
Date: Wed, 12 Jun 2002 10:53:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21220.E2604A90"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

------_=_NextPart_001_01C21220.E2604A90
Content-Type: text/plain

Just to close one loop in this discussion, I want to let you know that
although X.509 
didn't have any specific text on this topic previously that is being changed
and the following
changes are being made in current working document. This ties the matching
of DNs in 509 
to the X.501 matching rule and outlines where the matches occur. Note that
this applies 
regardless of whether or not those DNs in certificates ever get instantiated
as directory 
entries.

Here are the upcoming changes to X.509 on this topic:

1 The following text will be added to clause 7 of X.509:

The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.
X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the
issuer field of one certificate with the DN in the subject field of another.

2 In clause 8.6.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The distributionPoint
component contains.":

If the certificate in question contains a cRLDistributionPoints extension
and the CRL contains an issuingDistributionPoint extension, at least one
name for the distribution point as indicated in the certificate shall match
a name for the distribution point as indicated in the CRL. Note that in both
the certificate and CRL there are default names that may apply to the
distribution point, namely the DN of the CRL issuer (found in the issuer
field of the CRL). Also, it may be the case that only the
nameRelativeToCRLIssuer field is present. In that case, a name comparison
would be done on the full DN, constructed by appending the value of the
nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.  If
the names being compared are DNs (as opposed to names of other forms within
the GeneralNames construct), the distinguishedNameMatch matching rule is
used to compare the two DNs for equality.
  
3 In clause 8.4.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The maximum field
specifies the lower bound ."

For the directoryName name form, a certificate is considered subordinate to
the base 
(and therefore a candidate to be within the subtree) if the SEQUENCE of
RDNs, which forms the full DN in base, is identical to the initial SEQUENCE
of the same number of RDNs which forms the first part of the DN in the
subject field of the certificate. The DN in the subject field of the
certificate may have additional trailing RDNs in its sequence that do not
appear in the DN in base.

The distinguishedNameMatch matching rule is used to compare the value of
base  with the initial sequence of RDNs in the DN in the subject field of
the certificate.


-----Original Message-----
From: Laurence Lundblade [mailto:[e-mail]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [e-mail]
Subject: Re: DN comparison



At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:
>       Bruce:
>
>       I know, and I think many of us do, that a DN's original use is as an
>index to an X.500 or LDAP entry, that these are tree-structured databases,
>and that DN's are defined in X.501 as ordered sets (or sequences) of RDN's.
>However, I would like to see someone come up with a plausible example of
>two DN's which consist of different orderings of the same set of RDN's
>while referring to different entities.  Your point about directory access
>properties is valid, but is hardly relevant to a comparison of two
>different DN's.

In the DNS world order is pretty important as seen from my previous example 
of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the 
DNS world though I think because the parts of the domain name aren't 
tagged. Given that hint how about this example?

(ou=finance)(ou=it)(o=moderatelyconfused)
(ou=it)(ou=finance)(o=moderatelyconfused)

IT can have it's own finance department and finance can have it's own IT 
department.

On the parsing implementation side dealing with a SEQUENCE is easier than a 
SET as someone already mentioned. Dunno about the server/CA side 
implementation.

Didn't seem that anyone is seriously considering changing this, but the 
fact that it could matter, that a change would complicate implementations a 
little, and a change would add more confusion (let me personally serve as 
an example of confusion :-), it seems a change would be very bad.

LL

------_=_NextPart_001_01C21220.E2604A90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: DN comparison</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Just to close one loop in this discussion, I want to =
let you know that although X.509 </FONT>
<BR><FONT SIZE=3D2>didn't have any specific text on this topic =
previously that is being changed and the following</FONT>
<BR><FONT SIZE=3D2>changes are being made in current working document. =
This ties the matching of DNs in 509 </FONT>
<BR><FONT SIZE=3D2>to the X.501 matching rule and outlines where the =
matches occur. Note that this applies </FONT>
<BR><FONT SIZE=3D2>regardless of whether or not those DNs in =
certificates ever get instantiated as directory </FONT>
<BR><FONT SIZE=3D2>entries.</FONT>
</P>

<P><FONT SIZE=3D2>Here are the upcoming changes to X.509 on this =
topic:</FONT>
</P>

<P><FONT SIZE=3D2>1 The following text will be added to clause 7 of =
X.509:</FONT>
</P>

<P><FONT SIZE=3D2>The distinguishedNameMatch matching rule, defined in =
13.5.2 in ITU-T Rec. X.501|ISO/IEC 9594-2, is used to compare the =
Distinguished Name (DN) in the issuer field of one certificate with the =
DN in the subject field of another.</FONT></P>

<P><FONT SIZE=3D2>2 In clause 8.6.2.2, the following will be added as a =
new paragraph immediately following the paragraph that begins with =
&quot;The distributionPoint component contains.&quot;:</FONT></P>

<P><FONT SIZE=3D2>If the certificate in question contains a =
cRLDistributionPoints extension and the CRL contains an =
issuingDistributionPoint extension, at least one name for the =
distribution point as indicated in the certificate shall match a name =
for the distribution point as indicated in the CRL. Note that in both =
the certificate and CRL there are default names that may apply to the =
distribution point, namely the DN of the CRL issuer (found in the =
issuer field of the CRL). Also, it may be the case that only the =
nameRelativeToCRLIssuer field is present. In that case, a name =
comparison would be done on the full DN, constructed by appending the =
value of the nameRelativeToCRLIssuer to the DN found in the issuer =
field of the CRL.&nbsp; If the names being compared are DNs (as opposed =
to names of other forms within the GeneralNames construct), the =
distinguishedNameMatch matching rule is used to compare the two DNs for =
equality.</FONT></P>

<P><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>3 In clause 8.4.2.2, the following will be added as =
a new paragraph immediately following the paragraph that begins with =
&quot;The maximum field specifies the lower bound .&quot;</FONT></P>

<P><FONT SIZE=3D2>For the directoryName name form, a certificate is =
considered subordinate to the base </FONT>
<BR><FONT SIZE=3D2>(and therefore a candidate to be within the subtree) =
if the SEQUENCE of RDNs, which forms the full DN in base, is identical =
to the initial SEQUENCE of the same number of RDNs which forms the =
first part of the DN in the subject field of the certificate. The DN in =
the subject field of the certificate may have additional trailing RDNs =
in its sequence that do not appear in the DN in base.</FONT></P>

<P><FONT SIZE=3D2>The distinguishedNameMatch matching rule is used to =
compare the value of base&nbsp; with the initial sequence of RDNs in =
the DN in the subject field of the certificate.</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Laurence Lundblade [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, June 12, 2002 10:39 AM</FONT>
<BR><FONT SIZE=3D2>To: Tom Gindin; Bruce Stephens</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: DN comparison</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Bruce:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I know, and =
I think many of us do, that a DN's original use is as an</FONT>
<BR><FONT SIZE=3D2>&gt;index to an X.500 or LDAP entry, that these are =
tree-structured databases,</FONT>
<BR><FONT SIZE=3D2>&gt;and that DN's are defined in X.501 as ordered =
sets (or sequences) of RDN's.</FONT>
<BR><FONT SIZE=3D2>&gt;However, I would like to see someone come up =
with a plausible example of</FONT>
<BR><FONT SIZE=3D2>&gt;two DN's which consist of different orderings of =
the same set of RDN's</FONT>
<BR><FONT SIZE=3D2>&gt;while referring to different entities.&nbsp; =
Your point about directory access</FONT>
<BR><FONT SIZE=3D2>&gt;properties is valid, but is hardly relevant to a =
comparison of two</FONT>
<BR><FONT SIZE=3D2>&gt;different DN's.</FONT>
</P>

<P><FONT SIZE=3D2>In the DNS world order is pretty important as seen =
from my previous example </FONT>
<BR><FONT SIZE=3D2>of finance.yahoo.com vs yahoo.finance.com. It's more =
of a big deal in the </FONT>
<BR><FONT SIZE=3D2>DNS world though I think because the parts of the =
domain name aren't </FONT>
<BR><FONT SIZE=3D2>tagged. Given that hint how about this =
example?</FONT>
</P>

<P><FONT =
SIZE=3D2>(ou=3Dfinance)(ou=3Dit)(o=3Dmoderatelyconfused)</FONT>
<BR><FONT =
SIZE=3D2>(ou=3Dit)(ou=3Dfinance)(o=3Dmoderatelyconfused)</FONT>
</P>

<P><FONT SIZE=3D2>IT can have it's own finance department and finance =
can have it's own IT </FONT>
<BR><FONT SIZE=3D2>department.</FONT>
</P>

<P><FONT SIZE=3D2>On the parsing implementation side dealing with a =
SEQUENCE is easier than a </FONT>
<BR><FONT SIZE=3D2>SET as someone already mentioned. Dunno about the =
server/CA side </FONT>
<BR><FONT SIZE=3D2>implementation.</FONT>
</P>

<P><FONT SIZE=3D2>Didn't seem that anyone is seriously considering =
changing this, but the </FONT>
<BR><FONT SIZE=3D2>fact that it could matter, that a change would =
complicate implementations a </FONT>
<BR><FONT SIZE=3D2>little, and a change would add more confusion (let =
me personally serve as </FONT>
<BR><FONT SIZE=3D2>an example of confusion :-), it seems a change would =
be very bad.</FONT>
</P>

<P><FONT SIZE=3D2>LL</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C21220.E2604A90--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CEdbQ01774 for ietf-pkix-bks; Wed, 12 Jun 2002 07:39:37 -0700 (PDT)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CEdQn01768 for <[e-mail]>; Wed, 12 Jun 2002 07:39:36 -0700 (PDT)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5CEdPMU004943 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jun 2002 07:39:25 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.82]) by sabrina.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5CEdMhU001191; Wed, 12 Jun 2002 07:39:23 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 12 Jun 2002 07:39:20 -0700
To: "Tom Gindin" <[e-mail]>, Bruce Stephens <[e-mail]>
From: Laurence Lundblade <[e-mail]>
Subject: Re: DN comparison
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:
>       Bruce:
>
>       I know, and I think many of us do, that a DN's original use is as an
>index to an X.500 or LDAP entry, that these are tree-structured databases,
>and that DN's are defined in X.501 as ordered sets (or sequences) of RDN's.
>However, I would like to see someone come up with a plausible example of
>two DN's which consist of different orderings of the same set of RDN's
>while referring to different entities.  Your point about directory access
>properties is valid, but is hardly relevant to a comparison of two
>different DN's.

In the DNS world order is pretty important as seen from my previous example 
of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the 
DNS world though I think because the parts of the domain name aren't 
tagged. Given that hint how about this example?

(ou=finance)(ou=it)(o=moderatelyconfused)
(ou=it)(ou=finance)(o=moderatelyconfused)

IT can have it's own finance department and finance can have it's own IT 
department.

On the parsing implementation side dealing with a SEQUENCE is easier than a 
SET as someone already mentioned. Dunno about the server/CA side 
implementation.

Didn't seem that anyone is seriously considering changing this, but the 
fact that it could matter, that a change would complicate implementations a 
little, and a change would add more confusion (let me personally serve as 
an example of confusion :-), it seems a change would be very bad.

LL



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CDI8t26471 for ietf-pkix-bks; Wed, 12 Jun 2002 06:18:08 -0700 (PDT)
Received: from mail1.sse.ie (mail1.sse.ie [193.120.32.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CDI2n26451 for <[e-mail]>; Wed, 12 Jun 2002 06:18:04 -0700 (PDT)
Received: from michaelb (michaelb.sse.ie [193.120.33.15]) by mail1.sse.ie (8.11.1/8.11.1) with SMTP id g5CDH6V04518; Wed, 12 Jun 2002 14:17:10 +0100
Message-ID: <012d01c21213$74d7bf10$0f2178c1@michaelb>
From: "Mikhail Blinov" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: CMP Discussion References
Date: Wed, 12 Jun 2002 14:14:51 +0100
Organization: Guardeonic Solutions
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So.
I appreciate the humour of Peter but seriously
what's happened with the CMPv2 transport mapping ?

Michael

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, June 10, 2002 11:39 AM
Subject: Re: CMP Discussion References


> "Mikhail Blinov" <[e-mail]> writes:
> 
> >The CMPv2 Spec does not address the transport issues. So what is the standard
> >mapping of the CMPv2 to TCP/IP at present?
> 
> RFC 2068 :-).
> 
> Peter.
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CCTHf23537 for ietf-pkix-bks; Wed, 12 Jun 2002 05:29:17 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CCTGn23533 for <[e-mail]>; Wed, 12 Jun 2002 05:29:16 -0700 (PDT)
Received: from erwin.isode.com by woozle.isode.com (local) with ESMTP; Wed, 12 Jun 2002 13:29:04 +0100
Received: by erwin.isode.com (Postfix, from userid 168) id BB2F61403D; Wed, 12 Jun 2002 13:28:55 +0100 (BST)
From: Bruce Stephens <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: Bruce Stephens <[e-mail]>, Laurence Lundblade <[e-mail]>, [e-mail]
Subject: Re: DN comparison
References: <[e-mail]>
Date: Wed, 12 Jun 2002 13:28:55 +0100
In-Reply-To: <[e-mail]> (Tom Gindin's message of "Wed, 12 Jun 2002 07:54:54 -0400")
Message-ID: <[e-mail]>
Lines: 38
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin <[e-mail]> writes:

>       I know, and I think many of us do, that a DN's original use is
> as an index to an X.500 or LDAP entry, that these are
> tree-structured databases, and that DN's are defined in X.501 as
> ordered sets (or sequences) of RDN's.  However, I would like to see
> someone come up with a plausible example of two DN's which consist
> of different orderings of the same set of RDN's while referring to
> different entities.

It's tricky to come up with examples, yes.  If an organisation did use
DNs such that reordering RDNs would cause confusion, then probably
they're doing something confusing.

> Your point about directory access properties is valid, but is hardly
> relevant to a comparison of two different DN's.

>From a theoretical point of view the history is important, because
distinguished names come from that background, and are still used
there, and have their own comparison rules.  If PKI uses them
differently, then there's a significant opportunity for confusion.

> In any case, if a DN is assigned as part of a certificate issuance
> process, and that certificate is then published using the procedures
> in draft-ietf-pkix-certstore-http, the directory structure are not
> strongly involved in the processing of that certificate at any stage
> of its life cycle.

That's true.  In such a situation, probably there should be an
alternative to a DN, and so comparisons would be performed on that
alternative identification (which would have its own rules for
comparison).

[...]

-- 
Bruce Stephens			[e-mail]
ACI Worldwide/MessagingDirect	<URL:http://www.MessagingDirect.com/>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CBtDl23030 for ietf-pkix-bks; Wed, 12 Jun 2002 04:55:13 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CBtBn23024 for <[e-mail]>; Wed, 12 Jun 2002 04:55:11 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CBt6g5141930; Wed, 12 Jun 2002 07:55:06 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CBssK82974; Wed, 12 Jun 2002 07:54:54 -0400
Importance: Normal
Sensitivity: 
Subject: Re: DN comparison
To: Bruce Stephens <[e-mail]>
Cc: Laurence Lundblade <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 12 Jun 2002 07:54:54 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/12/2002 07:55:05 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Bruce:

      I know, and I think many of us do, that a DN's original use is as an
index to an X.500 or LDAP entry, that these are tree-structured databases,
and that DN's are defined in X.501 as ordered sets (or sequences) of RDN's.
However, I would like to see someone come up with a plausible example of
two DN's which consist of different orderings of the same set of RDN's
while referring to different entities.  Your point about directory access
properties is valid, but is hardly relevant to a comparison of two
different DN's.
      In any case, if a DN is assigned as part of a certificate issuance
process, and that certificate is then published using the procedures in
draft-ietf-pkix-certstore-http, the directory structure are not strongly
involved in the processing of that certificate at any stage of its life
cycle.

            Tom Gindin


Bruce Stephens <[e-mail]> on 06/11/2002 12:39:59
PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    Laurence Lundblade <[e-mail]>, [e-mail]
Subject:    Re: DN comparison


"Tom Gindin" <[e-mail]> writes:

[...]

> Personally, I have some difficulty understanding how two
> DN's which differ only in the RDN sequence can refer to different
objects,
> at least in those common cases in which DN's consist essentially of
> locality attributes, organizational attributes, and personal attributes.
> However, that's how section 9.7 of X.501 seems to want it.

Because in the X.500 world (and LDAP world), the DN says how you find
an entry in a tree, so the RDNs are very much ordered.

Presuming a little-endian representation, my entry in our directory
(which may or may not be linked usefully into whatever you might
easily access, because there isn't really a global Directory) is
"cn=Bruce Stephens,l=Richmond Office, o=MessagingDirect, c=CA".  And
internal to our directory, things are definitely stored in a tree, and
I can look at the l=Richmond Office, o=MessagingDirect, c=CA entry and
see how many subordinate entries it has (our directory implementation
keeps that as a pseudo attribute).  The administrative properties are
also arranged hierarchically, so l=Richmond Office,..., might have
separate administrative properties (including a separate set of
administrators) to l=Edmonton Office,..., for example (although I
can't remember if they actually do).

In short, the DN model sort of presumes a global directory---a tree
which gives a unique name to everything that you might want to give a
name to, and that name can point to an entry in the global directory
which you can find (possibly, depending on permissions) and interact
with (possibly), by following defined processes from your local
directory.  And all of this has features for delegated administration,
shadowing (to allow for more local copies of data), chaining (to allow
you to find things that aren't stored locally), and so on.

The global directory never really happened, and probably never can,
but that's why the ordering in RDNs matters: because it's showing the
reader how to follow a path down a tree, and the naming of attributes
at the various levels is a delegated consideration, although there are
some conventions.

[...]

--
Bruce Stephens
[e-mail]
ACI Worldwide/MessagingDirect        <URL:http://www.MessagingDirect.com/>







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5C32oS06083 for ietf-pkix-bks; Tue, 11 Jun 2002 20:02:50 -0700 (PDT)
Received: from servere.csc.cuhk.edu.hk (servere.itsc.cuhk.edu.hk [137.189.29.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C32mn06078 for <[e-mail]>; Tue, 11 Jun 2002 20:02:49 -0700 (PDT)
Received: by servere.itsc.cuhk.edu.hk with Internet Mail Service (5.5.2653.19) id <2A3SJ3MS>; Wed, 12 Jun 2002 11:02:51 +0800
Message-ID: <[e-mail]>
From: Hui Lai <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: 
Date: Wed, 12 Jun 2002 11:02:48 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="big5"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Pere,
	I've used my TS client to contact your TSA. When I could not
properly decode the response. 
My client program is also implemented according to RFC 3161, which reads
excatly  the number of bytes indicated in TCP header. Desipite the number of
bytes are match and the flag is 05, it seems that a complete TST couldn't be
retrieved.

I also have my testing TCP and HTTP TSA server, please have a try. Visit
http://www.e-timestamping.com/status.html for details.

Stern Lai
Open Secure Time-stamping Platform
Information Technology Services Centre
The Chinese University of Hong Kong



-----Original Message-----
From: Pere Fiol [mailto:[e-mail]]
Sent: Monday, June 10, 2002 11:19 PM
To: Peter Sylvester; [e-mail]
Subject: RE: TSP interoperability



Hi,

Where is your TSA?? I would like to test it with my TS-Client!!

Moreover, I've a TSA server in the address: 80.81.104.150 (port 318), can
someone test it??

Thanks,
Pere
	



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BJW9123352 for ietf-pkix-bks; Tue, 11 Jun 2002 12:32:09 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5BJW7n23346 for <[e-mail]>; Tue, 11 Jun 2002 12:32:07 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jun 2002 19:32:03 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA20020 for <[e-mail]>; Tue, 11 Jun 2002 15:32:05 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5BJU8p01506 for <[e-mail]>; Tue, 11 Jun 2002 15:30:08 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZNNAY>; Tue, 11 Jun 2002 15:32:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.30]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZNNAS; Tue, 11 Jun 2002 15:31:57 -0400
From: "Housley, Russ" <[e-mail]>
To: Laurence Lundblade <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 11 Jun 2002 13:46:55 -0400
Subject: Re: DN comparison
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Laurence:

>And more of a standard question, how should I have found the answer to 
>this question? From my current perspective it seems an addition to 
>RFC-3280 would be helpful.

I agree that a companion document would be useful.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BHcjL17142 for ietf-pkix-bks; Tue, 11 Jun 2002 10:38:45 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5BHchn17133 for <[e-mail]>; Tue, 11 Jun 2002 10:38:43 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jun 2002 17:38:39 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA09502 for <[e-mail]>; Tue, 11 Jun 2002 13:38:44 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g5BHalR18783 for <[e-mail]>; Tue, 11 Jun 2002 13:36:47 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <M28ZNK0Y>; Tue, 11 Jun 2002 13:38:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.7]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M28ZNK0W; Tue, 11 Jun 2002 13:38:38 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 11 Jun 2002 13:38:36 -0400
Subject: Re: x509 and ASN1 version 2002
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

>I would like to know what people would think about a replacement
>of the definition of Extension by using a 2002 mechanism in
>ASN1 as something like:
>
>Extension         ::=   SEQUENCE {
>     extnId            EXTENSION.&id ({ExtensionSet}),
>     critical          BOOLEAN DEFAULT FALSE,
>     extnValue         OCTET STRING (
>          CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
>     }
>
>Note that I there is no
>
>ENCODED BY {joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)})
>
>because I think it is may not necessary. It is not for signature calculation,
>but may create some backwards compatiblity problem for contexts where a 
>certificat
>is transfered in PER.
>
>Is there someone aware of an application that transfers certificats
>in any other encoding that DER?

Yes.  X.500 DAP often does so.  In many implementations, the DAP PDU (which 
is also defined in ASN.1) encodes the DAP header and the DAP payload in one 
blob.  Thus, certificates end up being re-encoded in BER, since BER is the 
transfer syntax normally used in DAP.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BHUwV16823 for ietf-pkix-bks; Tue, 11 Jun 2002 10:30:58 -0700 (PDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BHUvn16819 for <[e-mail]>; Tue, 11 Jun 2002 10:30:57 -0700 (PDT)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5BHUrDl009039 for <[e-mail]>; Tue, 11 Jun 2002 10:30:54 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.158.82]) by sabrina.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5BHUphU007622 for <[e-mail]>; Tue, 11 Jun 2002 10:30:52 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 11 Jun 2002 10:30:49 -0700
To: [e-mail]
From: Laurence Lundblade <[e-mail]>
Subject: Re: DN comparison
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for the responses. The concept my brain glossed over was the 
difference between SET and SEQUENCE. Having that I can now make sense of 
the X.500 text.  If you take the DNS example that finance.yahoo.com is 
different from yahoo.finance.com it's pretty easy to see why ordering is 
important.

BTW, some folks, who'll remain anonymous, suggested that a straight binary 
compare of the DN's was adequate since enough implementations do it which 
motivates any cert issuer to never change the order, string types, etc. 
Given my main goal is client-side SSL on a cell phone I suspect I could get 
away with the binary compare. I don't expect to be dealing with end user 
certs, LDAP etc. It is tempting because the object code is smaller and 
because it will execute faster.

Thanks again, LL



Received: by above.proper.com (8.11.6/8.11.3) id g5BGejj13847 for ietf-pkix-bks; Tue, 11 Jun 2002 09:40:45 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BGehn13843 for <[e-mail]>; Tue, 11 Jun 2002 09:40:44 -0700 (PDT)
Received: from erwin.isode.com by woozle.isode.com (local) with ESMTP; Tue, 11 Jun 2002 17:40:06 +0100
Received: by erwin.isode.com (Postfix, from userid 168) id 542961403D; Tue, 11 Jun 2002 17:40:00 +0100 (BST)
From: Bruce Stephens <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: Laurence Lundblade <[e-mail]>, [e-mail]
Subject: Re: DN comparison
References: <[e-mail]>
Date: Tue, 11 Jun 2002 17:39:59 +0100
In-Reply-To: <[e-mail]> ("Tom Gindin"'s message of "Tue, 11 Jun 2002 07:45:47 -0400")
Message-ID: <[e-mail]>
Lines: 46
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Tom Gindin" <[e-mail]> writes:

[...]

> Personally, I have some difficulty understanding how two
> DN's which differ only in the RDN sequence can refer to different objects,
> at least in those common cases in which DN's consist essentially of
> locality attributes, organizational attributes, and personal attributes.
> However, that's how section 9.7 of X.501 seems to want it.

Because in the X.500 world (and LDAP world), the DN says how you find
an entry in a tree, so the RDNs are very much ordered.  

Presuming a little-endian representation, my entry in our directory
(which may or may not be linked usefully into whatever you might
easily access, because there isn't really a global Directory) is
"cn=Bruce Stephens,l=Richmond Office, o=MessagingDirect, c=CA".  And
internal to our directory, things are definitely stored in a tree, and
I can look at the l=Richmond Office, o=MessagingDirect, c=CA entry and
see how many subordinate entries it has (our directory implementation
keeps that as a pseudo attribute).  The administrative properties are
also arranged hierarchically, so l=Richmond Office,..., might have
separate administrative properties (including a separate set of
administrators) to l=Edmonton Office,..., for example (although I
can't remember if they actually do).

In short, the DN model sort of presumes a global directory---a tree
which gives a unique name to everything that you might want to give a
name to, and that name can point to an entry in the global directory
which you can find (possibly, depending on permissions) and interact
with (possibly), by following defined processes from your local
directory.  And all of this has features for delegated administration,
shadowing (to allow for more local copies of data), chaining (to allow
you to find things that aren't stored locally), and so on.  

The global directory never really happened, and probably never can,
but that's why the ordering in RDNs matters: because it's showing the
reader how to follow a path down a tree, and the naming of attributes
at the various levels is a delegated consideration, although there are
some conventions.

[...]

-- 
Bruce Stephens			[e-mail]
ACI Worldwide/MessagingDirect	<URL:http://www.MessagingDirect.com/>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BFYxa12017 for ietf-pkix-bks; Tue, 11 Jun 2002 08:34:59 -0700 (PDT)
Received: from xenox.inexnet.de (xenox.inexnet.de [195.122.155.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BFYrn12011 for <[e-mail]>; Tue, 11 Jun 2002 08:34:57 -0700 (PDT)
Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id KAA09432; Sun, 16 Jun 2002 10:35:07 +0200
Received: from authentidate.de (goliath.authentidate.de [192.168.52.118]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g5BEY0c19288; Tue, 11 Jun 2002 16:34:02 +0200
X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.52.118] claimed to be authentidate.de
Message-ID: <[e-mail]>
Date: Tue, 11 Jun 2002 17:34:36 +0200
From: Torsten Hentschel <[e-mail]>
Organization: AuthentiDate International AG
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: DN comparison
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

My interpretation of section 9.7 of X.501 is, that it states
indirectly, that two names having just a different ordering of
RDN's are different, because it defines a distinguished name
as an ordered sequence where the order is the decending order
of all its superior entries plus its own. Thus changing the sequence
would denote a different hierarchy of the superior entries.
Because an object entry can have multiple distinguished names
(section 9.1.3) changed sequence does not neccessarily mean
that the corresponding object is a different as well.
I totally agree with you that in real life most cases
would not need a sequence. But im sure there are some,
where it makes sense, *and* enforcing a sequence looks
great for me as a programmer, because otherwise search algorithms
become greedy.

  Torsten

Tom Gindin wrote:

> [...]
> The difficulty with the definition is the word "corresponding".
> [...]
>   3  Whether the ordering of RDN's matters is much less clear.
>      It appears that "corresponding RDN's" need to match for
>      equality, but it isn't obvious to me whether corresponding
>      RDN's are ones in the same position or ones with the same
>      attributes.  DN's are matched as sequences of RDN's rather
>      than as sets. Personally, I have some difficulty understanding
>      how two DN's which differ only in the RDN sequence can refer
>      to different objects, at least in those common cases in which
>      DN's consist essentially of locality attributes,
>      organizational attributes, and personal attributes.
>      However, that's how section 9.7 of X.501 seems to want it.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BBjun25970 for ietf-pkix-bks; Tue, 11 Jun 2002 04:45:56 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BBjsn25959 for <[e-mail]>; Tue, 11 Jun 2002 04:45:54 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5BBjjg5029118; Tue, 11 Jun 2002 07:45:45 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5BBjhj34704; Tue, 11 Jun 2002 07:45:43 -0400
Importance: Normal
Sensitivity: 
Subject: Re: DN comparison
To: Laurence Lundblade <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 11 Jun 2002 07:45:47 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/11/2002 07:45:44 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Laurence:

      It's no more mundane than many other questions here, and while it
might be better on an LDAP group it is certainly relevant to us.  The
primary definition is X.501v4 section 13.5 or X.501v3 section 12.5.2.  The
difficulty with the definition is the word "corresponding".  Here are a few
simple rules:
1     The order of attributes inside an RDN is irrelevant to a comparison.
You can find this in X.501v4 section 9.4.
2     The grouping of attributes within RDN's is important.  It tends to be
standardized, but it does matter.  In particular, the meaning of a few
attributes such as serialNumber and DNQualifier is not guaranteed to be the
same when grouped with a personal name as when in an RDN by themselves.
3     Whether the ordering of RDN's matters is much less clear.  It appears
that "corresponding RDN's" need to match for equality, but it isn't obvious
to me whether corresponding RDN's are ones in the same position or ones
with the same attributes.  DN's are matched as sequences of RDN's rather
than as sets.  Personally, I have some difficulty understanding how two
DN's which differ only in the RDN sequence can refer to different objects,
at least in those common cases in which DN's consist essentially of
locality attributes, organizational attributes, and personal attributes.
However, that's how section 9.7 of X.501 seems to want it.

      Thus only #1 and #3 of your examples match.

            Tom Gindin

Laurence Lundblade <[e-mail]>@mail.imc.org on 06/10/2002 01:53:35
PM

Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    DN comparison



I know this question is much more mundane than usual fair here, but I'm
going to ask anyway as I think I've done a decent job reviewing RFC's,
X.500, discussion archives, etc.

What I want to know is how to compare DN's (subject with issuer). I found
all the stuff about the string processing in 2459 and am happy to see
that's reasonably dealt with. What I can't find is whether the order of
RDN's or the order of the parts of the RDN's matter or not. Also I haven't
been able to determine if the grouping of parts in RDN's matter or not.

To be specific, which of these are the same in these DN's?
  1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)
  2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
  3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)
  4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)

RDN's are in (). I would think/hope they're all the same. From reading the
source, it looks like OpenSSL doesn't care about the grouping of RDN's, but

does care about the order.

And more of a standard question, how should I have found the answer to this

question? From my current perspective it seems an addition to RFC-3280
would be helpful.

LL








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5AM1WM13977 for ietf-pkix-bks; Mon, 10 Jun 2002 15:01:32 -0700 (PDT)
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AM1Un13959 for <[e-mail]>; Mon, 10 Jun 2002 15:01:31 -0700 (PDT)
Received: from sdbo1005.db.com by imr5.us.db.com  id g5AM1WUT029420; Mon, 10 Jun 2002 18:01:33 -0400 (EDT)
Sensitivity: 
Subject: Re: DN comparison
To: Laurence Lundblade <[e-mail]>
Cc: [e-mail]
From: "Frank Balluffi" <[e-mail]>
Date: Mon, 10 Jun 2002 18:01:31 -0400
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.9a |January 7, 2002) at 06/10/2002 06:01:32 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Laurence,

In the following ASN.1, a SEQUENCE OF is ordered and a SET OF is not ordered:

   Name ::= CHOICE {
     RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET OF AttributeTypeAndValue

1) and 3) contain two RDNs, each of which contain the same AttributeTypeAndValues. Because the RDNs are in the same order, 1) and 3) are equal.

2) and 4) contain the same four RDNs, but the RDNs are in different order. So 2) and 4) are not equal.

Frank


---------------------------------------- Message History ----------------------------------------


From:  Laurence Lundblade <[e-mail]>@mail.imc.org on 06/10/2002 10:53 AM MST

DELEGATED - Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    DN comparison



I know this question is much more mundane than usual fair here, but I'm
going to ask anyway as I think I've done a decent job reviewing RFC's,
X.500, discussion archives, etc.

What I want to know is how to compare DN's (subject with issuer). I found
all the stuff about the string processing in 2459 and am happy to see
that's reasonably dealt with. What I can't find is whether the order of
RDN's or the order of the parts of the RDN's matter or not. Also I haven't
been able to determine if the grouping of parts in RDN's matter or not.

To be specific, which of these are the same in these DN's?
  1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)
  2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
  3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)
  4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)

RDN's are in (). I would think/hope they're all the same. From reading the
source, it looks like OpenSSL doesn't care about the grouping of RDN's, but
does care about the order.

And more of a standard question, how should I have found the answer to this
question? From my current perspective it seems an addition to RFC-3280
would be helpful.

LL




--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5AKRgD02240 for ietf-pkix-bks; Mon, 10 Jun 2002 13:27:42 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AKRen02236 for <[e-mail]>; Mon, 10 Jun 2002 13:27:40 -0700 (PDT)
Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g5AKRXoh007037; Mon, 10 Jun 2002 16:27:33 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 10 Jun 2002 16:27:21 -0400
To: Laurence Lundblade <[e-mail]>, [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: DN comparison
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:53 AM 6/10/02 -0700, Laurence Lundblade wrote:

>I know this question is much more mundane than usual fair here, but I'm going to ask anyway as I think I've done a decent job reviewing RFC's, X.500, discussion archives, etc.
>
>What I want to know is how to compare DN's (subject with issuer). I found all the stuff about the string processing in 2459 and am happy to see that's reasonably dealt with. What I can't find is whether the order of RDN's or the order of the parts of the RDN's matter or not. Also I haven't been able to determine if the grouping of parts in RDN's matter or not.
>
>To be specific, which of these are the same in these DN's?
>  1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)
>  2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
>  3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)
>  4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)
>
>RDN's are in (). I would think/hope they're all the same. From reading the source, it looks like OpenSSL doesn't care about the grouping of RDN's, but does care about the order.
>
>And more of a standard question, how should I have found the answer to this question? From my current perspective it seems an addition to RFC-3280 would be helpful.

The DNs that you list are not all the same. I believe that 1 and 3 are the same, but the others are not. A DN is defined in X.509 as follows (see section 4.1.2.4 in RFC 3280):

            Name ::= CHOICE {
              RDNSequence }

            RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

            RelativeDistinguishedName ::=
              SET OF AttributeTypeAndValue

            AttributeTypeAndValue ::= SEQUENCE {
              type     AttributeType,
              value    AttributeValue }

            AttributeType ::= OBJECT IDENTIFIER

            AttributeValue ::= ANY DEFINED BY AttributeType

A DN is a SEQUENCE of RDNs. So, in order to two DNs to be the same, they must contain the same RDNs in the same order. Each individual RDN is a SET of attribute-type and value pairs. Since an RDN consists of a SET of AV pairs, the ordering of the pairs is unimportant (note, however, that DER requires the AV pairs in an RDN to be encoded in a specific order).

In your examples above, DNs 2 and 4 contain the same set of RDNs, however, the RDNs are not in the same order. Since a DN is a SEQUENCE of RDNs, the different ordering makes them different DNs. While DNs 1 and 2 contain the same set of AV pairs, the RDNs are not the same.

So, the general rule is as follows:

1) Two DNs are the same if they contain the same sequence of RDNs (note that the order of the RDNs in the DN counts).
2) Two RDNs are the same if the contain the same set of AV pairs (order of AV pairs within RDN not important)
3) Two AV pairs are the same if their Attribute types (i.e., OIDs) are the same and their attribute values match according to the matching rules for the corresponding attribute type (e.g., directoryString).






Received: by above.proper.com (8.11.6/8.11.3) id g5AIGnN22702 for ietf-pkix-bks; Mon, 10 Jun 2002 11:16:49 -0700 (PDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AIGmn22697 for <[e-mail]>; Mon, 10 Jun 2002 11:16:48 -0700 (PDT)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5AIGeDl002543 for <[e-mail]>; Mon, 10 Jun 2002 11:16:40 -0700 (PDT)
Received: from LLUNDBLA2.qualcomm.com (r-cserve-host21.qualcomm.com [129.46.62.21]) by magus.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g5AIGYfq018262 for <[e-mail]>; Mon, 10 Jun 2002 11:16:37 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 10 Jun 2002 10:53:35 -0700
To: [e-mail]
From: Laurence Lundblade <[e-mail]>
Subject: DN comparison
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I know this question is much more mundane than usual fair here, but I'm 
going to ask anyway as I think I've done a decent job reviewing RFC's, 
X.500, discussion archives, etc.

What I want to know is how to compare DN's (subject with issuer). I found 
all the stuff about the string processing in 2459 and am happy to see 
that's reasonably dealt with. What I can't find is whether the order of 
RDN's or the order of the parts of the RDN's matter or not. Also I haven't 
been able to determine if the grouping of parts in RDN's matter or not.

To be specific, which of these are the same in these DN's?
  1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)
  2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
  3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)
  4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)

RDN's are in (). I would think/hope they're all the same. From reading the 
source, it looks like OpenSSL doesn't care about the grouping of RDN's, but 
does care about the order.

And more of a standard question, how should I have found the answer to this 
question? From my current perspective it seems an addition to RFC-3280 
would be helpful.

LL 



Received: by above.proper.com (8.11.6/8.11.3) id g5AFKNV10658 for ietf-pkix-bks; Mon, 10 Jun 2002 08:20:23 -0700 (PDT)
Received: from amatabogados.com ([213.229.156.26]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5AFKLn10653 for <[e-mail]>; Mon, 10 Jun 2002 08:20:21 -0700 (PDT)
Received: from gandalf [213.96.78.77] by amatabogados.com (SMTPD32-4.07) id A3654D00206; Mon, 10 Jun 2002 17:19:01 +0100
From: "Pere Fiol" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Subject: RE: TSP interoperability
Date: Mon, 10 Jun 2002 17:18:43 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Where is your TSA?? I would like to test it with my TS-Client!!

Moreover, I've a TSA server in the address: 80.81.104.150 (port 318), can
someone test it??

Thanks,
Pere

-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]]En
nombre de Peter Sylvester
Enviado el: lunes 10 de junio de 2002 15:33
Para: [e-mail]
Asunto: TSP interoperability



hello,

A bug in my experimental time stamping service was discovered
and corrected. All previously issued time stamps are not conformant
with RFC 3161 because the server ALWAYS violated one MUST.

If you still have old time stamp from the TSA, you may try to
find out what was wrong.

Peter








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5AFGxu10195 for ietf-pkix-bks; Mon, 10 Jun 2002 08:16:59 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AFGvn10185 for <[e-mail]>; Mon, 10 Jun 2002 08:16:57 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA28533 for <[e-mail]>; Mon, 10 Jun 2002 17:16:58 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Mon, 10 Jun 2002 17:16:58 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA19000 for <[e-mail]>; Mon, 10 Jun 2002 17:16:56 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA28824 for [e-mail]; Mon, 10 Jun 2002 17:16:56 +0200 (MET DST)
Date: Mon, 10 Jun 2002 17:16:56 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: x509 and ASN1 version 2002
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I would like to know what people would think about a replacement
of the definition of Extension by using a 2002 mechanism in
ASN1 as something like:

Extension         ::=   SEQUENCE {
    extnId            EXTENSION.&id ({ExtensionSet}),
    critical          BOOLEAN DEFAULT FALSE,
    extnValue         OCTET STRING (
         CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
    }

Note that I there is no

ENCODED BY {joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)})

because I think it is may not necessary. It is not for signature calculation, 
but may create some backwards compatiblity problem for contexts where a certificat
is transfered in PER.

Is there someone aware of an application that transfers certificats
in any other encoding that DER? 

(I am not talking about certificates that are in BER and the signature
 is done over the BER blob.)

Regards







Received: by above.proper.com (8.11.6/8.11.3) id g5ADY8u03798 for ietf-pkix-bks; Mon, 10 Jun 2002 06:34:08 -0700 (PDT)
Received: from edelweb.fr ([212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ADY6n03791 for <[e-mail]>; Mon, 10 Jun 2002 06:34:06 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA28095 for <[e-mail]>; Mon, 10 Jun 2002 15:33:26 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Mon, 10 Jun 2002 15:33:26 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA18251 for <[e-mail]>; Mon, 10 Jun 2002 15:33:25 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA28795 for [e-mail]; Mon, 10 Jun 2002 15:33:24 +0200 (MET DST)
Date: Mon, 10 Jun 2002 15:33:24 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TSP interoperability
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello,

A bug in my experimental time stamping service was discovered 
and corrected. All previously issued time stamps are not conformant 
with RFC 3161 because the server ALWAYS violated one MUST. 

If you still have old time stamp from the TSA, you may try to 
find out what was wrong. 

Peter







Received: by above.proper.com (8.11.6/8.11.3) id g5AAeZp23317 for ietf-pkix-bks; Mon, 10 Jun 2002 03:40:35 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AAeWn23312 for <[e-mail]>; Mon, 10 Jun 2002 03:40:33 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g5AAe2qf003954; Mon, 10 Jun 2002 22:40:02 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id WAA303014; Mon, 10 Jun 2002 22:39:57 +1200 (NZST) (sender [e-mail])
Date: Mon, 10 Jun 2002 22:39:57 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: CMP Discussion References
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Mikhail Blinov" <[e-mail]> writes:

>The CMPv2 Spec does not address the transport issues. So what is the standard
>mapping of the CMPv2 to TCP/IP at present?

RFC 2068 :-).

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g5A8qiE13260 for ietf-pkix-bks; Mon, 10 Jun 2002 01:52:44 -0700 (PDT)
Received: from mail1.sse.ie (mail1.sse.ie [193.120.32.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5A8qfn13252 for <[e-mail]>; Mon, 10 Jun 2002 01:52:41 -0700 (PDT)
Received: from michaelb (michaelb.sse.ie [193.120.33.15]) by mail1.sse.ie (8.11.1/8.11.1) with SMTP id g5A8qVV29104; Mon, 10 Jun 2002 09:52:31 +0100
Message-ID: <001301c2105c$27ac63c0$0f2178c1@michaelb>
From: "Mikhail Blinov" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: CMP Discussion References
Date: Mon, 10 Jun 2002 09:51:46 +0100
Organization: Guardeonic Solutions
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Carlisle,

Thanks for the brief reply.

> I don't know what you mean by the "pkiReq TCP message".  If you are
> referring to the TCP Management Protocol described in RFC 2510 Section
> 5.2, then all that says is "pkiMsg", which is any PKIMessage.  

I was looking at the CMPv2 Spec and the "Transport Protocols for CMP" 
<draft-ietf-pkix-cmp-transport-protocols-04.txt> document, which I assumed
was the recommended transport mapping for the CMPv2.
(The current PKIX Roadmap mentions this document as well.)
However, I just had a look again and have noticed that this document is
withdrawn from the official PKIX site. What's the story ?
The CMPv2 Spec does not address the transport issues.
So what is the standard mapping of the CMPv2 to TCP/IP at present?

Regards,
Michael Blinov




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58BWmu15418 for ietf-pkix-bks; Sat, 8 Jun 2002 04:32:48 -0700 (PDT)
Received: from web14808.mail.yahoo.com (web14808.mail.yahoo.com [216.136.224.224]) by above.proper.com (8.11.6/8.11.3) with SMTP id g58BWln15412 for <[e-mail]>; Sat, 8 Jun 2002 04:32:47 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [195.146.32.147] by web14808.mail.yahoo.com via HTTP; Sat, 08 Jun 2002 04:32:47 PDT
Date: Sat, 8 Jun 2002 04:32:47 -0700 (PDT)
From: af Lamei <[e-mail]>
Subject: Cryptographic Service Provider
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1860696696-1023535967=:95395"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0-1860696696-1023535967=:95395
Content-Type: text/plain; charset=us-ascii


Hi,

What does "Cryptographic Service Provider" (CSP) mean? I know that it's probably a software module that provides cryptographic functions (according to microsoft's documents), does it mean that we have different crypto APIs choices? If so, are these APIs containing different cryptographic functions?



---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
--0-1860696696-1023535967=:95395
Content-Type: text/html; charset=us-ascii

<P>Hi,</P>
<P>What does "Cryptographic Service Provider" (CSP) mean? I know that it's probably a software module that provides cryptographic functions (according to microsoft's documents), does it mean that we have different crypto APIs choices? If so, are these APIs containing different cryptographic functions?</P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com/fc/en/spl">Sign-up for Video Highlights</a> of 2002 FIFA World Cup
--0-1860696696-1023535967=:95395--


Received: by above.proper.com (8.11.6/8.11.3) id g582UOt26530 for ietf-pkix-bks; Fri, 7 Jun 2002 19:30:24 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g582UMn26526; Fri, 7 Jun 2002 19:30:22 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g582UKqf019497; Sat, 8 Jun 2002 14:30:20 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA501972; Sat, 8 Jun 2002 14:30:19 +1200 (NZST) (sender [e-mail])
Date: Sat, 8 Jun 2002 14:30:19 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Updated version of dumpasn1 available
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is the aperiodic announcement of a newer version of dumpasn1, my ASN.1
printing and diagnostic tool.  Recent updates include automated handling of
encapsulated data (if you're still using a version that uses -b and -o then you
really need to get this update), indication of bit positions in bitflags when
there's a single bitflag set, proper formatting of dates rather than just
dumping the ISO 8601 strings, and some other odds and ends.  It's available
from the usual location, http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g57Jcen17602 for ietf-pkix-bks; Fri, 7 Jun 2002 12:38:40 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57Jcdn17598 for <[e-mail]>; Fri, 7 Jun 2002 12:38:39 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <LSCR0KVN>; Fri, 7 Jun 2002 15:38:16 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Mikhail Blinov'" <[e-mail]>
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: CMP Discussion References
Date: Fri, 7 Jun 2002 15:38:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20E5A.DDA0E5B0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

------_=_NextPart_001_01C20E5A.DDA0E5B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Mikhail,

> ----------
> From: 	Mikhail Blinov[SMTP:[e-mail]]
> Sent: 	Friday, June 07, 2002 4:56 AM
> To: 	[e-mail]
> Subject: 	CMP Discussion References
> 
> Hi,
> 
> I've heard a lot of talk about the CMPv2 Interoperability Testing
> but I failed to find any mailing list archives related to this activity
> or any technical documents describing the results of it.
 
Tim Polk and Bob Moskowitz have been putting together this document for the
purposes of submitting CMPv2 to the IESG for consideration as a Draft
Standard.  Every time I ask about this document, I hear that it's not
finished yet.

Tim:  any update?  CMPv2 has been ready to progress for a very long time
now...

> (The only document that I could find was the
> <draft-ietf-moskowitz-cmpinterop-00.txt>
> Internet Draft dated June 1999, but it was too small to address all the
> questions.
> I looked through the ietf-pkix archive but there were only a few
> discussions
> related to the CMP details.
 
Very little discussion happened on the PKIX list.  It all happened on the
ca-talk list because that was the purpose for which that list was created.

> The CMPv2 Spec mentions the ICSA CA-talk mailing list but it seems to be
> gone
> without a trace. Carlisle Adams pointed me to Bob Moskowitz and I tried to
> contact him
> but with no response.)
 
I don't know why Bob has not responded.

> I guess nobody is going to claim that the CMP Spec is sufficient for
> developing
> an interoperable CMP implementation. 
 
I'm not so sure that's true...  The interop testing uncovered a number of
things that needed to be clarified or added; CMPv2 incorporates all of this.
So, with respect to the messages that were tested (which did not include the
batch scenario you describe below, by the way, as this is not listed in the
mandatory-to-implement messages in the Appendix), I think it is reasonable
to assume that the CMPv2 spec is sufficient.

> So I am pretty sure that there was a lot
> of technical discussion about how particular scenarios are to be
> implemented
> and how various parts of the Spec are to be interpreted. I would
> appreciate
> if somebody could point me to any resources related to this.
> 
> Just one example of what kind of questions I would like to find the answer
> to.
> 
> If 
> * an RA batches several EE's certification requests into one NestedMessage
>     like this
>         {sender=RA; recipient=CA; transactionID=5; body=nested {
>                 sender=EE1; recipient=CA; transactionID=10; body=cr;
>                 sender=EE2; recipient=CA; transactionID=22; body=cr }}
> * the RA establishes a connection to the CA and sends this message in the 
>     pkiReq TCP message 
> then 
> how the CA is expected to reply ?
 
I don't know what you mean by the "pkiReq TCP message".  If you are
referring to the TCP Management Protocol described in RFC 2510 Section 5.2,
then all that says is "pkiMsg", which is any PKIMessage.  Note that
NestedMessage is not something that is put inside a request message such as
ir or cr; a NestedMessage is the body of a PKIMessage.  Therefore, the
message from the RA to the CA is a pkiMsg TCP message, which is a PKIMessage
whose body is a NestedMessage.

Similarly, the response from the CA to the RA is a finalMsgRep TCP message,
which is a PKIMessage whose body is a NestedMessage containing all the ip or
cp messages.

> The CA cannot send several response messages like
>         {sender=CA; recipient=EE1; transactionID=10; body=cp}
>         {sender=CA; recipient=EE2; transactionID=22; body=cp}
> because one pkiReq TCP message can have only one pkiRep response.
> 
> The CA cannot batch the responses in the NestedNessage like
>         {sender=CA; recipient=RA; transactionID=5; body=nested {
>                 sender=CA; recipient=EE1; transactionID=10; body=cp; 
>                 sender=CA; recipient=EE2; transactionID=22; body=cp }}
> because the pkiRep is not allowed to contain the NestedNessage.
> 
> The only scenario that I can imagine is that the CA replies with the
> finRep
> and then establishes a separate connection to the RA and sends the 
> NestedNessage with the responses in the pkiReq TCP message.
> But overall it does not sound very interoperable with anybody.
 
See my response above for how the CA answers.

Have I misunderstood what you're asking?

Carlisle.


------_=_NextPart_001_01C20E5A.DDA0E5B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: CMP Discussion References</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Mikhail,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Mikhail =
Blinov[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, June 07, 2002 4:56 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">CMP Discussion References</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I've heard a lot of talk about the =
CMPv2 Interoperability Testing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but I failed to find any mailing list =
archives related to this activity</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">or any technical documents describing =
the results of it.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Tim Polk =
and Bob Moskowitz have been putting together this document for the =
purposes of submitting CMPv2 to the IESG for consideration as a Draft =
Standard.&nbsp; Every time I ask about this document, I hear that it's =
not finished yet.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Tim:&nbsp; =
any update?&nbsp; CMPv2 has been ready to progress for a very long time =
now...</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">(The only document that I could find =
was the &lt;draft-ietf-moskowitz-cmpinterop-00.txt&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Internet Draft dated June 1999, but =
it was too small to address all the questions.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I looked through the ietf-pkix =
archive but there were only a few discussions</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">related to the CMP details.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Very =
little discussion happened on the PKIX list.&nbsp; It all happened on =
the ca-talk list because that was the purpose for which that list was =
created.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The CMPv2 Spec mentions the ICSA =
CA-talk mailing list but it seems to be gone</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">without a trace. Carlisle Adams =
pointed me to Bob Moskowitz and I tried to contact him</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but with no response.)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I don't =
know why Bob has not responded.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I guess nobody is going to claim that =
the CMP Spec is sufficient for developing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">an interoperable CMP implementation. =
</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I'm not =
so sure that's true...&nbsp; The interop testing uncovered a number of =
things that needed to be clarified or added; CMPv2 incorporates all of =
this.&nbsp; So, with respect to the messages that were tested (which =
did not include the batch scenario you describe below, by the way, as =
this is not listed in the mandatory-to-implement messages in the =
Appendix), I think it is reasonable to assume that the CMPv2 spec is =
sufficient.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">So I am pretty sure that there was a =
lot</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of technical discussion about how =
particular scenarios are to be implemented</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and how various parts of the Spec are =
to be interpreted. I would appreciate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">if somebody could point me to any =
resources related to this.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Just one example of what kind of =
questions I would like to find the answer to.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">* an RA batches several EE's =
certification requests into one NestedMessage</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; like this</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {sender=3DRA; =
recipient=3DCA; transactionID=3D5; body=3Dnested {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sender=3DEE1; recipient=3DCA; =
transactionID=3D10; body=3Dcr;</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sender=3DEE2; recipient=3DCA; =
transactionID=3D22; body=3Dcr }}</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">* the RA establishes a connection to =
the CA and sends this message in the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; pkiReq TCP message =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">then </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">how the CA is expected to reply =
?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I don't =
know what you mean by the &quot;pkiReq TCP message&quot;.&nbsp; If you =
are referring to the TCP Management Protocol described in RFC 2510 =
Section 5.2, then all that says is &quot;pkiMsg&quot;, which is any =
PKIMessage.&nbsp; Note that NestedMessage is not something that is put =
inside a request message such as ir or cr; a NestedMessage is the body =
of a PKIMessage.&nbsp; Therefore, the message from the RA to the CA is =
a pkiMsg TCP message, which is a PKIMessage whose body is a =
NestedMessage.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Similarly, =
the response from the CA to the RA is a finalMsgRep TCP message, which =
is a PKIMessage whose body is a NestedMessage containing all the ip or =
cp messages.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The CA cannot send several response =
messages like</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {sender=3DCA; =
recipient=3DEE1; transactionID=3D10; body=3Dcp}</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {sender=3DCA; =
recipient=3DEE2; transactionID=3D22; body=3Dcp}</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">because one pkiReq TCP message can =
have only one pkiRep response.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The CA cannot batch the responses in =
the NestedNessage like</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {sender=3DCA; =
recipient=3DRA; transactionID=3D5; body=3Dnested {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sender=3DCA; recipient=3DEE1; =
transactionID=3D10; body=3Dcp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sender=3DCA; recipient=3DEE2; =
transactionID=3D22; body=3Dcp }}</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">because the pkiRep is not allowed to =
contain the NestedNessage.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The only scenario that I can imagine =
is that the CA replies with the finRep</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and then establishes a separate =
connection to the RA and sends the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">NestedNessage with the responses in =
the pkiReq TCP message.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">But overall it does not sound very =
interoperable with anybody.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">See my =
response above for how the CA answers.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Have I =
misunderstood what you're asking?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C20E5A.DDA0E5B0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g578vqY11542 for ietf-pkix-bks; Fri, 7 Jun 2002 01:57:52 -0700 (PDT)
Received: from mail1.sse.ie (mail1.sse.ie [193.120.32.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g578vjn11533 for <[e-mail]>; Fri, 7 Jun 2002 01:57:47 -0700 (PDT)
Received: from michaelb (michaelb.sse.ie [193.120.33.15]) by mail1.sse.ie (8.11.1/8.11.1) with SMTP id g578vYV23790 for <[e-mail]>; Fri, 7 Jun 2002 09:57:34 +0100
Message-ID: <004101c20e01$5d4da140$0f2178c1@michaelb>
From: "Mikhail Blinov" <[e-mail]>
To: <[e-mail]>
Subject: CMP Discussion References
Date: Fri, 7 Jun 2002 09:56:43 +0100
Organization: Guardeonic Solutions
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I've heard a lot of talk about the CMPv2 Interoperability Testing
but I failed to find any mailing list archives related to this activity
or any technical documents describing the results of it.

(The only document that I could find was the <draft-ietf-moskowitz-cmpinterop-00.txt>
Internet Draft dated June 1999, but it was too small to address all the questions.
I looked through the ietf-pkix archive but there were only a few discussions
related to the CMP details.
The CMPv2 Spec mentions the ICSA CA-talk mailing list but it seems to be gone
without a trace. Carlisle Adams pointed me to Bob Moskowitz and I tried to contact him
but with no response.)

I guess nobody is going to claim that the CMP Spec is sufficient for developing
an interoperable CMP implementation. So I am pretty sure that there was a lot
of technical discussion about how particular scenarios are to be implemented
and how various parts of the Spec are to be interpreted. I would appreciate
if somebody could point me to any resources related to this.

Just one example of what kind of questions I would like to find the answer to.

If 
* an RA batches several EE's certification requests into one NestedMessage
    like this
        {sender=RA; recipient=CA; transactionID=5; body=nested {
                sender=EE1; recipient=CA; transactionID=10; body=cr;
                sender=EE2; recipient=CA; transactionID=22; body=cr }}
* the RA establishes a connection to the CA and sends this message in the 
    pkiReq TCP message 
then 
how the CA is expected to reply ?

The CA cannot send several response messages like
        {sender=CA; recipient=EE1; transactionID=10; body=cp}
        {sender=CA; recipient=EE2; transactionID=22; body=cp}
because one pkiReq TCP message can have only one pkiRep response.

The CA cannot batch the responses in the NestedNessage like
        {sender=CA; recipient=RA; transactionID=5; body=nested {
                sender=CA; recipient=EE1; transactionID=10; body=cp; 
                sender=CA; recipient=EE2; transactionID=22; body=cp }}
because the pkiRep is not allowed to contain the NestedNessage.

The only scenario that I can imagine is that the CA replies with the finRep
and then establishes a separate connection to the RA and sends the 
NestedNessage with the responses in the pkiReq TCP message.
But overall it does not sound very interoperable with anybody.

Regards,
Michael Blinov





Received: by above.proper.com (8.11.6/8.11.3) id g56BYCk00715 for ietf-pkix-bks; Thu, 6 Jun 2002 04:34:12 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56BYBn00709 for <[e-mail]>; Thu, 6 Jun 2002 04:34:11 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07554; Thu, 6 Jun 2002 07:33:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-yoon-pkix-wireless-internet-01.txt
Date: Thu, 06 Jun 2002 07:33:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Wireless Internet X.509 Public Key Infrastructure 
                          Certificate Request Message Format and Protocol 
                          WCRMFP)
	Author(s)	: J. Yoon et al.
	Filename	: draft-yoon-pkix-wireless-internet-01.txt
	Pages		: 16
	Date		: 05-Jun-02
	
This document describes the Wireless Certificate Request 
Message Format and Protocol (WCRMFP) in wireless internet 
environment. This format and protocol are used to convey a request 
for a certificate to a Certification Authority (CA) (possibly via a 
Registration Authority (RA)) for the purposes of X.509 certificate 
production.  The request will typically include a public key and 
associated registration information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yoon-pkix-wireless-internet-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-yoon-pkix-wireless-internet-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-yoon-pkix-wireless-internet-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-yoon-pkix-wireless-internet-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-yoon-pkix-wireless-internet-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g554MAF21275 for ietf-pkix-bks; Tue, 4 Jun 2002 21:22:10 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz (mailhost2.auckland.ac.nz [130.216.1.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g554M4g21271 for <[e-mail]>; Tue, 4 Jun 2002 21:22:08 -0700 (PDT)
Received: from mailhost-mp.auckland.ac.nz (IDENT:[e-mail] [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id QAA14426; Wed, 5 Jun 2002 16:22:02 +1200 (NZST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost-mp.auckland.ac.nz (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id ADZ69414; Wed, 5 Jun 2002 16:21:59 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g554LxAC028639; Wed, 5 Jun 2002 16:21:59 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA310537; Wed, 5 Jun 2002 16:21:54 +1200 (NZST) (sender [e-mail])
Date: Wed, 5 Jun 2002 16:21:54 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Frank Balluffi" <[e-mail]> writes:

>I should have added that I prefer OCTET STRING, as the processing does not
>involve any math.

Yup, that's what I implied with the "sign bit" point.  Comparing two integers
(acting as octet string holes) is far more difficult than it needs to be, since
some will be zero-padded and some won't, and some should be but aren't, so
instead of a simple memcmp() you have to handle all sorts of special cases. You
also run into problems if a client submits a non-DER request (eg sign bit
incorrectly encoded) and the server replies with a correctly DER-encoded
response, which the client may or may not reject as not matching the request.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54LrC112048 for ietf-pkix-bks; Tue, 4 Jun 2002 14:53:12 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54LrCg12044 for <[e-mail]>; Tue, 4 Jun 2002 14:53:12 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 4 Jun 2002 14:47:49 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 04 Jun 2002 14:47:49 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <K7HL3STZ>; Tue, 04 Jun 2002 14:52:26 -0700
Content-return: allowed
Date: Tue, 04 Jun 2002 14:52:26 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: ASN.1 syntax for OCSP nonce value?
To: "'David Hopwood'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave, if there is no backwards compatibility issue, you could
decide to only support (b).

As a paranoid engineer, I would recommend that the entity
making the OCSP request followed (b), while a responder/proxy (to be
more liberal), used the rule defined in (c).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: David Hopwood [mailto:[e-mail]]
> Sent: Tuesday, June 04, 2002 2:01 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: ASN.1 syntax for OCSP nonce value?
> 
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> [Context for ietf-tls: the IETF-PKIX WG have been discussing 
> the fact that
> RFC 2560 (OCSP) is unclear about how the nonce value in the OCSP
> id-pkix-ocsp-nonce extension is encoded. OCSP Extensions 
> should be a DER
> encoding of some specified type encapsulated as an OCTET 
> STRING, but some
> OCSP clients just send a raw OCTET STRING containing the nonce.]
> 
> Peter Gutmann wrote:
> > Ambarish Malpani <[e-mail]> writes:
> > 
> > >Would people be fine with a nonce that was an OCTET STRING?
> > 
> > Even though I mentioned the use of INTEGER earlier on 
> (probably due to its
> > origins in TSP), I'd actually prefer OCTET STRING to 
> INTEGER because:
> > 
> >   a. Most applications use an octet string anyway 
> (typically a SHA-1 hash),
> >      even if it's encoded as an integer.
> >   b. There's no confusion over encoding of sign bits.
> 
> One of the TLS extensions in 
> <draft-ietf-tls-extensions-04.txt>, just about to
> go to Last Call, uses OCSP. In that extension (see section 
> 3.6 of the draft),
> the TLS client acts as an OCSP client, and the TLS server 
> acts as an OCSP proxy.
> 
> Strictly speaking it's not up to that draft to clarify the 
> specification of
> OCSP, but it might be helpful to do so if this is considered 
> a bug in RFC 2560.
> Which option would the PKIX group prefer?
> 
>   a) No change.
>   b) Say that an OCSP nonce extension generated by a TLS 
> client MUST be a
>      DER-encoded OCTET STRING (encapsulated as another OCTET STRING).
>   c) Say that the TLS server MUST pass each OCSP extension as 
> an opaque blob,
>      i.e. not check that it encapsulates a valid DER encoding.
>   d) Both b) and c).
> 
> My preference is for b) (there's no backward compatibility 
> problem in this
> case).
> 
> - -- 
> David Hopwood <[e-mail]>
> 
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C 
> D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If 
> I revoke a
> public key but refuse to specify why, it is because the 
> private key has been
> seized under the Regulation of Investigatory Powers Act; see 
> www.fipr.org/rip
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBPP0qbjkCAxeYt5gVAQFn+Af+OCYbp9OgVouFVImZVe3yrJ7Aafq0w0qa
> 9xFCuCB9ULOtilCg12NMwq772fv2bXlHWriOQGX8G0o90aqpuTfOELf3sw/CRcIS
> 5Y3cIeLbza//RcTw3JuL9Pk8OkCVKATbwlRW8ZenagI3XJuDoCDd5HiTHgBPf5lX
> 7Klb6ZZuZBBDIUYavRqMmzy7Bzq3zqy2fi3it3YYsYswl5UtHQgZ/f7tCDdc2uBS
> B75/skpdTJJ+C1DdUPQYRw3WwlZAxvcj4Q0z8dYmTfy0Aesg292e7jxp0Ckhrn23
> dm8xe/LsVmueV/lv8QXzFo7W9aZAUbEhNS1dBzVcVJu/kM+dOdIhtw==
> =N5lp
> -----END PGP SIGNATURE-----
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54LmcL11967 for ietf-pkix-bks; Tue, 4 Jun 2002 14:48:38 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Lmag11963 for <[e-mail]>; Tue, 4 Jun 2002 14:48:36 -0700 (PDT)
Received: from tsg1 ([12.81.65.23]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020604214829.FXIW5116.mtiwmhc23.worldnet.att.net@tsg1>; Tue, 4 Jun 2002 21:48:29 +0000
Message-ID: <14c101c20c10$bab17fc0$[e-mail]>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Juergen Brauckmann" <[e-mail]>
Cc: <[e-mail]>, "Pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01
Date: Tue, 4 Jun 2002 10:35:05 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Isn't the warranty specific to the RPA/CPS type agreements.

I said this a number of times. What is really missing is a unified global
PKI process/parameter negotiation protocol.

Todd

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Juergen Brauckmann" <[e-mail]>
Cc: <[e-mail]>; "Pkix" <[e-mail]>
Sent: Monday, June 03, 2002 5:41 AM
Subject: Re: draft-ietf-pkix-warranty-extn-01


>
> Juergen,
>
> > Hi Denis.
>
> > Denis Pinkas wrote:
>
> >  > COMMENT 2
> > >
> > > It seems difficult to be able to take benefit of a warranty without
proving
> > > that there is a real damage. However, this would imply to disclose the
> > > details of the transaction or the details of the damage. This is
conflicting
> > > with privacy considerations.
> >
> > Why should it be a privacy problem? In paper-world you are already
> > forced to disclose details on your damage if you want to get a refund
> > from an insurance. If you want money, you have to tell why.
>
> Not necessarilly. I have to tell how much. A good example is a payment
> guaranted by a smartcard. An inquiry is made for a certain amount of money
> and the warranty is granted for that amount. You do not have to tell which
> goods have been purchased.
>
> > Why is it necessary to object against this procedure when it is about
> > electronic transactions?
>
> See above.
>
> > > Another approach would be to obtain a warranty from a server to which
only
> > > the amount that is wished to be guaranteed would be disclosed. A
signed
> > > warranty would then be given.
> >
> > How can a warranty server solve the problem that someone is forced to
> > tell details about transactions if he wants to take benefit of a
> > warranty?
>
> The amount can be guaranted for a given date, irrespective of the nature
of
> the goods or the service being purchased.
>
> Denis
>
> >
> > Regards,
> >    Juergen
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54LmEA11955 for ietf-pkix-bks; Tue, 4 Jun 2002 14:48:14 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54LmDg11951 for <[e-mail]>; Tue, 4 Jun 2002 14:48:13 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 4 Jun 2002 14:42:53 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Tue, 04 Jun 2002 14:42:53 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <K7HL3SR9>; Tue, 04 Jun 2002 14:47:30 -0700
Content-return: allowed
Date: Tue, 04 Jun 2002 14:47:30 -0700
From: Ambarish Malpani <[e-mail]>
Subject: FW: (Fwd) Question on SCVP.
To: "IETF PKIX (E-mail)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, I forgot to cc the list on this response.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Ambarish Malpani 
> Sent: Tuesday, June 04, 2002 2:45 PM
> To: '[e-mail]'
> Cc: [e-mail]; [e-mail]
> Subject: RE: (Fwd) Question on SCVP.
> 
> 
> 
> Hi Rob,
>     I think that was a private comment that came out in the draft
> by mistake (one of the problems of using Word to edit text docs :-)).
> 
> It will be fixed in the next draft. Thanks for pointing it out.
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Chief Architect                                          650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Tuesday, June 04, 2002 1:39 PM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]; 
> [e-mail]
> > Subject: (Fwd) Question on SCVP.
> > 
> > 
> > Hi all.
> > 
> >   Sorry to rehash this message, my mistake for not sending it 
> > to the editors first while CC the 
> > pkix-ml.  Internet security considerations are too important 
> > to me to let this go without a 
> > comment.
> > 
> > -rob paar
> > [e-mail]
> > 
> > ------- Forwarded message follows -------
> > From:           	Self <[e-mail]>
> > To:             	[e-mail]
> > Subject:        	Question on SCVP.
> > Date sent:      	Tue, 28 May 2002 06:54:18 +0200
> > 
> > Hi,
> > 
> >   I was wondering if someone could clarify this paragraph, from
> >   'draft-ietf-pkix-scvp-08.txt' section 6. Security Considerations,
> > 
> >     "If the client does not include a RequestNonce item, or 
> > if the client
> >      does not check that the RequestNonce in the reply 
> > matches that in the
> >      request, an attacker can replay previous responses from 
> > the server.
> >      [This is not true if the request hash is used as a nonce 
> > by the client.]"
> > 
> >   In particular, the square bracket text may be interpreted in two
> >   ways.
> > 
> >   1.  While generating a PSRequest, a hash of the PSRequest is
> >       included as the requestNonce.  Quite a feat, as this 
> > requires that
> >       the hash be known before generating the PSRequest, of 
> > which the hash
> >       is a part.
> >  
> >   2.  When decoding the PSResponse, the requestHash is 
> compared with a
> >       previously calculated hash of PSRequest prior to 
> > transporting the
> >       ContentInfo to a SCVP compliant server.  This seems like a
> >       reasonable interpretation.  However, if this is the desired
> >       interpretation, then I do not believe the statement 
> true in all
> >       cases.  
> > 
> >       Consider a minimal PSRequest, where none of the 
> OPTIONAL fields
> >       are included, the typesOfCheck and wantBack items 
> being constant
> >       (which I believe to be a valid assumption for any given usage
> >       of a scvp client, for pratical purposes).  Then for each
> >       single certificate (or single set of certificates), for 
> > which validity
> >       information is required, the hash of PSRequest will 
> be the same.
> >       Therefore the requestHash cannot be used as a nonce. Or did I
> >       miss something?
> > 
> >       Another question that arises is, for security reasons, 
> > is it desirable
> >       to require a nonce extention, or is the whole nonce 
> > mechanism merely
> >       there to support clients that desire higher security 
> > than that which
> >       is provided if a minimum PSRequest is used?  Put 
> > another way, if a 
> >       client does not care to thwart replay attacks can they 
> > simply ignore
> >       checking the requestHash, if they are waiting on a 
> > single response?
> >       (Yes I know they MUST check it, but it is a trivial 
> > check if my point 
> >       2. above, is correct.)
> > 
> >       A last question would read, How can a server enforce 
> > the use of a
> >       nonce, or require a nonce before processing a PSRequest? And
> >       would it be desirable to do so, if not why not?
> > 
> > 
> >   BTW, I have a suggestion for normalizing the ASN.1 notation from
> > 
> >     "CertsQuery ::= SEQUENCE {
> >         queriedCerts          SEQUENCE SIZE (1..MAX) OF Cert,
> >         validityTime      [0] GeneralizedTime OPTIONAL,
> >         intermediateCerts [1] CertBundle OPTIONAL,
> >         trustedCerts      [2] CertBundle OPTIONAL,
> >         revocationInfos   [3] SEQUENCE SIZE (1..MAX) OF 
> > RevocationInfo OPTIONAL,
> >         policyID          [4] OBJECT IDENTIFIER OPTIONAL,
> >         configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL,
> >         queryExtensions        [6] Extensions OPTIONAL
> >     }"
> > 
> >   to
> > 
> >     CertsQuery ::= SEQUENCE {
> >         queriedCerts          CertBundle,
> >         validityTime      [0] GeneralizedTime OPTIONAL,
> >         intermediateCerts [1] CertBundle OPTIONAL,
> >         trustedCerts      [2] CertBundle OPTIONAL,
> >         revocationInfos   [3] SEQUENCE SIZE (1..MAX) OF 
> > RevocationInfo OPTIONAL,
> >         policyID          [4] OBJECT IDENTIFIER OPTIONAL,
> >         configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL,
> >         queryExtensions        [6] Extensions OPTIONAL
> >     }
> > 
> >   [change made to defintion of queriedCerts]
> > 
> > 
> >   Thanks for you time.
> > 
> > -rob paar
> > [e-mail]
> > 
> > ------- End of forwarded message -------
> > 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54Kc9J10168 for ietf-pkix-bks; Tue, 4 Jun 2002 13:38:09 -0700 (PDT)
Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Kc7g10164 for <[e-mail]>; Tue, 4 Jun 2002 13:38:07 -0700 (PDT)
Received: from pc1 (213-84-108-38.adsl.xs4all.nl [213.84.108.38]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g54Kc3bg040786; Tue, 4 Jun 2002 22:38:03 +0200 (CEST)
From: [e-mail]
To: [e-mail]
Date: Tue, 4 Jun 2002 22:38:45 +0200
MIME-Version: 1.0
Subject: (Fwd) Question on SCVP.
CC: [e-mail], [e-mail], [e-mail]
Message-ID: <3CFD4175.8792.CD981F@localhost>
X-mailer: Pegasus Mail for Windows (v4.01)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all.

  Sorry to rehash this message, my mistake for not sending it to the editors first while CC the 
pkix-ml.  Internet security considerations are too important to me to let this go without a 
comment.

-rob paar
[e-mail]

------- Forwarded message follows -------
From:           	Self <[e-mail]>
To:             	[e-mail]
Subject:        	Question on SCVP.
Date sent:      	Tue, 28 May 2002 06:54:18 +0200

Hi,

  I was wondering if someone could clarify this paragraph, from
  'draft-ietf-pkix-scvp-08.txt' section 6. Security Considerations,

    "If the client does not include a RequestNonce item, or if the client
     does not check that the RequestNonce in the reply matches that in the
     request, an attacker can replay previous responses from the server.
     [This is not true if the request hash is used as a nonce by the client.]"

  In particular, the square bracket text may be interpreted in two
  ways.

  1.  While generating a PSRequest, a hash of the PSRequest is
      included as the requestNonce.  Quite a feat, as this requires that
      the hash be known before generating the PSRequest, of which the hash
      is a part.
 
  2.  When decoding the PSResponse, the requestHash is compared with a
      previously calculated hash of PSRequest prior to transporting the
      ContentInfo to a SCVP compliant server.  This seems like a
      reasonable interpretation.  However, if this is the desired
      interpretation, then I do not believe the statement true in all
      cases.  

      Consider a minimal PSRequest, where none of the OPTIONAL fields
      are included, the typesOfCheck and wantBack items being constant
      (which I believe to be a valid assumption for any given usage
      of a scvp client, for pratical purposes).  Then for each
      single certificate (or single set of certificates), for which validity
      information is required, the hash of PSRequest will be the same.
      Therefore the requestHash cannot be used as a nonce. Or did I
      miss something?

      Another question that arises is, for security reasons, is it desirable
      to require a nonce extention, or is the whole nonce mechanism merely
      there to support clients that desire higher security than that which
      is provided if a minimum PSRequest is used?  Put another way, if a 
      client does not care to thwart replay attacks can they simply ignore
      checking the requestHash, if they are waiting on a single response?
      (Yes I know they MUST check it, but it is a trivial check if my point 
      2. above, is correct.)

      A last question would read, How can a server enforce the use of a
      nonce, or require a nonce before processing a PSRequest? And
      would it be desirable to do so, if not why not?


  BTW, I have a suggestion for normalizing the ASN.1 notation from

    "CertsQuery ::= SEQUENCE {
        queriedCerts          SEQUENCE SIZE (1..MAX) OF Cert,
        validityTime      [0] GeneralizedTime OPTIONAL,
        intermediateCerts [1] CertBundle OPTIONAL,
        trustedCerts      [2] CertBundle OPTIONAL,
        revocationInfos   [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL,
        policyID          [4] OBJECT IDENTIFIER OPTIONAL,
        configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL,
        queryExtensions        [6] Extensions OPTIONAL
    }"

  to

    CertsQuery ::= SEQUENCE {
        queriedCerts          CertBundle,
        validityTime      [0] GeneralizedTime OPTIONAL,
        intermediateCerts [1] CertBundle OPTIONAL,
        trustedCerts      [2] CertBundle OPTIONAL,
        revocationInfos   [3] SEQUENCE SIZE (1..MAX) OF RevocationInfo OPTIONAL,
        policyID          [4] OBJECT IDENTIFIER OPTIONAL,
        configurationIdentifier [5] OBJECT IDENTIFIER OPTIONAL,
        queryExtensions        [6] Extensions OPTIONAL
    }

  [change made to defintion of queriedCerts]


  Thanks for you time.

-rob paar
[e-mail]

------- End of forwarded message -------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54K2u808968 for ietf-pkix-bks; Tue, 4 Jun 2002 13:02:56 -0700 (PDT)
Received: from zetnet.co.uk ([e-mail] [194.247.47.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54K2tg08961 for <[e-mail]>; Tue, 4 Jun 2002 13:02:55 -0700 (PDT)
Received: from zetnet.co.uk (bts-1008.dialup.zetnet.co.uk [194.247.51.240]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g54K2s815031; Tue, 4 Jun 2002 21:02:54 +0100
Message-ID: <[e-mail]>
Date: Tue, 04 Jun 2002 21:01:24 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: ASN.1 syntax for OCSP nonce value?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----

[Context for ietf-tls: the IETF-PKIX WG have been discussing the fact that
RFC 2560 (OCSP) is unclear about how the nonce value in the OCSP
id-pkix-ocsp-nonce extension is encoded. OCSP Extensions should be a DER
encoding of some specified type encapsulated as an OCTET STRING, but some
OCSP clients just send a raw OCTET STRING containing the nonce.]

Peter Gutmann wrote:
> Ambarish Malpani <[e-mail]> writes:
> 
> >Would people be fine with a nonce that was an OCTET STRING?
> 
> Even though I mentioned the use of INTEGER earlier on (probably due to its
> origins in TSP), I'd actually prefer OCTET STRING to INTEGER because:
> 
>   a. Most applications use an octet string anyway (typically a SHA-1 hash),
>      even if it's encoded as an integer.
>   b. There's no confusion over encoding of sign bits.

One of the TLS extensions in <draft-ietf-tls-extensions-04.txt>, just about to
go to Last Call, uses OCSP. In that extension (see section 3.6 of the draft),
the TLS client acts as an OCSP client, and the TLS server acts as an OCSP proxy.

Strictly speaking it's not up to that draft to clarify the specification of
OCSP, but it might be helpful to do so if this is considered a bug in RFC 2560.
Which option would the PKIX group prefer?

  a) No change.
  b) Say that an OCSP nonce extension generated by a TLS client MUST be a
     DER-encoded OCTET STRING (encapsulated as another OCTET STRING).
  c) Say that the TLS server MUST pass each OCSP extension as an opaque blob,
     i.e. not check that it encapsulates a valid DER encoding.
  d) Both b) and c).

My preference is for b) (there's no backward compatibility problem in this
case).

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPP0qbjkCAxeYt5gVAQFn+Af+OCYbp9OgVouFVImZVe3yrJ7Aafq0w0qa
9xFCuCB9ULOtilCg12NMwq772fv2bXlHWriOQGX8G0o90aqpuTfOELf3sw/CRcIS
5Y3cIeLbza//RcTw3JuL9Pk8OkCVKATbwlRW8ZenagI3XJuDoCDd5HiTHgBPf5lX
7Klb6ZZuZBBDIUYavRqMmzy7Bzq3zqy2fi3it3YYsYswl5UtHQgZ/f7tCDdc2uBS
B75/skpdTJJ+C1DdUPQYRw3WwlZAxvcj4Q0z8dYmTfy0Aesg292e7jxp0Ckhrn23
dm8xe/LsVmueV/lv8QXzFo7W9aZAUbEhNS1dBzVcVJu/kM+dOdIhtw==
=N5lp
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54H4QA00894 for ietf-pkix-bks; Tue, 4 Jun 2002 10:04:26 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54H4Og00889 for <[e-mail]>; Tue, 4 Jun 2002 10:04:24 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA06040; Tue, 4 Jun 2002 19:04:09 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.5); Tue, 4 Jun 2002 19:04:10 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA27522; Tue, 4 Jun 2002 19:04:07 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA26644; Tue, 4 Jun 2002 19:04:07 +0200 (MET DST)
Date: Tue, 4 Jun 2002 19:04:07 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> 
> 
> I should have added that I prefer OCTET STRING, as the processing does not involve any math.
> 

3029 also has a Nonce of INTEGER but actually allows that during chaining nonces
can be made longer, and in the responses just a prefix should match (regarding the
integer as a octet string, not as a number. 

I don't know why TSP and DVCS initially uses Integer, maybe because of kerberos,
anyway, for OCSP no compatibility with other protocols seem necassary anyway. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54F6oK22107 for ietf-pkix-bks; Tue, 4 Jun 2002 08:06:50 -0700 (PDT)
Received: from imr3.srv.na.deuba.com (imr3.srv.na.deuba.com [165.250.91.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54F6ng22103 for <[e-mail]>; Tue, 4 Jun 2002 08:06:49 -0700 (PDT)
Received: from sdbo1005.db.com by imr3.srv.na.deuba.com  id g54F6ZRQ014905; Tue, 4 Jun 2002 11:06:36 -0400 (EDT)
Sensitivity: 
Subject: RE: ASN.1 syntax for OCSP nonce value?
To: "Frank Balluffi" <[e-mail]>
Cc: [e-mail] (Peter Gutmann), [e-mail], [e-mail], [e-mail], [e-mail]
From: "Frank Balluffi" <[e-mail]>
Date: Tue, 4 Jun 2002 11:06:34 -0400
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.9a |January 7, 2002) at 06/04/2002 11:06:36 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I should have added that I prefer OCTET STRING, as the processing does not involve any math.

Frank


---------------------------------------- Message History ----------------------------------------


From:  "Frank Balluffi" <[e-mail]>@mail.imc.org on 06/04/2002 08:45 AM AST

DELEGATED - Sent by:    [e-mail]


To:    [e-mail] (Peter Gutmann)
cc:    [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject:    RE: ASN.1 syntax for OCSP nonce value?




I was able to quickly find three precedents:

Kerberos (RFC 1510)  INTEGER
TSP (RFC 3161)       INTEGER
SCVP (draft)         OCTET STRING

Frank


---------------------------------------- Message History ----------------------------------------


From:  [e-mail] (Peter Gutmann)@mail.imc.org on 06/04/2002 02:59 PM ZE12

DELEGATED - Sent by:    [e-mail]


To:    [e-mail]; [e-mail]; [e-mail]
cc:    [e-mail]
Subject:    RE: ASN.1 syntax for OCSP nonce value?



Ambarish Malpani <[e-mail]> writes:

>Would people be fine with a nonce that was an OCTET STRING?

Even though I mentioned the use of INTEGER earlier on (probably due to its
origins in TSP), I'd actually prefer OCTET STRING to INTEGER because:

  a. Most applications use an octet string anyway (typically a SHA-1 hash),
     even if it's encoded as an integer.
  b. There's no confusion over encoding of sign bits.

Peter.



--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.





--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: by above.proper.com (8.11.6/8.11.3) id g54Ep8J21106 for ietf-pkix-bks; Tue, 4 Jun 2002 07:51:08 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Ep6g21102 for <[e-mail]>; Tue, 4 Jun 2002 07:51:07 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA20300; Tue, 4 Jun 2002 16:54:37 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060416503499:478 ; Tue, 4 Jun 2002 16:50:34 +0200 
Message-ID: <[e-mail]>
Date: Tue, 04 Jun 2002 16:50:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Esposito Alfredo <[e-mail]>
CC: Ietf-Pkix <[e-mail]>
Subject: Re: R: About Proof of Private Key
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/06/2002 16:50:35, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/06/2002 16:51:06, Serialize complete at 04/06/2002 16:51:06
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g54Ep7g21103
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
> The proof of possession is required in order to certify a key pair, usually
> signing the Certification Request with the corrisponding Private Key (see
> PKCS#10)

Not exactly. As an example, when ESSCertID from RFC 2634 is always being
used, then proof of possession is no more required by the CA.

Russ provided the right answer:

In general, the CA should have the potential subscriber prove that they can 
perform private key operations with the key that corresponds to the public 
key submitted for certification.  

Denis
 

> Alfredo Esposito
> InfoCamere S.C.p.A.
> E-business - Digital Signature
> Via Morgagni 30H
> 00161 Roma
> Phone [phone]
> Fax   [phone]
> 
> -----Messaggio originale-----
> Da: [e-mail]
> [mailto:[e-mail]]Per conto di Javier Bernardo -
> Decidir IT
> Inviato: martedì 4 giugno 2002 14.55
> A: [e-mail]; Ietf-Pkix
> Oggetto: RE: About Proof of Private Key
> 
> The CA doesn´t checks the validity of the public key against the private
> key, because the private key stays in the users computer and only sends to
> the CA the public key. The CA is used as Third Party in the authentication
> of the public keys, so the users must trust the CA (this is done when you
> import the CAs public key, to verify the digital signature of the CA with
> its private key)
> 
> I hope this helps you...
> 
> Javier I. Bernardo
> Security Technical Analyst
> Research and Development
> ________________________________________
> mailto:[e-mail] <mailto:[e-mail]>
> mailto:[e-mail] <mailto:[e-mail]>
> Tel [phone] (44)
> Visitenos en http://www.decidir.com
> Decidir International Ltd.
> 
> -----Mensaje original-----
> De: narendra [mailto:[e-mail]]
> Enviado el: Martes, 04 de Junio de 2002 02:31 a.m.
> Para: Ietf-Pkix
> Asunto: About Proof of Private Key
> 
> Dear Group Members,
>       How CA checks the validity of public key against corresponding private
> Key?
> 
> regards,
> narendra.
> 
> --------------------------------------------
> Parmar Narendrasinh Abhesinh
> Numen Technologies Pvt.Ltd,
> 505 "ADITYA"
> Opp.Sardar Patel Seva Samaj,
> Off.C.G.Road,Ahmedabad-380 006.India
> Phone no:- [phone]/6466310 ex-46,47,48


Received: by above.proper.com (8.11.6/8.11.3) id g54EbLF20295 for ietf-pkix-bks; Tue, 4 Jun 2002 07:37:21 -0700 (PDT)
Received: from dns01.infocamere.it (dns01.infocamere.it [193.70.148.50]) by above.proper.com (8.11.6/8.11.3) with SMTP id g54EbKg20284 for <[e-mail]>; Tue, 4 Jun 2002 07:37:20 -0700 (PDT)
Received: (qmail 15066 invoked from network); 4 Jun 2002 14:37:13 -0000
Received: from unknown (HELO esd03d.icnet) (193.70.148.67) by 0 with SMTP; 4 Jun 2002 14:37:13 -0000
Received: from weirma004082 ([1.5.16.64]) by esd03d.icnet (Netscape Messaging Server 4.15) with SMTP id GX6RA100.Q3S; Tue, 4 Jun 2002 16:37:13 +0200 
From: "Esposito Alfredo" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Ietf-Pkix" <[e-mail]>
Subject: R: About Proof of Private Key
Date: Tue, 4 Jun 2002 16:33:39 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The proof of possession is required in order to certify a key pair, usually
signing the Certification Request with the corrisponding Private Key (see
PKCS#10)

Alfredo Esposito
InfoCamere S.C.p.A.
E-business - Digital Signature
Via Morgagni 30H
00161 Roma
Phone [phone]
Fax   [phone]

-----Messaggio originale-----
Da: [e-mail]
[mailto:[e-mail]]Per conto di Javier Bernardo -
Decidir IT
Inviato: martedì 4 giugno 2002 14.55
A: [e-mail]; Ietf-Pkix
Oggetto: RE: About Proof of Private Key



The CA doesn´t checks the validity of the public key against the private
key, because the private key stays in the users computer and only sends to
the CA the public key. The CA is used as Third Party in the authentication
of the public keys, so the users must trust the CA (this is done when you
import the CAs public key, to verify the digital signature of the CA with
its private key)

I hope this helps you...

Javier I. Bernardo
Security Technical Analyst
Research and Development
________________________________________
mailto:[e-mail] <mailto:[e-mail]>
mailto:[e-mail] <mailto:[e-mail]>
Tel [phone] (44)
Visitenos en http://www.decidir.com
Decidir International Ltd.


-----Mensaje original-----
De: narendra [mailto:[e-mail]]
Enviado el: Martes, 04 de Junio de 2002 02:31 a.m.
Para: Ietf-Pkix
Asunto: About Proof of Private Key



Dear Group Members,
      How CA checks the validity of public key against corresponding private
Key?

regards,
narendra.

--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabad-380 006.India
Phone no:- [phone]/6466310 ex-46,47,48




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54DlfA18752 for ietf-pkix-bks; Tue, 4 Jun 2002 06:47:41 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g54Dldg18748 for <[e-mail]>; Tue, 4 Jun 2002 06:47:39 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Jun 2002 13:45:37 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA09193 for <[e-mail]>; Tue, 4 Jun 2002 09:47:40 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g54DjjM23676 for <[e-mail]>; Tue, 4 Jun 2002 09:45:45 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <MHPF662Z>; Tue, 4 Jun 2002 09:47:38 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MHPF662W; Tue, 4 Jun 2002 09:47:31 -0400
From: "Housley, Russ" <[e-mail]>
To: narendra <[e-mail]>
Cc: Ietf-Pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 04 Jun 2002 09:47:21 -0400
Subject: Re: About Proof of Private Key
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There has been a lot of discussion on this topic.  Please take a look at 
the threads on Proof of Possession in the archive 
(http://www.imc.org/ietf-pkix/mail-archive/maillist.html).

In general, the CA should have the potential subscriber prove that they can 
perform private key operations with the key that corresponds to the public 
key submitted for certification.  In the case of signatures, this is 
straightforward, just have the potential subscriber sign something.  In the 
case of key management keys, such as Diffie-Hellman keys, the situation is 
less straightforward.  See RFC 2875 for a discussion of this topic.

Russ


At 11:01 AM 6/4/2002 +0530, narendra wrote:

>Dear Group Members,
>       How CA checks the validity of public key against corresponding private
>Key?
>
>regards,
>narendra.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54CuBp14397 for ietf-pkix-bks; Tue, 4 Jun 2002 05:56:11 -0700 (PDT)
Received: from relay.decidir.net (200.80.72.194.abaconet.com.ar [200.80.72.194] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Cu9g14380 for <[e-mail]>; Tue, 4 Jun 2002 05:56:09 -0700 (PDT)
Received: from smithers.decidir.net [192.168.1.11] by decidir.net [200.16.224.132] with SMTP (MDaemon.PRO.v5.0.5.R) for <[e-mail]>; Tue, 04 Jun 2002 09:55:23 -0300
Received: by smithers.decidir.net with Internet Mail Service (5.5.2653.19) id <JWFNBZKZ>; Tue, 4 Jun 2002 09:55:22 -0300
Message-ID: <[e-mail]>
From: Javier Bernardo - Decidir IT <[e-mail]>
To: [e-mail], Ietf-Pkix <[e-mail]>
Subject: RE: About Proof of Private Key
Date: Tue, 4 Jun 2002 09:55:20 -0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
X-MDRemoteIP: 192.168.1.11
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Reply-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g54Cu9g14386
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The CA doesn´t checks the validity of the public key against the private
key, because the private key stays in the users computer and only sends to
the CA the public key. The CA is used as Third Party in the authentication
of the public keys, so the users must trust the CA (this is done when you
import the CAs public key, to verify the digital signature of the CA with
its private key)

I hope this helps you...

Javier I. Bernardo
Security Technical Analyst
Research and Development
________________________________________
mailto:[e-mail] <mailto:[e-mail]> 
mailto:[e-mail] <mailto:[e-mail]> 
Tel [phone] (44)
Visitenos en http://www.decidir.com 
Decidir International Ltd.


-----Mensaje original-----
De: narendra [mailto:[e-mail]]
Enviado el: Martes, 04 de Junio de 2002 02:31 a.m.
Para: Ietf-Pkix
Asunto: About Proof of Private Key



Dear Group Members,
      How CA checks the validity of public key against corresponding private
Key?

regards,
narendra.

--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabad-380 006.India
Phone no:- [phone]/6466310 ex-46,47,48




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54CkPc13411 for ietf-pkix-bks; Tue, 4 Jun 2002 05:46:25 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g54CkOg13407 for <[e-mail]>; Tue, 4 Jun 2002 05:46:24 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Jun 2002 12:44:22 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA16500; Tue, 4 Jun 2002 08:46:24 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g54CiUU29092; Tue, 4 Jun 2002 08:44:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <MHPF6Z3A>; Tue, 4 Jun 2002 08:46:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MHPF6ZN8; Tue, 4 Jun 2002 08:46:17 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 04 Jun 2002 08:45:08 -0400
Subject: Re: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

> > RFC 3280 also says, in section 4.1.2.4:
> >
> >     The issuer field identifies the entity who has signed and issued the
> >     certificate.  The issuer field MUST contain a non-empty distinguished
> >     name (DN).  The issuer field is defined as the X.501 type Name
> >     [X.501].
> >
> > As Tom already pointed out, we expect the issuer field to uniquely identify
> > the CA.  CRLs and CMS both rely on this feature.  So, I think you 
> should say:
> >
> >     If identifierType is missing, then the permanent identifier is
> >     locally unique to the CA.  The CA is uniquely identified by the
> >     distinguished name in the issuer field.
>
>I would rather prefer to suppress "uniquely" and have the following:
>
>      If identifierType is missing, then the permanent identifier is
>      locally unique to the CA.  The CA is identified by the distinguished
>      name in the issuer field.

Fine with me.


> > Then, I think that you should include a paragraph in the security
> > considerations that tell what the consequences are if the issuer
> > distinguished name is not unique.  I belive that that they are different
> > than the CRL.  With the CRL, the CRL signature will not check if the public
> > key associated with the second CA with the same distinguished name is used.
>
>The consideration would be the same as the uniqueness of the Serial Number
>or of the Subject field. Unfortunately, RFC 3280 does not contain in the
>security considerations section any advice about CA name collisions.
>
>So I would say that I would like to copy and paste the same warning that
>should have been placed in the security considerations section from RFC
>3280. Maybe we should ask to one of the co-authors to offer some text.
>
>:-)

I am sure that you will remember this omission if a revision to RFC 3280 is 
necessary in the future.


>Here is a first shot for an addition to the security considerations section:
>
>Subject names in certificates are chosen by the issuing CA and are mandated
>to be unique for each CA; so there can be no name collision between subject
>names from the same CA. These names may be an end-entity name, when the
>certificate is a leaf certificate or a CA name, when it is a CA certificate.
>
>Since a name is only unique towards its superior CA, unless some naming
>constraints are being used, a globally unique name would need to include a
>sequence of all the names of the superior CAs. As long as there is one
>single trust anchor, then there can be no name collision.
>
>However, if a relying party trusts more than one trust anchor then name
>collisions might still occur between CA names. In such a case the name of
>the trust anchor should be added to the sequence of CA names.
>
>When the identifierType is omitted and unless some naming constraints apply
>to CA names, the identifierValue should be used in conjunction with a
>sequence of CA names, from the trust anchor name until the name of the CA
>that has issued the end-entity certificate that contains the
>PermanentIdentifier.

You are providing more background than I anticipated. Which is very good, 
and it makes you case clear.  I propose a minor rewording in the last 
paragraph, as follows:

    When the identifierType is omitted and naming constraints do not apply
    to CA names, then the identifierValue ought to be considered in
    conjunction with the sequence of certificate issuer names, from the
    trust anchor name to the name of the CA that has issued the
    certificate that contains the PermanentIdentifier.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id g54CjWq13391 for ietf-pkix-bks; Tue, 4 Jun 2002 05:45:32 -0700 (PDT)
Received: from imr5.us.db.com (imr5.us.db.com [160.83.65.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54CjVg13387 for <[e-mail]>; Tue, 4 Jun 2002 05:45:31 -0700 (PDT)
Received: from sdbo1005.db.com by imr5.us.db.com  id g54CjOUT028795; Tue, 4 Jun 2002 08:45:25 -0400 (EDT)
Sensitivity: 
Subject: RE: ASN.1 syntax for OCSP nonce value?
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
From: "Frank Balluffi" <[e-mail]>
Date: Tue, 4 Jun 2002 08:45:22 -0400
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(Release 5.0.9a |January 7, 2002) at 06/04/2002 08:45:25 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I was able to quickly find three precedents:

Kerberos (RFC 1510)  INTEGER
TSP (RFC 3161)       INTEGER
SCVP (draft)         OCTET STRING

Frank


---------------------------------------- Message History ----------------------------------------


From:  [e-mail] (Peter Gutmann)@mail.imc.org on 06/04/2002 02:59 PM ZE12

DELEGATED - Sent by:    [e-mail]


To:    [e-mail]; [e-mail]; [e-mail]
cc:    [e-mail]
Subject:    RE: ASN.1 syntax for OCSP nonce value?



Ambarish Malpani <[e-mail]> writes:

>Would people be fine with a nonce that was an OCTET STRING?

Even though I mentioned the use of INTEGER earlier on (probably due to its
origins in TSP), I'd actually prefer OCTET STRING to INTEGER because:

  a. Most applications use an octet string anyway (typically a SHA-1 hash),
     even if it's encoded as an integer.
  b. There's no confusion over encoding of sign bits.

Peter.



--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54CR2U12648 for ietf-pkix-bks; Tue, 4 Jun 2002 05:27:02 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g54CR0g12644 for <[e-mail]>; Tue, 4 Jun 2002 05:27:01 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Jun 2002 12:24:59 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA10092 for <[e-mail]>; Tue, 4 Jun 2002 08:27:00 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g54CP5o22227 for <[e-mail]>; Tue, 4 Jun 2002 08:25:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <MHPF6ZAS>; Tue, 4 Jun 2002 08:26:58 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MHPF6ZAP; Tue, 4 Jun 2002 08:26:51 -0400
From: "Housley, Russ" <[e-mail]>
To: "Manger, James H" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 04 Jun 2002 08:26:47 -0400
Subject: RE: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail] l.telstra.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James:

When a CA uses the same private key to sign certificates and CRLs, which is 
the common practice today, then a mismatch will be apparent.  However, as 
you correctly observe, the mismatch is not apparent if different private 
keys are used to sign certificates and CRLs.  This can happen by design or 
it can happen during key rollover, not just when there is a name collision.

I still think that the consequences of name collision should be described 
in the security considerations section.

Russ

At 12:01 PM 6/4/2002 +1000, Manger, James H wrote:

>I suspect the consequences of issuer name clashes are not so different for
>perm. id and CRLs.  The clash will appear to a relying party as a separate
>key (different key id) for the same CA.
>The relying party will happily accept a CRL signed with CA1's key2 as a
>proper CRL for a cert signed with CA1's key1.  Similarly a relying party
>will happily compare a perm. id signed by CA1's key2 with a perm. id signed
>by CA1's key1.
>
>In both cases the system fails for the same reason when the two keys belong
>to different CAs with the same name "CA1".
>
>I agree with Russ' suggestion to add ~ "The CA is unambiguously identified
>by the distinguished name in the issuer field." to explicitly state the
>documents assumption.
>
>P.S. I much prefer "unambiguous" to "unique" were appropriate.  It is often
>unclear whether "unique" means only one entity is identified or an entity
>has only one of these identifiers.
>
>
> > ----------
> > From: Housley, Russ [SMTP:[e-mail]]
> > Sent: Tuesday, 4 June 2002 4:58 am
>         ...
> > As Tom already pointed out, we expect the issuer field to uniquely
> > identify
> > the CA.  CRLs and CMS both rely on this feature.  So, I think you should
> > say:
> >
> >     If identifierType is missing, then the permanent identifier is
> >     locally unique to the CA.  The CA is uniquely identified by the
> >     distinguished name in the issuer field.
> >
> > Then, I think that you should include a paragraph in the security
> > considerations that tell what the consequences are if the issuer
> > distinguished name is not unique.  I belive that that they are different
> > than the CRL.  With the CRL, the CRL signature will not check if the
> > public
> > key associated with the second CA with the same distinguished name is
> > used.
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g54CNdK12537 for ietf-pkix-bks; Tue, 4 Jun 2002 05:23:39 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54CNbg12532 for <[e-mail]>; Tue, 4 Jun 2002 05:23:37 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA28734; Tue, 4 Jun 2002 14:26:56 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060414231250:463 ; Tue, 4 Jun 2002 14:23:12 +0200 
Message-ID: <[e-mail]>
Date: Tue, 04 Jun 2002 14:23:11 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: Permanent Identifier
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/06/2002 14:23:12, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/06/2002 14:23:26, Serialize complete at 04/06/2002 14:23:26
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,
 
> Denis:
 
> It is neither a guess game or a trap game.
> 
> RFC 3280 also says, in section 4.1.2.4:
> 
>     The issuer field identifies the entity who has signed and issued the
>     certificate.  The issuer field MUST contain a non-empty distinguished
>     name (DN).  The issuer field is defined as the X.501 type Name
>     [X.501].
> 
> As Tom already pointed out, we expect the issuer field to uniquely identify
> the CA.  CRLs and CMS both rely on this feature.  So, I think you should say:
> 
>     If identifierType is missing, then the permanent identifier is
>     locally unique to the CA.  The CA is uniquely identified by the
>     distinguished name in the issuer field.

I would rather prefer to suppress "uniquely" and have the following:

     If identifierType is missing, then the permanent identifier is
     locally unique to the CA.  The CA is identified by the distinguished 
     name in the issuer field.
 
> Then, I think that you should include a paragraph in the security
> considerations that tell what the consequences are if the issuer
> distinguished name is not unique.  I belive that that they are different
> than the CRL.  With the CRL, the CRL signature will not check if the public
> key associated with the second CA with the same distinguished name is used.

The consideration would be the same as the uniqueness of the Serial Number
or of the Subject field. Unfortunately, RFC 3280 does not contain in the
security considerations section any advice about CA name collisions. 

So I would say that I would like to copy and paste the same warning that
should have been placed in the security considerations section from RFC
3280. Maybe we should ask to one of the co-authors to offer some text. 

:-)

Here is a first shot for an addition to the security considerations section:

Subject names in certificates are chosen by the issuing CA and are mandated
to be unique for each CA; so there can be no name collision between subject
names from the same CA. These names may be an end-entity name, when the
certificate is a leaf certificate or a CA name, when it is a CA certificate.

Since a name is only unique towards its superior CA, unless some naming
constraints are being used, a globally unique name would need to include a
sequence of all the names of the superior CAs. As long as there is one
single trust anchor, then there can be no name collision. 

However, if a relying party trusts more than one trust anchor then name
collisions might still occur between CA names. In such a case the name of 
the trust anchor should be added to the sequence of CA names. 

When the identifierType is omitted and unless some naming constraints apply
to CA names, the identifierValue should be used in conjunction with a
sequence of CA names, from the trust anchor name until the name of the CA
that has issued the end-entity certificate that contains the
PermanentIdentifier.

Denis

 
> Russ
> 
> At 06:04 PM 6/3/2002 +0200, Denis Pinkas wrote:
> >Russ,
> >
> >Is it a guess game or a trap game ?
> >
> >RFC 3280 mentions:
> >
> >4.1.2.2  Serial number
> >
> >    The serial number MUST be a positive integer assigned by the CA to
> >    each certificate.  It MUST be unique for each certificate issued by a
> >    given CA (i.e., the issuer name and serial number identify a unique
> >    certificate)
> >
> >4.1.2.6  Subject
> >
> >    Where it is non-empty, the subject field MUST contain an X.500
> >    distinguished name (DN).  The DN MUST be unique for each subject
> >    entity certified by the one CA as defined by the issuer name field.
> >
> > > Denis:
> >
> > > And, the CA is identified by ....
> >
> >So would you like:
> >
> >"If identifierType is missing, then the permanent identifier is locally
> >unique to the one CA as defined by the issuer name field."
> >
> >Denis
> >
> > > Russ
> > >
> > > At 05:42 PM 6/3/2002 +0200, Denis Pinkas wrote:
> > > >Russ,
> > > >
> > > > > Denis:
> > > > >
> > > > > I understand your position.  Please include text that explains your
> > > > > position regarding the uniqueness of the CA distinguished name.
> > > >
> > > >I am not sure that you understand my position, since there is no need for
> > > >text explaining the notion of uniqueness of CA distinguished names.
> > > >The subject DN is unique to the issuing CA. In the same way the Permanent
> > > >identifier, when the identifierType is missing is unique to the
> > issuing CA.
> > > >
> > > >The current text is stating:
> > > >
> > > >    If identifierType is missing, then the permanent identifier is
> > > >    locally unique to the CA.
> > > >
> > > >There is no more to say, otherwise we have a problem of understanding.
> > > >
> > > >Denis
> > > >
> > > >
> > > > > Russ
> > > > >
> > > > > At 03:27 PM 6/3/2002 +0200, Denis Pinkas wrote:
> > > > > >Russ,
> > > > > >
> > > > > > > Tom:
> > > > > >
> > > > > > > One of the reasons that has been provided by the advocates of the
> > > > perm id
> > > > > > > is that DNs are not unique.  I am not one of these advocates.  I do
> > > > think
> > > > > > > that they should explain why one situation is acceptable and the
> > > > other is
> > > > > > > not or they should remove the capability that raises the question.
> > > > > >
> > > > > >The basic question is whether the Permanent Identifier value is
> > > > specific to
> > > > > >the CA or whether it is chosen from an external name space. When it is
> > > > > >chosen from an external name space, then because of the problem of
> > > > > >uniqueness of names, an OID is being used.
> > > > > >
> > > > > >When it is specific to the CA, then it is not necessary to include
> > an OID
> > > > > >to designate unambiguously the external name space, hence why the
> > > > > >identifierType is OPTIONAL.
> > > > > >
> > > > > >So I support Tom's position and I believe that the current draft is
> > > > correct.
> > > > > >
> > > > > >To summarize, I would be ready to accept all comments, except
> > comment 3.
> > > > > >
> > > > > >Denis
> > > > > >
> > > > > >
> > > > > > > Russ
> > > > > > >
> > > > > > > At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:
> > > > > > >
> > > > > > > >       Russ:
> > > > > > > >
> > > > > > > >       I am not really convinced by point 3 of your technical
> > > > > > comments.  The
> > > > > > > >point of the draft is that DN's are not sufficiently unique for
> > > > > > > >individuals.  This argument can be extended to organizations in
> > > > general,
> > > > > > > >but organizations operating CA's are not all or even most
> > > > organizations.
> > > > > > > >In any event, so many general PKI features break if CA's have
> > > > duplicate
> > > > > > > >DN's, including CRL location and CMS signatures (the serial
> > > > number/issuer
> > > > > > > >combination), that getting this particular feature to work in an
> > > > > > > >environment where CA's have such DN's is little help.
> > > > > > > >
> > > > > > > >             Tom Gindin
> > > > > > > >
> > > > > > > >"Housley, Russ" <[e-mail]>@mail.imc.org on
> > 05/24/2002
> > > > > > > >05:31:03 PM
> > > > > > > >
> > > > > > > >Sent by:    [e-mail]
> > > > > > > >
> > > > > > > >
> > > > > > > >To:    [e-mail]
> > > > > > > >cc:
> > > > > > > >Subject:    Re: WG Last Call: Permanent Identifier
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >I have several comments on the Permanent Identifier Draft.  I have
> > > > divided
> > > > > > > >them between technical and editorial.
> > > > > > > >
> > > > > > > >TECHNICAL
> > > > > > > >
> > > > > > > >1.  The OID value { id-on 2 } has already been assigned for
> > another
> > > > > > > >purpose.  Please get fresh one.
> > > > > > > >
> > > > > > > >2.  It is my understanding that international URIs can be
> > encoded as
> > > > > > > >IA5String.  This was one of the last issues raised in the
> > > > development of
> > > > > > > >RFC 3280.
> > > > > > > >
> > > > > > > >3.  I do not understand how the identifierType can be
> > > > optional.  The whole
> > > > > > > >point of this draft is that distinguished names are not
> > sufficiently
> > > > > > > >unique.  (I am not trying to reopen this debate; it has been
> > debated
> > > > > > at too
> > > > > > > >
> > > > > > > >great a length already.)  If this is the case, then it would
> > > > follow that
> > > > > > > >two CAs could have the same distinguished name.  If two such
> > CAs both
> > > > > > > >include the proposed extension, then there will be undetectable
> > > > > > > >collisions.  The resolution seem to be clear.  Make the
> > identifierType
> > > > > > > >mandatory.
> > > > > > > >
> > > > > > > >4.  The Security Considerations section is pretty weak.  It mostly
> > > > > > restated
> > > > > > > >
> > > > > > > >the purpose of the extension.  I think that it should contain
> > > > advice for
> > > > > > > >implementors that will make use of the identifier as well as
> > advice
> > > > > > for the
> > > > > > > >
> > > > > > > >Assigner Authority.  For example, the Social Security
> > > > Administration would
> > > > > > > >be such an authority in the US, and they assign nine digit
> > > > > > > >indentifiers.  Are 123-45-6789 and 123456789 the same?
> > > > > > > >(snip)


Received: by above.proper.com (8.11.6/8.11.3) id g545Vki29699 for ietf-pkix-bks; Mon, 3 Jun 2002 22:31:46 -0700 (PDT)
Received: from popsmtp1.icenet.net (popsmtp.icenet.net [203.88.128.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g545Vdg29691 for <[e-mail]>; Mon, 3 Jun 2002 22:31:41 -0700 (PDT)
Received: from numenindia.com (ice.130.client215.icenet.net [203.88.130.215] (may be forged)) by popsmtp1.icenet.net (8.9.3/8.9.3) with SMTP id KAA19146 for <[e-mail]>; Tue, 4 Jun 2002 10:58:51 +0530
X-Distribution-To: [e-mail]
From: "narendra" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: About Proof of Private Key
Date: Tue, 4 Jun 2002 11:01:25 +0530
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Group Members,
      How CA checks the validity of public key against corresponding private
Key?

regards,
narendra.

--------------------------------------------
Parmar Narendrasinh Abhesinh
Numen Technologies Pvt.Ltd,
505 "ADITYA"
Opp.Sardar Patel Seva Samaj,
Off.C.G.Road,Ahmedabad-380 006.India
Phone no:- [phone]/6466310 ex-46,47,48





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g542xHp24884 for ietf-pkix-bks; Mon, 3 Jun 2002 19:59:17 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz (mailhost2.auckland.ac.nz [130.216.1.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g542xFg24879 for <[e-mail]>; Mon, 3 Jun 2002 19:59:15 -0700 (PDT)
Received: from mailhost-mp.auckland.ac.nz (IDENT:[e-mail] [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id OAA18749; Tue, 4 Jun 2002 14:59:11 +1200 (NZST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost-mp.auckland.ac.nz (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id ADY99974; Tue, 4 Jun 2002 14:59:10 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g542x9AC016954; Tue, 4 Jun 2002 14:59:09 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA195900; Tue, 4 Jun 2002 14:59:06 +1200 (NZST) (sender [e-mail])
Date: Tue, 4 Jun 2002 14:59:06 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: ASN.1 syntax for OCSP nonce value?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ambarish Malpani <[e-mail]> writes:

>Would people be fine with a nonce that was an OCTET STRING?

Even though I mentioned the use of INTEGER earlier on (probably due to its
origins in TSP), I'd actually prefer OCTET STRING to INTEGER because:

  a. Most applications use an octet string anyway (typically a SHA-1 hash), 
     even if it's encoded as an integer.
  b. There's no confusion over encoding of sign bits.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g542H0O24064 for ietf-pkix-bks; Mon, 3 Jun 2002 19:17:00 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g542Gwg24060 for <[e-mail]>; Mon, 3 Jun 2002 19:16:59 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA22447 for <[e-mail]>; Tue, 4 Jun 2002 12:16:51 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdmGT2S_; Tue Jun  4 12:16:14 2002
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA07600 for <[e-mail]>; Tue, 4 Jun 2002 12:16:13 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd1Nh2f_; Tue Jun  4 12:14:15 2002
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA00429 for <[e-mail]>; Tue, 4 Jun 2002 12:14:14 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id <MHRNG51M>; Tue, 4 Jun 2002 12:14:15 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: WG Last Call: Permanent Identifier
Date: Tue, 4 Jun 2002 12:01:46 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I suspect the consequences of issuer name clashes are not so different for
perm. id and CRLs.  The clash will appear to a relying party as a separate
key (different key id) for the same CA.
The relying party will happily accept a CRL signed with CA1's key2 as a
proper CRL for a cert signed with CA1's key1.  Similarly a relying party
will happily compare a perm. id signed by CA1's key2 with a perm. id signed
by CA1's key1.

In both cases the system fails for the same reason when the two keys belong
to different CAs with the same name "CA1".

I agree with Russ' suggestion to add ~ "The CA is unambiguously identified
by the distinguished name in the issuer field." to explicitly state the
documents assumption.

P.S. I much prefer "unambiguous" to "unique" were appropriate.  It is often
unclear whether "unique" means only one entity is identified or an entity
has only one of these identifiers.


> ----------
> From:	Housley, Russ [SMTP:[e-mail]]
> Sent:	Tuesday, 4 June 2002 4:58 am
	...
> As Tom already pointed out, we expect the issuer field to uniquely
> identify 
> the CA.  CRLs and CMS both rely on this feature.  So, I think you should
> say:
> 
>     If identifierType is missing, then the permanent identifier is
>     locally unique to the CA.  The CA is uniquely identified by the
>     distinguished name in the issuer field.
> 
> Then, I think that you should include a paragraph in the security 
> considerations that tell what the consequences are if the issuer 
> distinguished name is not unique.  I belive that that they are different 
> than the CRL.  With the CRL, the CRL signature will not check if the
> public 
> key associated with the second CA with the same distinguished name is
> used.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53K4IP16227 for ietf-pkix-bks; Mon, 3 Jun 2002 13:04:18 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53K4Hg16223 for <[e-mail]>; Mon, 3 Jun 2002 13:04:17 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 3 Jun 2002 12:58:49 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 03 Jun 2002 12:58:48 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <K7HL3C4A>; Mon, 03 Jun 2002 13:03:25 -0700
Content-return: allowed
Date: Mon, 03 Jun 2002 13:03:24 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: ASN.1 syntax for OCSP nonce value?
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Peter.

Would people be fine with a nonce that was an OCTET STRING?

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, May 31, 2002 11:11 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: ASN.1 syntax for OCSP nonce value?
> 
> 
> 
> Geoff Elgey <[e-mail]> writes:
> 
> >This leads to the following: treating the V part of the 
> nonce TLV as having
> >some specific syntax is clearly implementation specific. Any 
> OCSPRequest /
> >OCSPResponse value inspected by third-party tools (such as 
> Peter's "dumpasn1"
> >tool) therefore MUST treat the nonce as an untyped blob.
> 
> The problem with this is that it's then in violation of all 
> other definitions
> of EXTENSION in any other standard (X.509, RFC 2459/3280, etc 
> etc).  It's an
> error in the OCSP spec which needs to be fixed.  
> Bride-of-2560 should include a
> warning to implementors to say that older implementations may 
> get it wrong (in
> terms of what X.509/2459/3280 define) and that 
> implementations should therefore
> be able to handle either alternative, but what's actually 
> used should be
> consistent with the accepted definition.  Otherwise there's 
> little point in
> going through draft standards and whatnot if errors aren't corrected.
> 
> Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53JUHH15046 for ietf-pkix-bks; Mon, 3 Jun 2002 12:30:17 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g53JUFg15040 for <[e-mail]>; Mon, 3 Jun 2002 12:30:15 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Jun 2002 19:28:15 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA16487; Mon, 3 Jun 2002 15:30:17 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g53JSLG14645; Mon, 3 Jun 2002 15:28:21 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLJSV4>; Mon, 3 Jun 2002 15:30:13 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.28]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLJSVN; Mon, 3 Jun 2002 15:30:07 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 03 Jun 2002 14:57:36 -0400
Subject: Re: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

It is neither a guess game or a trap game.

RFC 3280 also says, in section 4.1.2.4:

    The issuer field identifies the entity who has signed and issued the
    certificate.  The issuer field MUST contain a non-empty distinguished
    name (DN).  The issuer field is defined as the X.501 type Name
    [X.501].

As Tom already pointed out, we expect the issuer field to uniquely identify 
the CA.  CRLs and CMS both rely on this feature.  So, I think you should say:

    If identifierType is missing, then the permanent identifier is
    locally unique to the CA.  The CA is uniquely identified by the
    distinguished name in the issuer field.

Then, I think that you should include a paragraph in the security 
considerations that tell what the consequences are if the issuer 
distinguished name is not unique.  I belive that that they are different 
than the CRL.  With the CRL, the CRL signature will not check if the public 
key associated with the second CA with the same distinguished name is used.

Russ


At 06:04 PM 6/3/2002 +0200, Denis Pinkas wrote:
>Russ,
>
>Is it a guess game or a trap game ?
>
>RFC 3280 mentions:
>
>4.1.2.2  Serial number
>
>    The serial number MUST be a positive integer assigned by the CA to
>    each certificate.  It MUST be unique for each certificate issued by a
>    given CA (i.e., the issuer name and serial number identify a unique
>    certificate)
>
>4.1.2.6  Subject
>
>    Where it is non-empty, the subject field MUST contain an X.500
>    distinguished name (DN).  The DN MUST be unique for each subject
>    entity certified by the one CA as defined by the issuer name field.
>
> > Denis:
>
> > And, the CA is identified by ....
>
>So would you like:
>
>"If identifierType is missing, then the permanent identifier is locally
>unique to the one CA as defined by the issuer name field."
>
>Denis
>
> > Russ
> >
> > At 05:42 PM 6/3/2002 +0200, Denis Pinkas wrote:
> > >Russ,
> > >
> > > > Denis:
> > > >
> > > > I understand your position.  Please include text that explains your
> > > > position regarding the uniqueness of the CA distinguished name.
> > >
> > >I am not sure that you understand my position, since there is no need for
> > >text explaining the notion of uniqueness of CA distinguished names.
> > >The subject DN is unique to the issuing CA. In the same way the Permanent
> > >identifier, when the identifierType is missing is unique to the 
> issuing CA.
> > >
> > >The current text is stating:
> > >
> > >    If identifierType is missing, then the permanent identifier is
> > >    locally unique to the CA.
> > >
> > >There is no more to say, otherwise we have a problem of understanding.
> > >
> > >Denis
> > >
> > >
> > > > Russ
> > > >
> > > > At 03:27 PM 6/3/2002 +0200, Denis Pinkas wrote:
> > > > >Russ,
> > > > >
> > > > > > Tom:
> > > > >
> > > > > > One of the reasons that has been provided by the advocates of the
> > > perm id
> > > > > > is that DNs are not unique.  I am not one of these advocates.  I do
> > > think
> > > > > > that they should explain why one situation is acceptable and the
> > > other is
> > > > > > not or they should remove the capability that raises the question.
> > > > >
> > > > >The basic question is whether the Permanent Identifier value is
> > > specific to
> > > > >the CA or whether it is chosen from an external name space. When it is
> > > > >chosen from an external name space, then because of the problem of
> > > > >uniqueness of names, an OID is being used.
> > > > >
> > > > >When it is specific to the CA, then it is not necessary to include 
> an OID
> > > > >to designate unambiguously the external name space, hence why the
> > > > >identifierType is OPTIONAL.
> > > > >
> > > > >So I support Tom's position and I believe that the current draft is
> > > correct.
> > > > >
> > > > >To summarize, I would be ready to accept all comments, except 
> comment 3.
> > > > >
> > > > >Denis
> > > > >
> > > > >
> > > > > > Russ
> > > > > >
> > > > > > At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:
> > > > > >
> > > > > > >       Russ:
> > > > > > >
> > > > > > >       I am not really convinced by point 3 of your technical
> > > > > comments.  The
> > > > > > >point of the draft is that DN's are not sufficiently unique for
> > > > > > >individuals.  This argument can be extended to organizations in
> > > general,
> > > > > > >but organizations operating CA's are not all or even most
> > > organizations.
> > > > > > >In any event, so many general PKI features break if CA's have
> > > duplicate
> > > > > > >DN's, including CRL location and CMS signatures (the serial
> > > number/issuer
> > > > > > >combination), that getting this particular feature to work in an
> > > > > > >environment where CA's have such DN's is little help.
> > > > > > >
> > > > > > >             Tom Gindin
> > > > > > >
> > > > > > >"Housley, Russ" <[e-mail]>@mail.imc.org on 
> 05/24/2002
> > > > > > >05:31:03 PM
> > > > > > >
> > > > > > >Sent by:    [e-mail]
> > > > > > >
> > > > > > >
> > > > > > >To:    [e-mail]
> > > > > > >cc:
> > > > > > >Subject:    Re: WG Last Call: Permanent Identifier
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >I have several comments on the Permanent Identifier Draft.  I have
> > > divided
> > > > > > >them between technical and editorial.
> > > > > > >
> > > > > > >TECHNICAL
> > > > > > >
> > > > > > >1.  The OID value { id-on 2 } has already been assigned for 
> another
> > > > > > >purpose.  Please get fresh one.
> > > > > > >
> > > > > > >2.  It is my understanding that international URIs can be 
> encoded as
> > > > > > >IA5String.  This was one of the last issues raised in the
> > > development of
> > > > > > >RFC 3280.
> > > > > > >
> > > > > > >3.  I do not understand how the identifierType can be
> > > optional.  The whole
> > > > > > >point of this draft is that distinguished names are not 
> sufficiently
> > > > > > >unique.  (I am not trying to reopen this debate; it has been 
> debated
> > > > > at too
> > > > > > >
> > > > > > >great a length already.)  If this is the case, then it would
> > > follow that
> > > > > > >two CAs could have the same distinguished name.  If two such 
> CAs both
> > > > > > >include the proposed extension, then there will be undetectable
> > > > > > >collisions.  The resolution seem to be clear.  Make the 
> identifierType
> > > > > > >mandatory.
> > > > > > >
> > > > > > >4.  The Security Considerations section is pretty weak.  It mostly
> > > > > restated
> > > > > > >
> > > > > > >the purpose of the extension.  I think that it should contain
> > > advice for
> > > > > > >implementors that will make use of the identifier as well as 
> advice
> > > > > for the
> > > > > > >
> > > > > > >Assigner Authority.  For example, the Social Security
> > > Administration would
> > > > > > >be such an authority in the US, and they assign nine digit
> > > > > > >indentifiers.  Are 123-45-6789 and 123456789 the same?
> > > > > > >(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53G57r05983 for ietf-pkix-bks; Mon, 3 Jun 2002 09:05:07 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53G55g05979 for <[e-mail]>; Mon, 3 Jun 2002 09:05:06 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA20214; Mon, 3 Jun 2002 18:08:34 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060318043356:370 ; Mon, 3 Jun 2002 18:04:33 +0200 
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 18:04:44 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: Permanent Identifier
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 18:04:33, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 18:05:05, Serialize complete at 03/06/2002 18:05:05
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Is it a guess game or a trap game ?

RFC 3280 mentions:

4.1.2.2  Serial number

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate)

4.1.2.6  Subject

   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN).  The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name field.
 
> Denis:
 
> And, the CA is identified by ....

So would you like:

"If identifierType is missing, then the permanent identifier is locally
unique to the one CA as defined by the issuer name field."

Denis
 
> Russ
> 
> At 05:42 PM 6/3/2002 +0200, Denis Pinkas wrote:
> >Russ,
> >
> > > Denis:
> > >
> > > I understand your position.  Please include text that explains your
> > > position regarding the uniqueness of the CA distinguished name.
> >
> >I am not sure that you understand my position, since there is no need for
> >text explaining the notion of uniqueness of CA distinguished names.
> >The subject DN is unique to the issuing CA. In the same way the Permanent
> >identifier, when the identifierType is missing is unique to the issuing CA.
> >
> >The current text is stating:
> >
> >    If identifierType is missing, then the permanent identifier is
> >    locally unique to the CA.
> >
> >There is no more to say, otherwise we have a problem of understanding.
> >
> >Denis
> >
> >
> > > Russ
> > >
> > > At 03:27 PM 6/3/2002 +0200, Denis Pinkas wrote:
> > > >Russ,
> > > >
> > > > > Tom:
> > > >
> > > > > One of the reasons that has been provided by the advocates of the
> > perm id
> > > > > is that DNs are not unique.  I am not one of these advocates.  I do
> > think
> > > > > that they should explain why one situation is acceptable and the
> > other is
> > > > > not or they should remove the capability that raises the question.
> > > >
> > > >The basic question is whether the Permanent Identifier value is
> > specific to
> > > >the CA or whether it is chosen from an external name space. When it is
> > > >chosen from an external name space, then because of the problem of
> > > >uniqueness of names, an OID is being used.
> > > >
> > > >When it is specific to the CA, then it is not necessary to include an OID
> > > >to designate unambiguously the external name space, hence why the
> > > >identifierType is OPTIONAL.
> > > >
> > > >So I support Tom's position and I believe that the current draft is
> > correct.
> > > >
> > > >To summarize, I would be ready to accept all comments, except comment 3.
> > > >
> > > >Denis
> > > >
> > > >
> > > > > Russ
> > > > >
> > > > > At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:
> > > > >
> > > > > >       Russ:
> > > > > >
> > > > > >       I am not really convinced by point 3 of your technical
> > > > comments.  The
> > > > > >point of the draft is that DN's are not sufficiently unique for
> > > > > >individuals.  This argument can be extended to organizations in
> > general,
> > > > > >but organizations operating CA's are not all or even most
> > organizations.
> > > > > >In any event, so many general PKI features break if CA's have
> > duplicate
> > > > > >DN's, including CRL location and CMS signatures (the serial
> > number/issuer
> > > > > >combination), that getting this particular feature to work in an
> > > > > >environment where CA's have such DN's is little help.
> > > > > >
> > > > > >             Tom Gindin
> > > > > >
> > > > > >"Housley, Russ" <[e-mail]>@mail.imc.org on 05/24/2002
> > > > > >05:31:03 PM
> > > > > >
> > > > > >Sent by:    [e-mail]
> > > > > >
> > > > > >
> > > > > >To:    [e-mail]
> > > > > >cc:
> > > > > >Subject:    Re: WG Last Call: Permanent Identifier
> > > > > >
> > > > > >
> > > > > >
> > > > > >I have several comments on the Permanent Identifier Draft.  I have
> > divided
> > > > > >them between technical and editorial.
> > > > > >
> > > > > >TECHNICAL
> > > > > >
> > > > > >1.  The OID value { id-on 2 } has already been assigned for another
> > > > > >purpose.  Please get fresh one.
> > > > > >
> > > > > >2.  It is my understanding that international URIs can be encoded as
> > > > > >IA5String.  This was one of the last issues raised in the
> > development of
> > > > > >RFC 3280.
> > > > > >
> > > > > >3.  I do not understand how the identifierType can be
> > optional.  The whole
> > > > > >point of this draft is that distinguished names are not sufficiently
> > > > > >unique.  (I am not trying to reopen this debate; it has been debated
> > > > at too
> > > > > >
> > > > > >great a length already.)  If this is the case, then it would
> > follow that
> > > > > >two CAs could have the same distinguished name.  If two such CAs both
> > > > > >include the proposed extension, then there will be undetectable
> > > > > >collisions.  The resolution seem to be clear.  Make the identifierType
> > > > > >mandatory.
> > > > > >
> > > > > >4.  The Security Considerations section is pretty weak.  It mostly
> > > > restated
> > > > > >
> > > > > >the purpose of the extension.  I think that it should contain
> > advice for
> > > > > >implementors that will make use of the identifier as well as advice
> > > > for the
> > > > > >
> > > > > >Assigner Authority.  For example, the Social Security
> > Administration would
> > > > > >be such an authority in the US, and they assign nine digit
> > > > > >indentifiers.  Are 123-45-6789 and 123456789 the same?
> > > > > >(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53Fq0k04008 for ietf-pkix-bks; Mon, 3 Jun 2002 08:52:00 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g53Fpvg03996 for <[e-mail]>; Mon, 3 Jun 2002 08:51:57 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Jun 2002 15:49:56 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA26997; Mon, 3 Jun 2002 11:51:58 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g53Fo2O21109; Mon, 3 Jun 2002 11:50:02 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLJ34D>; Mon, 3 Jun 2002 11:51:56 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLJ3TZ; Mon, 3 Jun 2002 11:51:41 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 03 Jun 2002 11:51:36 -0400
Subject: Re: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

And, the CA is identified by ....

Russ

At 05:42 PM 6/3/2002 +0200, Denis Pinkas wrote:
>Russ,
>
> > Denis:
> >
> > I understand your position.  Please include text that explains your
> > position regarding the uniqueness of the CA distinguished name.
>
>I am not sure that you understand my position, since there is no need for
>text explaining the notion of uniqueness of CA distinguished names.
>The subject DN is unique to the issuing CA. In the same way the Permanent
>identifier, when the identifierType is missing is unique to the issuing CA.
>
>The current text is stating:
>
>    If identifierType is missing, then the permanent identifier is
>    locally unique to the CA.
>
>There is no more to say, otherwise we have a problem of understanding.
>
>Denis
>
>
> > Russ
> >
> > At 03:27 PM 6/3/2002 +0200, Denis Pinkas wrote:
> > >Russ,
> > >
> > > > Tom:
> > >
> > > > One of the reasons that has been provided by the advocates of the 
> perm id
> > > > is that DNs are not unique.  I am not one of these advocates.  I do 
> think
> > > > that they should explain why one situation is acceptable and the 
> other is
> > > > not or they should remove the capability that raises the question.
> > >
> > >The basic question is whether the Permanent Identifier value is 
> specific to
> > >the CA or whether it is chosen from an external name space. When it is
> > >chosen from an external name space, then because of the problem of
> > >uniqueness of names, an OID is being used.
> > >
> > >When it is specific to the CA, then it is not necessary to include an OID
> > >to designate unambiguously the external name space, hence why the
> > >identifierType is OPTIONAL.
> > >
> > >So I support Tom's position and I believe that the current draft is 
> correct.
> > >
> > >To summarize, I would be ready to accept all comments, except comment 3.
> > >
> > >Denis
> > >
> > >
> > > > Russ
> > > >
> > > > At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:
> > > >
> > > > >       Russ:
> > > > >
> > > > >       I am not really convinced by point 3 of your technical
> > > comments.  The
> > > > >point of the draft is that DN's are not sufficiently unique for
> > > > >individuals.  This argument can be extended to organizations in 
> general,
> > > > >but organizations operating CA's are not all or even most 
> organizations.
> > > > >In any event, so many general PKI features break if CA's have 
> duplicate
> > > > >DN's, including CRL location and CMS signatures (the serial 
> number/issuer
> > > > >combination), that getting this particular feature to work in an
> > > > >environment where CA's have such DN's is little help.
> > > > >
> > > > >             Tom Gindin
> > > > >
> > > > >"Housley, Russ" <[e-mail]>@mail.imc.org on 05/24/2002
> > > > >05:31:03 PM
> > > > >
> > > > >Sent by:    [e-mail]
> > > > >
> > > > >
> > > > >To:    [e-mail]
> > > > >cc:
> > > > >Subject:    Re: WG Last Call: Permanent Identifier
> > > > >
> > > > >
> > > > >
> > > > >I have several comments on the Permanent Identifier Draft.  I have 
> divided
> > > > >them between technical and editorial.
> > > > >
> > > > >TECHNICAL
> > > > >
> > > > >1.  The OID value { id-on 2 } has already been assigned for another
> > > > >purpose.  Please get fresh one.
> > > > >
> > > > >2.  It is my understanding that international URIs can be encoded as
> > > > >IA5String.  This was one of the last issues raised in the 
> development of
> > > > >RFC 3280.
> > > > >
> > > > >3.  I do not understand how the identifierType can be 
> optional.  The whole
> > > > >point of this draft is that distinguished names are not sufficiently
> > > > >unique.  (I am not trying to reopen this debate; it has been debated
> > > at too
> > > > >
> > > > >great a length already.)  If this is the case, then it would 
> follow that
> > > > >two CAs could have the same distinguished name.  If two such CAs both
> > > > >include the proposed extension, then there will be undetectable
> > > > >collisions.  The resolution seem to be clear.  Make the identifierType
> > > > >mandatory.
> > > > >
> > > > >4.  The Security Considerations section is pretty weak.  It mostly
> > > restated
> > > > >
> > > > >the purpose of the extension.  I think that it should contain 
> advice for
> > > > >implementors that will make use of the identifier as well as advice
> > > for the
> > > > >
> > > > >Assigner Authority.  For example, the Social Security 
> Administration would
> > > > >be such an authority in the US, and they assign nine digit
> > > > >indentifiers.  Are 123-45-6789 and 123456789 the same?
> > > > >(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53FhFj02652 for ietf-pkix-bks; Mon, 3 Jun 2002 08:43:15 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53FhDg02644 for <[e-mail]>; Mon, 3 Jun 2002 08:43:14 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA26266; Mon, 3 Jun 2002 17:46:42 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060317424097:365 ; Mon, 3 Jun 2002 17:42:40 +0200 
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 17:42:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: Permanent Identifier
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 17:42:41, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 17:43:12, Serialize complete at 03/06/2002 17:43:12
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,
 
> Denis:
> 
> I understand your position.  Please include text that explains your
> position regarding the uniqueness of the CA distinguished name.

I am not sure that you understand my position, since there is no need for
text explaining the notion of uniqueness of CA distinguished names.
The subject DN is unique to the issuing CA. In the same way the Permanent
identifier, when the identifierType is missing is unique to the issuing CA.

The current text is stating:

   If identifierType is missing, then the permanent identifier is 
   locally unique to the CA.

There is no more to say, otherwise we have a problem of understanding.

Denis

 
> Russ
> 
> At 03:27 PM 6/3/2002 +0200, Denis Pinkas wrote:
> >Russ,
> >
> > > Tom:
> >
> > > One of the reasons that has been provided by the advocates of the perm id
> > > is that DNs are not unique.  I am not one of these advocates.  I do think
> > > that they should explain why one situation is acceptable and the other is
> > > not or they should remove the capability that raises the question.
> >
> >The basic question is whether the Permanent Identifier value is specific to
> >the CA or whether it is chosen from an external name space. When it is
> >chosen from an external name space, then because of the problem of
> >uniqueness of names, an OID is being used.
> >
> >When it is specific to the CA, then it is not necessary to include an OID
> >to designate unambiguously the external name space, hence why the
> >identifierType is OPTIONAL.
> >
> >So I support Tom's position and I believe that the current draft is correct.
> >
> >To summarize, I would be ready to accept all comments, except comment 3.
> >
> >Denis
> >
> >
> > > Russ
> > >
> > > At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:
> > >
> > > >       Russ:
> > > >
> > > >       I am not really convinced by point 3 of your technical
> > comments.  The
> > > >point of the draft is that DN's are not sufficiently unique for
> > > >individuals.  This argument can be extended to organizations in general,
> > > >but organizations operating CA's are not all or even most organizations.
> > > >In any event, so many general PKI features break if CA's have duplicate
> > > >DN's, including CRL location and CMS signatures (the serial number/issuer
> > > >combination), that getting this particular feature to work in an
> > > >environment where CA's have such DN's is little help.
> > > >
> > > >             Tom Gindin
> > > >
> > > >"Housley, Russ" <[e-mail]>@mail.imc.org on 05/24/2002
> > > >05:31:03 PM
> > > >
> > > >Sent by:    [e-mail]
> > > >
> > > >
> > > >To:    [e-mail]
> > > >cc:
> > > >Subject:    Re: WG Last Call: Permanent Identifier
> > > >
> > > >
> > > >
> > > >I have several comments on the Permanent Identifier Draft.  I have divided
> > > >them between technical and editorial.
> > > >
> > > >TECHNICAL
> > > >
> > > >1.  The OID value { id-on 2 } has already been assigned for another
> > > >purpose.  Please get fresh one.
> > > >
> > > >2.  It is my understanding that international URIs can be encoded as
> > > >IA5String.  This was one of the last issues raised in the development of
> > > >RFC 3280.
> > > >
> > > >3.  I do not understand how the identifierType can be optional.  The whole
> > > >point of this draft is that distinguished names are not sufficiently
> > > >unique.  (I am not trying to reopen this debate; it has been debated
> > at too
> > > >
> > > >great a length already.)  If this is the case, then it would follow that
> > > >two CAs could have the same distinguished name.  If two such CAs both
> > > >include the proposed extension, then there will be undetectable
> > > >collisions.  The resolution seem to be clear.  Make the identifierType
> > > >mandatory.
> > > >
> > > >4.  The Security Considerations section is pretty weak.  It mostly
> > restated
> > > >
> > > >the purpose of the extension.  I think that it should contain advice for
> > > >implementors that will make use of the identifier as well as advice
> > for the
> > > >
> > > >Assigner Authority.  For example, the Social Security Administration would
> > > >be such an authority in the US, and they assign nine digit
> > > >indentifiers.  Are 123-45-6789 and 123456789 the same?
> > > >(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53Feov02264 for ietf-pkix-bks; Mon, 3 Jun 2002 08:40:50 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g53Femg02254 for <[e-mail]>; Mon, 3 Jun 2002 08:40:48 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Jun 2002 15:38:48 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA25777; Mon, 3 Jun 2002 11:40:50 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g53Fcsm19665; Mon, 3 Jun 2002 11:38:54 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLJ3MF>; Mon, 3 Jun 2002 11:40:48 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLJ3MC; Mon, 3 Jun 2002 11:40:42 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: Juergen Brauckmann <[e-mail]>, [e-mail], Pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 03 Jun 2002 11:40:37 -0400
Subject: Re: draft-ietf-pkix-warranty-extn-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

I am not arguing against explanatory text, but I am suggesting that we not 
invent another means of describing monetary values.

Russ

At 11:37 AM 6/3/2002 -0400, Tom Gindin wrote:

>       Russ:
>
>       Since this structure is specified in an ISO standard, but it seems to
>be fairly subject to misunderstanding, I would still recommend putting in
>the sentence I suggested below ("The actual monetary value in the named
>currency unit, when amtExp10 is present, is amount divided by 10 to the
>(amtExp10) power".).  There is clearly nothing to be done about the format
>specification or even the field name.  IMHO, that field name is more
>naturally interpreted in Juergen's way than otherwise.
>
>             Tom Gindin
>
>
>"Housley, Russ" <[e-mail]> on 06/03/2002 11:29:12 AM
>
>To:    Tom Gindin/Watson/IBM@IBMUS
>cc:    Juergen Brauckmann <[e-mail]>,
>        [e-mail], Pkix <[e-mail]>
>Subject:    Re: draft-ietf-pkix-warranty-extn-01
>
>
>Tom & Juergen:
>
>This form of representing monetary values was not invented by the authors
>of this specification.  I it is used many different places, and it is
>specified in   ISO 4217 [1].
>
>Russ
>
>
>[1]     ISO. Codes for the Representation of Currencies and
>            Funds," ISO 4217. 1995.
>
>
>At 05:16 PM 5/31/2002 -0400, Tom Gindin wrote:
>
>
> >       Juergen:
> >
> >       This depends on the interpretation of the text.  There are two ways
> >to resolve this.  Either the amtExp10 field should have a different range
> >(perhaps (-6..MAX)) or amtExp10 is to be interpreted as a resolution
> >exponent only, so the actual value is amount / 10**amtExp10.  The example
> >points towards the second option.
> >       If the second of these options is to be taken, the wording must
> >change.  I suggest adding after the sentence defining amtExp10 an extra
> >sentence as follows: "The actual monetary value in the named currency
>unit,
> >when amtExp10 is present, is amount divided by 10 to the (amtExp10)
>power".
> >Anyway, why is this value an exponent base 10?  Not that long ago, one of
> >the world's principal hard currencies had two minor units, 1/20 and 1/240,
> >and I'm not sure there aren't some similar cases still around.  It could
>be
> >called minorUnitDivisor and the value would just be amount /
> >minorUnitDivisor.
> >
> >             Tom Gindin
> >
> >
> >Juergen Brauckmann <[e-mail]>@mail.imc.org on 05/31/2002
> >09:15:27 AM
> >
> >Sent by:    [e-mail]
> >
> >
> >To:    [e-mail]
> >cc:    Pkix <[e-mail]>
> >Subject:    Re: draft-ietf-pkix-warranty-extn-01
> >
> >
> >
> >Hi.
> >
> >How should extendedWarranty be used? Perhaps you can give an example?
> >
> >Format of the currency field in CurrencyAmount: There is at least one
> >standard ("ETSI qualified certificate profile") I know of which
> >recommends use of a PrintableString and the alphabetic code from ISO
> >4217.
> >
> >The example in chapter 2.2 is wrong:
> >  "$48,525.50 (in US dollars) is represented as:
> >      currency =      840
> >      amount   =  4852550
> >      amtExp10 =        2"
> >
> >That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
> >say that amtExp10 is -2, but you cannot do that because it has to be >=
> >0.
> >
> >Regards,
> >    Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53FbDH01683 for ietf-pkix-bks; Mon, 3 Jun 2002 08:37:13 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53FbBg01678 for <[e-mail]>; Mon, 3 Jun 2002 08:37:11 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g53Fb3g5079450; Mon, 3 Jun 2002 11:37:03 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g53Fb1d61796; Mon, 3 Jun 2002 11:37:01 -0400
Importance: Normal
Sensitivity: 
Subject: Re: draft-ietf-pkix-warranty-extn-01
To: "Housley, Russ" <[e-mail]>
Cc: Juergen Brauckmann <[e-mail]>, [e-mail], Pkix <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 3 Jun 2002 11:37:05 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/03/2002 11:37:02 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Russ:

      Since this structure is specified in an ISO standard, but it seems to
be fairly subject to misunderstanding, I would still recommend putting in
the sentence I suggested below ("The actual monetary value in the named
currency unit, when amtExp10 is present, is amount divided by 10 to the
(amtExp10) power".).  There is clearly nothing to be done about the format
specification or even the field name.  IMHO, that field name is more
naturally interpreted in Juergen's way than otherwise.

            Tom Gindin


"Housley, Russ" <[e-mail]> on 06/03/2002 11:29:12 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    Juergen Brauckmann <[e-mail]>,
       [e-mail], Pkix <[e-mail]>
Subject:    Re: draft-ietf-pkix-warranty-extn-01


Tom & Juergen:

This form of representing monetary values was not invented by the authors
of this specification.  I it is used many different places, and it is
specified in   ISO 4217 [1].

Russ


[1]     ISO. Codes for the Representation of Currencies and
           Funds," ISO 4217. 1995.


At 05:16 PM 5/31/2002 -0400, Tom Gindin wrote:


>       Juergen:
>
>       This depends on the interpretation of the text.  There are two ways
>to resolve this.  Either the amtExp10 field should have a different range
>(perhaps (-6..MAX)) or amtExp10 is to be interpreted as a resolution
>exponent only, so the actual value is amount / 10**amtExp10.  The example
>points towards the second option.
>       If the second of these options is to be taken, the wording must
>change.  I suggest adding after the sentence defining amtExp10 an extra
>sentence as follows: "The actual monetary value in the named currency
unit,
>when amtExp10 is present, is amount divided by 10 to the (amtExp10)
power".
>Anyway, why is this value an exponent base 10?  Not that long ago, one of
>the world's principal hard currencies had two minor units, 1/20 and 1/240,
>and I'm not sure there aren't some similar cases still around.  It could
be
>called minorUnitDivisor and the value would just be amount /
>minorUnitDivisor.
>
>             Tom Gindin
>
>
>Juergen Brauckmann <[e-mail]>@mail.imc.org on 05/31/2002
>09:15:27 AM
>
>Sent by:    [e-mail]
>
>
>To:    [e-mail]
>cc:    Pkix <[e-mail]>
>Subject:    Re: draft-ietf-pkix-warranty-extn-01
>
>
>
>Hi.
>
>How should extendedWarranty be used? Perhaps you can give an example?
>
>Format of the currency field in CurrencyAmount: There is at least one
>standard ("ETSI qualified certificate profile") I know of which
>recommends use of a PrintableString and the alphabetic code from ISO
>4217.
>
>The example in chapter 2.2 is wrong:
>  "$48,525.50 (in US dollars) is represented as:
>      currency =      840
>      amount   =  4852550
>      amtExp10 =        2"
>
>That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
>say that amtExp10 is -2, but you cannot do that because it has to be >=
>0.
>
>Regards,
>    Juergen





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53FTYv01435 for ietf-pkix-bks; Mon, 3 Jun 2002 08:29:34 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g53FTWg01430 for <[e-mail]>; Mon, 3 Jun 2002 08:29:32 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Jun 2002 15:27:32 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA24691; Mon, 3 Jun 2002 11:29:30 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g53FRX818341; Mon, 3 Jun 2002 11:27:33 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLJ31G>; Mon, 3 Jun 2002 11:29:27 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLJ31C; Mon, 3 Jun 2002 11:29:15 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: Juergen Brauckmann <[e-mail]>, [e-mail], Pkix <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 03 Jun 2002 11:29:12 -0400
Subject: Re: draft-ietf-pkix-warranty-extn-01
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom & Juergen:

This form of representing monetary values was not invented by the authors 
of this specification.  I it is used many different places, and it is 
specified in   ISO 4217 [1].

Russ


[1]     ISO. Codes for the Representation of Currencies and
           Funds," ISO 4217. 1995.


At 05:16 PM 5/31/2002 -0400, Tom Gindin wrote:


>       Juergen:
>
>       This depends on the interpretation of the text.  There are two ways
>to resolve this.  Either the amtExp10 field should have a different range
>(perhaps (-6..MAX)) or amtExp10 is to be interpreted as a resolution
>exponent only, so the actual value is amount / 10**amtExp10.  The example
>points towards the second option.
>       If the second of these options is to be taken, the wording must
>change.  I suggest adding after the sentence defining amtExp10 an extra
>sentence as follows: "The actual monetary value in the named currency unit,
>when amtExp10 is present, is amount divided by 10 to the (amtExp10) power".
>Anyway, why is this value an exponent base 10?  Not that long ago, one of
>the world's principal hard currencies had two minor units, 1/20 and 1/240,
>and I'm not sure there aren't some similar cases still around.  It could be
>called minorUnitDivisor and the value would just be amount /
>minorUnitDivisor.
>
>             Tom Gindin
>
>
>Juergen Brauckmann <[e-mail]>@mail.imc.org on 05/31/2002
>09:15:27 AM
>
>Sent by:    [e-mail]
>
>
>To:    [e-mail]
>cc:    Pkix <[e-mail]>
>Subject:    Re: draft-ietf-pkix-warranty-extn-01
>
>
>
>Hi.
>
>How should extendedWarranty be used? Perhaps you can give an example?
>
>Format of the currency field in CurrencyAmount: There is at least one
>standard ("ETSI qualified certificate profile") I know of which
>recommends use of a PrintableString and the alphabetic code from ISO
>4217.
>
>The example in chapter 2.2 is wrong:
>  "$48,525.50 (in US dollars) is represented as:
>      currency =      840
>      amount   =  4852550
>      amtExp10 =        2"
>
>That's wrong. 4852550 * (10 ** 2) is 485,255,000. I guess you wanted to
>say that amtExp10 is -2, but you cannot do that because it has to be >=
>0.
>
>Regards,
>    Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53EGmW27730 for ietf-pkix-bks; Mon, 3 Jun 2002 07:16:48 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g53EGkg27726 for <[e-mail]>; Mon, 3 Jun 2002 07:16:46 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Jun 2002 14:14:45 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA17373; Mon, 3 Jun 2002 10:16:45 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g53EEn709682; Mon, 3 Jun 2002 10:14:49 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLJMTR>; Mon, 3 Jun 2002 10:16:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLJMTP; Mon, 3 Jun 2002 10:16:36 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: Tom Gindin <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 03 Jun 2002 10:16:33 -0400
Subject: Re: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

I understand your position.  Please include text that explains your 
position regarding the uniqueness of the CA distinguished name.

Russ

At 03:27 PM 6/3/2002 +0200, Denis Pinkas wrote:
>Russ,
>
> > Tom:
>
> > One of the reasons that has been provided by the advocates of the perm id
> > is that DNs are not unique.  I am not one of these advocates.  I do think
> > that they should explain why one situation is acceptable and the other is
> > not or they should remove the capability that raises the question.
>
>The basic question is whether the Permanent Identifier value is specific to
>the CA or whether it is chosen from an external name space. When it is
>chosen from an external name space, then because of the problem of
>uniqueness of names, an OID is being used.
>
>When it is specific to the CA, then it is not necessary to include an OID
>to designate unambiguously the external name space, hence why the
>identifierType is OPTIONAL.
>
>So I support Tom's position and I believe that the current draft is correct.
>
>To summarize, I would be ready to accept all comments, except comment 3.
>
>Denis
>
>
> > Russ
> >
> > At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:
> >
> > >       Russ:
> > >
> > >       I am not really convinced by point 3 of your technical 
> comments.  The
> > >point of the draft is that DN's are not sufficiently unique for
> > >individuals.  This argument can be extended to organizations in general,
> > >but organizations operating CA's are not all or even most organizations.
> > >In any event, so many general PKI features break if CA's have duplicate
> > >DN's, including CRL location and CMS signatures (the serial number/issuer
> > >combination), that getting this particular feature to work in an
> > >environment where CA's have such DN's is little help.
> > >
> > >             Tom Gindin
> > >
> > >"Housley, Russ" <[e-mail]>@mail.imc.org on 05/24/2002
> > >05:31:03 PM
> > >
> > >Sent by:    [e-mail]
> > >
> > >
> > >To:    [e-mail]
> > >cc:
> > >Subject:    Re: WG Last Call: Permanent Identifier
> > >
> > >
> > >
> > >I have several comments on the Permanent Identifier Draft.  I have divided
> > >them between technical and editorial.
> > >
> > >TECHNICAL
> > >
> > >1.  The OID value { id-on 2 } has already been assigned for another
> > >purpose.  Please get fresh one.
> > >
> > >2.  It is my understanding that international URIs can be encoded as
> > >IA5String.  This was one of the last issues raised in the development of
> > >RFC 3280.
> > >
> > >3.  I do not understand how the identifierType can be optional.  The whole
> > >point of this draft is that distinguished names are not sufficiently
> > >unique.  (I am not trying to reopen this debate; it has been debated 
> at too
> > >
> > >great a length already.)  If this is the case, then it would follow that
> > >two CAs could have the same distinguished name.  If two such CAs both
> > >include the proposed extension, then there will be undetectable
> > >collisions.  The resolution seem to be clear.  Make the identifierType
> > >mandatory.
> > >
> > >4.  The Security Considerations section is pretty weak.  It mostly 
> restated
> > >
> > >the purpose of the extension.  I think that it should contain advice for
> > >implementors that will make use of the identifier as well as advice 
> for the
> > >
> > >Assigner Authority.  For example, the Social Security Administration would
> > >be such an authority in the US, and they assign nine digit
> > >indentifiers.  Are 123-45-6789 and 123456789 the same?
> > >(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53DRMw26036 for ietf-pkix-bks; Mon, 3 Jun 2002 06:27:22 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53DRKg26032 for <[e-mail]>; Mon, 3 Jun 2002 06:27:20 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA20978; Mon, 3 Jun 2002 15:30:48 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060315265559:349 ; Mon, 3 Jun 2002 15:26:55 +0200 
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 15:27:07 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Tom Gindin <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: Permanent Identifier
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 15:26:55, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 15:27:18, Serialize complete at 03/06/2002 15:27:18
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> Tom:
 
> One of the reasons that has been provided by the advocates of the perm id
> is that DNs are not unique.  I am not one of these advocates.  I do think
> that they should explain why one situation is acceptable and the other is
> not or they should remove the capability that raises the question.

The basic question is whether the Permanent Identifier value is specific to
the CA or whether it is chosen from an external name space. When it is
chosen from an external name space, then because of the problem of
uniqueness of names, an OID is being used.

When it is specific to the CA, then it is not necessary to include an OID
to designate unambiguously the external name space, hence why the
identifierType is OPTIONAL.

So I support Tom's position and I believe that the current draft is correct.

To summarize, I would be ready to accept all comments, except comment 3.

Denis

 
> Russ
> 
> At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:
> 
> >       Russ:
> >
> >       I am not really convinced by point 3 of your technical comments.  The
> >point of the draft is that DN's are not sufficiently unique for
> >individuals.  This argument can be extended to organizations in general,
> >but organizations operating CA's are not all or even most organizations.
> >In any event, so many general PKI features break if CA's have duplicate
> >DN's, including CRL location and CMS signatures (the serial number/issuer
> >combination), that getting this particular feature to work in an
> >environment where CA's have such DN's is little help.
> >
> >             Tom Gindin
> >
> >"Housley, Russ" <[e-mail]>@mail.imc.org on 05/24/2002
> >05:31:03 PM
> >
> >Sent by:    [e-mail]
> >
> >
> >To:    [e-mail]
> >cc:
> >Subject:    Re: WG Last Call: Permanent Identifier
> >
> >
> >
> >I have several comments on the Permanent Identifier Draft.  I have divided
> >them between technical and editorial.
> >
> >TECHNICAL
> >
> >1.  The OID value { id-on 2 } has already been assigned for another
> >purpose.  Please get fresh one.
> >
> >2.  It is my understanding that international URIs can be encoded as
> >IA5String.  This was one of the last issues raised in the development of
> >RFC 3280.
> >
> >3.  I do not understand how the identifierType can be optional.  The whole
> >point of this draft is that distinguished names are not sufficiently
> >unique.  (I am not trying to reopen this debate; it has been debated at too
> >
> >great a length already.)  If this is the case, then it would follow that
> >two CAs could have the same distinguished name.  If two such CAs both
> >include the proposed extension, then there will be undetectable
> >collisions.  The resolution seem to be clear.  Make the identifierType
> >mandatory.
> >
> >4.  The Security Considerations section is pretty weak.  It mostly restated
> >
> >the purpose of the extension.  I think that it should contain advice for
> >implementors that will make use of the identifier as well as advice for the
> >
> >Assigner Authority.  For example, the Social Security Administration would
> >be such an authority in the US, and they assign nine digit
> >indentifiers.  Are 123-45-6789 and 123456789 the same?
> >(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53DEIU25489 for ietf-pkix-bks; Mon, 3 Jun 2002 06:14:18 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g53DEGg25483 for <[e-mail]>; Mon, 3 Jun 2002 06:14:16 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Jun 2002 13:12:15 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA11482 for <[e-mail]>; Mon, 3 Jun 2002 09:14:17 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g53DCL002722 for <[e-mail]>; Mon, 3 Jun 2002 09:12:21 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLJLNK>; Mon, 3 Jun 2002 09:14:15 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLJLNJ; Mon, 3 Jun 2002 09:14:11 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 03 Jun 2002 09:14:04 -0400
Subject: Re: WG Last Call: Permanent Identifier
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

One of the reasons that has been provided by the advocates of the perm id 
is that DNs are not unique.  I am not one of these advocates.  I do think 
that they should explain why one situation is acceptable and the other is 
not or they should remove the capability that raises the question.

Russ

At 01:09 AM 6/3/2002 -0400, Tom Gindin wrote:

>       Russ:
>
>       I am not really convinced by point 3 of your technical comments.  The
>point of the draft is that DN's are not sufficiently unique for
>individuals.  This argument can be extended to organizations in general,
>but organizations operating CA's are not all or even most organizations.
>In any event, so many general PKI features break if CA's have duplicate
>DN's, including CRL location and CMS signatures (the serial number/issuer
>combination), that getting this particular feature to work in an
>environment where CA's have such DN's is little help.
>
>             Tom Gindin
>
>"Housley, Russ" <[e-mail]>@mail.imc.org on 05/24/2002
>05:31:03 PM
>
>Sent by:    [e-mail]
>
>
>To:    [e-mail]
>cc:
>Subject:    Re: WG Last Call: Permanent Identifier
>
>
>
>I have several comments on the Permanent Identifier Draft.  I have divided
>them between technical and editorial.
>
>TECHNICAL
>
>1.  The OID value { id-on 2 } has already been assigned for another
>purpose.  Please get fresh one.
>
>2.  It is my understanding that international URIs can be encoded as
>IA5String.  This was one of the last issues raised in the development of
>RFC 3280.
>
>3.  I do not understand how the identifierType can be optional.  The whole
>point of this draft is that distinguished names are not sufficiently
>unique.  (I am not trying to reopen this debate; it has been debated at too
>
>great a length already.)  If this is the case, then it would follow that
>two CAs could have the same distinguished name.  If two such CAs both
>include the proposed extension, then there will be undetectable
>collisions.  The resolution seem to be clear.  Make the identifierType
>mandatory.
>
>4.  The Security Considerations section is pretty weak.  It mostly restated
>
>the purpose of the extension.  I think that it should contain advice for
>implementors that will make use of the identifier as well as advice for the
>
>Assigner Authority.  For example, the Social Security Administration would
>be such an authority in the US, and they assign nine digit
>indentifiers.  Are 123-45-6789 and 123456789 the same?
>(snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53Cg3s21404 for ietf-pkix-bks; Mon, 3 Jun 2002 05:42:03 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Cg1g21398 for <[e-mail]>; Mon, 3 Jun 2002 05:42:02 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA15676; Mon, 3 Jun 2002 14:45:19 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060314411903:335 ; Mon, 3 Jun 2002 14:41:19 +0200 
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 14:41:30 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Juergen Brauckmann <[e-mail]>
CC: [e-mail], Pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 14:41:19, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 14:41:50, Serialize complete at 03/06/2002 14:41:50
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen,
 
> Hi Denis.
 
> Denis Pinkas wrote:

>  > COMMENT 2
> >
> > It seems difficult to be able to take benefit of a warranty without proving
> > that there is a real damage. However, this would imply to disclose the
> > details of the transaction or the details of the damage. This is conflicting
> > with privacy considerations.
> 
> Why should it be a privacy problem? In paper-world you are already
> forced to disclose details on your damage if you want to get a refund
> from an insurance. If you want money, you have to tell why.

Not necessarilly. I have to tell how much. A good example is a payment
guaranted by a smartcard. An inquiry is made for a certain amount of money
and the warranty is granted for that amount. You do not have to tell which
goods have been purchased.

> Why is it necessary to object against this procedure when it is about
> electronic transactions?

See above.

> > Another approach would be to obtain a warranty from a server to which only
> > the amount that is wished to be guaranteed would be disclosed. A signed
> > warranty would then be given.
> 
> How can a warranty server solve the problem that someone is forced to
> tell details about transactions if he wants to take benefit of a
> warranty?

The amount can be guaranted for a given date, irrespective of the nature of
the goods or the service being purchased.

Denis

> 
> Regards,
>    Juergen


Received: by above.proper.com (8.11.6/8.11.3) id g53Ce4Z21180 for ietf-pkix-bks; Mon, 3 Jun 2002 05:40:04 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Ce2g21173 for <[e-mail]>; Mon, 3 Jun 2002 05:40:02 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA17926; Mon, 3 Jun 2002 14:43:26 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060314392471:334 ; Mon, 3 Jun 2002 14:39:24 +0200 
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 14:39:36 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Phil Griffin <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Permanent Identifier
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 14:39:24, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 14:39:57, Serialize complete at 03/06/2002 14:39:57
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phil,

> <snip>
> > 4.  The Security Considerations section is pretty weak.  It mostly
> > restated the purpose of the extension.  I think that it should
> > contain advice for implementors that will make use of the identifier
> > as well as advice for the
> >
> > Assigner Authority.  For example, the Social Security Administration
> > would be such an authority in the US, and they assign nine digit
> > indentifiers.  Are 123-45-6789 and 123456789 the same?
> > (snip)
 
> One way to represent a series of integers efficiently is to
> use the RELATIVE-OID type:
> 
>    SocialSecurity  ::=  RELATIVE-OID
> 
>    number  SocialSecurity  ::=  { 233  21  1022 }
> 
>    number ::= <SocialSecurity> 233.21.1022 </SocialSecurity>

This is not the direction we are planning to take. We need to be able to
accept spaces between the digits, we do not want to impose punctuation
marks. So we need loose matching rules where all control characters, spaces,
and punctuation marks can be removed; and then where the values are
compared using CaseIgnoreMatch.

This is this sort of wording that Tom and myself are planning to add to the
draft.

Denis
 
> This requires only one tag octet, and the code to implement
> this type is nearly identical to that for OBJECT IDENTIFIER -
> the same minus the restriction on the sets of values and the
> merging of the first two nodes.
> 
> This example value BER encodes for transfer in only five octets,
> and XER encodes in 44 octets. The main drawback is that it requires
> use of ASN.1 notation from this century ;-)
> 
> Phil


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53AvxP15125 for ietf-pkix-bks; Mon, 3 Jun 2002 03:57:59 -0700 (PDT)
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Avvg15121 for <[e-mail]>; Mon, 3 Jun 2002 03:57:58 -0700 (PDT)
Received: from user-2ivf2il.dialup.mindspring.com ([165.247.138.85] helo=asn-1.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 17EpX9-0007tq-00 for [e-mail]; Mon, 03 Jun 2002 06:57:55 -0400
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 06:58:05 -0400
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: WG Last Call: Permanent Identifier
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<snip> 
> 4.  The Security Considerations section is pretty weak.  It mostly 
> restated the purpose of the extension.  I think that it should 
> contain advice for implementors that will make use of the identifier
> as well as advice for the
> 
> Assigner Authority.  For example, the Social Security Administration
> would be such an authority in the US, and they assign nine digit
> indentifiers.  Are 123-45-6789 and 123456789 the same?
> (snip)

One way to represent a series of integers efficiently is to
use the RELATIVE-OID type:

   SocialSecurity  ::=  RELATIVE-OID

   number  SocialSecurity  ::=  { 233  21  1022 }

   number ::= <SocialSecurity> 233.21.1022 </SocialSecurity>

This requires only one tag octet, and the code to implement
this type is nearly identical to that for OBJECT IDENTIFIER -
the same minus the restriction on the sets of values and the
merging of the first two nodes. 

This example value BER encodes for transfer in only five octets,
and XER encodes in 44 octets. The main drawback is that it requires
use of ASN.1 notation from this century ;-)

Phil


Received: by above.proper.com (8.11.6/8.11.3) id g53ANwb13346 for ietf-pkix-bks; Mon, 3 Jun 2002 03:23:58 -0700 (PDT)
Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53ANvg13342 for <[e-mail]>; Mon, 3 Jun 2002 03:23:57 -0700 (PDT)
Received: (from root@localhost) by mystic1.trustcenter.de (8.10.2+Sun/8.10.2) id g53AMF124030; Mon, 3 Jun 2002 12:22:15 +0200 (MEST)
Received: from venus.trustcenter.de(192.168.200.233) by mystic1.trustcenter.de via csmap (V6.0) id srcAAAjPaO7U; Mon, 3 Jun 02 12:22:14 +0200
Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id g53AMXQ16916; Mon, 3 Jun 2002 12:22:33 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 12:22:33 +0200
From: Juergen Brauckmann <[e-mail]>
Organization: TC TrustCenter AG
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail], Pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis.

Denis Pinkas wrote:
 > COMMENT 2
> 
> It seems difficult to be able to take benefit of a warranty without proving
> that there is a real damage. However, this would imply to disclose the
> details of the transaction or the details of the damage. This is conflicting
> with privacy considerations.

Why should it be a privacy problem? In paper-world you are already
forced to disclose details on your damage if you want to get a refund
from an insurance. If you want money, you have to tell why.

Why is it necessary to object against this procedure when it is about
electronic transactions?

> Another approach would be to obtain a warranty from a server to which only
> the amount that is wished to be guaranteed would be disclosed. A signed
> warranty would then be given.

How can a warranty server solve the problem that someone is forced to
tell details about transactions if he wants to take benefit of a
warranty?
 
Regards,
   Juergen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g539bup07683 for ietf-pkix-bks; Mon, 3 Jun 2002 02:37:56 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g539btg07676 for <[e-mail]>; Mon, 3 Jun 2002 02:37:55 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA15358; Mon, 3 Jun 2002 11:41:22 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060311374138:298 ; Mon, 3 Jun 2002 11:37:41 +0200 
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 11:37:53 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Haaino Beljaars <[e-mail]>
CC: [e-mail]
Subject: Re: Validation
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 11:37:41, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 11:37:52, Serialize complete at 03/06/2002 11:37:52
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi,
 
> What should I do, as an end-user, to 'validate' an (end-entity) certificate?
> Is it enough to check the certificate path on (delta-)CRL,OCSP? Or should I do more: for example check to repository and look whether or not the certificate was ever issued? Should I check the fingerprint of the root CA against a published fingerprint?

The full details are provided in RFC 3280:

   6.1  Basic Path Validation . . . . . . . . . . . . . . . . .  63
   6.2  Extending Path Validation . . . . . . . . . . . . . . .  80

There is no "more" to do.

How the root keys are determined is local matter. Using a fingerprint is 
one possibility.

Denis

 
> Thanks,
> Haaino


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g539TCf06763 for ietf-pkix-bks; Mon, 3 Jun 2002 02:29:12 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g539TAg06759 for <[e-mail]>; Mon, 3 Jun 2002 02:29:10 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA14454; Mon, 3 Jun 2002 11:32:17 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002060311281578:294 ; Mon, 3 Jun 2002 11:28:15 +0200 
Message-ID: <[e-mail]>
Date: Mon, 03 Jun 2002 11:28:27 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: Pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-warranty-extn-01
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 11:28:15, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/06/2002 11:28:48, Serialize complete at 03/06/2002 11:28:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alice,

Thank you for inquiring. The new draft is still not adequate.

COMMENT 1

It is very questionable whether the implicit insurance model is appropriate.
The text says: " Usually, the subscriber pays for the extended warranty
coverage". The major issue is whether a subscriber pays a flat price that is
included in the price of the certificate or a price that is per insured
transaction which would be paid by the relying party. Implicitly the first
choice is being made but this choice is questionable.

COMMENT 2

It seems difficult to be able to take benefit of a warranty without proving
that there is a real damage. However, this would imply to disclose the
details of the transaction or the details of the damage. This is conflicting 
with privacy considerations.

End-users may be willing to disclose the amount of transaction that has been
guaranteed, but without providing the details. This does not seem possible
with that approach.

Another approach would be to obtain a warranty from a server to which only
the amount that is wished to be guaranteed would be disclosed. A signed
warranty would then be given.

COMMENT 3

WarrantyData contains:

       tcURL                TermsAndConditionsURL OPTIONAL  

"WarrantyData is defined as a URL that points to the terms and conditions of
the warranty.  The URL is provided using the TermsAndConditionsURL type,
which is an IA5 string."

In this document the warranty is said to be given by the CA. RFC 3280
states:

"   The CPS Pointer qualifier contains a pointer to a Certification
    Practice Statement (CPS) published by the CA.  The pointer is in 
    the form of a URI."

The Certification Practice Statement contains all the conditions, including
the terms and conditions of the warranty. So this extension is not needed as
soon as the CPS Pointer qualifier is being used.

However, these terms and conditions of the warranty are only human being
understandable, but not machine processable and this means that applications
will not be able to know how to take benefit of the terms and conditions of
the warranty. In particular is there a need to prove that the revocation
status of the certificate has been checked ? When this is the case, the
application should know whether an OCSP check, a DPV check or another kind
of check is needed. There is no information to be able to know this.

COMMENT 4

Normally claims about a warranty have to be presented a few days or weeks
after the damage. Insurance company do not take into account claims that are
too old. There is no indication for that time period in the document.

Would such a time period be indicated, the next point would be to make sure
that the damage really took place at that time. Going in that direction
would once again make necessary to disclose the details of the transaction
and also to place in the time scale that transaction. The use of a
time-stamp tokens would solve this last problem, but there would be a much
simpler solution: the use of a on-line warranty server. The date included in
the signed warranty would be the date of the transaction.

COMMENT 5

The text says:

"Once the value of fulfilled claims reaches the warranty currency amount,
then no further claim will be fulfilled. "

This is nice for the insurance company, but not for end-users !

This is not going to work nicely, unless on-line warranty server is being
used. In such a case the on-line warranty server could compute in real-time
the aggregated amount and then stop to offer the warranty when this amount
is being reached.

COMMENT 6

In the comments on the previous version, it has been mentioned that a
similar extension has already been defined in ETSI TS 101 862. This
extension takes advantage of the qcStatement defined in RFC 3039 and
specifies a statement regarding limits on the value of transactions.

This optional statement contains:

- an identifier of this statement (represented by an OID);
- a monetary value expressing the limit on the value of transactions.

This statement is a statement by the issuer which imposes a limitation on
the value of transaction for which this certificate can be used to the
specified amount (MonetaryValue), according to the Directive 1999/93/EC of
the European Parliament and of the Council of 13 December 1999 on a
Community framework for electronic signatures, as implemented in the law of
the country specified in the issuer field of this certificate.

In fact the Directive is requiring (in Annex I) a field to specify "limits
on the value of transactions for which the certificate can be used, if
applicable". The reason for that field is specified in these terms:

"The certification-service-provider shall not be liable for damage arising
from use of a qualified certificate which exceeds the limitations placed on
it".

The text does *not* say: "The certification-service-provider *shall be*
liable for damage arising from use of a qualified certificate which *meets*
the limitations placed on it".

So it is more a *disclaimer of warranty* extension rather than a warranty.
If the proposal was for a warranty disclaimer extension, then it would be
more appropriate. 

A much better title and abstract would be:

         Warranty Disclaimer Certificate Extension

  This document describes a certificate extension to explicitly state
  a warranty disclaimer from the Certificate Authority (CA) for a 
  certificate containing the extension.

COMMENT 7

The security consideration section states:

" The procedures and practices employed by the CA MUST ensure that the
  correct values for the warranty are inserted in each certificate that is
  issued."

Since this extension is optional, the MUST statement is not appropriate.   

CONCLUSION

The current proposal is missing to address several aspects which are even
not being discussed in the security considerations section. The first
impression is that this field is useful, but once a closer look is given,
the warranty is really a fake one. Of course it is well known that
warranties are to be well advertised by insurance companies, but never
granted because you have not seen a small sentence at the back of the
contract in small gray characters on a gray background.

Such "small" sentences are:

 - the conditions to get advantage of the warranty 
   (i.e. what needs to be presented, like transaction details and
   certificate status check),

 - the time before which the claims have to be presented.

A major issue which is not mentioned at all is the problem of the privacy of
the transaction.

As indicated above, there are many dangers to include such an extension and
such dangers are not advertised, even in the security considerations
section. When they will be, it will then be questionable whether the
advantages of such an extension will be worth the disadvantages.

Should this extension be maintained, it is proposed to transform it into a 
Warranty Disclaimer Certificate Extension. This would indicate the
transaction amount above which there is no warranty at all.

Denis

 
> Hi folks,
> The revised draft on certificate warranty extension was issued to the list
> last week, addressing the first round of comments, and there have been no
> comments back.  Is everyone satisfied with it now, with the revisions?  I
> know some were not thrilled with the I-D but decided they could live with
> it, given it is optional.  Some also thought it was more a legal matter -
> The I-D was also posted to the ABA list, and received few comments; these
> too have been taken into consideration.
> 
> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     [phone]
> Cell:         613-291-0331


Received: by above.proper.com (8.11.6/8.11.3) id g538Afl26427 for ietf-pkix-bks; Mon, 3 Jun 2002 01:10:41 -0700 (PDT)
Received: from ms01.dh02.ictu.nl ([193.173.47.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g538Aeg26423 for <[e-mail]>; Mon, 3 Jun 2002 01:10:40 -0700 (PDT)
Received: from gw01.dh01.ictu.nl (unverified) by ms01.dh02.ictu.nl (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 3 Jun 2002 09:54:50 +0200
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Validation
Date: Mon, 3 Jun 2002 10:13:32 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Validation
Thread-Index: AcIK1o0SQ/j3fcSHR/CumWFossMC+g==
From: "Haaino Beljaars" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g538Aeg26424
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

What should I do, as an end-user, to 'validate' an (end-entity) certificate?
Is it enough to check the certificate path on (delta-)CRL,OCSP? Or should I do more: for example check to repository and look whether or not the certificate was ever issued? Should I check the fingerprint of the root CA against a published fingerprint?

Thanks,
Haaino


Received: by above.proper.com (8.11.6/8.11.3) id g535Nu206777 for ietf-pkix-bks; Sun, 2 Jun 2002 22:23:56 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g535Nsg06773 for <[e-mail]>; Sun, 2 Jun 2002 22:23:54 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g535Nng5042218; Mon, 3 Jun 2002 01:23:49 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g535NmB102370; Mon, 3 Jun 2002 01:23:48 -0400
Importance: Normal
Sensitivity: 
Subject: Re: WG Last Call: Permanent Identifier
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 3 Jun 2002 01:09:48 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/03/2002 01:23:47 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Russ:

      I am not really convinced by point 3 of your technical comments.  The
point of the draft is that DN's are not sufficiently unique for
individuals.  This argument can be extended to organizations in general,
but organizations operating CA's are not all or even most organizations.
In any event, so many general PKI features break if CA's have duplicate
DN's, including CRL location and CMS signatures (the serial number/issuer
combination), that getting this particular feature to work in an
environment where CA's have such DN's is little help.

            Tom Gindin

"Housley, Russ" <[e-mail]>@mail.imc.org on 05/24/2002
05:31:03 PM

Sent by:    [e-mail]


To:    [e-mail]
cc:
Subject:    Re: WG Last Call: Permanent Identifier



I have several comments on the Permanent Identifier Draft.  I have divided
them between technical and editorial.

TECHNICAL

1.  The OID value { id-on 2 } has already been assigned for another
purpose.  Please get fresh one.

2.  It is my understanding that international URIs can be encoded as
IA5String.  This was one of the last issues raised in the development of
RFC 3280.

3.  I do not understand how the identifierType can be optional.  The whole
point of this draft is that distinguished names are not sufficiently
unique.  (I am not trying to reopen this debate; it has been debated at too

great a length already.)  If this is the case, then it would follow that
two CAs could have the same distinguished name.  If two such CAs both
include the proposed extension, then there will be undetectable
collisions.  The resolution seem to be clear.  Make the identifierType
mandatory.

4.  The Security Considerations section is pretty weak.  It mostly restated

the purpose of the extension.  I think that it should contain advice for
implementors that will make use of the identifier as well as advice for the

Assigner Authority.  For example, the Social Security Administration would
be such an authority in the US, and they assign nine digit
indentifiers.  Are 123-45-6789 and 123456789 the same?
(snip)