Re: SV: Permanent identifiers in QC

[[e-mail]]

     I take your point about duplicating the serial number using the
two-name form I proposed for id-qcs-identifierAssignmentAuthority, and I
hereby withdraw that suggestion.
     However, assuming that adding name information in the qcStatements
extension contradicts the purpose of that extension, I still do not see why
the one-name version of id-qcs-identifierAssignmentAuthority, in which the
only name in the extension is the name of the identifier assignment
authority, contradicts the purpose of the extension.  The draft's current
definition says about the name component: "The NameRegistrationAuthorities
component, if present, SHALL contain a name of one or more name
registration authorities, responsible for registration of attributes or
names associated with the subject."  Why does the assigner of a serial
number not fit into this definition of a registration authority?
     Equally, id-qcs-nationalIdentifier and id-qcs-CALocal define the
semantics of an existing attribute in a DN within the certificate.  How
does that contradict the statement that a semantics ID "may define
semantics for all, or for a subgroup of all present attributes and/or
names"?  Perhaps it would be more in keeping with the spirit of the profile
if there were two different OID's for each of these three semantics, one to
interpret subject name serial numbers and one to interpret subject
alternate name serial numbers, but that is not a reason not to have the
feature available.

          Tom Gindin


"Stefan Santesson" <[e-mail]> on 03/31/2000 06:45:54 AM

To:   Tom Gindin/Watson/IBM@IBMUS, "'Stefan Santesson'"
      <[e-mail]>
cc:   <[e-mail]>
Subject:  SV: Permanent identifiers in QC



Tom,

Using this extension to contain subject name information would break the
intent of this extension.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [e-mail] [mailto:[e-mail]]
> Skickat: den 31 mars 2000 09:10
> Till: Stefan Santesson
> Kopia: [e-mail]
> Ämne: Re: Permanent identifiers in QC
>
>
>      I have a counter-proposal.  Given the profile defined for
> serialNumber, and the definition of SemanticsInformation in
> draft section
> 3.2.5.1, a semanticsIdentifier known as
> id-qcs-identifierAssignmentAuthority should be assigned with
> the following
> rules of interpretation: either one or two name registration
> authorities
> must be present, and the first one present shall be interpreted as the
> authority governing the name space, while the second
> (optional) one may
> contain the serial number or other unique identifier; if
> there is only one
> name registration authority present, the unique identifier is
> assumed to be
> the serial number attribute of the subject name if there is a
> serial number
> attribute in it, and the first serial number attribute
> encountered in the
> subject alternate name if there is none in the subject name.  Another
> semanticsIdentifier known as id-qcs-CALocal should be
> assigned to identify
> serial numbers assigned locally within the CA.  Optionally, a
> semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> assigned with the rule that when one searches for the serial
> number in the
> subject name and subject alternate name in the same way as
> for identifier
> assignment authorities with only one name registration authority, the
> serial number shall be interpreted as being assigned by the
> country given
> in the DN where the serial number is found.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[e-mail]> on 03/30/2000 01:49:44 AM
>
> To:   <[e-mail]>
> cc:
> Subject:  Permanent identifiers in QC
>
>
>
> The PKIX meeting in Adelaide raised only 1 issue related to
> the QC draft.
>
> This issue is whether we should include a new name form in the
> subjectAltName extension holding  a permanent identifier.
>
> The permanent identifier would then be a name of the subject,
> unique within
> the issuers domain, that is not reused over time for another subject.
>
> The reason to include such a name form would be that the use of
> serialNumber in DN, or directoryName in subjectAltName
> extension, does not
> explicitly define this property by itself, unless seen in the
> light of a
> defined policy etc.
>
> Chair Stephen Kent decided that the decision whether or not
> to include this
> name form in QC should be taken to the list.
>
> My observation in regards to this is:
>
> 1) Adding this name form would add confusion to the QC
> specification since
> it would overlap use of serialNumber in the DN.
>
> [Tom Gindin]   Why would this cause confusion if the name
> form itself had
> the same syntax as a DN, and the identity were in the serialNumber
> attribute of that name?
>
> 2) Use of DN attributes covers all needs related to
> identification of the
> subject, and that's all we need to support electronic
> signatures, at least
> as seen from the EU-directive. And as far I know, this goes
> for any other
> legal system.
>
> [Tom Gindin]   This does not cover the joint specification of
> an ID and an
> assignment authority.  A single ID field with quasi-arbitrary values
> similar to a serial number has meaning primarily within the
> scope of its
> assignment authority.
>
> 3) Use of DN in combination with either implicit knowledge, use of
> Directory name in the subjectAltname ext, use of a related policy
> identifier or use of information in the qcStatements
> extension also provide
> support for use of permanent identifiers identified as such.
>
> [Tom Gindin]   No rule for implicit knowledge which would permit an
> arbitrary RP to recognize a permanent identifier and its assignment
> authority within a DN (whether subject name or alt name) has yet been
> received with favor.  However, it should be possible to do
> this using the
> semanticsIdentifier.
>
> 4) In each and every case raised in favor of this new name form, the
> benefit relates to access control rather than electronic signatures.
>
> [Tom Gindin]   Allowing organizations to assign permanent
> identifiers of
> this type (most usually, but not necesarily, to employees)
> has roughly the
> same impact on signatures as on access control.  If it is
> assumed that the
> identity number is assigned by a governmental or quasi-governmental
> authority, then the serial number is sufficient because my
> above arguments
> for assignment authority become irrelevant.
>
> 5) This is a new input to the discussion, which before
> adoption must be
> reviewed by the community over some time.
>
> [Tom Gindin]   It has been under discussion for months.
>
> Observation 4 makes this whole discussion outside the scope
> of QC and in
> combination with the other observations, I would request that
> the QC is
> moved forward to proposed standard without this new name form.
>
> [Tom Gindin]   If QC requires that the serial number be
> assigned either by
> a governmental or quasi-governmental authority as a permanent
> identifier or
> by the CA as a tiebreaker, and that the certificate itself contain
> somewhere an indicator of whether the name is a permanent
> identifier or a
> tiebreaker, then this name form would not be relevant to
> QC's.  Otherwise
> it would.
>
> If PKIX at a later stage would find that a permanent
> identifier solution,
> as discussed here, is of general value, then this can be
> moved forward as a
> separate item. At that time we would also know if it should
> be merged with
> RFC 2459 or the QC profile, if merged at all.
>
>
>
> /Stefan
>







Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24991 for <[e-mail]>; Fri, 31 Mar 2000 15:42:09 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA84204; Fri, 31 Mar 2000 18:42:50 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id SAA235476; Fri, 31 Mar 2000 18:44:15 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568B3.00826481 ; Fri, 31 Mar 2000 18:44:14 -0500
X-Lotus-FromDomain: IBMUS
To: "Stefan Santesson" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 31 Mar 2000 18:44:09 -0500
Subject: Re: SV: Permanent identifiers in QC
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA24992

     I take your point about duplicating the serial number using the
two-name form I proposed for id-qcs-identifierAssignmentAuthority, and I
hereby withdraw that suggestion.
     However, assuming that adding name information in the qcStatements
extension contradicts the purpose of that extension, I still do not see why
the one-name version of id-qcs-identifierAssignmentAuthority, in which the
only name in the extension is the name of the identifier assignment
authority, contradicts the purpose of the extension.  The draft's current
definition says about the name component: "The NameRegistrationAuthorities
component, if present, SHALL contain a name of one or more name
registration authorities, responsible for registration of attributes or
names associated with the subject."  Why does the assigner of a serial
number not fit into this definition of a registration authority?
     Equally, id-qcs-nationalIdentifier and id-qcs-CALocal define the
semantics of an existing attribute in a DN within the certificate.  How
does that contradict the statement that a semantics ID "may define
semantics for all, or for a subgroup of all present attributes and/or
names"?  Perhaps it would be more in keeping with the spirit of the profile
if there were two different OID's for each of these three semantics, one to
interpret subject name serial numbers and one to interpret subject
alternate name serial numbers, but that is not a reason not to have the
feature available.

          Tom Gindin


"Stefan Santesson" <[e-mail]> on 03/31/2000 06:45:54 AM

To:   Tom Gindin/Watson/IBM@IBMUS, "'Stefan Santesson'"
      <[e-mail]>
cc:   <[e-mail]>
Subject:  SV: Permanent identifiers in QC



Tom,

Using this extension to contain subject name information would break the
intent of this extension.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [e-mail] [mailto:[e-mail]]
> Skickat: den 31 mars 2000 09:10
> Till: Stefan Santesson
> Kopia: [e-mail]
> Ämne: Re: Permanent identifiers in QC
>
>
>      I have a counter-proposal.  Given the profile defined for
> serialNumber, and the definition of SemanticsInformation in
> draft section
> 3.2.5.1, a semanticsIdentifier known as
> id-qcs-identifierAssignmentAuthority should be assigned with
> the following
> rules of interpretation: either one or two name registration
> authorities
> must be present, and the first one present shall be interpreted as the
> authority governing the name space, while the second
> (optional) one may
> contain the serial number or other unique identifier; if
> there is only one
> name registration authority present, the unique identifier is
> assumed to be
> the serial number attribute of the subject name if there is a
> serial number
> attribute in it, and the first serial number attribute
> encountered in the
> subject alternate name if there is none in the subject name.  Another
> semanticsIdentifier known as id-qcs-CALocal should be
> assigned to identify
> serial numbers assigned locally within the CA.  Optionally, a
> semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> assigned with the rule that when one searches for the serial
> number in the
> subject name and subject alternate name in the same way as
> for identifier
> assignment authorities with only one name registration authority, the
> serial number shall be interpreted as being assigned by the
> country given
> in the DN where the serial number is found.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[e-mail]> on 03/30/2000 01:49:44 AM
>
> To:   <[e-mail]>
> cc:
> Subject:  Permanent identifiers in QC
>
>
>
> The PKIX meeting in Adelaide raised only 1 issue related to
> the QC draft.
>
> This issue is whether we should include a new name form in the
> subjectAltName extension holding  a permanent identifier.
>
> The permanent identifier would then be a name of the subject,
> unique within
> the issuers domain, that is not reused over time for another subject.
>
> The reason to include such a name form would be that the use of
> serialNumber in DN, or directoryName in subjectAltName
> extension, does not
> explicitly define this property by itself, unless seen in the
> light of a
> defined policy etc.
>
> Chair Stephen Kent decided that the decision whether or not
> to include this
> name form in QC should be taken to the list.
>
> My observation in regards to this is:
>
> 1) Adding this name form would add confusion to the QC
> specification since
> it would overlap use of serialNumber in the DN.
>
> [Tom Gindin]   Why would this cause confusion if the name
> form itself had
> the same syntax as a DN, and the identity were in the serialNumber
> attribute of that name?
>
> 2) Use of DN attributes covers all needs related to
> identification of the
> subject, and that's all we need to support electronic
> signatures, at least
> as seen from the EU-directive. And as far I know, this goes
> for any other
> legal system.
>
> [Tom Gindin]   This does not cover the joint specification of
> an ID and an
> assignment authority.  A single ID field with quasi-arbitrary values
> similar to a serial number has meaning primarily within the
> scope of its
> assignment authority.
>
> 3) Use of DN in combination with either implicit knowledge, use of
> Directory name in the subjectAltname ext, use of a related policy
> identifier or use of information in the qcStatements
> extension also provide
> support for use of permanent identifiers identified as such.
>
> [Tom Gindin]   No rule for implicit knowledge which would permit an
> arbitrary RP to recognize a permanent identifier and its assignment
> authority within a DN (whether subject name or alt name) has yet been
> received with favor.  However, it should be possible to do
> this using the
> semanticsIdentifier.
>
> 4) In each and every case raised in favor of this new name form, the
> benefit relates to access control rather than electronic signatures.
>
> [Tom Gindin]   Allowing organizations to assign permanent
> identifiers of
> this type (most usually, but not necesarily, to employees)
> has roughly the
> same impact on signatures as on access control.  If it is
> assumed that the
> identity number is assigned by a governmental or quasi-governmental
> authority, then the serial number is sufficient because my
> above arguments
> for assignment authority become irrelevant.
>
> 5) This is a new input to the discussion, which before
> adoption must be
> reviewed by the community over some time.
>
> [Tom Gindin]   It has been under discussion for months.
>
> Observation 4 makes this whole discussion outside the scope
> of QC and in
> combination with the other observations, I would request that
> the QC is
> moved forward to proposed standard without this new name form.
>
> [Tom Gindin]   If QC requires that the serial number be
> assigned either by
> a governmental or quasi-governmental authority as a permanent
> identifier or
> by the CA as a tiebreaker, and that the certificate itself contain
> somewhere an indicator of whether the name is a permanent
> identifier or a
> tiebreaker, then this name form would not be relevant to
> QC's.  Otherwise
> it would.
>
> If PKIX at a later stage would find that a permanent
> identifier solution,
> as discussed here, is of general value, then this can be
> moved forward as a
> separate item. At that time we would also know if it should
> be merged with
> RFC 2459 or the QC profile, if merged at all.
>
>
>
> /Stefan
>






Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19944 for <[e-mail]>; Fri, 31 Mar 2000 09:41:10 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT8MJ2>; Fri, 31 Mar 2000 12:43:18 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'500 list'" <[e-mail]>
Cc: "'Blake Greenlee'" <[e-mail]>, "'Hoyt Kesterson'" <[e-mail]>
Subject: RE: X.509 approved - see ITU-T press release
Date: Fri, 31 Mar 2000 12:43:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

FYI:

http://www.itu.int/ITU-T/itu-t_news/sg7_x509_press.htm


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17362 for <[e-mail]>; Fri, 31 Mar 2000 07:25:29 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT8KXM>; Fri, 31 Mar 2000 10:27:37 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Blake Greenlee'" <[e-mail]>, "'Hoyt Kesterson'" <[e-mail]>
Subject: Mini report on X.509 mtg last week
Date: Fri, 31 Mar 2000 10:27:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

As many of you know, the part of ITU-T that X.509 is under met last week.
The editorial corrections (most of them correcting invalid asn.1) and defect
resolutions were all accepted and a few more editorial fixes identified
(e.g. pointers to deleted annexes etc.). The corrected revised
Recommendation X.509 was sent to ITU yesterday. Formal approval is expected
today by ITU-T. Pre-publication is expected by ITU within a couple of weeks,
so this will formally be known as X.509 (2000). You probably remember that
this includes a complete restructuring of the content of 509, hopefully
making it much better organized and easier to read or find items of
interest. Note also that the title has been changed from "Authentication
Framework" to "Public-Key and Attribute Certificate Frameworks". 

Specifc items some of you may be interested in:

- the ASN.1 syntax of the targeting information extension was modified. This
was done 
  in close collaboration with the editors of the PKIX profile of X.509 for
attribute 
  certs. It seems that while both had the extension (and the intention was
always for 
  aligned syntax) they had managed to diverge. It is my understanding that
PKIX syntax 
  is also being modified and we have a single syntax that meets all stated
requirements.

- the ASN.1 syntax for attribute descriptor extension was modified. The
syntax that was 
  in the earlier draft was invalid asn.1 and didn't actually do what was
intended
  anyway.

- the ASN.1 of the AttCertIssuer construct was modified. While it was always
the intent
  to maintain backward compatibility with v1 attribute certificate format,
an error had 
  crept in and we needed to fix that to retain backward compatibility.

- some precision was added to the ASN.1 for the crossCertificatePair
construct (WITH 
  COMPONENTS statements) to ensure that something be present in the
attribute.

- some clarifications were added, including:
  a)interpretation of the subjectKeyIDRange DER
  b) recommending that if no certs have been revoked,the revokedCertificates

     parameter be omitted from a CRL 
     (rather than being included with an empty SEQUENCE)
  c) clarifying that attribute certificates do not ALWAYS point to a
specific 
     public-key certificate
  d) clarifying the actions to be taken with user notices in attribute
certs.

The changes made in the 2000 text as a result of Defect Reports registered
against 
the 1997 edition include:

- The DTCs that were balloted by ISO last year (1,3,4,5 and 7) are all
reflected 
  in this text. There were some comments received from US, Canada and Japan.
All 
  comments were accepted and are reflected as well. If anyone wants to see
the 
  DTCs themselves, Hoyt still has them available on his server. Note that
although 
  the comment from Japan was accepted (resulting in rejection of Defect
Report 219 
  against the 97 edition) the change proposed in the Defect Report was
accepted 
  for the 2000 text and is reflected in this document. 

- A couple of new defect reports have been registered against the 97 edition
(DR
  226, 227 and 240). These DRs and the associated DTCs are either available
now 
  or will be shortly on Hoyt's server. One deals with deletion of a sentence
that 
  used to require all cert certificate production to occur offline, another
is 
  with respect to the two mechanisms for authority key identifiers and the
3rd 
  is a number of typographical corrections to the ASN.1 in Annex A. The 3rd
is
  irrelevant for the 2000 edition, but the first two are relevant. The
offending 
  sentence (about offline production only) was deleted. The authority key
identifier 
  issue was addressed by adding text that clarifies that keyIdentifier can
be used 
  to select CA certificates during path construction while
authorityCertIssuer, 
  authoritySerialNumber pair can only be used to provide preference to one
certificate
  over others during path construction. Rather than deprecate the latter
mechanism 
  in X.509 itself, it was agreed that this was better left for profiling
groups to 
  determine.

X.509 requirements that resulted in changes to other Recommendations:

- In response to the liaison statement received from IETF, the text that
describes
  serialNumber in X.520 was modified with "device" being changed to "object"
in 
  the Draft Amendment to be approved today by ITU-T for the new edition. A
Defect 
  Report was also registered (DR 241) to make this same change retroactively
to the 
  1997 edition of X.520. This is included in a new DTC to be balloted.

- Because the definition of the crlDistributionPoints attribute was added
directly 
  to X.509, the duplicate definition is being deleted from X.521.  

This is, from the ITU perspective, the closure of the 2000 edition for
X.509. ISO still 
has the Final DAM ballot (a 2 month ballot with no technical comments
basically) to conduct. ITU-T will pre-publish the text very shortly, to be
followed by final publication following the ISO ballot. The final draft that
is available on Hoyt's server has been converted to North American paper
size. For those who haven't seen his email sent to PKIX and the directory
list, here are the pointers:
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraft.do
c

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraft.pd
f

I have the original A4 paper version and asked Hoyt to post that as well. If
anyone needs that version prior to Hoyt posting it, let me know and I can
email it to you. In terms of future work for X.509 itself, I'm hoping it
will be basically maintenance work only - always the potential for defect
reports I suppose :-( . The door has been left open, however, should any new
requirements emerge for X.509 itself as a result of the new work in many
other forums (e.g. should the WAP work require any 509 modifications). I
don't believe any specific items have been identified, but just in case ... 

Finally, I really want to thank EVERYONE who took the time to proof the
editors drafts. This really helped me catch a number of errors in the text
and reduce the number of 
future defect reports. Special thanks to those who ran the modules through
asn.1 compilers (Erik Andersen, Olivier Dubuisson, Phil Griffin and Sandy
Shaw), and to the editors of the PKIX attribute certificate profile for
catching a couple of "gotchas" (Steve Farrell and Russ Housley).

Any specific questions, feel free to send them by email directly to me.     

Sharon Boeyen
Entrust Technologies
[e-mail]


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17259 for <[e-mail]>; Fri, 31 Mar 2000 07:24:29 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT8KWY>; Fri, 31 Mar 2000 10:26:36 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>
Cc: PKIX Mailing List <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Establishing POP capabilities
Date: Fri, 31 Mar 2000 10:26:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Chris,

This may be a fair observation, but I honestly don't think that there's
quite the potential for problems that you're envisioning.  If we go through
the choices carefully, I think you'll see what I mean (and you can correct
me if I'm mistaken).

> RAVerified = {id-pkix-pop 1}
 
This one is not an end entity decision; the RA uses this if and only if it
has verified POP before forwarding the request on to the CA.  There's no
ambiguity here.

> SKPOP = {id-pkix-pop 2}
 
Again, no real ambiguity.  If you've got a signing key, use this method.

> EKPOPThisMessage = {id-pkix-pop 3}
 
For the "thisMessage" choice, there's no ambiguity here either.  It is an
end entity decision whether or not to give up its private key to the CA/RA
and, having received the key, how can the CA/RA possibly say it doesn't
support this?

> KAKPOPThisMessage = {id-pkix-pop 6}
 
(Same comment as for EKPOPThisMessage above.)

> KAKPOPThisMessageDHMac = {id-pkix-pop 7}
 
The EE can only use this method if (1) the CA has a DH cert available for
this purpose, and (2) the EE already has this cert.  Given that the CA has
such a cert, it can't claim that it doesn't support this method.  No
ambiguity.

> EKPOPEncryptedCert = {id-pkix-pop 4}
> EKPOPChallengeResp = {id-pkix-pop 5}
> KAKPOPEncryptedCert = {id-pkix-pop 8}
> KAKPOPChallengeResp = {id-pkix-pop 9}
> 
The only things left are the choice between EncryptedCert and
ChallengeResponse for EK and KAK.  Recall, however, that the EE picks one of
these (in the subsequentMessage field) in the request message.  The EE is
not doing POP at this point; it's simply saying which method it wants to
use.  Therefore, if the CA/RA comes back with a "badPOP" error, I would
contend that there is, again, no ambiguity.  The EE can simply re-request
with the other POP method chosen in subsequentMessage.

Note, however, that the spec encourages use of the EncryptedCert choice and,
furthermore, says that the challenge-response choice would typically be used
when an RA is involved and doing POP verification.  Therefore, I think that
the EE should be able to make an intelligent decision regarding what POP
method to choose in the request message.

Carlisle.


> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Friday, March 31, 2000 4:07 AM
> To: 	PKIX Mailing List
> Subject: 	Establishing POP capabilities
> 
> There does not currently seem to be any way for a client to establish
> which
> POP modes are supported which could cause problems.  For example, I may
> have
> developed client software that seeks to establish POP of an encryption key
> by engaging in the challenge-response.  However, the authors of the server
> software have quite reasonably decided not to implement this means of POP
> (as there are better methods available) but the client software has no
> means
> of finding this out, the certification request will fail as POP cannot be
> established and the server can only indicate the error by means of an
> ambiguous "badPOP" error code.
> 
> The POP modes supported by a server could be established in a general
> message, something like the following:
> 
> { SupportedPOPModes = {id-it 16}, SEQUENCE OF ObjectIdentifier }
> 
> The parameters would be an OID for each POP mode supported; the modes
> might
> be numbered as follows:
> 
> RAVerified = {id-pkix-pop 1}
> SKPOP = {id-pkix-pop 2}
> EKPOPThisMessage = {id-pkix-pop 3}
> EKPOPEncryptedCert = {id-pkix-pop 4}
> EKPOPChallengeResp = {id-pkix-pop 5}
> KAKPOPThisMessage = {id-pkix-pop 6}
> KAKPOPThisMessageDHMac = {id-pkix-pop 7}
> KAKPOPEncryptedCert = {id-pkix-pop 8}
> KAKPOPChallengeResp = {id-pkix-pop 9}
> 
> where {id-pkix-pop} = {id-pkix n} = {1 3 6 1 5 5 7 n}
> 
> Alternatively, the supported modes could be returned as bits in a BIT
> STRING.  Another possibility is to establish the preferred modes for an
> encryption key and a key agreement key.
> 
> What do people think?
> 
> Chris Williams,
> NetLexis Ltd.
> 


Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA16695 for <[e-mail]>; Fri, 31 Mar 2000 07:11:45 -0800 (PST)
From: [e-mail]
Received: 	id KAA24236; Fri, 31 Mar 2000 10:05:19 -0500
Received: by gateway id <HXFJB3RY>; Fri, 31 Mar 2000 10:17:42 -0500
Message-ID: <[e-mail]>
To: [e-mail]
Subject: unsubscribe
Date: Fri, 31 Mar 2000 10:17:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08767 for <[e-mail]>; Fri, 31 Mar 2000 04:21:39 -0800 (PST)
Received: from HYDRA ([195.198.186.85]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id OAA21015; Fri, 31 Mar 2000 14:26:46 +0200
Received: by HYDRA with Microsoft Mail id <01BF9B1B.6E39B080@HYDRA>; Fri, 31 Mar 2000 14:14:30 +0200
Message-ID: <01BF9B1B.6E39B080@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Permanent identifiers in QC
Date: Fri, 31 Mar 2000 14:14:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Tom,
regardless how this fits the QC spec.  I feel that you are touching the "Naming Domain"
issue which I have touted quite some time as an important information, but have been put down by Steve.

It would be nice to see someone elaborate a bit on ID-certificates, DNs and naming domains

Anders

----------
From:  [e-mail] [SMTP:[e-mail]]
Sent:  Friday, March 31, 2000 01:40
To:  Stefan Santesson
Cc:  [e-mail]
Subject:  Re: Permanent identifiers in QC

     I have a counter-proposal.  Given the profile defined for
serialNumber, and the definition of SemanticsInformation in draft section
3.2.5.1, a semanticsIdentifier known as
id-qcs-identifierAssignmentAuthority should be assigned with the following
rules of interpretation: either one or two name registration authorities
must be present, and the first one present shall be interpreted as the
authority governing the name space, while the second (optional) one may
contain the serial number or other unique identifier; if there is only one
name registration authority present, the unique identifier is assumed to be
the serial number attribute of the subject name if there is a serial number
attribute in it, and the first serial number attribute encountered in the
subject alternate name if there is none in the subject name.  Another
semanticsIdentifier known as id-qcs-CALocal should be assigned to identify
serial numbers assigned locally within the CA.  Optionally, a
semanticsIdentifier known as id-qcs-nationalIdentifier might also be
assigned with the rule that when one searches for the serial number in the
subject name and subject alternate name in the same way as for identifier
assignment authorities with only one name registration authority, the
serial number shall be interpreted as being assigned by the country given
in the DN where the serial number is found.

          Tom Gindin


"Stefan Santesson" <[e-mail]> on 03/30/2000 01:49:44 AM

To:   <[e-mail]>
cc:
Subject:  Permanent identifiers in QC



The PKIX meeting in Adelaide raised only 1 issue related to the QC draft.

This issue is whether we should include a new name form in the
subjectAltName extension holding  a permanent identifier.

The permanent identifier would then be a name of the subject, unique within
the issuers domain, that is not reused over time for another subject.

The reason to include such a name form would be that the use of
serialNumber in DN, or directoryName in subjectAltName extension, does not
explicitly define this property by itself, unless seen in the light of a
defined policy etc.

Chair Stephen Kent decided that the decision whether or not to include this
name form in QC should be taken to the list.

My observation in regards to this is:

1) Adding this name form would add confusion to the QC specification since
it would overlap use of serialNumber in the DN.

[Tom Gindin]   Why would this cause confusion if the name form itself had
the same syntax as a DN, and the identity were in the serialNumber
attribute of that name?

2) Use of DN attributes covers all needs related to identification of the
subject, and that's all we need to support electronic signatures, at least
as seen from the EU-directive. And as far I know, this goes for any other
legal system.

[Tom Gindin]   This does not cover the joint specification of an ID and an
assignment authority.  A single ID field with quasi-arbitrary values
similar to a serial number has meaning primarily within the scope of its
assignment authority.

3) Use of DN in combination with either implicit knowledge, use of
Directory name in the subjectAltname ext, use of a related policy
identifier or use of information in the qcStatements extension also provide
support for use of permanent identifiers identified as such.

[Tom Gindin]   No rule for implicit knowledge which would permit an
arbitrary RP to recognize a permanent identifier and its assignment
authority within a DN (whether subject name or alt name) has yet been
received with favor.  However, it should be possible to do this using the
semanticsIdentifier.

4) In each and every case raised in favor of this new name form, the
benefit relates to access control rather than electronic signatures.

[Tom Gindin]   Allowing organizations to assign permanent identifiers of
this type (most usually, but not necesarily, to employees) has roughly the
same impact on signatures as on access control.  If it is assumed that the
identity number is assigned by a governmental or quasi-governmental
authority, then the serial number is sufficient because my above arguments
for assignment authority become irrelevant.

5) This is a new input to the discussion, which before adoption must be
reviewed by the community over some time.

[Tom Gindin]   It has been under discussion for months.

Observation 4 makes this whole discussion outside the scope of QC and in
combination with the other observations, I would request that the QC is
moved forward to proposed standard without this new name form.

[Tom Gindin]   If QC requires that the serial number be assigned either by
a governmental or quasi-governmental authority as a permanent identifier or
by the CA as a tiebreaker, and that the certificate itself contain
somewhere an indicator of whether the name is a permanent identifier or a
tiebreaker, then this name form would not be relevant to QC's.  Otherwise
it would.

If PKIX at a later stage would find that a permanent identifier solution,
as discussed here, is of general value, then this can be moved forward as a
separate item. At that time we would also know if it should be merged with
RFC 2459 or the QC profile, if merged at all.



/Stefan



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05997 for <[e-mail]>; Fri, 31 Mar 2000 03:45:08 -0800 (PST)
Received: from santesson (syd-tgn-vce-vty21.as.wcom.net [63.12.28.21]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA24393; Fri, 31 Mar 2000 13:47:14 +0200
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: <[e-mail]>
Subject: SV: Permanent identifiers in QC
Date: Fri, 31 Mar 2000 21:15:54 +0930
Message-ID: <004901bf9b06$accba700$3d0cfea9@santesson>
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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <[e-mail]>
Importance: Normal

Tom,

Using this extension to contain subject name information would break the
intent of this extension.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [e-mail] [mailto:[e-mail]]
> Skickat: den 31 mars 2000 09:10
> Till: Stefan Santesson
> Kopia: [e-mail]
> Ämne: Re: Permanent identifiers in QC
>
>
>      I have a counter-proposal.  Given the profile defined for
> serialNumber, and the definition of SemanticsInformation in
> draft section
> 3.2.5.1, a semanticsIdentifier known as
> id-qcs-identifierAssignmentAuthority should be assigned with
> the following
> rules of interpretation: either one or two name registration
> authorities
> must be present, and the first one present shall be interpreted as the
> authority governing the name space, while the second
> (optional) one may
> contain the serial number or other unique identifier; if
> there is only one
> name registration authority present, the unique identifier is
> assumed to be
> the serial number attribute of the subject name if there is a
> serial number
> attribute in it, and the first serial number attribute
> encountered in the
> subject alternate name if there is none in the subject name.  Another
> semanticsIdentifier known as id-qcs-CALocal should be
> assigned to identify
> serial numbers assigned locally within the CA.  Optionally, a
> semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> assigned with the rule that when one searches for the serial
> number in the
> subject name and subject alternate name in the same way as
> for identifier
> assignment authorities with only one name registration authority, the
> serial number shall be interpreted as being assigned by the
> country given
> in the DN where the serial number is found.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[e-mail]> on 03/30/2000 01:49:44 AM
>
> To:   <[e-mail]>
> cc:
> Subject:  Permanent identifiers in QC
>
>
>
> The PKIX meeting in Adelaide raised only 1 issue related to
> the QC draft.
>
> This issue is whether we should include a new name form in the
> subjectAltName extension holding  a permanent identifier.
>
> The permanent identifier would then be a name of the subject,
> unique within
> the issuers domain, that is not reused over time for another subject.
>
> The reason to include such a name form would be that the use of
> serialNumber in DN, or directoryName in subjectAltName
> extension, does not
> explicitly define this property by itself, unless seen in the
> light of a
> defined policy etc.
>
> Chair Stephen Kent decided that the decision whether or not
> to include this
> name form in QC should be taken to the list.
>
> My observation in regards to this is:
>
> 1) Adding this name form would add confusion to the QC
> specification since
> it would overlap use of serialNumber in the DN.
>
> [Tom Gindin]   Why would this cause confusion if the name
> form itself had
> the same syntax as a DN, and the identity were in the serialNumber
> attribute of that name?
>
> 2) Use of DN attributes covers all needs related to
> identification of the
> subject, and that's all we need to support electronic
> signatures, at least
> as seen from the EU-directive. And as far I know, this goes
> for any other
> legal system.
>
> [Tom Gindin]   This does not cover the joint specification of
> an ID and an
> assignment authority.  A single ID field with quasi-arbitrary values
> similar to a serial number has meaning primarily within the
> scope of its
> assignment authority.
>
> 3) Use of DN in combination with either implicit knowledge, use of
> Directory name in the subjectAltname ext, use of a related policy
> identifier or use of information in the qcStatements
> extension also provide
> support for use of permanent identifiers identified as such.
>
> [Tom Gindin]   No rule for implicit knowledge which would permit an
> arbitrary RP to recognize a permanent identifier and its assignment
> authority within a DN (whether subject name or alt name) has yet been
> received with favor.  However, it should be possible to do
> this using the
> semanticsIdentifier.
>
> 4) In each and every case raised in favor of this new name form, the
> benefit relates to access control rather than electronic signatures.
>
> [Tom Gindin]   Allowing organizations to assign permanent
> identifiers of
> this type (most usually, but not necesarily, to employees)
> has roughly the
> same impact on signatures as on access control.  If it is
> assumed that the
> identity number is assigned by a governmental or quasi-governmental
> authority, then the serial number is sufficient because my
> above arguments
> for assignment authority become irrelevant.
>
> 5) This is a new input to the discussion, which before
> adoption must be
> reviewed by the community over some time.
>
> [Tom Gindin]   It has been under discussion for months.
>
> Observation 4 makes this whole discussion outside the scope
> of QC and in
> combination with the other observations, I would request that
> the QC is
> moved forward to proposed standard without this new name form.
>
> [Tom Gindin]   If QC requires that the serial number be
> assigned either by
> a governmental or quasi-governmental authority as a permanent
> identifier or
> by the CA as a tiebreaker, and that the certificate itself contain
> somewhere an indicator of whether the name is a permanent
> identifier or a
> tiebreaker, then this name form would not be relevant to
> QC's.  Otherwise
> it would.
>
> If PKIX at a later stage would find that a permanent
> identifier solution,
> as discussed here, is of general value, then this can be
> moved forward as a
> separate item. At that time we would also know if it should
> be merged with
> RFC 2459 or the QC profile, if merged at all.
>
>
>
> /Stefan
>



Received: from mta03-svc.ntlworld.com (mta3-win.server.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24669 for <[e-mail]>; Fri, 31 Mar 2000 01:05:50 -0800 (PST)
Received: from darxstar ([62.252.196.136]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000331090825.LOAQ290.mta03-svc.ntlworld.com@darxstar> for <[e-mail]>; Fri, 31 Mar 2000 10:08:25 +0100
Message-ID: <001d01bf9af0$f103f460$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Establishing POP capabilities
Date: Fri, 31 Mar 2000 10:07:14 +0100
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.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

There does not currently seem to be any way for a client to establish which
POP modes are supported which could cause problems.  For example, I may have
developed client software that seeks to establish POP of an encryption key
by engaging in the challenge-response.  However, the authors of the server
software have quite reasonably decided not to implement this means of POP
(as there are better methods available) but the client software has no means
of finding this out, the certification request will fail as POP cannot be
established and the server can only indicate the error by means of an
ambiguous "badPOP" error code.

The POP modes supported by a server could be established in a general
message, something like the following:

{ SupportedPOPModes = {id-it 16}, SEQUENCE OF ObjectIdentifier }

The parameters would be an OID for each POP mode supported; the modes might
be numbered as follows:

RAVerified = {id-pkix-pop 1}
SKPOP = {id-pkix-pop 2}
EKPOPThisMessage = {id-pkix-pop 3}
EKPOPEncryptedCert = {id-pkix-pop 4}
EKPOPChallengeResp = {id-pkix-pop 5}
KAKPOPThisMessage = {id-pkix-pop 6}
KAKPOPThisMessageDHMac = {id-pkix-pop 7}
KAKPOPEncryptedCert = {id-pkix-pop 8}
KAKPOPChallengeResp = {id-pkix-pop 9}

where {id-pkix-pop} = {id-pkix n} = {1 3 6 1 5 5 7 n}

Alternatively, the supported modes could be returned as bits in a BIT
STRING.  Another possibility is to establish the preferred modes for an
encryption key and a key agreement key.

What do people think?

Chris Williams,
NetLexis Ltd.



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29365 for <[e-mail]>; Thu, 30 Mar 2000 15:37:44 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA425700; Thu, 30 Mar 2000 18:38:50 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id SAA146620; Thu, 30 Mar 2000 18:40:16 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568B2.0082058D ; Thu, 30 Mar 2000 18:40:11 -0500
X-Lotus-FromDomain: IBMUS
To: "Stefan Santesson" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 30 Mar 2000 18:40:08 -0500
Subject: Re: Permanent identifiers in QC
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I have a counter-proposal.  Given the profile defined for
serialNumber, and the definition of SemanticsInformation in draft section
3.2.5.1, a semanticsIdentifier known as
id-qcs-identifierAssignmentAuthority should be assigned with the following
rules of interpretation: either one or two name registration authorities
must be present, and the first one present shall be interpreted as the
authority governing the name space, while the second (optional) one may
contain the serial number or other unique identifier; if there is only one
name registration authority present, the unique identifier is assumed to be
the serial number attribute of the subject name if there is a serial number
attribute in it, and the first serial number attribute encountered in the
subject alternate name if there is none in the subject name.  Another
semanticsIdentifier known as id-qcs-CALocal should be assigned to identify
serial numbers assigned locally within the CA.  Optionally, a
semanticsIdentifier known as id-qcs-nationalIdentifier might also be
assigned with the rule that when one searches for the serial number in the
subject name and subject alternate name in the same way as for identifier
assignment authorities with only one name registration authority, the
serial number shall be interpreted as being assigned by the country given
in the DN where the serial number is found.

          Tom Gindin


"Stefan Santesson" <[e-mail]> on 03/30/2000 01:49:44 AM

To:   <[e-mail]>
cc:
Subject:  Permanent identifiers in QC



The PKIX meeting in Adelaide raised only 1 issue related to the QC draft.

This issue is whether we should include a new name form in the
subjectAltName extension holding  a permanent identifier.

The permanent identifier would then be a name of the subject, unique within
the issuers domain, that is not reused over time for another subject.

The reason to include such a name form would be that the use of
serialNumber in DN, or directoryName in subjectAltName extension, does not
explicitly define this property by itself, unless seen in the light of a
defined policy etc.

Chair Stephen Kent decided that the decision whether or not to include this
name form in QC should be taken to the list.

My observation in regards to this is:

1) Adding this name form would add confusion to the QC specification since
it would overlap use of serialNumber in the DN.

[Tom Gindin]   Why would this cause confusion if the name form itself had
the same syntax as a DN, and the identity were in the serialNumber
attribute of that name?

2) Use of DN attributes covers all needs related to identification of the
subject, and that's all we need to support electronic signatures, at least
as seen from the EU-directive. And as far I know, this goes for any other
legal system.

[Tom Gindin]   This does not cover the joint specification of an ID and an
assignment authority.  A single ID field with quasi-arbitrary values
similar to a serial number has meaning primarily within the scope of its
assignment authority.

3) Use of DN in combination with either implicit knowledge, use of
Directory name in the subjectAltname ext, use of a related policy
identifier or use of information in the qcStatements extension also provide
support for use of permanent identifiers identified as such.

[Tom Gindin]   No rule for implicit knowledge which would permit an
arbitrary RP to recognize a permanent identifier and its assignment
authority within a DN (whether subject name or alt name) has yet been
received with favor.  However, it should be possible to do this using the
semanticsIdentifier.

4) In each and every case raised in favor of this new name form, the
benefit relates to access control rather than electronic signatures.

[Tom Gindin]   Allowing organizations to assign permanent identifiers of
this type (most usually, but not necesarily, to employees) has roughly the
same impact on signatures as on access control.  If it is assumed that the
identity number is assigned by a governmental or quasi-governmental
authority, then the serial number is sufficient because my above arguments
for assignment authority become irrelevant.

5) This is a new input to the discussion, which before adoption must be
reviewed by the community over some time.

[Tom Gindin]   It has been under discussion for months.

Observation 4 makes this whole discussion outside the scope of QC and in
combination with the other observations, I would request that the QC is
moved forward to proposed standard without this new name form.

[Tom Gindin]   If QC requires that the serial number be assigned either by
a governmental or quasi-governmental authority as a permanent identifier or
by the CA as a tiebreaker, and that the certificate itself contain
somewhere an indicator of whether the name is a permanent identifier or a
tiebreaker, then this name form would not be relevant to QC's.  Otherwise
it would.

If PKIX at a later stage would find that a permanent identifier solution,
as discussed here, is of general value, then this can be moved forward as a
separate item. At that time we would also know if it should be merged with
RFC 2459 or the QC profile, if merged at all.



/Stefan




Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27123 for <[e-mail]>; Thu, 30 Mar 2000 13:10:17 -0800 (PST)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A34C17B0196; Thu, 30 Mar 2000 23:12:44 +0200
Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Do, 30 M?r 2000 23:13:19 +0100
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>
Subject: a question on inhibitPolicyMapping and requireExplicitPolicy
Date: Thu, 30 Mar 2000 23:13:15 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.2D74C785--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.2D74C785--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Discussing X.509-extensions with my students, the question on why these
extension-parts are defined that way came up and I wasn't sure what to
answer. Neither x509 nor 2459 say anything about the motivation behind that.
So the question is: Is there any practical value in setting the respective
skipcerts to something else than 0?

Peter



----IAIK.SMIME.MAPPER.2D74C785--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDAzMzAyMTEzMTlaMCMGCSqGSIb3DQEJBDEWBBSwnB//Vhba2RQs
DpS3noATL+LdzDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgEXBaDksmdt9uuZFL91W5wk41CLYeInFsx6+8It8ZrRY
ODjC46PbAfzm02DsvJzlb+/3lPnlLo1yN8WxEXy9zkmqfEp+7kbv4iekJrUSKSPR
V03BpcxrEJO/Dd+LzzYUNXa7egh+Si8K6FGE33fBDNLCT8fm+hAcDU5CNAdhYdMo
AAAAAAAA
----IAIK.SMIME.MAPPER.2D74C785----



Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24662 for <[e-mail]>; Thu, 30 Mar 2000 10:41:12 -0800 (PST)
Received: from [38.29.122.97] (ip243.phoenix12.az.pub-ip.psi.net [38.29.124.243]) by goose.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id KAA10708; Thu, 30 Mar 2000 10:42:51 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a04310109b5094d9ee1b8@[38.29.122.97]>
Date: Thu, 30 Mar 2000 11:39:54 -0700
To: OSI Directory List <[e-mail]>, [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: 4th edition of x.509
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

hello

as most of you know sharon has been preparing the reorganized 4th 
edition of x.509 in parallel with the amendment.

at the recent SG7 meeting in geneva, we agreed to publish the 4th 
edition instead of the amendment. this means that x.509 will lead the 
others by about a year while we wait for the related entries text to 
be approved by itu and iso early next year.

i have placed this text on the server in doc and pdf forms at

  ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraft.doc

  ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraft.doc

this text is unofficial until itu and iso approves it. i expect itu 
to approve it at the SG7 plenary this friday. iso will begin a final 
amendment ballot soon. the ballot perion lasts for two months.

note that when the text is approved and available for purchase, it 
will be removed from this server.

    hoyt


Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22039 for <[e-mail]>; Thu, 30 Mar 2000 08:22:42 -0800 (PST)
Received: from kiwi.foobar.com ([12.78.203.194]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <[e-mail]>; Thu, 30 Mar 2000 16:25:01 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Thu, 30 Mar 2000 11:21:58 -0500
To: "Christopher Williams" <[e-mail]>
From: "Michael S. Shanzer" <[e-mail]>
Subject: Re: Any PKIX compliant servers?
Cc: <[e-mail]>
In-Reply-To: <006c01bf9a22$e320dad0$0100a8c0@darxstar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:34 AM 3/30/00 +0100, Christopher Williams wrote:
>One of the main problems that I'm finding with PKIX development is the lack
>of available PKIX-compliant certificate server software.  Does anybody know
>of any commercial software that understands certificate requests compliant
>with RFC 2510 / 2511?  Jonah is not much good because it does not appear to
>implement POP or message protection.  Alternatively (and better), are there
>any servers available over the Internet?
Jonah defiantly does POP for signing keys and message protection. You should
get the latest version of the code if the version you have does not support 
these things


                                         Mike





Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21092 for <[e-mail]>; Thu, 30 Mar 2000 07:43:21 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT8BW5>; Thu, 30 Mar 2000 10:45:23 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Algorithm parameters for symmetric algorithms in EncryptedVal ue
Date: Thu, 30 Mar 2000 10:45:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Thursday, March 30, 2000 10:11 AM
> To: 	PKIX Mailing List
> Subject: 	Algorithm parameters for symmetric algorithms in
> EncryptedValue
> 
> In the EncryptedValue structure, the symmAlg member, like most members, is
> optional.  This, I guess, is for when communication between an EE and CA
> is
> always done using 3-DES and never using RC4, for example.  However, one
> passes important information with the AlgorithmIdentifier, e.g.:
> 
> DES / 3-DES - the IV
> RC2 - the IV and the effective key length
> 
> If one does not set the symmAlg member, there is no way of passing this
> information between the EE and CA; therefore, should one ever set the
> parameters, even if symmAlg is set?
 
Recall that the purpose of an IV is simply to randomize the first block of
data (so that if two pieces of text start with the same first 8 characters,
for example, their corresponding ciphertexts will look completely different,
instead of identical).  An alternative way of doing this is to use an IV of
zero and to prepend 8 random bytes to the actual text (the receiver, after
decryption, simply ignores the first 8 bytes and then starts reading the
actual text).  This method is perfectly legitimate and accomplishes the same
function as the "true" IV method (although it causes slight data expansion
-- the ciphertext is 8 bytes larger than it would be if a true IV was used).

In any case, all I'm suggesting is that it is possible -- within a
particular, known environment -- to omit even things like IV in the
EncryptedValue structure without compromising security.  In general,
however, the symmAlg field can be expected to be present because, as you
note, the AlgId passes important information.

Carlisle.



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20605 for <[e-mail]>; Thu, 30 Mar 2000 07:25:20 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT8B3K>; Thu, 30 Mar 2000 10:27:23 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Confusion with regards to "thisMessage" POP
Date: Thu, 30 Mar 2000 10:27:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Thursday, March 30, 2000 4:04 AM
> To: 	[e-mail]
> Subject: 	Confusion with regards to "thisMessage" POP
> 
> There is still some ambiguity as to establishment in "thisMessage" of POP
> for an encryption key.
> 
> draft-ietf-pkix-rfc2510bis says in section 3.2.8 that POP can be
> established:
> "By the inclusion of the private key (encrypted) in the
> CertRequest (in the PKIArchiveOptions control structure)."
> 
> However, in Appendix D, we then have:
> 
> "-- **********
> -- * the type of "thisMessage" was mistakenly given as BIT STRING in
> -- * RFC 2511; it should have been "EncryptedValue" (in accordance with
> -- * Section 3.2.2 of this specification).  Therefore, this document makes
> -- * the behavioral clarification of specifying that the contents of
> -- * "thisMessage" MUST be encoded as an EncryptedValue and then wrapped
> -- * in a BIT STRING.  This allows the necessary conveyance and protection
> -- * of the private key while maintaining bits-on-the-wire compatibility
> -- * with RFC 2511.
> -- **********"
> 
> I'm guessing that the latter is how the authors now envision POP of a
> private key as this is a recent addition to the standard; however, the
> PKIArchiveOptions control is the structure specifically designed for
> sending
> a private key to a CA.  Which is correct?
 
This is not meant to be confusing.  Proof-of-possession and archive are two
different things:  the former is simply a proof to the CA that I, in fact,
hold the private key corresponding to the public key I'm asking to get
certified; the latter asks the CA (or associated facility) to hold a copy of
my private key so that this key can be recovered later if I lose it or it
otherwise becomes inaccessible.

As it turns out, ONE of the ways (not necessarily the most desirable way) of
proving possession is to actually reveal the private key to the CA.  In
general, it's probably advisable to avoid this method unless the EE also
wants the private key archived, but if the CA is trusted not to abuse its
knowledge of a private key revealed only for POP purposes, then an EE is
free to do this if it desires.

In any case, POP and archive are different functions that serve different
purposes; they just happen to overlap in one optional mechanism (i.e.,
revealing the private key for POP).  Therefore the question "Which is
correct?" does not apply.

Carlisle.



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20211 for <[e-mail]>; Thu, 30 Mar 2000 07:10:25 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT8B21>; Thu, 30 Mar 2000 10:12:27 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail], "'Christopher Williams'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Any PKIX compliant servers?
Date: Thu, 30 Mar 2000 10:12:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Thursday, March 30, 2000 3:34 AM
> To: 	[e-mail]
> Subject: 	Any PKIX compliant servers?
> 
> One of the main problems that I'm finding with PKIX development is the
> lack
> of available PKIX-compliant certificate server software.  Does anybody
> know
> of any commercial software that understands certificate requests compliant
> with RFC 2510 / 2511?  Jonah is not much good because it does not appear
> to
> implement POP or message protection.  Alternatively (and better), are
> there
> any servers available over the Internet?
> 
> Also, does anybody have any syntactically correct PKIX messages that I (we
> if there's anybody else out there developing in anger) could use to test
> the
> software that I'm writing, along with whatever is required to verify
> protection / POP (e.g. password used in a password-based MAC, signing
> certificate with corresponding private key, CA encryption certificate and
> decryption private key, etc.)?
 
Interoperability testing for RFC 2510/2511 has been going on for a long time
now amongst a number of implementers.  This is what has led to rfc2510bis
(note that some of this has occurred over the net -- "virtually" free
participation!  :-).  Interoperability testing will continue within the PKI
Forum on this draft.  Bob Moskowitz (copied on this e-mail) is trying to
arrange schedules/times/places/participants/etc. for the next bake-off.
Please contact him if you are interested in getting involved.

Carlisle.



Received: from mta03-svc.ntlworld.com (mta3-win.server.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19994 for <[e-mail]>; Thu, 30 Mar 2000 07:07:32 -0800 (PST)
Received: from darxstar ([62.252.196.112]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000330151001.LEYG290.mta03-svc.ntlworld.com@darxstar> for <[e-mail]>; Thu, 30 Mar 2000 16:10:01 +0100
Message-ID: <000701bf9a5a$49bc13e0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Algorithm parameters for symmetric algorithms in EncryptedValue
Date: Thu, 30 Mar 2000 16:11:16 +0100
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.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

In the EncryptedValue structure, the symmAlg member, like most members, is
optional.  This, I guess, is for when communication between an EE and CA is
always done using 3-DES and never using RC4, for example.  However, one
passes important information with the AlgorithmIdentifier, e.g.:

DES / 3-DES - the IV
RC2 - the IV and the effective key length

If one does not set the symmAlg member, there is no way of passing this
information between the EE and CA; therefore, should one ever set the
parameters, even if symmAlg is set?

Chris Williams,
NetLexis



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19546 for <[e-mail]>; Thu, 30 Mar 2000 06:51:56 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT8BAY>; Thu, 30 Mar 2000 09:53:55 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>
Cc: PKIX Mailing List <[e-mail]>
Subject: RE: PKIX error message content
Date: Thu, 30 Mar 2000 09:53:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Thursday, March 30, 2000 4:26 AM
> To: 	PKIX Mailing List
> Subject: 	PKIX error message content
> 
> The ErrorMsgContent structure is defined in RFC 2510 (and subsequent
> drafts)
> as follows:
> 
> ErrorMsgContent ::= SEQUENCE {
>          pKIStatusInfo          PKIStatusInfo,
>          errorCode              INTEGER           OPTIONAL,
>          -- implementation-specific error codes
>          errorDetails           PKIFreeText       OPTIONAL
>          -- implementation-specific error details
>      }
> 
> The PKIStatusInfo structure already has fields for the error code and
> error
> text, so what is the purpose of the same fields in ErrorMsgContent?
 
As noted in the comments, these fields are for sending
implementation-specific details, as opposed to the generic code/text carried
in PKIStatusInfo.  If you have good knowledge of the implementation on the
receiving end (for example, during product testing, or interoperability
trials, etc., although it's not confined to this) then these fields may come
in handy.

We were just trying to make life a little easier for implementers...  :-)

Carlisle.



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17975 for <[e-mail]>; Thu, 30 Mar 2000 05:10:57 -0800 (PST)
Received: from santesson ([63.12.29.38]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id PAA00542; Thu, 30 Mar 2000 15:13:18 +0200
From: "Stefan Santesson" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Permanent identifiers in QC
Date: Thu, 30 Mar 2000 22:42:05 +0930
Message-ID: <000701bf9a49$8cc6eb80$3d0cfea9@santesson>
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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <01BF9A30.0195B780@HYDRA>

Anders,

I'm delighted to se us agree on so much :-)

... and the only disagreement I think can be explained by a
misunderstanding.

<snip>
> >4) In each and every case raised in favor of this new name
> form, the benefit
> >relates to access control rather than electronic signatures.
>
> Do not agree.  Permanent IDs are used in Sweden TODAY (by
> authorities) for things
> that cannot be regarded as access control.   Permanent IDs
> helps to clear out many things
> without bothering the CA which is very cost-efficient.  There
> is nothing that says that CAs
> are particularly interested in becoming an extension to the
> Police.  Particularly not
> commercial CAs.

Maybe I should have explained this further. What I mean here is not the
benefit from using a permanent identifier, but the benefit from constructing
a new name form that explicitly defines this property, rather than using
serial Number in DN for the same purpose.

/Stefan



Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17538 for <[e-mail]>; Thu, 30 Mar 2000 04:54:51 -0800 (PST)
From: [e-mail]
Subject: Re: Any PKIX compliant servers?
To: "Christopher Williams" <[e-mail]>
Cc: <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Thu, 30 Mar 2000 07:59:42 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 03/30/2000 07:59:43 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Perhaps you were looking at one of the Jonah pre-releases;  the final drop
of Jonah, available from MIT, implements POP and message protection.

John




"Christopher Williams" <[e-mail]> on 03/30/2000 03:34:33 AM

To:   <[e-mail]>
cc:
Subject:  Any PKIX compliant servers?


One of the main problems that I'm finding with PKIX development is the lack
of available PKIX-compliant certificate server software.  Does anybody know
of any commercial software that understands certificate requests compliant
with RFC 2510 / 2511?  Jonah is not much good because it does not appear to
implement POP or message protection.  Alternatively (and better), are there
any servers available over the Internet?

Also, does anybody have any syntactically correct PKIX messages that I (we
if there's anybody else out there developing in anger) could use to test
the
software that I'm writing, along with whatever is required to verify
protection / POP (e.g. password used in a password-based MAC, signing
certificate with corresponding private key, CA encryption certificate and
decryption private key, etc.)?

Regards,

Chris Williams,
NetLexis Ltd.







Received: from mta03-svc.ntlworld.com (mta3-win.server.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08198 for <[e-mail]>; Thu, 30 Mar 2000 01:25:25 -0800 (PST)
Received: from darxstar ([62.252.196.144]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000330092752.LBCC290.mta03-svc.ntlworld.com@darxstar> for <[e-mail]>; Thu, 30 Mar 2000 10:27:52 +0100
Message-ID: <001f01bf9a2a$7d12ef00$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: PKIX error message content
Date: Thu, 30 Mar 2000 10:26:56 +0100
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.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

The ErrorMsgContent structure is defined in RFC 2510 (and subsequent drafts)
as follows:

ErrorMsgContent ::= SEQUENCE {
         pKIStatusInfo          PKIStatusInfo,
         errorCode              INTEGER           OPTIONAL,
         -- implementation-specific error codes
         errorDetails           PKIFreeText       OPTIONAL
         -- implementation-specific error details
     }

The PKIStatusInfo structure already has fields for the error code and error
text, so what is the purpose of the same fields in ErrorMsgContent?

Chris Williams,
NetLexis



Received: from mta01-svc.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06006 for <[e-mail]>; Thu, 30 Mar 2000 01:00:45 -0800 (PST)
Received: from darxstar ([62.252.200.86]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000330090315.NPIQ4470.mta01-svc.ntlworld.com@darxstar> for <[e-mail]>; Thu, 30 Mar 2000 10:03:15 +0100
Message-ID: <000901bf9a27$0c883b80$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: <[e-mail]>
Subject: Confusion with regards to "thisMessage" POP
Date: Thu, 30 Mar 2000 10:04:31 +0100
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.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

There is still some ambiguity as to establishment in "thisMessage" of POP
for an encryption key.

draft-ietf-pkix-rfc2510bis says in section 3.2.8 that POP can be
established:
"By the inclusion of the private key (encrypted) in the
CertRequest (in the PKIArchiveOptions control structure)."

However, in Appendix D, we then have:

"-- **********
-- * the type of "thisMessage" was mistakenly given as BIT STRING in
-- * RFC 2511; it should have been "EncryptedValue" (in accordance with
-- * Section 3.2.2 of this specification).  Therefore, this document makes
-- * the behavioral clarification of specifying that the contents of
-- * "thisMessage" MUST be encoded as an EncryptedValue and then wrapped
-- * in a BIT STRING.  This allows the necessary conveyance and protection
-- * of the private key while maintaining bits-on-the-wire compatibility
-- * with RFC 2511.
-- **********"

I'm guessing that the latter is how the authors now envision POP of a
private key as this is a recent addition to the standard; however, the
PKIArchiveOptions control is the structure specifically designed for sending
a private key to a CA.  Which is correct?

Chris Williams,
NetLexis




Received: from mta01-svc.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04276 for <[e-mail]>; Thu, 30 Mar 2000 00:30:59 -0800 (PST)
Received: from darxstar ([62.252.199.118]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000330083328.NPAK4470.mta01-svc.ntlworld.com@darxstar> for <[e-mail]>; Thu, 30 Mar 2000 09:33:28 +0100
Message-ID: <006c01bf9a22$e320dad0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: <[e-mail]>
Subject: Any PKIX compliant servers?
Date: Thu, 30 Mar 2000 09:34:33 +0100
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.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

One of the main problems that I'm finding with PKIX development is the lack
of available PKIX-compliant certificate server software.  Does anybody know
of any commercial software that understands certificate requests compliant
with RFC 2510 / 2511?  Jonah is not much good because it does not appear to
implement POP or message protection.  Alternatively (and better), are there
any servers available over the Internet?

Also, does anybody have any syntactically correct PKIX messages that I (we
if there's anybody else out there developing in anger) could use to test the
software that I'm writing, along with whatever is required to verify
protection / POP (e.g. password used in a password-based MAC, signing
certificate with corresponding private key, CA encryption certificate and
decryption private key, etc.)?

Regards,

Chris Williams,
NetLexis Ltd.



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03349 for <[e-mail]>; Thu, 30 Mar 2000 00:16:21 -0800 (PST)
Received: from HYDRA ([195.198.186.85]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id KAA27294; Thu, 30 Mar 2000 10:21:31 +0200
Received: by HYDRA with Microsoft Mail id <01BF9A30.0195B780@HYDRA>; Thu, 30 Mar 2000 10:09:16 +0200
Message-ID: <01BF9A30.0195B780@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Permanent identifiers in QC
Date: Thu, 30 Mar 2000 10:09:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<snip>
>My observation in regards to this is:

>1) Adding this name form would add confusion to the QC specification since
>it would overlap use of serialNumber in the DN.

Correct.  That is why I have pushed "DN interpretation support" mechanisms

>2) Use of DN attributes covers all needs related to identification of the
>subject, and that's all we need to support electronic signatures, at least
>as seen from the EU-directive. And as far I know, this goes for any other
>legal system.

Hope so.

>3) Use of DN in combination with either implicit knowledge, use of Directory
>name in the subjectAltname ext, use of a related policy identifier or use of
>information in the qcStatements extension also provide support for use of
>permanent identifiers identified as such.

All over-the.map solutions but in principal correct.

>4) In each and every case raised in favor of this new name form, the benefit
>relates to access control rather than electronic signatures.

Do not agree.  Permanent IDs are used in Sweden TODAY (by authorities) for things
that cannot be regarded as access control.   Permanent IDs helps to clear out many things
without bothering the CA which is very cost-efficient.  There is nothing that says that CAs
are particularly interested in becoming an extension to the Police.  Particularly not
commercial CAs.

>5) This is a new input to the discussion, which before adoption must be
>reviewed by the community over some time.

Correct

<snip>

Anders




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28094 for <[e-mail]>; Wed, 29 Mar 2000 22:48:37 -0800 (PST)
Received: from santesson (dhcp-33-27.ietf.connect.com.au [169.208.33.27]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id IAA23735 for <[e-mail]>; Thu, 30 Mar 2000 08:50:51 +0200
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Subject: Permanent identifiers in QC
Date: Thu, 30 Mar 2000 16:19:44 +0930
Message-ID: <03E49309E8F5D31183F7000629396ECCD61C@TRUST>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

The PKIX meeting in Adelaide raised only 1 issue related to the QC draft.

This issue is whether we should include a new name form in the
subjectAltName extension holding  a permanent identifier.

The permanent identifier would then be a name of the subject, unique within
the issuers domain, that is not reused over time for another subject.

The reason to include such a name form would be that the use of serialNumber
in DN, or directoryName in subjectAltName extension, does not explicitly
define this property by itself, unless seen in the light of a defined policy
etc.

Chair Stephen Kent decided that the decision whether or not to include this
name form in QC should be taken to the list.

My observation in regards to this is:

1) Adding this name form would add confusion to the QC specification since
it would overlap use of serialNumber in the DN.

2) Use of DN attributes covers all needs related to identification of the
subject, and that's all we need to support electronic signatures, at least
as seen from the EU-directive. And as far I know, this goes for any other
legal system.

3) Use of DN in combination with either implicit knowledge, use of Directory
name in the subjectAltname ext, use of a related policy identifier or use of
information in the qcStatements extension also provide support for use of
permanent identifiers identified as such.

4) In each and every case raised in favor of this new name form, the benefit
relates to access control rather than electronic signatures.

5) This is a new input to the discussion, which before adoption must be
reviewed by the community over some time.

Observation 4 makes this whole discussion outside the scope of QC and in
combination with the other observations, I would request that the QC is
moved forward to proposed standard without this new name form.

If PKIX at a later stage would find that a permanent identifier solution, as
discussed here, is of general value, then this can be moved forward as a
separate item. At that time we would also know if it should be merged with
RFC 2459 or the QC profile, if merged at all.



/Stefan




Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12345 for <[e-mail]>; Tue, 28 Mar 2000 16:22:31 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dhcp-193-54.ietf.connect.com.au [169.208.193.54]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA12075; Tue, 28 Mar 2000 16:24:11 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 28 Mar 2000 19:18:45 -0500
To: Sungjin Lee <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Certificate Extension Fields For "a resident registration number"
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sungjin:

There is more than one possible answer.  The best solution would depend on 
the application that needs access to the hash value and the hooks that are 
available in the application environment.

Some choices for carrying the the hash value are (in no particular order):
  - private extension;
  - subject alternative name of the directory name form could
     include a serial number attribute; and
  - subject alternative name of the other name form.

If none of these work in your application environment, then the subject 
unique identifier could be used.  RFC 2459 says that this field SHOULD NOT 
be used by certificate authorities, so this should be a last resort.

Russ

At 12:32 AM 03/28/2000 +0900, Sungjin Lee wrote:

>I want to insert the hash value of "a resident registration number" into 
>X.509 Certificate.
>
>a resident registration number" is a unique id like drive license no.
>
>What field can I use for the hash value ?
>
>Sungjin Lee



Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09481 for <[e-mail]>; Mon, 27 Mar 2000 08:18:35 -0800 (PST)
From: [e-mail]
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA238074; Mon, 27 Mar 2000 11:19:05 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay01.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA56532; Mon, 27 Mar 2000 11:20:27 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568AF.0059BEA4 ; Mon, 27 Mar 2000 11:20:15 -0500
X-Lotus-FromDomain: IBMUS
To: Santosh Chokhani <[e-mail]>
cc: "'Russ Housley'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 27 Mar 2000 11:20:05 -0500
Subject: RE: Need verification of Issuing DP against CRL DP in son-of-2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     You are right that annex B (which can be found in the Certificate
Extensions DAM) covers this area.  For example, section B.5.1.4 in the
Certificate Extensions DAM includes pretty nearly all of the points I made,
except for the suggested rule about matching LDAP URI's to DN's.  Section
B.4 of the DAM on obtaining CRL's might well profit by being more
thoroughly worked out, by comparison.
     The DAM does not seem to be available at present on Bull's FTP site.


          Tom Gindin

Santosh Chokhani <[e-mail]> on 03/27/2000 07:37:46 AM

To:   "'Russ Housley'" <[e-mail]>, Tom Gindin/Watson/IBM@IBMUS
cc:   [e-mail]
Subject:  RE: Need verification of Issuing DP against CRL DP in son-of-2459



May be in stead of these band aid type solutions, son-of-2459 authors
should
adopt or synopsize the cogent material from Annex B of the current X.509
draft.  By the way, that Annex is normative.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Sunday, March 26, 2000 11:57 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Need verification of Issuing DP against CRL DP in
son-of-2459


Tom:

You are correct.  Thanks for catching this omission.

We need to say that the Certificate CRLDP DistributionPointName must match
the CRL IDP DistributionPointName, if both are preaent.

Russ


At 04:29 PM 03/23/2000 -0500, [e-mail] wrote:
>      There does not appear to be any specification in the CRL Processing
>section that the IssuingDistributionPoint extension be verified against
the
>CRL Distribution Point extension.  This leaves the possibility that a
>malicious systems administrator could switch the contents of two
>distribution points with different names signed by the same CA, causing
all
>revocations within those CRL's not to be found.
>      To close this hole, I would recommend rewording step (1) of section
>6.3.3 as follows: "Locate those CRL's whose IssuingDistributionPoint
>extension contain a distributionPoint matching that in the CRL
Distribution
>Point and an onlySomeReasons flag value which is a subset of the reasons
>field in the CRL Distribution Point, and perform the following
>verifications:".  Furthermore, we might want to add notes that an LDAP URI
>in RFC 2255 format may be considered to match a DN if and only if the
URI's
>DN field matches the DN, that missing distributionPoint names match other
>missing names, and that a missing reasons field is interpreted as
>all-reasons for the purposes of the subset calculation above.
>      There is also no statement in the current version about how the CRL
>cache is to be populated.  In my suggested version above, I have removed
>references to it.  In practice, the verifier is probably supposed to
locate
>the CRL either in the CRL cache, by resolving the URI of a URI
distribution
>point, by LDAP or X.500 access to the directory entry of the DN of a DN
>distribution point, or by LDAP or X.500 access to the issuer's directory
>entry for a missing distribution point or one with no name component;
while
>a CRL located by any of the other methods may be added to the CRL cache.
>
>           Tom Gindin





Received: from ns.koscom.co.kr (ns.koscom.co.kr [128.134.148.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08198 for <[e-mail]>; Mon, 27 Mar 2000 07:31:53 -0800 (PST)
Received: from koscom.co.kr ([128.134.151.31]) by ns.koscom.co.kr (8.9.1/8.9.1) with ESMTP id AAA12143 for <[e-mail]>; Tue, 28 Mar 2000 00:26:58 +0900 (KST)
Message-ID: <[e-mail]>
Date: Tue, 28 Mar 2000 00:32:57 +0900
From: Sungjin Lee <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Certificate Extension Fields For "a resident registration number"
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit

I want to insert the hash value of "a resident registration number" into X.509 Certificate.

a resident registration number" is a unique id like drive license no.

What field can I use for the hash value ?

Sungjin Lee


Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03455 for <[e-mail]>; Mon, 27 Mar 2000 04:57:34 -0800 (PST)
From: [e-mail]
Subject: Re: how to implement X.509
To: kripal singh <[e-mail]>
Cc: [e-mail]
Date: Mon, 27 Mar 2000 08:02:06 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 03/27/2000 07:59:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

The Jonah freeware (http://web.mit.edu/pfl) will issue V3 certs, and
contains an asn.1-aware C++ class library that you can use directly to
generate certificates of whatever version you choose.

John




kripal singh <[e-mail]> on 03/25/2000 01:56:22 AM

To:   [e-mail]
cc:

Subject:  how to implement X.509


How can i generate my own X.509v2 and v3 certificates.
is there any source code or documentation available on
the net(particularly in c++).

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com






Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02914 for <[e-mail]>; Mon, 27 Mar 2000 04:42:58 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <H47RZKP3>; Mon, 27 Mar 2000 07:37:47 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E5AAC93@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Need verification of Issuing DP against CRL DP in son-of-2459
Date: Mon, 27 Mar 2000 07:37:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

May be in stead of these band aid type solutions, son-of-2459 authors should
adopt or synopsize the cogent material from Annex B of the current X.509
draft.  By the way, that Annex is normative.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Sunday, March 26, 2000 11:57 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Need verification of Issuing DP against CRL DP in
son-of-2459


Tom:

You are correct.  Thanks for catching this omission.

We need to say that the Certificate CRLDP DistributionPointName must match 
the CRL IDP DistributionPointName, if both are preaent.

Russ


At 04:29 PM 03/23/2000 -0500, [e-mail] wrote:
>      There does not appear to be any specification in the CRL Processing
>section that the IssuingDistributionPoint extension be verified against the
>CRL Distribution Point extension.  This leaves the possibility that a
>malicious systems administrator could switch the contents of two
>distribution points with different names signed by the same CA, causing all
>revocations within those CRL's not to be found.
>      To close this hole, I would recommend rewording step (1) of section
>6.3.3 as follows: "Locate those CRL's whose IssuingDistributionPoint
>extension contain a distributionPoint matching that in the CRL Distribution
>Point and an onlySomeReasons flag value which is a subset of the reasons
>field in the CRL Distribution Point, and perform the following
>verifications:".  Furthermore, we might want to add notes that an LDAP URI
>in RFC 2255 format may be considered to match a DN if and only if the URI's
>DN field matches the DN, that missing distributionPoint names match other
>missing names, and that a missing reasons field is interpreted as
>all-reasons for the purposes of the subset calculation above.
>      There is also no statement in the current version about how the CRL
>cache is to be populated.  In my suggested version above, I have removed
>references to it.  In practice, the verifier is probably supposed to locate
>the CRL either in the CRL cache, by resolving the URI of a URI distribution
>point, by LDAP or X.500 access to the directory entry of the DN of a DN
>distribution point, or by LDAP or X.500 access to the issuer's directory
>entry for a missing distribution point or one with no name component; while
>a CRL located by any of the other methods may be added to the CRL cache.
>
>           Tom Gindin


Received: from center.kisa.or.kr (ns.kisa.or.kr [203.233.150.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21689 for <[e-mail]>; Sun, 26 Mar 2000 21:43:11 -0800 (PST)
Received: from kisa.or.kr ([172.16.2.81]) by center.kisa.or.kr (8.9.3/8.9.3) with ESMTP id OAA16012 for <[e-mail]>; Mon, 27 Mar 2000 14:39:57 +0900 (KST)
Message-ID: <[e-mail]>
Date: Mon, 27 Mar 2000 14:48:59 +0900
From: JeeyeonKim <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe



Received: from sina.com ([202.106.187.152]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA21603 for <[e-mail]>; Sun, 26 Mar 2000 21:42:44 -0800 (PST)
Received: (qmail 24230 invoked by uid 99); 27 Mar 2000 05:43:31 -0000
Message-ID: <[e-mail]>
From: henrys_hive <[e-mail]>
To: [e-mail]
Subject: For Help
Date: Mon Mar 27 13:43:31 CST 2000
X-Mailer: SinaMail 3.0Beta (FireToad)

This is Mr. Henry. 

I'm a new man in this maillist and I found myself cannot catch your topics.
And I'd like to know how to get started and I think I need some introducing
papers of the archetecture about this huge system. I need your help. 

Any of your advice is welcome!

Henry

______________________________________


===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn 



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20878 for <[e-mail]>; Sun, 26 Mar 2000 20:59:19 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dhcp-193-54.ietf.connect.com.au [169.208.193.54]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id VAA20437; Sun, 26 Mar 2000 21:00:09 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 26 Mar 2000 23:57:14 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Need verification of Issuing DP against CRL DP in son-of-2459
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tom:

You are correct.  Thanks for catching this omission.

We need to say that the Certificate CRLDP DistributionPointName must match 
the CRL IDP DistributionPointName, if both are preaent.

Russ


At 04:29 PM 03/23/2000 -0500, [e-mail] wrote:
>      There does not appear to be any specification in the CRL Processing
>section that the IssuingDistributionPoint extension be verified against the
>CRL Distribution Point extension.  This leaves the possibility that a
>malicious systems administrator could switch the contents of two
>distribution points with different names signed by the same CA, causing all
>revocations within those CRL's not to be found.
>      To close this hole, I would recommend rewording step (1) of section
>6.3.3 as follows: "Locate those CRL's whose IssuingDistributionPoint
>extension contain a distributionPoint matching that in the CRL Distribution
>Point and an onlySomeReasons flag value which is a subset of the reasons
>field in the CRL Distribution Point, and perform the following
>verifications:".  Furthermore, we might want to add notes that an LDAP URI
>in RFC 2255 format may be considered to match a DN if and only if the URI's
>DN field matches the DN, that missing distributionPoint names match other
>missing names, and that a missing reasons field is interpreted as
>all-reasons for the purposes of the subset calculation above.
>      There is also no statement in the current version about how the CRL
>cache is to be populated.  In my suggested version above, I have removed
>references to it.  In practice, the verifier is probably supposed to locate
>the CRL either in the CRL cache, by resolving the URI of a URI distribution
>point, by LDAP or X.500 access to the directory entry of the DN of a DN
>distribution point, or by LDAP or X.500 access to the issuer's directory
>entry for a missing distribution point or one with no name component; while
>a CRL located by any of the other methods may be added to the CRL cache.
>
>           Tom Gindin



Received: from slack.lne.com (IDENT:[e-mail] [209.157.136.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22551 for <[e-mail]>; Sat, 25 Mar 2000 11:14:46 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.9.3/8.9.3) id KAA12804; Sat, 25 Mar 2000 10:43:51 -0800
Date: Sat, 25 Mar 2000 10:43:51 -0800
From: ericm <[e-mail]>
To: kripal singh <[e-mail]>
Cc: [e-mail]
Subject: Re: how to implement  X.509
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <[e-mail]>

On Fri, Mar 24, 2000 at 10:56:22PM -0800, kripal singh wrote:
> How can i generate my own X.509v2 and v3 certificates.
> is there any source code or documentation available on
> the net(particularly in c++).

It's not c++, but OpenSSL will do it.

-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5


Received: from web4103.mail.yahoo.com (web4103.mail.yahoo.com [216.115.104.123]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA01726 for <[e-mail]>; Fri, 24 Mar 2000 22:54:56 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [203.197.240.253] by web4103.mail.yahoo.com; Fri, 24 Mar 2000 22:56:22 PST
Date: Fri, 24 Mar 2000 22:56:22 -0800 (PST)
From: kripal singh <[e-mail]>
Subject: how to implement  X.509
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

How can i generate my own X.509v2 and v3 certificates.
is there any source code or documentation available on
the net(particularly in c++).

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


Received: from gnu.IN-Berlin.DE (gnu.in-berlin.de [192.109.42.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13275 for <[e-mail]>; Fri, 24 Mar 2000 15:51:35 -0800 (PST)
Received: from hirsch.in-berlin.de ([e-mail] [192.109.42.6]) by gnu.IN-Berlin.DE (8.9.3/8.9.3) with ESMTP id AAA10150; Sat, 25 Mar 2000 00:53:35 +0100 (CET) (envelope-from aurora.in-berlin.de![e-mail])
Received: by hirsch.in-berlin.de (Smail3.2)  from  aurora.in-berlin.de with uucp id <m12YdtU-000glJC>; Sat, 25 Mar 2000 00:53:32 +0100 (CET)
Received: by aurora.in-berlin.de (/\oo/\ Smail3.1.29.1 #29.14) id <[e-mail]>; Sat, 25 Mar 2000 00:51 MET
Message-Id: <[e-mail]>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
In-Reply-To: <[e-mail]>
X-Nextstep-Mailer: Mail 3.3 [m68k] (Enhance 2.2.3, Nov 1999)
Received: by NeXT.Mailer (1.118.2)
From: Ingmar Camphausen <[e-mail]>
Date: Sat, 25 Mar 2000 00:51:25 +0100
To: kripal singh <[e-mail]>
Subject: Re: help on X.509
cc: [e-mail]
Reply-To: [e-mail]
References: <[e-mail]>
Organization: Individual Network Berlin
Priority: normal

on Fri, 24 Mar 2000, kripal singh <[e-mail]> wrote:

> where i will get detailes information on X.509
> versions ie v1 v2 v3.
> which rfc's define these versions.

X.509 is not defined in an RFC, it is an _ITU-T Recommendation_
(X-Series ;-). ('ITU' stands for 'International Telecommunication
Union'). That's why it is not available as an RFC. (But there's hope,
see below ;-). ITU recommendations can be bought from the ITU
(http://www.itu.int/publications/index.html) or might be obtainable
via your national ITU member institution.

As ITU-T's X.509 happens to be a joint document with the ISO (ITU-T
X.509 = ISO/IEC 9594-8), so it should be available from the ISO
(http://www.iso.ch) or your national standardization organization/
institution, too.

As Monica Ene-Pietrosanu wrote in her reply, the ASN.1 definition of
the X.509v3 certificate format is described in RFC2459, in appendices
A and B.

BTW:
The following paper might be a good text to read besides the
X.509/ISO 9594-8 standard itself: "X.509 Style Guide" by Peter Gutmann,
available via

     http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt


Hope this helps,

	Ingmar

--
Ingmar Camphausen    PGP key: 'finger [e-mail]' or via keyserver
DFN-PCA (Policy CA, German Research Network)                [e-mail]
Vogt-Koelln-Str. 30                                    http://www.pca.dfn.de/
D-22527 Hamburg, Germany                       +49.40.42883-2262 / Fax: -2241


Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA08089 for <[e-mail]>; Fri, 24 Mar 2000 09:55:28 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Mar 2000 09:53:02 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <GRS2V89R>; Fri, 24 Mar 2000 09:53:02 -0800
Message-ID: <[e-mail]>
From: Monica Ene-Pietrosanu <[e-mail]>
To: "'kripal singh'" <[e-mail]>, [e-mail]
Subject: RE: help on X.509
Date: Fri, 24 Mar 2000 09:54:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

X.509v3 certificates and X.509v2 CRLs are described in RFC2459. See section
8 (references) of this RFC for additional info.

-----Original Message-----
From: kripal singh [mailto:[e-mail]]
Sent: Friday, March 24, 2000 5:43 AM
To: [e-mail]
Subject: help on X.509


where i will get detailes information on X.509
versions ie v1 v2 v3.
which rfc's define these versions.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04823 for <[e-mail]>; Fri, 24 Mar 2000 06:54:25 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA02933; Fri, 24 Mar 2000 06:55:47 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 23 Mar 2000 13:47:41 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: OID value for DES and DES3 keys
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The following DES OIDs were assigned by the OSI Implementor's Working 
Group, Security Special Interest Group:

     algorithm OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) oiw(14) secsig(3)
              algorithm(2) }

DES-ECB:  { algorithm 6 }

DES-CBC:  { algorithm 7 }; Carries an IV as a parameter.

DES-OFB:  { algorithm 8 }; carries an FBParameter as a parameter.

    FBParameter ::= SEQUENCE {
       iv                IV,
       numberOfBits      NumberOfBits }

    IV ::= OCTET STRING
    NumberOfBits ::= INTEGER     -- number of feedback bits (1-64)

DES-CFB:  { algorithm 9 }; carries an FBParameter as a parameter.

DES-MAC:  { algorithm 10 }; carries an INTEGER parameter, the
length of the MAC (constrained by comment to 16, 24, 32, 40, 48 or
64 bits).

DES-EDE:  { algorithm 17 }; Triple DES in ECB mode, per ANSI X9.17.


At 06:52 PM 03/20/2000 -0800, Terry Hayes wrote:
>I'm looking for a standard OBJECT IDENTIFIER value that represents a DES
>or DES3 (triple-DES) key value.  This value would be used in a data
>structure that contains the key value, such as the PKCS-8
>PrivateKeyInfo, or the PKCS-12 SecretBag.   That is, I'm looking for the
>ASN.1 equivalent of the PKCS-11 CKK_DES or CKK_DES3 key-type values.
>
>One possible way to identify a DES key is to use the OID for one of the
>DES encryption algorithms.  This method was used for RSA keys, which
>identify both the key values, and the basic RSA encryption operations
>with the same identifier.
>
>Does anyone know of previously defined OID values for DES keys, or know
>of any previous examples that use a DES algorithm OID to identify the
>key?
>
>Thanks,
>
>Terry Hayes
>[e-mail]



Received: from web4101.mail.yahoo.com (web4101.mail.yahoo.com [216.115.104.121]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA03281 for <[e-mail]>; Fri, 24 Mar 2000 05:41:33 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [203.197.135.144] by web4101.mail.yahoo.com; Fri, 24 Mar 2000 05:43:05 PST
Date: Fri, 24 Mar 2000 05:43:05 -0800 (PST)
From: kripal singh <[e-mail]>
Subject: help on X.509
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

where i will get detailes information on X.509
versions ie v1 v2 v3.
which rfc's define these versions.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


Received: from web4101.mail.yahoo.com (web4101.mail.yahoo.com [216.115.104.121]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA03270 for <[e-mail]>; Fri, 24 Mar 2000 05:41:30 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [203.197.135.144] by web4101.mail.yahoo.com; Fri, 24 Mar 2000 05:43:03 PST
Date: Fri, 24 Mar 2000 05:43:03 -0800 (PST)
From: kripal singh <[e-mail]>
Subject: help on X.509
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

where i will get detailes information on X.509
versions ie v1 v2 v3.
which rfc's define these versions.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17343 for <[e-mail]>; Thu, 23 Mar 2000 13:28:29 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA197606 for <[e-mail]>; Thu, 23 Mar 2000 16:28:32 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id QAA245004 for <[e-mail]>; Thu, 23 Mar 2000 16:29:55 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568AB.00761836 ; Thu, 23 Mar 2000 16:29:54 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 23 Mar 2000 16:29:49 -0500
Subject: Need verification of Issuing DP against CRL DP in son-of-2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     There does not appear to be any specification in the CRL Processing
section that the IssuingDistributionPoint extension be verified against the
CRL Distribution Point extension.  This leaves the possibility that a
malicious systems administrator could switch the contents of two
distribution points with different names signed by the same CA, causing all
revocations within those CRL's not to be found.
     To close this hole, I would recommend rewording step (1) of section
6.3.3 as follows: "Locate those CRL's whose IssuingDistributionPoint
extension contain a distributionPoint matching that in the CRL Distribution
Point and an onlySomeReasons flag value which is a subset of the reasons
field in the CRL Distribution Point, and perform the following
verifications:".  Furthermore, we might want to add notes that an LDAP URI
in RFC 2255 format may be considered to match a DN if and only if the URI's
DN field matches the DN, that missing distributionPoint names match other
missing names, and that a missing reasons field is interpreted as
all-reasons for the purposes of the subset calculation above.
     There is also no statement in the current version about how the CRL
cache is to be populated.  In my suggested version above, I have removed
references to it.  In practice, the verifier is probably supposed to locate
the CRL either in the CRL cache, by resolving the URI of a URI distribution
point, by LDAP or X.500 access to the directory entry of the DN of a DN
distribution point, or by LDAP or X.500 access to the issuer's directory
entry for a missing distribution point or one with no name component; while
a CRL located by any of the other methods may be added to the CRL cache.

          Tom Gindin




Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10349 for <[e-mail]>; Wed, 22 Mar 2000 02:46:32 -0800 (PST)
Received: by balinese.baltimore.ie; id KAA10325; Wed, 22 Mar 2000 10:48:22 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma010235; Wed, 22 Mar 00 10:47:26 GMT
Received: from baltimore.ie (lease168-21.baltimore.ie [192.168.21.168]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA11683; Wed, 22 Mar 2000 10:47:24 GMT
Message-ID: <[e-mail]>
Date: Wed, 22 Mar 2000 10:47:29 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>, xme <[e-mail]>, Sharon Boeyen <[e-mail]>
Subject: AC profile: targeting extension
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,

The ISO folks added a targeting extension into the X.509 PDAM
based on the one already defined in the AC profile draft.
Unfortunately they used a different syntax, but fortunately, 
since everyone working with X.509 is very reasonable, we 
managed to come up with a syntax that keeps all the
document editors happy. So, the question is whether anyone
else has a problem with the aligned solution? (The ASN.1 
is at the end of this message).

Notes: 
- the new syntax is backwards compatible with the -01 
  AC profile draft version
- I'll also add text that says not to use the TargetCert
  field, since I at least need to think this through before
  wanting to use it (this is the same as in the -02 draft)
- the extension OID will then be the ISO one, not the 
  IETF one (i.e. id-ce-targetInformation from the X.509 DAM)
- there's an ISO editing meeting on this week, so its possible
  that some tags or whatever might still change

Regards,
Stephen.

  Targets ::= SEQUENCE OF Target
 
  Target  ::= CHOICE {
     targetName        [0] GeneralName,
     targetGroup       [1] GeneralName,
     targetCert        [2] TargetCert
  }
 
  TargetCert  ::= SEQUENCE {
     targetCertificate       IssuerSerial,
     targetName              GeneralName OPTIONAL,
     certDigestInfo          ObjectDigestInfo OPTIONAL
  }

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from dynamite.com.au (m1.dynamite.com.au [203.17.154.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18492 for <[e-mail]>; Tue, 21 Mar 2000 02:36:53 -0800 (PST)
Received: from designer (isp894.canb.dynamite.com.au [202.139.71.132]) by dynamite.com.au (8.9.3/8.9.3) with SMTP id VAA02633; Tue, 21 Mar 2000 21:38:32 +1100
Reply-To: <[e-mail]>
From: "Gus Kollar" <[e-mail]>
To: <[e-mail]>
Cc: "COMSEC Traffic (E-mail)" <[e-mail]>
Subject: subscribe
Date: Tue, 21 Mar 2000 21:32:34 +1100
Message-ID: <000001bf9320$c5ead000$[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 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

subscribe


Received: from mta02.mail.mel.aone.net.au (mta02.mail.au.uu.net [203.2.192.82]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03331 for <[e-mail]>; Mon, 20 Mar 2000 22:35:55 -0800 (PST)
Received: from designer ([203.12.189.25]) by mta02.mail.mel.aone.net.au with SMTP id <20000321063738.QLYT10269.mta02.mail.mel.aone.net.au@designer>; Tue, 21 Mar 2000 17:37:38 +1100
Reply-To: <[e-mail]>
From: "Gus Kollar" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: unsubscribe
Date: Tue, 21 Mar 2000 17:31:39 +1100
Message-ID: <000001bf92ff$2352adc0$[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 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

unsubscribe


Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19830 for <[e-mail]>; Mon, 20 Mar 2000 18:51:09 -0800 (PST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA06116 for <[e-mail]>; Mon, 20 Mar 2000 18:49:53 -0800 (PST)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FRR3ZC00.MF4 for <[e-mail]>; Mon, 20 Mar 2000 18:52:24 -0800 
Message-ID: <[e-mail]>
Date: Mon, 20 Mar 2000 18:52:23 -0800
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: OID value for DES and DES3 keys
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm looking for a standard OBJECT IDENTIFIER value that represents a DES
or DES3 (triple-DES) key value.  This value would be used in a data
structure that contains the key value, such as the PKCS-8
PrivateKeyInfo, or the PKCS-12 SecretBag.   That is, I'm looking for the
ASN.1 equivalent of the PKCS-11 CKK_DES or CKK_DES3 key-type values.

One possible way to identify a DES key is to use the OID for one of the
DES encryption algorithms.  This method was used for RSA keys, which
identify both the key values, and the basic RSA encryption operations
with the same identifier.

Does anyone know of previously defined OID values for DES keys, or know
of any previous examples that use a DES algorithm OID to identify the
key?

Thanks,

Terry Hayes
[e-mail]



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10170 for <[e-mail]>; Mon, 20 Mar 2000 15:43:21 -0800 (PST)
Received: from santesson (mfs-pci-bqg-vty111.as.wcom.net [212.211.4.111]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id AAA17770; Tue, 21 Mar 2000 00:44:57 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: SV: SerialNumber consensus in QC 03
Date: Tue, 21 Mar 2000 00:40:58 +0100
Message-ID: <002601bf92c5$be1011c0$6f04d3d4@santesson>
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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <[e-mail]>

Denis, Stephen and all,

This serial number beast is a hard kill :-)

I've been thinking through this and have come to the conclusion that the
final issue that Denis raises, should not be a QC issue.
The QC specification is meant to support use of electronic signatures
according to applicable law. And this does only require that the actual
person behind the certificate can be determined with sufficient accuracy. It
does not explicitly require use of "non-reusable" identifiers.

The concept of specifying static identifiers that can never be reused among
entities when seen alone OR when seen in combination with some other
attribute(s), seams to be a general problem for authentication schemes more
than for recognition of advanced electronic signatures.

So to me Denis proposal address a general concern which is not necessary for
QC, but which may be relevant for general applications related to X.509
certificates.

I could argue against Denis proposal here but I will limit to the conclusion
that:

1) It is incomplete as presented, and;
2) There are other legitimate alternatives (such as use of
subjectUniqueIdentifier)

With this I suggest that the issue is taken of the PKIX QC work item.
Instead I suggest that the discussion, if relevant, will be related to son
of RFC 2459 instead.

Steve, could you give your opinion as the keeper of order between work
items?

/Stefan


-----Ursprungligt meddelande-----
Från: Denis Pinkas [mailto:[e-mail]]
Skickat: den 15 mars 2000 18:14
Till: Stefan Santesson
Kopia: [e-mail]
Ämne: Re: SerialNumber consensus in QC 03


Stefan,

The SerialNumber is a way to solve several problems. Before defining
its semantics, it is important to define what the problems are.
There are two different problems that can be both solved by using a
SerialNumber :

a) making two names different when otherwise the name of two or more
entities would not be different. An example of the first case, is
"Mary White 3" and "Mary White 22".

b) allowing the use of a permanent identifier for an entity, even if
the name of the entity changes. An example of that case is "C = US ;
OU = Delta ; OU1= Corporate ; CN= Mary White" while the permanent
identifier would be "C = US ; OU = Delta ; SN= 12345" where 12345 is
an employee number assigned by the Delta company. In that case Mary
White gets married with Mr Green and becomes "Mary Green". Her
permanent identifier does not change. Another example is that she
moves from "Corporate" to "Marketing". Her permanent identifier does
not change.

Note that the last case also allows to solve the problem of re-use
of DN names and directory names. A DN or a directory name that has
been used in a certificate can be re-used after the certificate that
contained it has expired, as long as a permanent identifier, instead
of the DN or the directory name, can be used by a relying party,
e.g. in an ACL.

A sub-goal is to be able to know what are the components of a
permanent identifier without the need to make any look up. This
means that the certificate must contain all the information to
interpret directly the semantics of the serial number. Proposals 1,
2, and 3 to the issue 2 do not solve this concern.

However, the proposal 4 would fit that concern with some changes. It
is suggested to repeat information into the directory name.

However a directory name is defined in X.501 as: "A construct that
singles out a particular object from all other objects. A name shall
be unambiguous (that is, denote just one object), however it need
not be unique (that is, be the only name which unambiguously denotes
the object)."

The semantics of a directory name does not allow to play the role of
a permanent identifier. We thus need a new form for this. From RFC
2459 we have:

SubjectAltName ::= GeneralNames

      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     Name,
           ediPartyName                    [5]     EDIPartyName,
           uniformResourceIdentifier       [6]     IA5String,
           iPAddress                       [7]     OCTET STRING,
           registeredID                    [8]     OBJECT
IDENTIFIER}

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

We could define under OtherName a "permanentIdentifier". We would
then need to get/obtain an OID for it. We would define the
permanentIdentifier as a Name.

If the name of the certificate owner changes, the
permanentIdentifier does not change. The content of the
permanentIdentifier can be used in an ACL.

In order to fit with the approach above, since the serial number
solves two different issues, we need two different statements to
cover both cases a) and b).

For case a), here is the proposal :

"A serial Number attribute may be used either in a DN or a
SubjectAltName to differentiate between two names (for two different
individuals) that otherwise would not be different."

For case b), here is the proposal :

"A serial Number attribute may be used in a permanentIdentifier in
an otherName from a SubjectAltName. In that case, when used in
combination with the other components of the permanentIdentifier, it
defines a permanent identifier for the certificate owner for the
issuing CA (that is, two different entities will never get the same
permanent identifier)."

In the security consideration section we can now have the following
text :

"A given physical entity may have at an instant of time or at
different instant of time multiple forms of unmistakable identity.
If two certificates contain two identical permanentIdentifiers in an
otherName from a SubjectAltName, then it is possible to determine by
examination if two qualified certificates refer to the same physical
entity."

Regards,

Denis


> All,
>
> I'd like to summarize and propose a consensus solution to the serialNumber
> Issue in QC 03.
>
> First of all I would like to point out that this is not at debate of
whether
> to use serialNumber or any other attribute (that issue was settled last
> year). This is a debate regarding:
>
> 1) to define the semantics for information hold in the serial Number
> attribute
> 2) how to indicate the applied semantics and characteristics of the
> serialNumber attribute use in a particular certificate.
>
> The proposed text regarding issue 1 is:
>
>     "The serialNumber attribute type SHALL, when present, be used
>     to differentiate between names where the subject field might
>     otherwise be identical.  This attribute has no defined semantics
>     beyond ensuring uniqueness of subject names."
>
> This covers a number of usages from codes that may be reused among
entities
> to globally unique identifiers. Just as long as they provide uniqueness of
> subject names.
>
> Issue 2 have several valid solution which all are supported by the current
> text:
>
> 1) Implicit knowledge
> 2) Through information defined by a certificate policy OID (contained in
the
> referred policy or the associated CPS).
> 3) Through semantics information defined by an OID in the qcStatements
> extension.
> 4) Through repeating information into the subjectAltName extension as a
> directory name.
>
> Solution 4 was the last solution discussed on the list and could easily
> handle the case where a subset of the attributes in the subject field have
> the capacity to identify a person. By duplicating these attributes as a
> directoryName in the subjectAltName extension, The CA also indicates that
> this set of attributes provide a complete DN.
>
> We can conclude that all options above are valid. We can also conclude
that
> this solution is already supported  by X.509 and thus, doesn't need
further
> profiling.
>
> I would personally avoid inclusion/recommendations of this solution in QC
> 03) since that may imply that this solution is more valid than any other
> solution mentioned above.
>
> The conclusion is that QC 03 should remain unchanged with respect to this
> topic.
>
> /Stefan



Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05185 for <[e-mail]>; Mon, 20 Mar 2000 10:51:03 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00224 for <[e-mail]>; Mon, 20 Mar 2000 11:52:45 -0700 (MST)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA03861 for <[e-mail]>; Mon, 20 Mar 2000 13:52:44 -0500 (EST)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id NAA01689; Mon, 20 Mar 2000 13:52:43 -0500 (EST)
From: Anne Anderson <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 20 Mar 2000 13:52:43 -0500 (EST)
To: [e-mail]
Subject: NameConstraints clarifications needed
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid

I have identified two possible clarifications needed with
NameConstraints.

1. For DNS names, is there any way to constrain the permitted or
   excluded SubjectAlternativeNames to a single host?

   According to both RFC2459 and draft-ietf-pkix-new-part1-01.txt, a
   constraint of the form foo.bar.com would permit or exclude not
   only foo.bar.com, but also www.foo.bar.com and wwwfoo.bar.com.

   Note that this differs from the treatment of DNS names when they
   are included in names of type UniformResourceIdentifier or
   RFC822Name.  In these name types, the DNS name portion must be
   preceded by "." in order to include subdomains; otherwise, the
   DNS name constraint specifies only the specified host.

2. For NameConstraints of type UniformResourceIdentifier, if the
   host name is specified as an IPAddress, can that IPAddress be a
   range of addresses (e.g. 10.9.8.0/255.255.255.0)?  The text
   states "When the constraint does not begin with a period, it
   specifies a host," but this is in a context of discussing only
   host names of type DNS name, so it is not entirely clear.

Anne
-- 
Anne H. Anderson             Email: [e-mail]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: from facade.firsthop.fi (facade.firsthop.fi [195.163.185.50]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA01069 for <[e-mail]>; Mon, 20 Mar 2000 07:26:59 -0800 (PST)
Received: (qmail 4681 invoked by uid 516); 20 Mar 2000 15:28:41 -0000
Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Mar 2000 15:28:41 -0000
Date: Mon, 20 Mar 2000 17:28:41 +0200 (EET)
From: =?ISO-8859-1?Q?Juha_P=E4=E4j=E4rvi?= <[e-mail]>
X-Sender: [e-mail]
Reply-To: =?ISO-8859-1?Q?Juha_P=E4=E4j=E4rvi?= <[e-mail]>
To: SPKI list <[e-mail]>, PKIX list <[e-mail]>
Subject: XML Encoded SPKI Certificates
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

Hi,

I have released an Internet-Draft that defines XML encoding for SPKI
certificates. The draft can be accessed at

http://www.ietf.org/internet-drafts/draft-paajarvi-xml-spki-cert-00.txt

The draft combines existing SPKI structures, XML encoding and
XML-signature (defined by XML-Signature WG). In particular, the draft
concentrates on XML encoding of SPKI authorization certificates.

I will present the draft for the XML-Signature WG as an application
example of XML-signature at Adelaide (Monday, March 27, 1300-1500 at room
10).

To mention just a couple of topics that might be of interest to SPKI and
PKIX mailing list members:
 -The introduction chapter of the draft discusses the benefits of XML
  encoding for certificates over other encoding options.
 -Appendix B contains an example of an XML encoded SPKI authorization
  certificate.


Regards,
        Juha

--
j u h a    p ä ä j ä r v i
     [R&D Engineer]                                      First Hop Ltd.
                                                         Tekniikantie 12
work   [phone]    [e-mail]    FIN-02150 Espoo
mobile [phone]    www.firsthop.com              Finland




Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28792 for <[e-mail]>; Mon, 20 Mar 2000 06:04:42 -0800 (PST)
Received: by balinese.baltimore.ie; id OAA08173; Mon, 20 Mar 2000 14:06:19 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma008156; Mon, 20 Mar 00 14:06:05 GMT
Received: from baltimore.ie (lease168-21.baltimore.ie [192.168.21.168]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA19825; Mon, 20 Mar 2000 14:05:45 GMT
Message-ID: <[e-mail]>
Date: Mon, 20 Mar 2000 14:05:47 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Charles W. Gardiner" <[e-mail]>
CC: "'PKIX'" <[e-mail]>, "Manger, James H" <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B2D@NTMSG0131> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Charles W. Gardiner" wrote:
> 
> At 02:53 PM 3/16/2000 +0000, Stephen Farrell wrote:
> >
> >All,
> >
> >Now that the other angels are dancing on the naming pin,
> >maybe we can finish this one quickly!
> >
> >> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits
> 
>     This gets my vote.  As far as I can tell, all anyone does with these is
> match them as octet strings.  (I wouldn't mind a 31- or 32-bit restriction
> on each component.)

That last was choice 3 or 4, not 1. We've only been discussing the size
of the components, not the overall size.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28345 for <[e-mail]>; Mon, 20 Mar 2000 06:02:38 -0800 (PST)
Received: by balinese.baltimore.ie; id OAA07896; Mon, 20 Mar 2000 14:04:19 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma007820; Mon, 20 Mar 00 14:03:51 GMT
Received: from baltimore.ie (lease168-21.baltimore.ie [192.168.21.168]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA19589; Mon, 20 Mar 2000 14:03:41 GMT
Message-ID: <[e-mail]>
Date: Mon, 20 Mar 2000 14:03:44 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], xme <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
> Why do you need to break it down into components though?

There are a few reasons why this happens:

- GUIs that involve entry/display of dot separated OIDs
- referencing PKIX related OIDs in an SNMP context 

Not saying these are compelling, but I certainly don't
find 9216 bit long OID arc elements compelling!

Actually, the SNMP RFC does set a precedent, doesn't it?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26988 for <[e-mail]>; Sun, 19 Mar 2000 08:34:17 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA08479; Sun, 19 Mar 2000 08:35:12 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 19 Mar 2000 11:33:41 -0500
To: "Valery Smyslov" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Certificate verification algorithm
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Valera:

You are correct.  I misunderstood your first posting.

We need to update the approved_reasons to be the union of the previous 
approved_reasons and intersection of the Certificate CRLDP reasons with the 
CRL IDP onlySomeReasons.

Russ


At 12:29 PM 03/16/2000 +0300, Valery Smyslov wrote:
>On 15 Mar 00, at 13:56, Russ Housley wrote:
>
>Russ,
>
>thanks for your reply. I understand your example. However, it seems to me 
>that
>the current text doesn't follow the logic you've described. Let me try to
>explain it in more detail.
>
>The "CRL validation" algorithm, described in 6.3, defines approved_reasons as
>the variable that "contains the set of revocation reasons supported by the
>approved_CRLs". It is initialized to the empty set. Then, each of the 
>possible
>CRLs after its validation is processed as follows (until "the 
>approved_reasons
>= "all reasons" or approved_reasons is a superset of which_reasons or
>possible_CRLs is exhausted"): if current CRL does'nt include an IDP 
>extension,
>or the onlySomeReasons field is not present in that extension, set
>approved_reasons to "all_reasons" (special case); if current CRL  includes an
>IDP extension, and the onlySomeReasons field is present, "assign
>approved_reasons the intersection of approved reasons and the onlySomeReasons
>field".
>
>In other words, apart from the special case when CRL doesn't contain IDP
>extension or that extension doesn't contain onlySomeReasons field, the text
>assumes that:
>
>approved_reasons = approved_reasons AND IDP.onlySomeReasons
>
>Even from the pure logic this is a senseless operation, because 
>intersection of
>an empty set (initial value for approved_reasons) with any set will always be
>an empty set. From the logical point of view it seems to me that this should
>be:
>
>approved_reasons = approved_reasons OR IDP.onlySomeReasons
>
>e.g. approved_reasons should accumulate reasons that are covered by already
>processed CRLs until all reasons of interest are covered, so that we can skip
>the unnecessary processing of remaining CRL. Am I right?
>
>However, after considering your example, it seems to me that correct logic
>should be:
>
>approved_reasons = approved_reasons OR (CDP.reasons AND IDP.onlySomeReasons)
>
>In other words, set of reasons, supported by current CRL must be 
>considered as
>an intersection of the CRL's IDP.onlySomeReason field and the "reasons" field
>of the CDP extension that points to that CRL in the certificate being
>validated. Is it right? If so, this requires some modification to the
>algorithm, because  currently CDP.reasons doesn't take part in CRL validation
>algorithm at all.
>
>Please, correct me if I'm wrong.
>
>Regards,
>Valera.
>
> > Valera:
> >
> > The text is correct.
> >
> > I made a posting to this list while we were developing this text that
> > explain is significant detail.  Let me see if I can try again.
> >
> > Consider the following example:
> >     Cert-A contains a CRLDP that points to CRL-X with reasons
> >          {keyCompromise, affiliationChanged}
> >     Cert-B contains a CRLDP that points to CRL-X with reasons
> >          {cACompromise, cessationOfOperation}
> >     CRL-X contains an IDP with onlySomeReasons
> >          {keyCompromise, cACompromise, superseded}
> >
> > The issuer of Cert-A is delegating the revocation notification of
> > keyCompromise and affiliationChanged reasons to the issuer of CRL-X.  The
> > issuer of CRL-X has not covered all of the reasons that the issuer of
> > Cert-A expected.  That is, the affiliationChanged is not handled.  The
> > intersection operation ensures that the validation of Cert-A only 
> considers
> > CRL-X for keyCompromise.
> >
> > Similarly, a certificate user that tries to validate Cert-B, when
> > processing CRL-X, only gets coverage for cACompromise.
> >
> > Russ
> >
> >
> > At 05:14 PM 03/14/2000 +0300, Valery Smyslov wrote:
> > >Hi,
> > >
> > >I have one question about certficate verification algorithm described in
> > >son-of-2459. Section 6.3.3, Step1, second "b", (ii) on page 71 states:
> > >
> > >---------------------------------------------------------------------
> > >             (ii) If CRL X did not include an issuing distribution point
> > >             extension, or the onlySomeReasons field was not present in
> > >             that extension, set approved_reasons to "all_reasons."  If
> > >             CRL X includes an issuing distribution point extension, and
> > >             the onlySomeReasons field is present, assign
> > >             approved_reasons the intersection of approved reasons and
> > >                                  ^^^^^^^^^^^^
> > >             the onlySomeReasons field.
> > >---------------------------------------------------------------------
> > >
> > >Isn't it a typo in this paragraph? Shouldn't it be "union" instead of
> > >"intersection"? Otherwise this logic is unclear to me.
> > >
> > >The same paragraph appears also on the next page (72).
> > >
> > >Regards,
> > >Valera Smyslov.
> >
> >



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21065 for <[e-mail]>; Sat, 18 Mar 2000 12:59:03 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA19486; Sun, 19 Mar 2000 09:00:13 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95341321328831>; Sun, 19 Mar 2000 09:00:13 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: ACprof: 28-bit restriction on OID components
Cc: [e-mail]
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sun, 19 Mar 2000 09:00:13 (NZST)
Message-ID: <[e-mail]>

Brian Tvedt <[e-mail]> writes:

>Right now our Java libraries require each component to be an int (limited to 
>31 bits for positive numbers).  We could accomodate BigInteger's without much
>problem, but why do it if OIDs that require them are never encountered?

Why do you need to break it down into components though?  The only thing you
ever do with an OID is a comparison for equality, why impose arbitrary limits 
on it based on the underlying CPU architecture of the platform which is
processing it?

Peter.



Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21519 for <[e-mail]>; Fri, 17 Mar 2000 12:09:58 -0800 (PST)
Received: from trsvrbk.tr.unisys.com (trsvrbk.tr.unisys.com [192.63.236.1]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id UAA05536 for <[e-mail]>; Fri, 17 Mar 2000 20:08:52 GMT
Received: from US-TR-EXCH-1.tr.unisys.com by trsvrbk.tr.unisys.com (8.8.5/8.8.5) id UAA25453 ; Fri, 17 Mar 2000 20:10:59 GMT
Received: by us-tr-exch-1.tr.unisys.com with Internet Mail Service (5.5.2650.21) id <G68CP356>; Fri, 17 Mar 2000 15:11:10 -0500
Message-ID: <[e-mail]>
From: "Kain, Michael T" <[e-mail]>
To: [e-mail]
Cc: "Kain, Michael T" <[e-mail]>
Subject: Where to put additional information in certificate?
Date: Fri, 17 Mar 2000 15:11:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I'm in a dilemma.  I'm trying to define multiple websites
for a machine (multiple ports), each with its own certificate.  
Each certificate has to have the same name, but I have to 
store the certificate in a unique container (name).  I'm looking for an OID
to put "alternate" information into the certificate request, so that 
the Certificate Authority will pass through into the resultant 
certificate.

>From the comments in WinCrypt.h (Microsoft) I have:

#define szOID_DN_QUALIFIER                  "2.5.4.46"

// The DN Qualifier attribute type specifies disambiguating information to
add
// to the relative distinguished name of an entry. It is intended to be used
// for entries held in multiple DSAs which would otherwise have the same
name,
// and that its value be the same in a given DSA for all entries to which
// the information has been added.

I haven't read through RFC 2459 for how it feels about this field
(or the new draft.part01 which I received)...  Is this field right, or does
another one make more sense?

Mike Kain
Open Networking Group, Networking & I/O Channels
Unisys Corporation, Malvern, PA [[e-mail]]

Adjunct Professor, Math & Computer Science Department
Drexel University, Philadelphia, PA [[e-mail]]



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16511 for <[e-mail]>; Fri, 17 Mar 2000 08:18:45 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 17 Mar 2000 09:19:36 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 17 Mar 2000 09:19:21 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16512

This isn't quite an OID, but in the Novell Security Attributes 
which we include in all our certificates, there is a capability 
of assigning a unique number to "registries", which might 
correspond to public CAs, and to "enterprises". This concept 
is used to manage a globally unique mandatory access control 
label. (For the gory details, cf. http://developer./novell.com/repository/attributes/certattrs_v10.htm 

The algorithm we use to assure global uniqueness of an 
identifier is to take the organization ID assigned by a 
national standards body, multiply it by 1024, and add 
the unique country code.

The conventional name registration arc wouldn't work, 
because we needed a simple way to represent 
what is effectively a bit number in a virtual label string.
And this is when I discovered, courtesy of Peter Gutman, 
that Australia uses a nine digit number for enterprises, much 
ike the US Social Security Number.

That was when I became convinced that trying to use ASN.1 
like it was COBOL, and worry about fitting numbers into machine 
word representations was A Bad Idea.

As the Pennsylvania Dutch say,
"Ve get so soon alt, und so late schmart!"

Bob



>>><[e-mail]> 03/16/00 08:25AM >>>
 There is at least one plausible use for OID components greater than 31
or 32 bits. If an experimental OID arc were to be defined under which
OID's could be assigned with a format similar to { id-experimental
E163-phone-number date-of-assignment user-defined-num }, the E.163 phone
number would not usually fit in 31 or 32 bits. Indeed, even if the country
prefix were separated out, North American numbers would take 34 bits.
Presumably such an arc could only be used for temporary assignments since
it would lack a central registry, but OID's under it would be globally
unique since the owner of a given phone number on a given date is
well-defined (the owner of a given phone number is NOT well-defined for all
time). One could probably get around this by defining a similar arc under
which the phone number would be split into three components: country code,
area or regional code, and local number.
 Something similar would be true if a similar arrangement were made
based on IPv6 addresses, which would even overflow 63-64 bits.
 Thus, one reason for large OID components is the desire to have a sort
of automatic registration for assignment authorities. Personally, I can't
think of any other reason, but maybe someone else can :-)

 Tom Gindin

Stephen Farrell <[e-mail]> on 03/16/2000 09:53:53 AM

Please respond to [e-mail] 

To: "'PKIX'" <[e-mail]>
cc: "Manger, James H" <[e-mail]>, xme
<[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components




All,

Now that the other angels are dancing on the naming pin,
maybe we can finish this one quickly!

> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits
> 2nd choice: support the greater of 32 bits or the computer's largest
> natively supported word size
> 3rd choice: support <= 32 bits
> 4th choice: support <= 31 bits
> unacceptable: support <= 28 bits

I go for your 4th, and would note that rfc2459 already contains
analagous things, e.g. ub-common-name is 64 etc, and that SNMP
also has limits (to 32 bits, rfc2578) but I'd still prefer 31
'cause of Java. I'd also be quite happy with SHOULD be <=31 and
MUST be <=32.

(BTW: I really wonder whether we need more OIDs than there
are atoms in the Universe or whatever. Presumably at some
stage the only object left to identify would be another
OID:-)

Stephen.

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) [phone]
61 Fitzwilliam Lane, fax: [phone]
Dublin 2.mailto:[e-mail] 
Irelandhttp://www.baltimore.com 







Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15076 for <[e-mail]>; Fri, 17 Mar 2000 07:29:39 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA146032 for <[e-mail]>; Fri, 17 Mar 2000 10:29:06 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA207436 for <[e-mail]>; Fri, 17 Mar 2000 10:30:28 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568A5.00552E3B ; Fri, 17 Mar 2000 10:30:23 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 17 Mar 2000 10:30:12 -0500
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-01.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     In the new section 6.3.3, step 2e, it needs to be specified that when
a base and delta CRL are combined to make a complete CRL, an entry with
reason code removeFromCRL causes the omission of any entries with the same
certificate serial number, reason code certificateHold, and a
revocationDate which is not later than the removeFromCRL one, while the
entry with reason code removeFromCRL is also omitted from the complete CRL.
Otherwise, the combination involves the concatenation of the delta's
revokedCertificates to the base's.

          Tom Gindin






Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13686 for <[e-mail]>; Fri, 17 Mar 2000 06:48:43 -0800 (PST)
Received: from gardiner.bbn.com (dhcp030-247.bbn.com [171.78.30.247]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id JAA18362; Fri, 17 Mar 2000 09:44:13 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 17 Mar 2000 09:45:11 -0500
To: [e-mail], "'PKIX'" <[e-mail]>
From: "Charles W. Gardiner" <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
Cc: "Manger, James H" <[e-mail]>, xme <[e-mail]>
In-Reply-To: <[e-mail]>
References: <73388857A695D31197EF00508B08F2988A3B2D@NTMSG0131>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 02:53 PM 3/16/2000 +0000, Stephen Farrell wrote:
>
>All,
>
>Now that the other angels are dancing on the naming pin,
>maybe we can finish this one quickly!
>
>> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits

    This gets my vote.  As far as I can tell, all anyone does with these is
match them as octet strings.  (I wouldn't mind a 31- or 32-bit restriction
on each component.)

Charlie Gardiner



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09000 for <[e-mail]>; Fri, 17 Mar 2000 05:22:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22429; Fri, 17 Mar 2000 08:23:34 -0500 (EST)
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-new-part1-01.txt
Date: Fri, 17 Mar 2000 08:23:33 -0500
Sender: [e-mail]

--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 and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk,  D. Solo
	Filename	: draft-ietf-pkix-new-part1-01.txt
	Pages		: 146
	Date		: 16-Mar-00
	
This is the first draft of a specification based upon RFC 2459.  When
complete, this specification will obsolete RFC 2459.  This
specification includes numerous edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.  However,
parameter inheritance was omitted from the path validation algorithm in RFC 2459.  In this draft, the path validation algorithm has a
comprehensive and extremely detailed description.  Details such as
parameter inheritance are covered thoroughly.  In addition, this
draft anticipates certain corrections proposed in the X.509 standard
for the policy processing aspects of path validation.
A new section 6.3, CRL validation, has been added as well.  This
section provides a supplement to the path validation algorithm that
determines if a particular CRL may be used to verify the status of a
particular certificate.  (The basic path validation algorithm is, by
design, independent of the type and format of status information.)
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.  An overview of the approach and model are provided
as an introduction.  The X.509 v3 certificate format is described in
detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses).  Standard
certificate extensions are described and one new Internet-specific
extension is defined.  A required set of certificate extensions is
specified.  The X.509 v2 CRL format is described and a required
extension set is defined as well.  An algorithm for X.509 certificate
path validation is described. Supplemental infor

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

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-new-part1-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-new-part1-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-new-part1-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-new-part1-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 www.charteralliance.com ([206.114.168.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21302; Fri, 17 Mar 2000 00:39:49 -0800 (PST)
From: [e-mail]
Received: from avation - 206.114.168.98 by www.charteralliance.com  with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 16 Mar 2000 13:04:04 +0000
To: [e-mail]
Subject: Post & Search Empty Legs FREE!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Message-ID: <[e-mail]>
Date: 16 Mar 2000 13:04:04 +0000

CHARTER OPERATORS! POST YOUR AVAILABLE FLIGHTS 
& DEAD LEGS ONTO OUR SITE ABSOLUTELY FREE! 
REGISTER AT:   http://www.charteralliance.com/register.asp 

CHARTER BUYERS! HAVE EMPTY LEGS EMAILED TO YOU 
EVERY DAY ABSOLUTELY FREE! REGISTER ONLINE OR 
REPLY TO THIS EMAIL. 

For the very first time CharterAlliance.com brings the industry 
operators  & buyers together by offering a totally FREE service 
that optimizes the selling and  purchasing of those available flights 
& empty legs.  Not only  are the dead legs posted onto our high 
traffic Internet site but they also get emailed out to a vast network 
of brokers & industry buyers twice daily! CharterAlliance.com 
is the only posting site that actually places this vital information 
into buyer's hands and we do this for YOU absolutely FREE! 
International operators & buyers welcome. Start increasing your 
bottom line right now! Make sure that you become one of our 
members today. 

CHARTER OPERATORS: 

* Create a powerful new revenue stream instantly! 
* Increase aircraft utilization! 
* Postings for: Charter, Cargo, & Air Ambulance! 
* Separate postings for available flights & empty legs! 
* Marketed to a vast network of brokers and industry buyers 
* Put the power of the Internet, with our marketing muscle, behind you! 

Just go to: http://CharterAlliance.com/register.asp, register, and 
start posting!  It's FREE! 

**** ADDITIONAL BONUS! Register with our site and receive three full 
months of advertising on CharterAlliance.com absolutely FREE! 

CHARTER BUYERS: 

* Hundreds of flights! 
* So powerful, yet easy to use! 
* Advanced searches by categories you set up! 
* Daily digest of empty legs emailed to you twice daily! 

Do you want our daily digest of available deadheads emailed to you 
every day? Just respond to this message! Leave the Subject line intact. 
If you want this valuable information to go to any other addresses 
just type them  into the top of the Body of this message. You can 
also accomplish this by visiting our site: 
http://CharterAlliance.com/register.asp 

CharterAlliance.com has a global vision for how information will be 
shared among the Charter Aviation Industry in the Twenty First Century. 
This is only the beginning. Visit us at http://CharterAlliance.com to 
find out more about our exciting services. 

******************************************* 
To be removed from this email list, reply to this email with 
"remove" in the Subject line.  Thanks.



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA15419 for <[e-mail]>; Thu, 16 Mar 2000 22:19:33 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.5) id JAA00241; Fri, 17 Mar 2000 09:20:56 +0300 (MSK)
Message-Id: <[e-mail]>
Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0) id xma000221; Fri, 17 Mar 00 09:20:09 +0300
From: "Valery Smyslov" <[e-mail]>
Organization: TWS
To: [e-mail]
Date: Fri, 17 Mar 2000 09:20:05 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Certificate verification algorithm
CC: Russ Housley <[e-mail]>, [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12b)

On 16 Mar 00, at 11:06, [e-mail] wrote:

Tom,

thank you for good example. That's exactly what I meant.

Best regards,
Valera.

>      I think you're probably right about updating approved_reasons by doing
> unions rather than intersections.  Here's an example of why, which neglects
> CRL Distribution Points as unnecessary to this point.  Suppose that every
> CRL processed has a single-bit value in onlySomeReasons (inside
> issuingDistributionPoint) and which-reasons is initialized to a two-element
> set, approved_reasons starts as an empty value and can never take on any
> value with more than one element by performing intersections.  Thus step
> 1-d of section 6.3.3 will always result in the certificate being rejected,
> since approved_reasons will never be a superset of which-reasons.
> 
>           Tom Gindin
> 
> 
> 




Received: from www.charteralliance.com ([206.114.168.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08142; Thu, 16 Mar 2000 20:17:05 -0800 (PST)
From: [e-mail]
Received: from avation - 206.114.168.98 by www.charteralliance.com  with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 16 Mar 2000 13:25:49 +0000
To: [e-mail]
Subject: FREE Aviation Scheduling!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Message-ID: <[e-mail]>
Date: 16 Mar 2000 13:25:49 +0000

FREE SIX-MONTH MEMBERSHIP OF 
INTERNET BASED PRIMARY SCHEDULING 
& DISPATCHING SOLUTION GIVES YOU 
FREEDOM FROM THE LIMITATIONS OF 
YOUR EXISTING SCHEDULE! 

Welcome to the future of aviation scheduling & dispatching! 
No longer will you have to install a cumbersome, and costly, 
network system to take advantage of advances in scheduling 
technology.  From now on, aviation software packages
are a thing of the past.  In fact, with our solution, there is 
nothing to buy!  All that’s needed is a personal computer 
with an Internet connection. Everything's FREE! 

* No Large Purchase of Hardware or Software! 
* Free Your System From the Technology Trap! 
* Works For: 135, 91, Cargo, Flight Schools, etc., etc.! 
* Decrease Dispatcher's Hours & Increase Aircraft Utilization! 
* Easy Multi-User/Multi-Tasking Ability From Anywhere! 
* 135! Post Deadheads Onto the Internet Automatically! 

Our service works better than many software packages 
costing thousands of dollars! Being Internet based, it also 
boasts features that no mere client-server system can match. 
All you have to do is go to: 
http://charteralliance.com/register.asp 
to register. Immediately you can begin benefiting from this 
FREE solution! 

CharterAlliance.com has a global vision for how information 
will be shared among the Charter Aviation Industry in the 
Twenty-First Century. No longer will technological advances 
be only available to the operators who can afford them. Now 
is your chance to climb aboard the cusp of something that is 
sweeping the industry. Don’t delay! This is the key. Use it! 
There are no strings attached! It's FREE! Use it! 


Kiloh R. Smith 
Director of Marketing 
CharterAlliance.com 
[e-mail]
[phone]


*******************************************
To be removed from this list, reply to this email with
"remove" in the subject line.  
We will be announcing other FREE aviation services 
in upcoming emails.   
Remain on this list for these exciting notices.


Received: from www.charteralliance.com ([206.114.168.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16906; Thu, 16 Mar 2000 11:32:44 -0800 (PST)
From: [e-mail]
Received: from avation - 206.114.168.98 by www.charteralliance.com  with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 16 Mar 2000 14:14:15 +0000
To: [e-mail]
Subject: FREE Aviation Scheduling!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Message-ID: <[e-mail]>
Date: 16 Mar 2000 14:14:15 +0000

SIX MONTHS OF FREE BANNER ADVERTISING
ON THE CHARTERALLIANCE.COM INTERNET SITE!

Why are we doing this? The CharterAlliance Internet based
aircraft scheduling & dispatching solution is so advanced, so
easy-to-use, that we will do almost anything to put it into your
hands. Immediately, you will see how this powerful,
easy-to-use, tool can optimize your scheduling & dispatching.

Go to: http://charteralliance.com/register.asp to
register right now.

*No large purchase of hardware or software!

*Secure Internet access for your entire team!

* Easy multi-user and multi-tasking ability!

*100% FREE tech support & system upgrades!

Have you ever wished for an easy-to-use, high-end,
technology solution for your scheduling? Are you tired of
expensive network systems and hard-to-use software
packages that quickly become obsolete? From now on,
aviation "software packages" are a thing of the past. In fact,
with our solution there is nothing to buy; all that's needed is
a personal computer and an Internet connection!

*Bring your scheduling system up to date!

*Increase profit for your organization!

*Publish available flights & deadheads onto the Internet!

*Decrease dispatchers time and increase aircraft utilization!

Go to: http://charteralliance.com/register.asp to register.
There are a limited number of advertising spots and the
quicker you respond the quicker your FREE ad can start.
Remember, even if you don't use our remarkable service
you still get the six months of advertising FREE!
Visit: http://www.CharterAlliance.com



Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12901 for <[e-mail]>; Thu, 16 Mar 2000 08:33:21 -0800 (PST)
Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout3.email.verio.net with esmtp (Exim 3.12 #7) id 12VdEN-0000xF-00; Thu, 16 Mar 2000 16:34:39 +0000
Received: from [209.21.28.118] (helo=nma.com) by dfw-mmp1.email.verio.net with esmtp (Exim 3.12 #7) id 12VdEF-0002GF-00; Thu, 16 Mar 2000 16:34:31 +0000
Message-ID: <[e-mail]>
Date: Thu, 16 Mar 2000 08:35:24 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Anders Rundgren  </o=Jaybis.AB/ou=JAYBIS/cn=Recipients/cn=[e-mail]>, "'Bob Jueneman'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Good at the source, was Re: What good is a DN if the REAL stuff is  somewhere else?
References: <01BF8F50.9C2B6AF0@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> Bob,
> What you are saying is that DN is a lost case and cannot be used
> for anything except for pointing out a storage position in a directory.
>
> So unmistakable identity is to be found somewhere else?

There is IMO a reference-frame confusion here.  The concept of
"unmistakable identity" is being defined under the QC draft in
terms of the "source" (the directory), not in terms of the
"receiver" (you).

These two views are incompatible and even unknowable I
advance, because the basic tenet in communication is that
there is a chasm between source and receiver -- which is made
worse in the Internet by having one source and 400,000,000
receivers.

So, Bob J. is correct (as well as David K.) IMO, because that
"unmistakable identity" must be defined in directory terms for
the QC based on that directory.  OTOH, in your directory, or
end-user application, you may decide to provide quite another
"unmistakable identity" to that QC -- for example, the timestamp
in milliseconds when that QC: (a) entered your system, (b) was
accepted by you in terms of its signature validation, (c) was
verified by you in terms of its absence in a CRL, (d) was
verified by you in terms of its key challenge-response, etc.
These are *all* an "unmistakable identity" for that QC * within
your system*.  There are many other possibilities, of course.

So, "What good is a DN if the REAL stuff is somewhere else?"
Answer: good at the source, cope with it at your end.

And, X.509/PKIX certificates in general are not different.  In legal
reliance terms, one (the receiver) may trust the confirmation procedures
of the CA during certificate reliance, but one cannot rely upon them
for other than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules (the
source) -- therefore, a X.509 certificate is neither necessarily meaningful
nor valid in a user's reference frame or for the user's purposes.

The source of the confusion is to think that data is absolute.
It isn't -- data is relative. More on this if you wish, off list.

Cheers,

Ed Gerck


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12326 for <[e-mail]>; Thu, 16 Mar 2000 08:16:05 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27193 for <[e-mail]>; Thu, 16 Mar 2000 17:17:26 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 16 Mar 2000 17:17:26 +0100 (MET)
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 RAA09918 for <[e-mail]>; Thu, 16 Mar 2000 17:17:25 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA09874 for [e-mail]; Thu, 16 Mar 2000 17:17:25 +0100 (MET)
Date: Thu, 16 Mar 2000 17:17:25 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: ACprof: 28-bit restriction on OID components

 
> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits

Was there some agreement that there is probably only some need to
either have the internal octet representaion or an external decimal
string dotted notation ? if so, I'd go for this one. 

One of two conversion routines is something like that. There might be bugs,
and you have to guess the definition of the types. 

/* TBC : should test some errors; First and second number present or else */
static CF_ReturnCode CM_rfc2oid(asn1_field * oid, VSChar * f, VSInt f_len)
{
  asn1  my_octets ;
  asn1  octets_end ;
  asn1  begin ;
  asn1  actual ;
  asn1  last; 
  VSInt first ;
  register VSInt i;

  if((my_octets = (asn1) asn1_malloc(f_len)) == NULL) return CF_MEMORY_ERR ;
 /* too much, but who cares */
  
  octets_end = my_octets + f_len - 1 ;
  begin = my_octets;

  if (*f < '0' || *f > '2') {env_free(my_octets); return CF_SUCCESS ;}
  first = (*f - '0'); f++; f_len --;
  if (!f_len) {env_free(my_octets); return CF_SUCCESS ;}
  if (*f != '.') {env_free(my_octets); return CF_SUCCESS ;}
  f++ ; f_len--;
  if (!f_len) {env_free(my_octets); return CF_SUCCESS ;}

  while(f_len >0) {
    actual = octets_end;
    i = 0;
    *actual = 0;
    while(f_len > 0 && *f != '.') {

      if ((*f != '0' || i > 0 || last > actual) && *f >= '0' && *f <= '9') {
        last = octets_end;
        i = (*f - '0');
        while (last >= actual) {
          i = *last * 10 + i;	
          if (first >= 0 && i>=10) {
            if ((first < 2) && (i > 39)) {env_free(my_octets); return CF_SUCCESS ;}
            i+=(first*40) ; first = -1;						
          }
          *last = i % 128; i = i/128 ; last--;
        }
        if (i > 0) { actual--; *actual = i ; }				
      }
      f++; f_len--;								
    }
    if (first >=0) *last += (first*40) ; 
    first = -1;
			 
    if (*f == '.') {f++; f_len--;}

    last = octets_end;
    while (actual <= last) {
      *begin = *actual | 0x80 ;  begin++ ; actual++ ;
    }
    *(begin-1) &= 0x7F ;			
  }

  if (begin == my_octets) {env_free(my_octets); return CF_SUCCESS ;} 

  oid->l = (begin - my_octets);
  oid->v = my_octets;

  return CF_SUCCESS;	
}	


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11848 for <[e-mail]>; Thu, 16 Mar 2000 08:05:26 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA268286; Thu, 16 Mar 2000 11:05:22 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA28016; Thu, 16 Mar 2000 11:06:43 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568A4.005880E5 ; Thu, 16 Mar 2000 11:06:41 -0500
X-Lotus-FromDomain: IBMUS
To: "Valery Smyslov" <[e-mail]>
cc: Russ Housley <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 16 Mar 2000 11:06:22 -0500
Subject: Re: Certificate verification algorithm
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I think you're probably right about updating approved_reasons by doing
unions rather than intersections.  Here's an example of why, which neglects
CRL Distribution Points as unnecessary to this point.  Suppose that every
CRL processed has a single-bit value in onlySomeReasons (inside
issuingDistributionPoint) and which-reasons is initialized to a two-element
set, approved_reasons starts as an empty value and can never take on any
value with more than one element by performing intersections.  Thus step
1-d of section 6.3.3 will always result in the certificate being rejected,
since approved_reasons will never be a superset of which-reasons.

          Tom Gindin




Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10611 for <[e-mail]>; Thu, 16 Mar 2000 07:25:18 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA154410; Thu, 16 Mar 2000 10:24:50 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA40222; Thu, 16 Mar 2000 10:26:11 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568A4.0054CA8A ; Thu, 16 Mar 2000 10:26:08 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: "'PKIX'" <[e-mail]>, "Manger, James H" <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 16 Mar 2000 10:25:57 -0500
Subject: Re: ACprof: 28-bit restriction on OID components
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     There is at least one plausible use for OID components greater than 31
or 32 bits.  If an experimental OID arc were to be defined under which
OID's could be assigned with a format similar to { id-experimental
E163-phone-number date-of-assignment user-defined-num }, the E.163 phone
number would not usually fit in 31 or 32 bits.  Indeed, even if the country
prefix were separated out, North American numbers would take 34 bits.
Presumably such an arc could only be used for temporary assignments since
it would lack a central registry, but OID's under it would be globally
unique since the owner of a given phone number on a given date is
well-defined (the owner of a given phone number is NOT well-defined for all
time).  One could probably get around this by defining a similar arc under
which the phone number would be split into three components: country code,
area or regional code, and local number.
     Something similar would be true if a similar arrangement were made
based on IPv6 addresses, which would even overflow 63-64 bits.
     Thus, one reason for large OID components is the desire to have a sort
of automatic registration for assignment authorities.  Personally, I can't
think of any other reason, but maybe someone else can :-)

          Tom Gindin

Stephen Farrell <[e-mail]> on 03/16/2000 09:53:53 AM

Please respond to [e-mail]

To:   "'PKIX'" <[e-mail]>
cc:   "Manger, James H" <[e-mail]>, xme
      <[e-mail]>
Subject:  Re: ACprof: 28-bit restriction on OID components




All,

Now that the other angels are dancing on the naming pin,
maybe we can finish this one quickly!

> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits
> 2nd choice: support the greater of 32 bits or the computer's largest
> natively supported word size
> 3rd choice: support <= 32 bits
> 4th choice: support <= 31 bits
> unacceptable: support <= 28 bits

I go for your 4th, and would note that rfc2459 already contains
analagous things, e.g. ub-common-name is 64 etc, and that SNMP
also has limits (to 32 bits, rfc2578) but I'd still prefer 31
'cause of Java. I'd also be quite happy with SHOULD be <=31 and
MUST be <=32.

(BTW: I really wonder whether we need more OIDs than there
are atoms in the Universe or whatever. Presumably at some
stage the only object left to identify would be another
OID:-)

Stephen.

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com





Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09789 for <[e-mail]>; Thu, 16 Mar 2000 06:52:45 -0800 (PST)
Received: by balinese.baltimore.ie; id OAA24009; Thu, 16 Mar 2000 14:54:05 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma023933; Thu, 16 Mar 00 14:53:55 GMT
Received: from baltimore.ie (lease168-21.baltimore.ie [192.168.21.168]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA05239; Thu, 16 Mar 2000 14:53:54 GMT
Message-ID: <[e-mail]>
Date: Thu, 16 Mar 2000 14:53:53 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'PKIX'" <[e-mail]>
CC: "Manger, James H" <[e-mail]>, xme <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B2D@NTMSG0131>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Now that the other angels are dancing on the naming pin,
maybe we can finish this one quickly!

> 1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits
> 2nd choice: support the greater of 32 bits or the computer's largest
> natively supported word size
> 3rd choice: support <= 32 bits
> 4th choice: support <= 31 bits
> unacceptable: support <= 28 bits

I go for your 4th, and would note that rfc2459 already contains
analagous things, e.g. ub-common-name is 64 etc, and that SNMP 
also has limits (to 32 bits, rfc2578) but I'd still prefer 31 
'cause of Java. I'd also be quite happy with SHOULD be <=31 and 
MUST be <=32.

(BTW: I really wonder whether we need more OIDs than there 
are atoms in the Universe or whatever. Presumably at some 
stage the only object left to identify would be another 
OID:-)

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08713 for <[e-mail]>; Thu, 16 Mar 2000 06:24:26 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA28552 for <[e-mail]>; Thu, 16 Mar 2000 09:26:15 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA28547 for <[e-mail]>; Thu, 16 Mar 2000 09:26:14 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA01426 for <[e-mail]>; Thu, 16 Mar 2000 09:26:01 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA00613 for <[e-mail]>; Thu, 16 Mar 2000 09:22:28 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 16 Mar 2000 09:22:28 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: What good is a DN if the REAL stuff is somewhere else?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: eypM7qzRkFTWr1JTaF4Vmg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> Date: Wed, 15 Mar 2000 13:46:13 -0700
> From: "Bob Jueneman" <[e-mail]>
> To: <[e-mail]>, <[e-mail]>, 
<[e-mail]>
> Cc: <[e-mail]>
> 
>   [...]
>
> The DN in the certificate should match whatever the DN in the directory 
> is for that user, as determined by the directory administrator. Period. Finis.
> Full Stop. The End. 
> 
> Otherwise, it may work, but it won't be WORKABLE.
> 
> Any other useful information, such as the user's current "real name", 
> department organization ,street address, DNA encoding, or whatever, 
> that needs to be in the certificate should be carried elsewhere in the 
> certificate, in particular in a subjectAltName, just we do for the RFC822 
> name, and for the same reasons.



The same objective could be accomplished by putting the user's display
name in Certificate:subject, and the directory name in, ummm,
subjectAltName:directoryName.



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA05451 for <[e-mail]>; Thu, 16 Mar 2000 05:13:11 -0800 (PST)
Received: from HYDRA ([195.198.186.78]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id OAA22831; Thu, 16 Mar 2000 14:17:06 +0100
Received: by HYDRA with Microsoft Mail id <01BF8F50.9C2B6AF0@HYDRA>; Thu, 16 Mar 2000 14:04:56 +0100
Message-ID: <01BF8F50.9C2B6AF0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Anders Rundgren </o=Jaybis.AB/ou=JAYBIS/cn=Recipients/cn=[e-mail]>, "'Bob Jueneman'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: What good is a DN if the REAL stuff is somewhere else?
Date: Thu, 16 Mar 2000 14:04:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bob,
What you are saying is that DN is a lost case and cannot be used
for anything except for pointing out a storage position in a directory.

So unmistakable identity is to be found somewhere else?

This is getting weird IMO.

Regarding the RFC822 name it looks like the most well-known CA of all, VeriSign
actually puts it in the DN so apparently theory (PKIX?) and practice are pretty mixed.

BTW, is permanent identifier equivalent to unmistakable identity?  To me
permanent goes one step further.

Although I agree that DN is a lost case, I believe that the better solution is to add an OPTION
to aid its INTERPRETATION, GUI DISPLAY and applicable NAME SPACE.  Such an option
could also include support for subjectAltName in case the directory administrator believes that
this is the place to put the REAL STUFF.   Admittedly a bit hairy

Anders

----------
From:  Bob Jueneman [SMTP:[e-mail]]
Sent:  Wednesday, March 15, 2000 21:46
To:  [e-mail]; [e-mail]; [e-mail]
Cc:  [e-mail]
Subject:  What good is a DN if the REAL stuff is somewhere else?

<<File: ATT00001.htm>>>"What good is a DN if the REAL stuff is somewhere else?"

Anders, this is the train wreck that has been about to happen 
for ten years or more, as a result of overloading the DN and not 
using directories in the way they are typically used in practice.

Render unto Caesar that which is Caesar's, and unto the directory 
administrator as well, and don't try to get organizations to change 
their directory structures to fit your notion of what a certificate should 
look like.  It simply won't work.

As we used to say back in the NADF days, it is like trying to 
teach a pig to whistle.  It's a waste of time, and it annoys the pig!

The DN in the certificate should match whatever the DN in the directory 
is for that user, as determined by the directory administrator. Period. Finis.
Full Stop. The End. 

Otherwise, it may work, but it won't be WORKABLE.

Any other useful information, such as the user's current "real name", 
department organization ,street address, DNA encoding, or whatever, 
that needs to be in the certificate should be carried elsewhere in the 
certificate, in particular in a subjectAltName, just we do for the 
name, and for the same reasons.

Let the record show that for once I agree with Denis. :-)  And by the way, large 
organizations such as the US Navy have come to the same conclusions.

Bob


>>> "Anders Rundgren" <[e-mail]> 03/15/00 12:33PM >>>
Denis,

<snip>

>b) allowing the use of a permanent identifier for an entity, even if
>the name of the entity changes. An example of that case is "C = US ;
>OU = Delta ; OU1= Corporate ; CN= Mary White" while the permanent
>identifier would be "C = US ; OU = Delta ; SN= 12345" where 12345 is
>an employee number assigned by the Delta company. In that case Mary
>White gets married with Mr Green and becomes "Mary Green". Her
>permanent identifier does not change. Another example is that she
>moves from "Corporate" to "Marketing". Her permanent identifier does
>not change. 


What good is a DN if the REAL stuff is somewhere else?

>
>Note that the last case also allows to solve the problem of re-use
>of DN names and directory names. A DN or a directory name that has
>been used in a certificate can be re-used after the certificate that
>contained it has expired, as long as a permanent identifier, instead
>of the DN or the directory name, can be used by a relying party,
>e.g. in an ACL.


I liked your original suggestion

   http://www.imc.org/ietf-pkix/mail-archive/msg04094.html

more as it keeps DN unmistakable,   Re-use of DNs in QCs does not sound
too attractive IMO.

You original suggestion could also easily be expanded to include support for
"Preferred Display DN components" and the Naming Domain issue which so far
has beem totally neglected.

Both your solutions require a new OID to flag "enhanced" sematic interpretation.

Anders

<snip>



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22970 for <[e-mail]>; Thu, 16 Mar 2000 01:28:25 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.5) id MAA03860; Thu, 16 Mar 2000 12:29:43 +0300 (MSK)
Message-Id: <[e-mail]>
Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0) id xma003846; Thu, 16 Mar 00 12:29:14 +0300
From: "Valery Smyslov" <[e-mail]>
Organization: TWS
To: Russ Housley <[e-mail]>
Date: Thu, 16 Mar 2000 12:29:11 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Certificate verification algorithm
CC: [e-mail]
Priority: normal
In-reply-to: <[e-mail]>
References: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12b)

On 15 Mar 00, at 13:56, Russ Housley wrote:

Russ,

thanks for your reply. I understand your example. However, it seems to me that 
the current text doesn't follow the logic you've described. Let me try to 
explain it in more detail.

The "CRL validation" algorithm, described in 6.3, defines approved_reasons as 
the variable that "contains the set of revocation reasons supported by the 
approved_CRLs". It is initialized to the empty set. Then, each of the possible 
CRLs after its validation is processed as follows (until "the approved_reasons 
= "all reasons" or approved_reasons is a superset of which_reasons or 
possible_CRLs is exhausted"): if current CRL does'nt include an IDP extension, 
or the onlySomeReasons field is not present in that extension, set 
approved_reasons to "all_reasons" (special case); if current CRL  includes an 
IDP extension, and the onlySomeReasons field is present, "assign 
approved_reasons the intersection of approved reasons and the onlySomeReasons 
field".

In other words, apart from the special case when CRL doesn't contain IDP 
extension or that extension doesn't contain onlySomeReasons field, the text 
assumes that:

approved_reasons = approved_reasons AND IDP.onlySomeReasons

Even from the pure logic this is a senseless operation, because intersection of 
an empty set (initial value for approved_reasons) with any set will always be 
an empty set. From the logical point of view it seems to me that this should 
be:

approved_reasons = approved_reasons OR IDP.onlySomeReasons

e.g. approved_reasons should accumulate reasons that are covered by already 
processed CRLs until all reasons of interest are covered, so that we can skip 
the unnecessary processing of remaining CRL. Am I right?

However, after considering your example, it seems to me that correct logic 
should be:

approved_reasons = approved_reasons OR (CDP.reasons AND IDP.onlySomeReasons)

In other words, set of reasons, supported by current CRL must be considered as 
an intersection of the CRL's IDP.onlySomeReason field and the "reasons" field 
of the CDP extension that points to that CRL in the certificate being 
validated. Is it right? If so, this requires some modification to the 
algorithm, because  currently CDP.reasons doesn't take part in CRL validation 
algorithm at all.

Please, correct me if I'm wrong.

Regards,
Valera.
 
> Valera:
> 
> The text is correct.
> 
> I made a posting to this list while we were developing this text that 
> explain is significant detail.  Let me see if I can try again.
> 
> Consider the following example:
>     Cert-A contains a CRLDP that points to CRL-X with reasons
>          {keyCompromise, affiliationChanged}
>     Cert-B contains a CRLDP that points to CRL-X with reasons
>          {cACompromise, cessationOfOperation}
>     CRL-X contains an IDP with onlySomeReasons
>          {keyCompromise, cACompromise, superseded}
> 
> The issuer of Cert-A is delegating the revocation notification of 
> keyCompromise and affiliationChanged reasons to the issuer of CRL-X.  The 
> issuer of CRL-X has not covered all of the reasons that the issuer of 
> Cert-A expected.  That is, the affiliationChanged is not handled.  The 
> intersection operation ensures that the validation of Cert-A only considers 
> CRL-X for keyCompromise.
> 
> Similarly, a certificate user that tries to validate Cert-B, when 
> processing CRL-X, only gets coverage for cACompromise.
> 
> Russ
> 
> 
> At 05:14 PM 03/14/2000 +0300, Valery Smyslov wrote:
> >Hi,
> >
> >I have one question about certficate verification algorithm described in
> >son-of-2459. Section 6.3.3, Step1, second "b", (ii) on page 71 states:
> >
> >---------------------------------------------------------------------
> >             (ii) If CRL X did not include an issuing distribution point
> >             extension, or the onlySomeReasons field was not present in
> >             that extension, set approved_reasons to "all_reasons."  If
> >             CRL X includes an issuing distribution point extension, and
> >             the onlySomeReasons field is present, assign
> >             approved_reasons the intersection of approved reasons and
> >                                  ^^^^^^^^^^^^
> >             the onlySomeReasons field.
> >---------------------------------------------------------------------
> >
> >Isn't it a typo in this paragraph? Shouldn't it be "union" instead of
> >"intersection"? Otherwise this logic is unclear to me.
> >
> >The same paragraph appears also on the next page (72).
> >
> >Regards,
> >Valera Smyslov.
> 
> 




Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA11540 for <[e-mail]>; Wed, 15 Mar 2000 21:16:54 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA06608 for <[e-mail]>; Thu, 16 Mar 2000 16:17:42 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdsgvYB_; Thu Mar 16 16:17:04 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA15084 for <[e-mail]>; Thu, 16 Mar 2000 16:17:03 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0dluhi; Thu Mar 16 16:16:30 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA26294 for <[e-mail]>; Thu, 16 Mar 2000 16:16:29 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <HAKDPT30>; Thu, 16 Mar 2000 16:16:04 +1100
Message-ID: <73388857A695D31197EF00508B08F2988A3B2D@NTMSG0131>
From: "Manger, James H" <[e-mail]>
To: "'PKIX'" <[e-mail]>
Subject: RE: ACprof: 28-bit restriction on OID components
Date: Thu, 16 Mar 2000 16:15:28 +1100
X-MS-TNEF-Correlator: <73388857A695D31197EF00508B08F2988A3B2D@NTMSG0131>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8F06.B9664008"

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_000_01BF8F06.B9664008
Content-Type: text/plain;
	charset="iso-8859-1"

 >  the only operation you should do [with OIDs] is equality matching so
this argument [scanf()] doesn't justify any particular sizing 
 

Converting an object identifier from a BER-encoding to dotted-decimal or
value notation (or vice versa) is not quite only a "local display issue".
Most PKIX protocols use BER-encodings, but LDAP uses dotted-decimal in the
protocol (i.e. dotted-decimal is exchanged over the wire).  I would guess
that software dealing with LDAP and Certificates is likely to convert
between these two forms.

06 07 2A2482C1D1F932 <--> 1.2.36.674528434 <--> { 1 2 36 674528434 }


1st choice: support any size allowed by ASN.1, i.e. < 2^9216 bits
2nd choice: support the greater of 32 bits or the computer's largest
natively supported word size
3rd choice: support <= 32 bits
4th choice: support <= 31 bits
unacceptable: support <= 28 bits

P.S. There is no storage overhead from using a large OID component as the
only alternative is to use more than one small components.  Code size and
complexity (i.e. easy of implementation) are the issues.  Does the
simplicity of being able to use "native" 32 bit words/functions outweigh the
imposition of an arbitrary limit (~2 billion) on allowed component values?


------_=_NextPart_000_01BF8F06.B9664008
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IgYFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0AcDABAAEAAPABwABAApAQEggAMADgAAANAHAwAQ
ABAAEAADAAQAEQEBCYABACEAAAAyQkQ0QThBOENBRkFEMzExOTdGOTAwNTA4QjA4RjI5OABBBwEE
gAEAMQAAAFJFOiBBQ3Byb2Y6IDI4LWJpdCByZXN0cmljdGlvbiBvbiBPSUQgY29tcG9uZW50cwCR
EAENgAQAAgAAAAIAAgABA5AGADwPAAA2AAAAAwDeP69vAAADAACACCAGAAAAAADAAAAAAAAARgAA
AABShQAA8BMAAB4AAYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQALAA2ACCAG
AAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA
CwADgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALAASACCAGAAAAAADAAAAAAAAARgAAAAAO
hQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAA
AEYAAAAAEYUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ACIAIIAYAAAAA
AMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAmACCAGAAAAAADAAAAAAAAARgAAAAA3hQAA
AQAAAAEAAAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4ARoAI
IAYAAAAAAMAAAAAAAABGAAAAAIOFAAABAAAAEwAAADY0ODU4NTEwMi0xNjAzMjAwMAAACwAOgAsg
BgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAA+ACyAGAAAAAADAAAAAAAAARgAAAAAFiAAAAAAA
AAIBCRABAAAA8AgAAOwIAACmHQAATFpGdboc3aMDAAoAcmNwZzEyNYIyA0NodG1sMQMw/wEDAfcK
gAKkA+QHEwKAEAP/AFAEVghVB7IRNQ5RAwECAIRjaArAc2V0MgYA2wbDETUzBEYTxzASPwIAfjQD
xRXZEOURQwjvCfc7uxofDjA1Gz8cRw4gOBpsOxFBDGBjAFALCQFkMzZXFmALpRegYwEwIBACKhZc
DrIBkGchYDMgPAAhRE9DVFlQRQAgSFRNTCBQVQBCTElDICItLxAvVzNDJGBEVERJI3Q0LhZgVHIA
cnQOaQIgB0AkYEVOIj6fEUMiFyLACqMmzDE5ItCLI4ImvjQpEUVBRCa9CDE3NyLQVElUTJ5FJr0h
YA7wKB04NSLQ/i8sLyjCJ78tNSLvI/8yRLgzLjImby//KIY2MZHgTUVUQSAFoAIwCfBYdD0iBeAy
UzUlcDAFNEA5KPAuNjMwN0wiICYwB4A9RzSARWBSQVRPUia9MYIvLyqvIoE1vyJxNRZgPEIYT0RZ
JrAh+TY0fbsiIwAhIAAAP8UhvTgqcXBTUEFON4ALYAQQPYc/gC6QLpAxMDItNvB8MDMB0DiwJrA/
vyGuMcNCwDGgRk9OVDeBGbH0PSNDoTABIEPbIZA84f9ErzsUPPVD90PnIOFKjxZgPyH5AcBD50sI
CoAh2zk2BT5RTDHgS1FVT1RhMjBzdHlsOcA4EEEAUkdJTi1SSUfBMlA6IDBweCahQ///Ia4g4T0f
IpEWYFYQJsw/gB0xoFBQz1HfUuxcbGl/IMNZT1rLSE9Fb0ZxAJB6vTnAMlkbC+JdD14fZgDQ/znA
BxNfjEnxYL9FvQqjVhD9RqU4RxJDzCGQJ6Fkb0F//0KPQ59oz0W/Rs9cb21faiFgJm5ic3ACgGxX
XJwnYQFAcP9yB2d0ctn+PnPISR9Uz2oSVi5yX3Nv9Sg7NU/xL26ybDlLCU8cHxRQLsBqYn3ffuN0
aGVSIAIgbHmCIHAEkGFZJgIgeQhgV3BoCGBs8GQgZG95j3qfe69pr29mZmrPa99s6VsD8IHwIOBP
SURzXYP/hQ+GHw9/j4CfjsMEACBlcXVvB0Al8IJgAMB0E+ALgGf9V3BvgeGR0XcPeB95JArA/Gd1
B4ACMIw/jU+OX4cvH4ivib+KywTwAHBmKCn/jC+Xr5i/j1+Qb6DUg9AHkDxuJwVAk6+Uv3kkanV/
V4AGkIJgAHCCYAqxJgBj/4OQCsFfIZLhfG99f36Pbf//bw9wH6s/h4+a35vvbM+en/+fr7O/KLM2
8D5ROmG1qFqA/G5lCoG2j7S/tc+536IP/6q/qP+qD78/wE/BX8Jvw3//Su/HL8g/yUgKok5au4gK
sVe5X00oLrFQKu4wKnEv/1Aoxs/Nb8YRvdLGhK+MrIH/vgVTz6WPVy9YP7MPq39er/9fv9o/mh+x
n7Kv3c9ljwXAn60LYq+uOmQrCFBudgSQxyYAkvEDkW9iagWQBUB+aQEAAjAGkBKCA1KnYCBaQjoQ
LQnwBaBkkuJ0v5MwpH/WUoPQAkAJgC0Fge8HcAdAgiAFwHYHQApQOYB77ICCxCjtYg3gghDn4XPs
YSmRwu3xIJIQJfCCFf3qACIZsJ3gAyDrL+wzBADPC1GCYAQBClAiLrofuy8bvDoF0G/XwDKQS0lY
/6egA2Dq8BmRBCCnAIIQ6iogcywgYnUFQExE/kHXoPehk4/sH+0iC4CB48P3Bu5waS5lLoPB+yz9
keF4E+GS8AmAgiDn4YHj7/m/1lID8BogKfNv9H/1jPhJIHeDg5ZAB5CR4IHw94LAkxEggHcKwIIQ
DyCSMd+S8YuT+RMNsIOwQ+fy6WA/8PA3wJHgk3/WJVqAa2W/glHq8TeR5+L4wBQwdxqRH4Hi97EF
oJMwD5BybXP/AUy377j/tw8NXw5vxX/Gj/8Rz71/E/8SPxNPFx/iz2ZF/9wv3T/eT99f4G/hfxq/
rK/35P/mDyI4MBjQOVAIX9ZDBDJBVeA4MkMxRPgxRjkhIBfvGP8aDyM/fyRPJV8mb3a/AhOlAHWZ
PLkseC0tMg91fzGGMTjQZi5aoDkgNzTTEB9gM/95MCgf1l8y3zPvNP82Dx5vfwI/vA8tPy5PL18w
b8jne+03QCDTIFqgIDfPSZ3O/f8QPxFPSW9Kf0uPTJ9Nr065djH2gZLAb+7R2PDzIHC+cO1g6OCn
chxy8JBsrSALCwCDsGLwgEFTTi4+Mfiw/QM+/zrPMYYyXq8V8FBBR/85cmKSUHNPb7tQf06MMgcx
Uq6B8mcF0P8H4eQgBYBHENMgWg8/z0DeZ+1hgfL3UG1w+ODvICffCE8JVZYhpBDo4G6Cwefg7/Bx
UyX+4QRgcoOwHHJaT/tbX06MM2cBUq5f71a/TvXePV9vaA9pH08TNIuxY+//OXJqv2vPbN9t50bg
bp9vr1dwv/eQZbBjREBw1eBi/9fwc89033XvbkBHkHIPWb//Ks8r308/gT+CTxVfFm+Fj/+Dz4ef
Qc/bvx0fix+wLx///yEPIh9333jvkx+Gf4pfiJ//ia+Yn4vPjN+N747/kA+RH/+SL59flE+VX6Qf
Qq9Dv0TP0TEcUC5T/TBU/DAF0f/vg36/OWPXwO1gORDwMefhvfwwYQSg6bP3oOgjIGUz8CBPSUR7
72D/QRpjMv/nwOkh8JAFAvA2OPDvIGW0360/OWP+Qerx96Jt7WALkff+ofBB/EBz+7H70LPnDD3/
sd8DP+ew6RBT1V1SY0HX8H54gCDwgPz0tg85cgYQc+/wgF9B+6C94W3pIe4j72A/BcL8IvMDuc+6
3/V9RG//+YH8Ip2gvdHu0L4iX0EK0F/oI3sRvr85Y7eFImW0IuNuVWbTcy9meoDo0O5B5/5QBHAK
8WlncfDB07QBf52g7jNfQehh5BCAEa7AcvfwgMefCXRtgCDCj8OfQRr8KH5uclRAwUPuUVQ2s+jn
zd85cu2Tcz+Zb5p/m4//lw/Xv9jP1w/a3T22oSLbGK+mmDlDpp84tjfZ4lClkIekW6IA3MFCT0RZ
4t2GMifw3NBIVE1M4t0KMzlFfedQHgBwAAEAAAAtAAAAQUNwcm9mOiAyOC1iaXQgcmVzdHJpY3Rp
b24gb24gT0lEIGNvbXBvbmVudHMAAAAAAgFxAAEAAAAbAAAAAb+OK3XQzM+21/odEdOVpAAIxySt
0gAxyL5wAAMALgAAAAAACwArAAAAAAALAAIAAQAAAB4AQhABAAAAMwAAADw3MzM4ODg1N0E2OTVE
MzExOTdFRjAwNTA4QjA4RjI5OEM1RThCQkBOVE1TRzAxMzE+AAADAP0/5AQAAEAAOQBA4oKkBo+/
AQMA8T8JBAAAHgAxQAEAAAAIAAAAQzc5OTg3OAADABpAAAAAAB4AMEABAAAACAAAAEM3OTk4NzgA
AwAZQAAAAAADACYAAAAAAAMANgAAAAAAAwCAEP////8LAPIQAQAAAAIBRwABAAAAPAAAAGM9QVU7
YT10ZWxlbWVtbztwPWNvcnBtYWlsO2w9TlRNU0cwMTMxLTAwMDMxNjA1MTUyOFotMjQyNjQ2AAIB
+T8BAAAATgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1URUxTVFJBL09VPVZJQyBN
T05BU0gvQ049UkVDSVBJRU5UUy9DTj1DNzk5ODc4AAAAHgD4PwEAAAAQAAAATWFuZ2VyLCBKYW1l
cyBIAB4AOEABAAAACAAAAEM3OTk4NzgAAgH7PwEAAABOAAAAAAAAANynQMjAQhAatLkIACsv4YIB
AAAAAAAAAC9PPVRFTFNUUkEvT1U9VklDIE1PTkFTSC9DTj1SRUNJUElFTlRTL0NOPUM3OTk4NzgA
AAAeAPo/AQAAABAAAABNYW5nZXIsIEphbWVzIEgAHgA5QAEAAAAIAAAAQzc5OTg3OABAAAcw6kpm
pAaPvwFAAAgwCEBmuQaPvwEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAALQAAAEFDcHJvZjog
MjgtYml0IHJlc3RyaWN0aW9uIG9uIE9JRCBjb21wb25lbnRzAAAAAB4ANRABAAAAMwAAADw3MzM4
ODg1N0E2OTVEMzExOTdFRjAwNTA4QjA4RjI5ODhBM0IyREBOVE1TRzAxMzE+AAALACkAAAAAAAsA
IwAAAAAAAwAGEGPo+YkDAAcQ3AMAAAMAEBABAAAAAwAREAAAAAAeAAgQAQAAAGUAAABUSEVPTkxZ
T1BFUkFUSU9OWU9VU0hPVUxERE9XSVRIT0lEU0lTRVFVQUxJVFlNQVRDSElOR1NPVEhJU0FSR1VN
RU5UU0NBTkYoKURPRVNOVEpVU1RJRllBTllQQVJUSUNVTEFSAAAAAAIBfwABAAAAMwAAADw3MzM4
ODg1N0E2OTVEMzExOTdFRjAwNTA4QjA4RjI5ODhBM0IyREBOVE1TRzAxMzE+AAAz9A==

------_=_NextPart_000_01BF8F06.B9664008--


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22951 for <[e-mail]>; Wed, 15 Mar 2000 17:46:08 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA545214; Wed, 15 Mar 2000 20:46:04 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id UAA224884; Wed, 15 Mar 2000 20:47:25 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568A4.0009D2C3 ; Wed, 15 Mar 2000 20:47:17 -0500
X-Lotus-FromDomain: IBMUS
To: Denis Pinkas <[e-mail]>
cc: Stefan Santesson <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 20:47:10 -0500
Subject: Re: SerialNumber consensus in QC 03
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Denis:

     This sounds like a fine idea to me.  However, I have one suggestion
for the interpretation of the DN in permanentIdentifier.  This is quite
similar to the one which was vetoed as applied to DN's in subjectAltName
containing serialNumber, but it causes permanentIdentifier to be
interpreted as (name space) + (id).  Was that consistent with your intent
in proposing it?

          Tom Gindin

Denis Pinkas <[e-mail]> on 03/15/2000 12:14:01 PM

To:   Stefan Santesson <[e-mail]>
cc:   [e-mail]
Subject:  Re: SerialNumber consensus in QC 03



Stefan,

The SerialNumber is a way to solve several problems. Before defining
its semantics, it is important to define what the problems are.
There are two different problems that can be both solved by using a
SerialNumber :

a) making two names different when otherwise the name of two or more
entities would not be different. An example of the first case, is
"Mary White 3" and "Mary White 22".

b) allowing the use of a permanent identifier for an entity, even if
the name of the entity changes. An example of that case is "C = US ;
OU = Delta ; OU1= Corporate ; CN= Mary White" while the permanent
identifier would be "C = US ; OU = Delta ; SN= 12345" where 12345 is
an employee number assigned by the Delta company. In that case Mary
White gets married with Mr Green and becomes "Mary Green". Her
permanent identifier does not change. Another example is that she
moves from "Corporate" to "Marketing". Her permanent identifier does
not change.

(snip)

The semantics of a directory name does not allow to play the role of
a permanent identifier. We thus need a new form for this. From RFC
2459 we have:

SubjectAltName ::= GeneralNames

      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     Name,
           ediPartyName                    [5]     EDIPartyName,
           uniformResourceIdentifier       [6]     IA5String,
           iPAddress                       [7]     OCTET STRING,
           registeredID                    [8]     OBJECT
IDENTIFIER}

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

We could define under OtherName a "permanentIdentifier". We would
then need to get/obtain an OID for it. We would define the
permanentIdentifier as a Name.

If the name of the certificate owner changes, the
permanentIdentifier does not change. The content of the
permanentIdentifier can be used in an ACL.

In order to fit with the approach above, since the serial number
solves two different issues, we need two different statements to
cover both cases a) and b).

For case a), here is the proposal :

"A serial Number attribute may be used either in a DN or a
SubjectAltName to differentiate between two names (for two different
individuals) that otherwise would not be different."

For case b), here is the proposal :

"A serial Number attribute may be used in a permanentIdentifier in
an otherName from a SubjectAltName. In that case, when used in
combination with the other components of the permanentIdentifier, it
defines a permanent identifier for the certificate owner for the
issuing CA (that is, two different entities will never get the same
permanent identifier)."

[Tom Gindin] Here is my variant proposal.  "A serial Number attribute may
be used in a permanentIdentifier in an otherName from a SubjectAltName. In
that case, the serial number and any other components (and there need not
be any) of its RDN define a permanent identifier assigned uniquely to the
certificate owner within a name space whose DN is given by the combination
of all RDN's preceding the RDN containing the serial number.  Two different
entities must never be assigned the same permanent identifier."

(snip)




Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22086 for <[e-mail]>; Wed, 15 Mar 2000 17:16:25 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id RAA02540; Wed, 15 Mar 2000 17:17:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 15 Mar 2000 13:56:13 -0500
To: "Valery Smyslov" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Certificate verification algorithm
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Valera:

The text is correct.

I made a posting to this list while we were developing this text that 
explain is significant detail.  Let me see if I can try again.

Consider the following example:
    Cert-A contains a CRLDP that points to CRL-X with reasons
         {keyCompromise, affiliationChanged}
    Cert-B contains a CRLDP that points to CRL-X with reasons
         {cACompromise, cessationOfOperation}
    CRL-X contains an IDP with onlySomeReasons
         {keyCompromise, cACompromise, superseded}

The issuer of Cert-A is delegating the revocation notification of 
keyCompromise and affiliationChanged reasons to the issuer of CRL-X.  The 
issuer of CRL-X has not covered all of the reasons that the issuer of 
Cert-A expected.  That is, the affiliationChanged is not handled.  The 
intersection operation ensures that the validation of Cert-A only considers 
CRL-X for keyCompromise.

Similarly, a certificate user that tries to validate Cert-B, when 
processing CRL-X, only gets coverage for cACompromise.

Russ


At 05:14 PM 03/14/2000 +0300, Valery Smyslov wrote:
>Hi,
>
>I have one question about certficate verification algorithm described in
>son-of-2459. Section 6.3.3, Step1, second "b", (ii) on page 71 states:
>
>---------------------------------------------------------------------
>             (ii) If CRL X did not include an issuing distribution point
>             extension, or the onlySomeReasons field was not present in
>             that extension, set approved_reasons to "all_reasons."  If
>             CRL X includes an issuing distribution point extension, and
>             the onlySomeReasons field is present, assign
>             approved_reasons the intersection of approved reasons and
>                                  ^^^^^^^^^^^^
>             the onlySomeReasons field.
>---------------------------------------------------------------------
>
>Isn't it a typo in this paragraph? Shouldn't it be "union" instead of
>"intersection"? Otherwise this logic is unclear to me.
>
>The same paragraph appears also on the next page (72).
>
>Regards,
>Valera Smyslov.



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22052 for <[e-mail]>; Wed, 15 Mar 2000 17:16:14 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id RAA02517; Wed, 15 Mar 2000 17:16:51 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 15 Mar 2000 13:15:56 -0500
To: Ismo Heikkonen <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: CRL Problem
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Ismo:

The CRL does not include the subject name (in any form).  I think this is 
correct.  Otherwise, the size of the certificate would get significantly 
larger.

Russ


At 10:36 AM 03/14/2000 +0200, Ismo Heikkonen wrote:
>Hi,
>I have the following kind of problem:
>I have to create grandmother- mother-child certificate chains. Each
>parent will have
>one or more children. The only common factors between these three
>certificates are
>the public key and serial number attribute in
>subjectAltName-directoryName field.
>Different CA's have signed these certs.
>
>When the upper level certificate is revoked, all child certificates
>shall be revoked
>also.
>A solution could be to have three CRL's, and each certificate  will have
>one, two or
>three distribution points, where respective  CRL information can be
>found. But the
>problem is that the child does not know implicitly the
>certificateSerialNumber of it's
>parent, just the subjectAltName serialNumber. It means that when each
>CRL entry
>is processed, the respective certificate shall be searched from the
>directory, and
>subjectAltName --serialNumber attribute picked up. This is too
>tedious and resource consuming.
>
>An easier solution would be if I were able to use subjectAltName
>extension also in
>CRL entry extension. In this case I would be able to add both
>certificateSerialNumber and subjectAltName-serialNumber on CRL, and my
>application could see easily if the subjectAltName-serialNumber is
>revoked or not.
>
>Actually issuerAltName is a legal extension for CRL entry, but
>subjetAltName is not,
>which is a defect in X.509, I think.
>
>An other solution could be to publish two CRL's: one based on
>certificateSerialNumber and the other one based on
>subjectAltName-directoryName-serialNumber. I tried with an
>implementation, but it can create CRL' s just for it's own certificates.
>
>Have you seen any working solutions for this kind of case? I would not
>like to go to
>OCSP based solution due to the strict response time and availability
>requirements.
>
>Ismo
>
>



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA18333 for <[e-mail]>; Wed, 15 Mar 2000 14:13:17 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 15 Mar 2000 15:13:07 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 15 Mar 2000 15:12:34 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: What good is a DN if the REAL stuff is somewhere else?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA18334

Robert,

I would expect that nearly all such products would be 
capable of displaying the name as part of their general 
certificate display capability.

What I believe you are asking is a different issue, however, 
and that is what name would typically be displayed as 
the banner of an e-mail message, and/or matched against 
the e-mail address.

That's a different problem, and one that so far hasn't been 
solved very well, in part because of the reluctance of the 
IETF to meddle with GUI issues.

But it is, I believe, at the heart of the believability and 
workability issue for the general consumer of certificates, 
i.e., the non-specialist.

At present, neither my DN (bjueneman.nsrd.prv.novell) nor 
my email address ([e-mail]) is particularly 
meaningful, and if novell were replaced by say AOL, it would 
be even less meaningful unless you already knew me.

And note that I could change my From address to 
"President William Clinton
                                                                                   "<[e-mail]> 
and no e-mail program that I know of would display the From 
address correctly. The naive user could then be fooled into believing 
the message was really from Pres. Clinton.

My personal advice would be to stick to your guns regarding the
directory problem, and apply pressure to the various vendors (including
us, mea culpa) to solve this display problem.

The PKIX standard allows multiple subjectAltNames, including
a GeneralizedName construct.  We should take advantage of it.

Regards,

Bob


>>> Robert Malick <[e-mail]> 03/15/00 02:29PM >>>

On Wed, 15 Mar 2000, Bob Jueneman wrote:

> The DN in the certificate should match whatever the DN in the directory 
> is for that user, as determined by the directory administrator. Period. Finis.
> Full Stop. The End. 
> 
> Otherwise, it may work, but it won't be WORKABLE.
> 
> Any other useful information, such as the user's current "real name", 
> department organization ,street address, DNA encoding, or whatever, 
> that needs to be in the certificate should be carried elsewhere in the 
> certificate, in particular in a subjectAltName, just we do for the RFC822 
> name, and for the same reasons.

We at National Institutes of Health have been planning our directory under
these assumptions for the past 2.5 years but have recently been
reconsidering our ways in light of the recent discussions on this list.

It has been indicated by some off the list that not having displayable
values in ones certificate subjects is not useful to current off the shelf
applications (but messes with DITs). If we were to place the displayable
value (for example "cn") in the SubjectAltName extension and yet still
have a Subject of "serialnumber=12345567890, o=ACME, c=US" would current
off the shelf clients (S/MIME and such) be inclined to show both the
Subject and SubjectAltName provided in the certificate or do vendors
usually choose over the other.

Any comments on this would be useful to us.

	Robert Malick
	National Institutes of Health




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA17614 for <[e-mail]>; Wed, 15 Mar 2000 13:45:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 15 Mar 2000 14:45:50 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 15 Mar 2000 14:45:43 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: ASN.1 Notation
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA17615

>Cryptix has the beginnings of an ASN.1->Java compiler that seems to be
under relatively current development (www.cryptix.org).

Now there's an approach that I'd bet generates blindingly fast code! :-(

Bob



Received: from snoopy.cit.nih.gov (snoopy.cit.nih.gov [156.40.8.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17120 for <[e-mail]>; Wed, 15 Mar 2000 13:30:14 -0800 (PST)
Received: from localhost (rmalick@localhost) by snoopy.cit.nih.gov (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id QAA21234; Wed, 15 Mar 2000 16:29:12 -0500 (EST)
Date: Wed, 15 Mar 2000 16:29:11 -0500 (EST)
From: Robert Malick <[e-mail]>
Sender: [e-mail]
To: Bob Jueneman <[e-mail]>
cc: [e-mail]
Subject: Re: What good is a DN if the REAL stuff is somewhere else?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 15 Mar 2000, Bob Jueneman wrote:

> The DN in the certificate should match whatever the DN in the directory 
> is for that user, as determined by the directory administrator. Period. Finis.
> Full Stop. The End. 
> 
> Otherwise, it may work, but it won't be WORKABLE.
> 
> Any other useful information, such as the user's current "real name", 
> department organization ,street address, DNA encoding, or whatever, 
> that needs to be in the certificate should be carried elsewhere in the 
> certificate, in particular in a subjectAltName, just we do for the RFC822 
> name, and for the same reasons.

We at National Institutes of Health have been planning our directory under
these assumptions for the past 2.5 years but have recently been
reconsidering our ways in light of the recent discussions on this list.

It has been indicated by some off the list that not having displayable
values in ones certificate subjects is not useful to current off the shelf
applications (but messes with DITs). If we were to place the displayable
value (for example "cn") in the SubjectAltName extension and yet still
have a Subject of "serialnumber=12345567890, o=ACME, c=US" would current
off the shelf clients (S/MIME and such) be inclined to show both the
Subject and SubjectAltName provided in the certificate or do vendors
usually choose over the other.

Any comments on this would be useful to us.

	Robert Malick
	National Institutes of Health



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA15978 for <[e-mail]>; Wed, 15 Mar 2000 12:45:41 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 15 Mar 2000 13:46:22 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 15 Mar 2000 13:46:13 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: What good is a DN if the REAL stuff is somewhere else?
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_E7BE1D8E.771608CF"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_E7BE1D8E.771608CF
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

>"What good is a DN if the REAL stuff is somewhere else?"

Anders, this is the train wreck that has been about to happen=20
for ten years or more, as a result of overloading the DN and not=20
using directories in the way they are typically used in practice.

Render unto Caesar that which is Caesar's, and unto the directory=20
administrator as well, and don't try to get organizations to change=20
their directory structures to fit your notion of what a certificate =
should=20
look like.  It simply won't work.

As we used to say back in the NADF days, it is like trying to=20
teach a pig to whistle.  It's a waste of time, and it annoys the pig!

The DN in the certificate should match whatever the DN in the directory=20
is for that user, as determined by the directory administrator. Period. =
Finis.
Full Stop. The End.=20

Otherwise, it may work, but it won't be WORKABLE.

Any other useful information, such as the user's current "real name",=20
department organization ,street address, DNA encoding, or whatever,=20
that needs to be in the certificate should be carried elsewhere in the=20
certificate, in particular in a subjectAltName, just we do for the =
RFC822=20
name, and for the same reasons.

Let the record show that for once I agree with Denis. :-)  And by the way, =
large=20
organizations such as the US Navy have come to the same conclusions.

Bob


>>> "Anders Rundgren" <[e-mail]> 03/15/00 12:33PM >>>
Denis,

<snip>

>b) allowing the use of a permanent identifier for an entity, even if
>the name of the entity changes. An example of that case is "C =3D US ;
>OU =3D Delta ; OU1=3D Corporate ; CN=3D Mary White" while the permanent
>identifier would be "C =3D US ; OU =3D Delta ; SN=3D 12345" where 12345 =
is
>an employee number assigned by the Delta company. In that case Mary
>White gets married with Mr Green and becomes "Mary Green". Her
>permanent identifier does not change. Another example is that she
>moves from "Corporate" to "Marketing". Her permanent identifier does
>not change.=20


What good is a DN if the REAL stuff is somewhere else?

>
>Note that the last case also allows to solve the problem of re-use
>of DN names and directory names. A DN or a directory name that has
>been used in a certificate can be re-used after the certificate that
>contained it has expired, as long as a permanent identifier, instead
>of the DN or the directory name, can be used by a relying party,
>e.g. in an ACL.


I liked your original suggestion

   http://www.imc.org/ietf-pkix/mail-archive/msg04094.html

more as it keeps DN unmistakable,   Re-use of DNs in QCs does not sound
too attractive IMO.

You original suggestion could also easily be expanded to include support =
for
"Preferred Display DN components" and the Naming Domain issue which so far
has beem totally neglected.

Both your solutions require a new OID to flag "enhanced" sematic interpreta=
tion.

Anders

<snip>

--=_E7BE1D8E.771608CF
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV>&gt;"What good is a DN if the REAL stuff is somewhere else?"</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anders, this is the train wreck that has been about to happen </DIV>
<DIV>for ten years or more, as a result of overloading the DN and not =
</DIV>
<DIV>using directories in the way they are typically used in practice.</DIV=
>
<DIV>&nbsp;</DIV>
<DIV>Render unto Caesar that which is Caesar's, and unto the directory =
</DIV>
<DIV>administrator as well, and don't try to get organizations to change =
</DIV>
<DIV>their directory structures to fit your notion of what a certificate =
should=20
</DIV>
<DIV>look like.&nbsp; It simply won't work.</DIV>
<DIV>&nbsp;</DIV>
<DIV>As we used to say back in the NADF days, it is like trying to </DIV>
<DIV>teach a pig to whistle.&nbsp; It's a waste of time, and it annoys =
the=20
pig!</DIV>
<DIV>&nbsp;</DIV>
<DIV>The DN in the certificate should match whatever the DN in the =
directory=20
</DIV>
<DIV>is for that user, as determined by the directory administrator. =
Period.=20
Finis.</DIV>
<DIV>Full Stop. The End. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Otherwise, it may work, but it won't be WORKABLE.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Any other useful information, such as the user's current "real =
name",=20
</DIV>
<DIV>department organization ,street address, DNA encoding, or whatever, =
</DIV>
<DIV>that needs to be in the certificate should be carried elsewhere in =
the=20
</DIV>
<DIV>certificate, in particular in a subjectAltName, just we do for the =
RFC822=20
</DIV>
<DIV>name, and for the same reasons.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Let the record show that for once I agree with Denis. :-)&nbsp; And =
by the=20
way, large </DIV>
<DIV>organizations such as the US Navy have come to the same conclusions.</=
DIV>
<DIV>&nbsp;</DIV>
<DIV>Bob</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;&gt;&gt; "Anders Rundgren" &lt;[e-mail]&gt; =
03/15/00=20
12:33PM &gt;&gt;&gt;<BR>Denis,<BR><BR>&lt;snip&gt;<BR><BR>&gt;b) allowing =
the=20
use of a permanent identifier for an entity, even if<BR>&gt;the name of =
the=20
entity changes. An example of that case is "C =3D US ;<BR>&gt;OU =3D Delta =
; OU1=3D=20
Corporate ; CN=3D Mary White" while the permanent<BR>&gt;identifier would =
be "C =3D=20
US ; OU =3D Delta ; SN=3D 12345" where 12345 is<BR>&gt;an employee number =
assigned=20
by the Delta company. In that case Mary<BR>&gt;White gets married with Mr =
Green=20
and becomes "Mary Green". Her<BR>&gt;permanent identifier does not =
change.=20
Another example is that she<BR>&gt;moves from "Corporate" to "Marketing". =
Her=20
permanent identifier does<BR>&gt;not change. <BR><BR><BR>What good is a DN =
if=20
the REAL stuff is somewhere else?<BR><BR>&gt;<BR>&gt;Note that the last =
case=20
also allows to solve the problem of re-use<BR>&gt;of DN names and =
directory=20
names. A DN or a directory name that has<BR>&gt;been used in a certificate =
can=20
be re-used after the certificate that<BR>&gt;contained it has expired, as =
long=20
as a permanent identifier, instead<BR>&gt;of the DN or the directory name, =
can=20
be used by a relying party,<BR>&gt;e.g. in an ACL.<BR><BR><BR>I liked =
your=20
original suggestion<BR><BR>&nbsp;&nbsp; <A=20
href=3D"http://www.imc.org/ietf-pkix/mail-archive/msg04094.html">http://www=
.imc.org/ietf-pkix/mail-archive/msg04094.html</A><BR><BR>more=20
as it keeps DN unmistakable,&nbsp;&nbsp; Re-use of DNs in QCs does not=20
sound<BR>too attractive IMO.<BR><BR>You original suggestion could also =
easily be=20
expanded to include support for<BR>"Preferred Display DN components" and =
the=20
Naming Domain issue which so far<BR>has beem totally neglected.<BR><BR>Both=
 your=20
solutions require a new OID to flag "enhanced" sematic=20
interpretation.<BR><BR>Anders<BR><BR>&lt;snip&gt;<BR><BR><BR></DIV></BODY><=
/HTML>

--=_E7BE1D8E.771608CF--


Received: from harry.cmr.gov (harry.cmr.gov [140.162.6.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14582 for <[e-mail]>; Wed, 15 Mar 2000 11:53:05 -0800 (PST)
Received: from dolphin.cmr.gov (dolphin [140.162.3.135]) by harry.cmr.gov (8.9.3/8.9.3) with ESMTP id OAA18787; Wed, 15 Mar 2000 14:54:14 -0500 (EST)
Received: from cmr.gov (localhost [127.0.0.1]) by dolphin.cmr.gov (8.9.1b+Sun/8.9.1) with ESMTP id OAA09573; Wed, 15 Mar 2000 14:53:55 -0500 (EST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 14:53:54 -0500
From: "Patrick G. Moore" <[e-mail]>
Organization: Center for Monitoring Research
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: [e-mail]
Subject: Re: key update - problem
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Carlisle,

I should have read more carefully.  It seemed strange to me that
the Certificate Management Protocol wasn't self-contained in
this regard.

Pat

Carlisle Adams wrote:
> 
> Hi Pat,
> 
> > ----------
> > From:         Patrick G. Moore[SMTP:[e-mail]]
> > Sent:         Tuesday, March 14, 2000 5:23 PM
> > To:   Carlisle Adams; [e-mail]
> > Subject:      Re: key update - problem
> >
> > Carlisle Adams wrote:
> > >
> > > When doing a key update it is not necessary to supply the old public key
> > and
> > > to prove possession of the old private key all over again.  In the
> > request
> > > for a certificate for the new key pair, it is sufficient to put a
> > pointer to
> > > the old certificate that is being updated/replaced.  This is the purpose
> > of
> > > the OldCertId control (see Section 6.5 of RFC 2511).
> > >
> > > The key update request needs to contain the new public key and POP for
> > the
> > > new private key, but need not contain anything pertaining to the old
> > > certificate beyond this pointer.
> > >
> > > Carlisle.
> >
> > Hi Carlisle,
> >
> > RFC 2510 says to use a secure transport for requests.  I would think, for
> > POP
> > of an old key, you could put the update request in the body of a signed
> > S/MIME
> > message, signed with the old cert.  Are there any profiles defined for CMP
> > over
> > different transports, like S/MIME, http, FTP etc..., which address this
> > issue?
> > It seems appropriate for key updates, so that an imposter can't request a
> > new
> > key
> > for an existing cert.
> >
> > Pat
> 
> Perhaps my (slightly hasty) answer was not sufficiently clear.  What I meant
> to convey was that the key update request itself (i.e., the CertReqMsg in
> RFC 2511) need not contain anything pertaining to the old certificate
> (including POP of the old private key), with the possible exception of the
> OldCertId control.
> 
> However, the key update request is a PKIBody, framed by PKIHeader and
> PKIProtection fields (and perhaps extraCerts) to form the full PKIMessage.
> In typical use, the key update request (i.e., this request for a replacement
> certificate) will be signed by the private key corresponding to the current
> certificate.  That is, the PKIHeader protectionAlg will contain a
> MSG_SIG_ALG and PKIProtection will contain a digital signature created using
> the (current / soon-to-be-old) private key.  In a sense this might be
> considered to be POP of the old key but, more correctly, it is simply strong
> authentication of the update request message (which avoids the
> impostor-requesting-a-new-key-for-an-existing-cert problem).
> 
> Carlisle.


Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12992 for <[e-mail]>; Wed, 15 Mar 2000 10:57:27 -0800 (PST)
Received: from phaos.com ([207.51.38.134]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id SAA40668; Wed, 15 Mar 2000 18:34:35 -0500 (EST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 14:05:19 -0500
From: Brian Tvedt <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Paul Koning <[e-mail]>, IETF <[e-mail]>
CC: [e-mail]
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Koning wrote:
> 
> >>>>> "Brian" == Brian Tvedt <[e-mail]> writes:
> 

>  Brian> Using long raises the same issue, except the limit becomes 63
>  Brian> instead of 31.  The fundamental question is whether there is a
>  Brian> limit or not.
> 
>  Brian> Of course BigInteger objects or byte arrays will work fine,
>  Brian> but why allocate a reference object when a primitive will do
>  Brian> nicely?  The extra overhead may not amount to much, but it
>  Brian> still seems to be catering to a situation that is extremely
>  Brian> unlikely to occur in the real world.
> 
> Most of the time there is no need to know or care about the structure
> of an OID -- it can simply be treated as an opaque octet string.  The
> fact that it has a display syntax consisting of a dotted decimal
> sequence is entirely irrelevant.
> 
> Is there some reason why that doesn't apply here?  If it does apply,
> then the argument about int sizes in your favorite programming
> language doesn't matter at all.
> 
>         paul

Upon further reflection, I can't think of a reason for exposing the actual
component values outside of the parsing and display code.  I now agree that
there is no reason for a limit on component sizes.

Thanks,

Brian Tvedt


Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12611 for <[e-mail]>; Wed, 15 Mar 2000 10:47:55 -0800 (PST)
Received: from phaos.com ([207.51.38.134]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id SAA40637; Wed, 15 Mar 2000 18:24:58 -0500 (EST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 13:55:39 -0500
From: Brian Tvedt <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: David Boyce <[e-mail]>, IETF <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for the well-written response.  I see your point completely, and withdraw
my previous objection to unrestricted component sizes.

--
Brian Tvedt, Ph.D.
Sr. Security Architect
Phaos Technology Corp.


David Boyce wrote:
> 
> Brian Tvedt writes:
> 
> >Charles W. Gardiner wrote:
> 
> >>     Why limit it at all?  It's just a string of bytes -- and storage
> is
> >> pretty cheap now.  A beauty of OIDs is that arcs can be assigned
> >> for all sorts of thing to all sorts of organizations and people
> >> just by extending the string.  Doesn't history show that early
> >> notions of upper limits on size are soon overrun, e.g. 640 kbytes
> >> of RAM?
> 
> FWIW, I'm in full agreement with Charles in his opposition to arbitrary
> upper limits.  The Attribute OIDs being handled in ACs 'belong' to
> whoever chooses to define them, and who knows whether someone might not
> have a very good reason for an OID component which overflows 31 bits (or
> any limit) defined in some other context, and then wish to use
> attributes below that arc in an AC.  I agree it's unlikely, but we
> should not remove the option for the sake of a temporary convenience.
> 
> >Storage is not so cheap when you're developing for handheld devices
> >or smart cards.  Also, in Java, creating lots of BigInteger objects
> >creates work for the garbage collector.
> >
> >Right now our Java libraries require each component to be an int
> >(limited to 31 bits for positive numbers).  We could accomodate
> >BigInteger's without much problem, but why do it if OIDs that require
> >them are never encountered?
> 
> Because the ASN.1 standards say so, and 'past performance is no
> indication of future performance'.  As indicated above, restricting
> component size involves taking a decision out of the hands of the person
> to whom it would properly belong.
> 
> Charles's point is that for most internal uses you should not need the
> ints at all, since the octet string representing the OID is normally
> all that is required for internal OID operations (copy, compare for
> equality).  Consequently, your Java libraries (which seem to require
> each component to be an int) are doing more work than necessary
> converting to/from integral OID representations, and placing
> unnecessary restrictions on the form of OID in the process.
> 
> The occasions when you MAY need ints are when constructing an OID from
> user (numeric) input, and constructing a printable representation of the
> OID values, but even then the ints would be a convenience rather than a
> necessity.  Both of these operations are sufficiently well-localised
> that it should not be difficult to perform these operations without
> impacting other areas.
> 
> >Note also that this restriction applies only to component size.  No
> >limit is necessary for the number of components.  So you can still
> >"extend the string" indefinitely.
> 
> I don't understand why, if you have storage for an indefinite number
> of components, you don't have storage for indefinitely long
> components.
> 
> Incidentally, I notice that SerialNumber (section 4.2.5) is being
> artificially restricted as well.  IMO, similar counter-arguments
> apply.
> 
> David.
> 
> --
> David Boyce
> 
> MessagingDirect (UK) Ltd.
> Tel:    [phone]                 Richmond, Surrey, ENGLAND
> Email:  [e-mail]  WWW: http://www.MessagingDirect.
> com/


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12421 for <[e-mail]>; Wed, 15 Mar 2000 10:46:51 -0800 (PST)
Received: from loaner-pc (bbialick-pc.spyrus.com [207.212.34.214]) by mail.spyrus.com (8.9.3/8.9.3) with SMTP id KAA27297; Wed, 15 Mar 2000 10:46:40 -0800 (PST)
Message-ID: <004001bf8eae$a2be56e0$[e-mail]>
From: "Charles Moore" <[e-mail]>
To: "Brian Tvedt" <[e-mail]>, "David Boyce" <[e-mail]>
Cc: <[e-mail]>, "Charles W. Gardiner" <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components 
Date: Wed, 15 Mar 2000 10:45:28 -0800
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 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

-----Original Message-----
From: David Boyce <[e-mail]>
To: Brian Tvedt <[e-mail]>
Cc: [e-mail] <[e-mail]>; Charles W. Gardiner
<[e-mail]>
Date: Wednesday, March 15, 2000 9:18 AM
Subject: Re: ACprof: 28-bit restriction on OID components


>Brian Tvedt writes:
>
snip
>As indicated above, restricting
>component size involves taking a decision out of the hands of the person
>to whom it would properly belong.
>

Agree....The creator of the OID makes the decision....




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12153 for <[e-mail]>; Wed, 15 Mar 2000 10:42:56 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQigqs16695; Wed, 15 Mar 2000 18:44:09 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA21487; Wed, 15 Mar 00 13:41:07 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA13431; Wed, 15 Mar 2000 13:44:08 -0500
Date: Wed, 15 Mar 2000 13:44:08 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Brian" == Brian Tvedt <[e-mail]> writes:

 Brian> Steve Hanna wrote:
 >>  Stephen Farrell wrote: > If no one else objects then I'd be ok
 >> with 31 bits which > caters for 9 decimal digits fine (32 bits
 >> potentially gets > into signed int muck, esp with Java).
 >> 
 >> Don't worry about Java. Just use a long (always 64 bits). Or a
 >> byte array, a boolean array, or a BigInteger (all almost unlimited
 >> in size).
 >> 
 >> Steve Hanna Sun Microsystems

 Brian> Using long raises the same issue, except the limit becomes 63
 Brian> instead of 31.  The fundamental question is whether there is a
 Brian> limit or not.

 Brian> Of course BigInteger objects or byte arrays will work fine,
 Brian> but why allocate a reference object when a primitive will do
 Brian> nicely?  The extra overhead may not amount to much, but it
 Brian> still seems to be catering to a situation that is extremely
 Brian> unlikely to occur in the real world.

Most of the time there is no need to know or care about the structure
of an OID -- it can simply be treated as an opaque octet string.  The
fact that it has a display syntax consisting of a dotted decimal
sequence is entirely irrelevant.

Is there some reason why that doesn't apply here?  If it does apply,
then the argument about int sizes in your favorite programming
language doesn't matter at all.

	paul



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11632 for <[e-mail]>; Wed, 15 Mar 2000 10:32:19 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDTZNJZ>; Wed, 15 Mar 2000 13:33:07 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Martin Szotkowski'" <[e-mail]>
Cc: [e-mail]
Subject: RE: key update - problem
Date: Wed, 15 Mar 2000 13:33:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Martin,

> ----------
> From: 	Martin Szotkowski[SMTP:[e-mail]]
> Sent: 	Wednesday, March 15, 2000 12:59 PM
> To: 	Carlisle Adams
> Cc: 	[e-mail]
> Subject: 	Re: key update - problem
> 
> Sorry man,
> that was my mistake, maybe too much information in few day.
> CertReqMessages contain POP for new key pair and PKIMessage contain
> PKIProtection for old key sign, isn't it?
> Martin
 
I just saw your message (after composing my own).  Yes, you're right -- see
my recently-posted message on this.

Carlisle.



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11624 for <[e-mail]>; Wed, 15 Mar 2000 10:32:17 -0800 (PST)
Received: from mega (t1o69p94.telia.com [62.20.144.94]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id TAA03886; Wed, 15 Mar 2000 19:36:14 +0100
Message-ID: <003501bf8eb5$4d3a14a0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: SerialNumber consensus in QC 03
Date: Wed, 15 Mar 2000 19:33:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA11626

Denis,

<snip>

>b) allowing the use of a permanent identifier for an entity, even if
>the name of the entity changes. An example of that case is "C = US ;
>OU = Delta ; OU1= Corporate ; CN= Mary White" while the permanent
>identifier would be "C = US ; OU = Delta ; SN= 12345" where 12345 is
>an employee number assigned by the Delta company. In that case Mary
>White gets married with Mr Green and becomes "Mary Green". Her
>permanent identifier does not change. Another example is that she
>moves from "Corporate" to "Marketing". Her permanent identifier does
>not change. 


What good is a DN if the REAL stuff is somewhere else?

>
>Note that the last case also allows to solve the problem of re-use
>of DN names and directory names. A DN or a directory name that has
>been used in a certificate can be re-used after the certificate that
>contained it has expired, as long as a permanent identifier, instead
>of the DN or the directory name, can be used by a relying party,
>e.g. in an ACL.


I liked your original suggestion

   http://www.imc.org/ietf-pkix/mail-archive/msg04094.html

more as it keeps DN unmistakable,   Re-use of DNs in QCs does not sound
too attractive IMO.

You original suggestion could also easily be expanded to include support for
"Preferred Display DN components" and the Naming Domain issue which so far
has beem totally neglected.

Both your solutions require a new OID to flag "enhanced" sematic interpretation.

Anders

<snip>




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11390 for <[e-mail]>; Wed, 15 Mar 2000 10:29:25 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDTZN2Z>; Wed, 15 Mar 2000 13:30:13 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Patrick G. Moore'" <[e-mail]>
Cc: [e-mail]
Subject: RE: key update - problem
Date: Wed, 15 Mar 2000 13:30:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Pat,

> ----------
> From: 	Patrick G. Moore[SMTP:[e-mail]]
> Sent: 	Tuesday, March 14, 2000 5:23 PM
> To: 	Carlisle Adams; [e-mail]
> Subject: 	Re: key update - problem
> 
> Carlisle Adams wrote:
> > 
> > When doing a key update it is not necessary to supply the old public key
> and
> > to prove possession of the old private key all over again.  In the
> request
> > for a certificate for the new key pair, it is sufficient to put a
> pointer to
> > the old certificate that is being updated/replaced.  This is the purpose
> of
> > the OldCertId control (see Section 6.5 of RFC 2511).
> > 
> > The key update request needs to contain the new public key and POP for
> the
> > new private key, but need not contain anything pertaining to the old
> > certificate beyond this pointer.
> > 
> > Carlisle.
> 
> Hi Carlisle,
> 
> RFC 2510 says to use a secure transport for requests.  I would think, for
> POP
> of an old key, you could put the update request in the body of a signed
> S/MIME
> message, signed with the old cert.  Are there any profiles defined for CMP
> over
> different transports, like S/MIME, http, FTP etc..., which address this
> issue?
> It seems appropriate for key updates, so that an imposter can't request a
> new
> key
> for an existing cert.
> 
> Pat
 
Perhaps my (slightly hasty) answer was not sufficiently clear.  What I meant
to convey was that the key update request itself (i.e., the CertReqMsg in
RFC 2511) need not contain anything pertaining to the old certificate
(including POP of the old private key), with the possible exception of the
OldCertId control.

However, the key update request is a PKIBody, framed by PKIHeader and
PKIProtection fields (and perhaps extraCerts) to form the full PKIMessage.
In typical use, the key update request (i.e., this request for a replacement
certificate) will be signed by the private key corresponding to the current
certificate.  That is, the PKIHeader protectionAlg will contain a
MSG_SIG_ALG and PKIProtection will contain a digital signature created using
the (current / soon-to-be-old) private key.  In a sense this might be
considered to be POP of the old key but, more correctly, it is simply strong
authentication of the update request message (which avoids the
impostor-requesting-a-new-key-for-an-existing-cert problem).

Carlisle.



Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10725 for <[e-mail]>; Wed, 15 Mar 2000 10:04:14 -0800 (PST)
Received: from phaos.com ([207.51.38.134]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id RAA40438; Wed, 15 Mar 2000 17:41:31 -0500 (EST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 13:12:15 -0500
From: Brian Tvedt <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: IETF <[e-mail]>
CC: Steve Hanna <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve Hanna wrote:
> 
> Stephen Farrell wrote:
> > If no one else objects then I'd be ok with 31 bits which
> > caters for 9 decimal digits fine (32 bits potentially gets
> > into signed int muck, esp with Java).
> 
> Don't worry about Java. Just use a long (always 64 bits). Or a byte
> array, a boolean array, or a BigInteger (all almost unlimited in size).
> 
> Steve Hanna
> Sun Microsystems

Using long raises the same issue, except the limit becomes 63 instead of 31. 
The fundamental question is whether there is a limit or not.

Of course BigInteger objects or byte arrays will work fine, but why allocate a
reference object when a primitive will do nicely?  The extra overhead may not
amount to much, but it still seems to be catering to a situation that is
extremely unlikely to occur in the real world.


--
Brian Tvedt, Ph.D.
Sr. Security Architect
Phaos Technology Corp.


Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10464 for <[e-mail]>; Wed, 15 Mar 2000 09:58:52 -0800 (PST)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id SAA31849; Wed, 15 Mar 2000 18:59:51 +0100 (CET)
Message-ID: <061501bf8ea8$43adb250$0c7011ac@SZOTKOWSKI>
From: "Martin Szotkowski" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: key update - problem
Date: Wed, 15 Mar 2000 18:59:51 +0100
Organization: PVT, a.s.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Sorry man,
that was my mistake, maybe too much information in few day.
CertReqMessages contain POP for new key pair and PKIMessage contain
PKIProtection for old key sign, isn't it?
Martin

----- Original Message -----
From: Carlisle Adams <[e-mail]>
To: 'Martin Szotkowski' <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, March 14, 2000 8:39 PM
Subject: RE: key update - problem


> Hi Martin,
>
> > ----------
> > From: Martin Szotkowski[SMTP:[e-mail]]
> > Sent: Tuesday, March 14, 2000 10:42 AM
> > To: [e-mail]
> > Subject: key update - problem
> >
> > Hi all,
> >
> > (excuse me my English)
> > I think, that new key must be sign with old key (or in other way POP old
> > key) and new key POP must be too present.
> > I can't find, how create key update request. In CMP [RFC 2510] and CRMF
> > [RFC
> > 2511] are defined
> > "kur as CertReqMessages; CertReqMsg; CertRequest", but there is no place
> > for
> > old key.
> > Can me someone advise right way.
>
> When doing a key update it is not necessary to supply the old public key
and
> to prove possession of the old private key all over again.  In the request
> for a certificate for the new key pair, it is sufficient to put a pointer
to
> the old certificate that is being updated/replaced.  This is the purpose
of
> the OldCertId control (see Section 6.5 of RFC 2511).
>
> The key update request needs to contain the new public key and POP for the
> new private key, but need not contain anything pertaining to the old
> certificate beyond this pointer.
>
> Carlisle.



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09212 for <[e-mail]>; Wed, 15 Mar 2000 09:12:56 -0800 (PST)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA23940; Wed, 15 Mar 2000 18:13:59 +0100
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 18:14:01 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: SerialNumber consensus in QC 03
References: <000701bf8a29$be7da220$3178e8c3@Santesson>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefan,

The SerialNumber is a way to solve several problems. Before defining
its semantics, it is important to define what the problems are.
There are two different problems that can be both solved by using a
SerialNumber :

a) making two names different when otherwise the name of two or more
entities would not be different. An example of the first case, is
"Mary White 3" and "Mary White 22".
 
b) allowing the use of a permanent identifier for an entity, even if
the name of the entity changes. An example of that case is "C = US ;
OU = Delta ; OU1= Corporate ; CN= Mary White" while the permanent
identifier would be "C = US ; OU = Delta ; SN= 12345" where 12345 is
an employee number assigned by the Delta company. In that case Mary
White gets married with Mr Green and becomes "Mary Green". Her
permanent identifier does not change. Another example is that she
moves from "Corporate" to "Marketing". Her permanent identifier does
not change. 

Note that the last case also allows to solve the problem of re-use
of DN names and directory names. A DN or a directory name that has
been used in a certificate can be re-used after the certificate that
contained it has expired, as long as a permanent identifier, instead
of the DN or the directory name, can be used by a relying party,
e.g. in an ACL.

A sub-goal is to be able to know what are the components of a
permanent identifier without the need to make any look up. This
means that the certificate must contain all the information to
interpret directly the semantics of the serial number. Proposals 1,
2, and 3 to the issue 2 do not solve this concern.

However, the proposal 4 would fit that concern with some changes. It
is suggested to repeat information into the directory name. 

However a directory name is defined in X.501 as: "A construct that
singles out a particular object from all other objects. A name shall
be unambiguous (that is, denote just one object), however it need
not be unique (that is, be the only name which unambiguously denotes
the object)."

The semantics of a directory name does not allow to play the role of
a permanent identifier. We thus need a new form for this. From RFC
2459 we have: 

SubjectAltName ::= GeneralNames

      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     Name,
           ediPartyName                    [5]     EDIPartyName,
           uniformResourceIdentifier       [6]     IA5String,
           iPAddress                       [7]     OCTET STRING,
           registeredID                    [8]     OBJECT
IDENTIFIER}

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

We could define under OtherName a "permanentIdentifier". We would
then need to get/obtain an OID for it. We would define the
permanentIdentifier as a Name.

If the name of the certificate owner changes, the
permanentIdentifier does not change. The content of the
permanentIdentifier can be used in an ACL.

In order to fit with the approach above, since the serial number
solves two different issues, we need two different statements to
cover both cases a) and b).

For case a), here is the proposal :

"A serial Number attribute may be used either in a DN or a
SubjectAltName to differentiate between two names (for two different
individuals) that otherwise would not be different."

For case b), here is the proposal :

"A serial Number attribute may be used in a permanentIdentifier in
an otherName from a SubjectAltName. In that case, when used in
combination with the other components of the permanentIdentifier, it
defines a permanent identifier for the certificate owner for the
issuing CA (that is, two different entities will never get the same
permanent identifier)."

In the security consideration section we can now have the following
text :

"A given physical entity may have at an instant of time or at
different instant of time multiple forms of unmistakable identity.
If two certificates contain two identical permanentIdentifiers in an
otherName from a SubjectAltName, then it is possible to determine by
examination if two qualified certificates refer to the same physical
entity."

Regards,

Denis

 
> All,
> 
> I'd like to summarize and propose a consensus solution to the serialNumber
> Issue in QC 03.
> 
> First of all I would like to point out that this is not at debate of whether
> to use serialNumber or any other attribute (that issue was settled last
> year). This is a debate regarding:
> 
> 1) to define the semantics for information hold in the serial Number
> attribute
> 2) how to indicate the applied semantics and characteristics of the
> serialNumber attribute use in a particular certificate.
> 
> The proposed text regarding issue 1 is:
> 
>     "The serialNumber attribute type SHALL, when present, be used
>     to differentiate between names where the subject field might
>     otherwise be identical.  This attribute has no defined semantics
>     beyond ensuring uniqueness of subject names."
> 
> This covers a number of usages from codes that may be reused among entities
> to globally unique identifiers. Just as long as they provide uniqueness of
> subject names.
> 
> Issue 2 have several valid solution which all are supported by the current
> text:
> 
> 1) Implicit knowledge
> 2) Through information defined by a certificate policy OID (contained in the
> referred policy or the associated CPS).
> 3) Through semantics information defined by an OID in the qcStatements
> extension.
> 4) Through repeating information into the subjectAltName extension as a
> directory name.
> 
> Solution 4 was the last solution discussed on the list and could easily
> handle the case where a subset of the attributes in the subject field have
> the capacity to identify a person. By duplicating these attributes as a
> directoryName in the subjectAltName extension, The CA also indicates that
> this set of attributes provide a complete DN.
> 
> We can conclude that all options above are valid. We can also conclude that
> this solution is already supported  by X.509 and thus, doesn't need further
> profiling.
> 
> I would personally avoid inclusion/recommendations of this solution in QC
> 03) since that may imply that this solution is more valid than any other
> solution mentioned above.
> 
> The conclusion is that QC 03 should remain unchanged with respect to this
> topic.
> 
> /Stefan


Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08903 for <[e-mail]>; Wed, 15 Mar 2000 09:06:17 -0800 (PST)
Received: from MessagingDirect.com (actually dougal.isode.com)  by woozle.isode.com (local) with ESMTP; Wed, 15 Mar 2000 17:06:22 +0000
X-Mailer: exmh version 2.0.2 2/24/98
To: Brian Tvedt <[e-mail]>
cc: [e-mail], "Charles W. Gardiner" <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components 
In-reply-to: Your message of "Wed, 15 Mar 2000 10:34:33 EST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 Mar 2000 17:06:21 +0000
Message-ID: <[e-mail]>
From: David Boyce <[e-mail]>

Brian Tvedt writes:

>Charles W. Gardiner wrote:

>>     Why limit it at all?  It's just a string of bytes -- and storage 
is
>> pretty cheap now.  A beauty of OIDs is that arcs can be assigned
>> for all sorts of thing to all sorts of organizations and people
>> just by extending the string.  Doesn't history show that early
>> notions of upper limits on size are soon overrun, e.g. 640 kbytes
>> of RAM?

FWIW, I'm in full agreement with Charles in his opposition to arbitrary
upper limits.  The Attribute OIDs being handled in ACs 'belong' to
whoever chooses to define them, and who knows whether someone might not
have a very good reason for an OID component which overflows 31 bits (or
any limit) defined in some other context, and then wish to use
attributes below that arc in an AC.  I agree it's unlikely, but we
should not remove the option for the sake of a temporary convenience.
 
>Storage is not so cheap when you're developing for handheld devices 
>or smart cards.  Also, in Java, creating lots of BigInteger objects 
>creates work for the garbage collector. 
> 
>Right now our Java libraries require each component to be an int 
>(limited to 31 bits for positive numbers).  We could accomodate 
>BigInteger's without much problem, but why do it if OIDs that require 
>them are never encountered?

Because the ASN.1 standards say so, and 'past performance is no
indication of future performance'.  As indicated above, restricting
component size involves taking a decision out of the hands of the person
to whom it would properly belong.

Charles's point is that for most internal uses you should not need the
ints at all, since the octet string representing the OID is normally
all that is required for internal OID operations (copy, compare for
equality).  Consequently, your Java libraries (which seem to require
each component to be an int) are doing more work than necessary
converting to/from integral OID representations, and placing
unnecessary restrictions on the form of OID in the process.

The occasions when you MAY need ints are when constructing an OID from
user (numeric) input, and constructing a printable representation of the
OID values, but even then the ints would be a convenience rather than a
necessity.  Both of these operations are sufficiently well-localised
that it should not be difficult to perform these operations without
impacting other areas. 

>Note also that this restriction applies only to component size.  No
>limit is necessary for the number of components.  So you can still
>"extend the string" indefinitely.

I don't understand why, if you have storage for an indefinite number
of components, you don't have storage for indefinitely long
components.

Incidentally, I notice that SerialNumber (section 4.2.5) is being
artificially restricted as well.  IMO, similar counter-arguments
apply.

David.

-- 
David Boyce

MessagingDirect (UK) Ltd.
Tel:	[phone]		 Richmond, Surrey, ENGLAND
Email:	[e-mail]	 WWW: http://www.MessagingDirect.
com/




Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08617; Wed, 15 Mar 2000 09:00:29 -0800 (PST)
Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id LAA03452; Wed, 15 Mar 2000 11:56:16 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdNAA0py_st; Wed Mar 15 11:56:08 2000
Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP; Wed, 15 Mar 2000 12:01:36 -0500
Received: from pmk_laptop ([192.168.218.97]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6)  with ESMTP id AAA2FFD; Wed, 15 Mar 2000 12:01:40 -0500
Reply-To: <[e-mail]>
From: "Paul Kierstead" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, <[e-mail]>
Subject: RE: ACprof: 28-bit restriction on OID components
Date: Wed, 15 Mar 2000 11:55:17 -0500
Message-Id: <004701bf8e9f$3e806790$61daa8c0@pmk_laptop.timestep.com>
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 8.5, Build 4.71.2232.26
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>

I am not so sure about 'slightly'. When you have OID's in text form, it gets
considerably more complex.

Parsing
	"OID.1.2.3.102048"
is vastly different from parsing
	"OID.1.2.3.12345678901233454"
In the former, delimiter examination, atoi and convert to base-128  does the
trick.
In the latter, you're going to need a _lot_ more code to
encode arbitrary decimal integers into base-128. Suddenly all standard
validation, etc. are thrown out the window. What purpose would it serve to
have a component so large? Just add another level ... it is what the
hierarchy is for.


Paul Kierstead
TimeStep Corporation
mailto:[e-mail]		http:\\www.timestep.com


> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: Wednesday, March 15, 2000 11:52 AM
> To: [e-mail]
> Subject: Re: ACprof: 28-bit restriction on OID components
>
>
> At 11:37 AM 3/15/00 -0500, Paul Koning wrote:
> >Yes, I agree, strongly.  The limitations on OIDs should be those that
> >are in the OID standard, and no others.
>
> This makes sense to me. OID parts that are >31 bits impose
> two types of
> overhead: code overhead so that the program can read/create
> the bit string,
> and storage overhead. The AC spec can strongly suggest
> against >31 bit
> values and give the reason of storage overhead, but all
> processing programs
> must be able to handle them. The latter only increases the
> code overhead
> slightly.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
>



Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08262 for <[e-mail]>; Wed, 15 Mar 2000 08:50:41 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Wed, 15 Mar 2000 08:51:59 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
In-Reply-To: <[e-mail]>
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:37 AM 3/15/00 -0500, Paul Koning wrote:
>Yes, I agree, strongly.  The limitations on OIDs should be those that
>are in the OID standard, and no others.

This makes sense to me. OID parts that are >31 bits impose two types of 
overhead: code overhead so that the program can read/create the bit string, 
and storage overhead. The AC spec can strongly suggest against >31 bit 
values and give the reason of storage overhead, but all processing programs 
must be able to handle them. The latter only increases the code overhead 
slightly.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07631 for <[e-mail]>; Wed, 15 Mar 2000 08:36:33 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQigqk04473; Wed, 15 Mar 2000 16:37:44 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA19575; Wed, 15 Mar 00 11:34:42 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA13328; Wed, 15 Mar 2000 11:37:43 -0500
Date: Wed, 15 Mar 2000 11:37:43 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Charles" == Charles W Gardiner <[e-mail]> writes:

 Charles> At 11:39 AM 3/15/2000 +0000, Stephen Farrell wrote:
 >>  Hi James,
 >> 
 >> If no one else objects then I'd be ok with 31 bits which caters
 >> for 9 decimal digits fine (32 bits potentially gets into signed
 >> int muck, esp with Java).

 Charles> Why limit it at all?  It's just a string of bytes -- and
 Charles> storage is pretty cheap now.  A beauty of OIDs is that arcs
 Charles> can be assigned for all sorts of thing to all sorts of
 Charles> organizations and people just by extending the string.
 Charles> Doesn't history show that early notions of upper limits on
 Charles> size are soon overrun, e.g. 640 kbytes of RAM?

Yes, I agree, strongly.  The limitations on OIDs should be those that
are in the OID standard, and no others.

	paul


Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05699 for <[e-mail]>; Wed, 15 Mar 2000 07:26:49 -0800 (PST)
Received: from phaos.com ([207.51.38.134]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id PAA39699; Wed, 15 Mar 2000 15:03:48 -0500 (EST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 10:34:33 -0500
From: Brian Tvedt <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
CC: "Charles W. Gardiner" <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Charles W. Gardiner wrote:

> 
> At 11:39 AM 3/15/2000 +0000, Stephen Farrell wrote:
> >
> >Hi James,
> >
> >If no one else objects then I'd be ok with 31 bits which
> >caters for 9 decimal digits fine (32 bits potentially gets
> >into signed int muck, esp with Java).

I am strongly in favor of a limit of 31 bits.

>     Why limit it at all?  It's just a string of bytes -- and storage is
> pretty cheap now.  A beauty of OIDs is that arcs can be assigned for all
> sorts of thing to all sorts of organizations and people just by extending
> the string.  Doesn't history show that early notions of upper limits on
> size are soon overrun, e.g. 640 kbytes of RAM?
> 

Storage is not so cheap when you're developing for handheld devices or smart
cards.  Also, in Java, creating lots of BigInteger objects creates work for the
garbage collector.

Right now our Java libraries require each component to be an int (limited to 31
bits for positive numbers).  We could accomodate BigInteger's without much
problem, but why do it if OIDs that require them are never encountered?

Note also that this restriction applies only to component size.  No limit is
necessary for the number of components.  So you can still "extend the string"
indefinitely.


--
Brian Tvedt, Ph.D.
Sr. Security Architect
Phaos Technology Corp.


Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04873 for <[e-mail]>; Wed, 15 Mar 2000 07:00:57 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13434; Wed, 15 Mar 2000 08:02:06 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA11665; Wed, 15 Mar 2000 10:02:03 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA20188; Wed, 15 Mar 2000 10:01:58 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 09:59:21 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "Manger, James H" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Farrell wrote:
> If no one else objects then I'd be ok with 31 bits which
> caters for 9 decimal digits fine (32 bits potentially gets
> into signed int muck, esp with Java).

Don't worry about Java. Just use a long (always 64 bits). Or a byte
array, a boolean array, or a BigInteger (all almost unlimited in size).

Steve Hanna
Sun Microsystems


Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04265 for <[e-mail]>; Wed, 15 Mar 2000 06:38:15 -0800 (PST)
Received: from gardiner.bbn.com (dhcp030-247.bbn.com [171.78.30.247]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id JAA12783; Wed, 15 Mar 2000 09:39:04 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 15 Mar 2000 09:34:09 -0500
To: [e-mail], "Manger, James H" <[e-mail]>
From: "Charles W. Gardiner" <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
Cc: "'PKIX'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:39 AM 3/15/2000 +0000, Stephen Farrell wrote:
>
>Hi James,
>
>If no one else objects then I'd be ok with 31 bits which 
>caters for 9 decimal digits fine (32 bits potentially gets 
>into signed int muck, esp with Java).

    Why limit it at all?  It's just a string of bytes -- and storage is
pretty cheap now.  A beauty of OIDs is that arcs can be assigned for all
sorts of thing to all sorts of organizations and people just by extending
the string.  Doesn't history show that early notions of upper limits on
size are soon overrun, e.g. 640 kbytes of RAM?

Charlie Gardiner
>
>Does anyone else know of other arcane OIDs that don't fit?
>I believe Russ and Tim are planning to include the same 
>restriction in the next rev of 2459bis, and the two profiles 
>really should impose the same limits.
>
>> P.S. Typo: rename "Appendix B: Object Identifiers" to "Appendix A: Object
>> Identifiers".
>
>Ta.
>
>Regards,
>Stephen.
>
>PS: Just a nit, but there is one thing with which I would 
>take issue: "scanf("%lu", &acn);" isn't an appropriate thing 
>to do with an OID arc is it? AFAIK, the only operation you 
>should do is equality matching so this argument doesn't 
>justify any particular sizing. (I've tried to suggest things 
>like this before and have always gotten beaten up for it:-)
>
>-- 
>____________________________________________________________
>Stephen Farrell         				   
>Baltimore Technologies,   tel: (direct line) [phone]
>61 Fitzwilliam Lane,                    fax: [phone]
>Dublin 2.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com
>


Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA03377 for <[e-mail]>; Wed, 15 Mar 2000 06:12:38 -0800 (PST)
Received: (qmail 52193 invoked from network); 15 Mar 2000 14:13:54 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 15 Mar 2000 14:13:54 -0000
Received: (qmail 5870 invoked by uid 1183); 15 Mar 2000 14:13:53 -0000
Date: Wed, 15 Mar 2000 15:13:51 +0100 (MET)
From: Magnus Nystrom <[e-mail]>
X-Sender: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Mobile credentials
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id GAA03378

All,

Please find attached to this email a memo discussing the use of and
potential need for a PDU format and associated protocol for down- (and
potentiall up-) load of personal credentials, such as private keys and
X.509 certificates.

Stephen Farrell of Baltimore is likely to give a presentation on this
subject at the upcoming IETF meeting in Adelaide. We are currently
unsure of whether this would be a work item for PKIX or for some BOF
(or at all), but at least it seems as if this mailing list would be a
good starting point. Comments are of course welcome and solicited.

Thanks,
-- Magnus & Stephen

Magnus Nyström,  RSA Laboratories
Stephen Farrell, Baltimore Technologies
---------------------------------------------------
                           Mobile credentials

1 Introduction

As the number, and more particularly the number of different types,
of devices, (particularly wirless), connecting to the Internet 
increases, the issue of credential mobility becomes an issue for 
IETF standardization. This note presents some background and 
existing work on the topic and recommends pursuing this topic in 
either the PKIX WG or a BOF.

2 Mobile Credentials

2.1 Background

A nice feature of smart-card based PKIs, in addition to the security
offered by the cards themselves, is the "free-seating solution," or
the portability of user's credentials. In order to provide a similar
solution to environments based on purely software implementations or 
"virtual cards" (a.k.a "soft tokens," software files containing 
information normally stored on smart cards) some kind of credential 
store from which users can download their soft-tokens, using some 
specified protocol is required. This protocol will provide mobility
for credentials.

Such a solution would also allow users to have identical credentials
on, e.g. their mobile phone as in their desktop. Adding an upload
protocol to the solution means that it in principle is possible to
always have the credential store up-to-date.

If a specification for a smart card application also specifies how to
store the application's data in a single software file, then it will
be possible to use this file format as a "virtual card" or "soft
token". Soft tokens can be used, e.g., for transfer of information
for later storage on a real card, or for use within a token-aware
system not using "real" tokens such as smart cards. An advantage of
having the soft token format similar to the "real" token format is
that the "format" layer in the software does not have to know if it
is dealing with a real token or not. Further, if the soft token
format is well known, it will in principle be possible to download
such a token from a "credential server". By doing this one would in
principle accommodate what generally is known as the "free seating
solution" - users will be able to use a single set of credentials
regardless of where they happen to work.

Even in some cases where real smart cards are used, there may
be some benefit to using such a protocol - e.g. when a new card
is received, but "old" credentials should be used. If the cards
offered the appropriate install and delete interfaces, then the
credentials could be (securely) moved between cards.

Many desktop applications also require mobility of credentials, for 
example to  support some "kiosk" style operation, when a user 
upgrades a PC, or when "hot-desking". It is sometimes required to 
integrate such credential mobility with single-sign-on solutions. A 
protocol that could be used in the smart card case, can also be 
used to solve this case.

Finally, some applications may benefit from being able to migrate
credentials from a desktop to a smart card, in particular where
the smart card using device has limited user interface capabililies,
e.g. a mobile phone.

2.2 Security Issues

Mobile credentials will never be as secure as a "pure" smart card 
solution. However, reasonable security may be accomplished through 
some simple means, outlined in the following sections. One should 
keep in mind, however, that platforms to which credentials are 
downloaded usually cannot be regarded as tamper-resistant, and it 
therefore is not too hard to analyze contents of their memories. 
Further, storage of private keys, even if they are encrypted, on 
a credential server, will be unacceptable in some environments.

2.2.1 Confidentiality Protection

Private information in credentials must be protected by
encryption. The key for this encryption can be derived from a
password, but can also be something stronger. As an example of a
stronger method, one could consider the user authenticating to the
credential store using some strong authentication method (not
requiring public-key cryptography) and then downloading (over a
confidentiality-protected connection) not only the credentials but
also (parts of) the key to unlock the card. This way, the key used to
protect the credentials will not be derived from the user's password
solely. Further, in order to make it harder for a credential store
administrator to find out about users' private objects, the key
stored at the operator's server may be combined with a user-derived
key to form an actual key-encryption key.

2.2.2 Integrity Protection

Credentials must be integrity protected, since it would otherwise be
possible for an attacker to substitute parts of the credentials
(e.g. trusted certificates) with something more advantageous for
the attacker. Once again, the key for this integrity-protection may
be derived from a user password, but in this case, it could also be
the user's own private key (assuming that private objects on the
token are decrypted before the integrity check is done).

2.2.3 Down- and Up-load protocols

The copy of the credentials stored in the credential store should
always be up-to-date, in order to provide for a true free-seating
solution. This means that uploads should be performed as soon as
changes are made to the user's copy of the credentials. A user could
always downloads the credentials from the store when e.g. connecting
to the network. If the store is unavailable, e.g. due to a roaming
user, a locally cached copy of the credentials may be used. The 
protocols used must be integrity protected, and a user might be 
required to do a strong (public-key based) authentication in order 
to upload credentials.

2.3 Other Issues

In addition to the specific issues raised above, the following
more generic issues may pose challenges in providing a solution
to this problem:

- IPR: Some of the useful mechanisms are encumbered
- Privacy: Use of a credential store should not decrase the
  expectations of the user for privacy (e.g. if the credentials
  are subsequently used for authentication with some protocol
  that does provide privacy)
- Robustness: Credential stores should not unacceptably 
  increase the potential for denial-of-service attacks
- Performance: Clients for the putative protocol should not
  typically have to wait too long for access to credentials
- Bootstrapping: The use of, e.g. TLS server authentication,
  depends on the client having a (set of) trusted root(s) - as
  the putative protocol may be providing these roots, there 
  may be some hard bootstrapping issues.
  
Finally, we note that whether or not the user authentication,
credential protection and specific credential formats should 
be separated, or should be intertwined, is an open issue.

3 Prior work

3.1 The "inetOrgPerson" object class

In [6], an auxiliary object class, "inetOrgPerson," is specified. One
attribute defined for use with this object class is "userPKCS12",
which is a PKCS #12 [4] PDU, containing personal credentials.

3.2 The "pkcsEntity" object class

In [3], another auxiliary object class, "pkcsEntity," is
specified. This object class is capable of carrying "userPKCS12" PDUs
as well as "pKCS15Token" PDUs.

3.3 Active Directory's "user" object class

In [2], an object class "user" is specified, holding, among other
attributes a "privateKey" attribute, whose values are encrypted
private keys.

4 Possible Specifications needed

4.1 Soft-token up- or down-load protocol

This protocol could be made very simple; it could in principle be
specified in terms of the current http [1] protocol, using the
request-response model specified therein. Credential servers would
listen on certain ports for connection requests, perform TLS
handshakes and act in accordance with received requests. Some
stronger authentication methods may have to be defined for use with
http.

4.2 Specification of soft token format

The specification should leverage some existing specification. As an
example, the current draft of PKCS #15 [5] includes a format for 
credentials, which could simplify this task, but other solutions are
clearly also possible.

5 Discussion and Conclusion

Evidently, all the examples from section 3 are based on the use of 
LDAP-accessible directories as "credential stores." A disadvantage 
with this is that LDAP, despite its name, can be considered 
"heavy-weight" in this context, since a very simple protocol for 
up- and down-loads would suffice. LDAP is clearly to complex for 
wireless devices such as current mobile phones. The solution in 
Section 3.3 above also suffers from the use of non-standard 
attributes.

The conclusion is therefore, that while the work mentioned in
sections 3.1 - 3.3 is useful and provides a basic framework, it does
not quite fullfil our needs of a simple protocol and a standardized
format for personal credentials.

In summary, this topic appears to be suited for consideration 
in the PKIX WG, or, perhaps more likely, for a more BOF on the 
topic; followed by standardization of a credential mobility 
protocol and (set of) credential format(s).

5 References

[1] "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter,
    P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol --
    HTTP/1.1", IETF RFC 2616, June 1999.

[2] "Microsoft Windows NT Active Directory Technical Summary,"
    Microsoft Corp., September 1997.

[3] "PKCS #9 v2.0: Selected object classes and attribute types," RSA
    Laboratories, February 2000.

[4] "PKCS #12 v1.0: Personal Information Exchange Syntax," RSA
    Laboratories, June 1999.

[5] "PKCS #15 v1.1 (Draft): Cryptographic Token Information Syntax
    Standard," RSA Laboratories, December 1999.

[6] M. Smith, "Definition of the inetOrgPerson LDAP Object Class,"
    IETF work in progress, January 2000



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26744 for <[e-mail]>; Wed, 15 Mar 2000 03:39:11 -0800 (PST)
Received: by balinese.baltimore.ie; id LAA24273; Wed, 15 Mar 2000 11:40:19 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma024186; Wed, 15 Mar 00 11:40:01 GMT
Received: from baltimore.ie (lease168-21.baltimore.ie [192.168.21.168]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA04394; Wed, 15 Mar 2000 11:39:58 GMT
Message-ID: <[e-mail]>
Date: Wed, 15 Mar 2000 11:39:58 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: "'PKIX'" <[e-mail]>, xme <[e-mail]>
Subject: Re: ACprof: 28-bit restriction on OID components
References: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi James,

If no one else objects then I'd be ok with 31 bits which 
caters for 9 decimal digits fine (32 bits potentially gets 
into signed int muck, esp with Java).

Does anyone else know of other arcane OIDs that don't fit?
I believe Russ and Tim are planning to include the same 
restriction in the next rev of 2459bis, and the two profiles 
really should impose the same limits.

> P.S. Typo: rename "Appendix B: Object Identifiers" to "Appendix A: Object
> Identifiers".

Ta.

Regards,
Stephen.

PS: Just a nit, but there is one thing with which I would 
take issue: "scanf("%lu", &acn);" isn't an appropriate thing 
to do with an OID arc is it? AFAIK, the only operation you 
should do is equality matching so this argument doesn't 
justify any particular sizing. (I've tried to suggest things 
like this before and have always gotten beaten up for it:-)

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00698 for <[e-mail]>; Tue, 14 Mar 2000 18:59:36 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA29064 for <[e-mail]>; Wed, 15 Mar 2000 14:00:19 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdcLUEI_; Wed Mar 15 13:59:46 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id NAA01950 for <[e-mail]>; Wed, 15 Mar 2000 13:59:44 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0uaQqN; Wed Mar 15 13:59:14 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA00534 for <[e-mail]>; Wed, 15 Mar 2000 13:59:13 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <G9VG5DXG>; Wed, 15 Mar 2000 13:58:49 +1100
Message-ID: <73388857A695D31197EF00508B08F2988A3B28@NTMSG0131>
From: "Manger, James H" <[e-mail]>
To: "'PKIX'" <[e-mail]>
Subject: ACprof: 28-bit restriction on OID components
Date: Wed, 15 Mar 2000 13:58:48 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"

draft-ietf-pkix-ac509prof-02.txt "An Internet Attribute Certificate Profile
for Authorization" restricts object identifier components to be less than
2^28 [Appendix B: Object Identifiers, 2nd paragraph].  The rational is that
this allows each component to be represented within a single 32 bit word.
The 28 bit limit is unreasonable and unnecessary.
28 bits is unreasonable as there is an existing standard that assigns larger
object identifier components.  Standards Australia MP59 "Naming and
addressing in the Australian OSI environment" (published in 1995) assigns an
object identifier arc for each organization in Australia.  The arc takes the
form { 1 2 36 acn }, where 'acn' is the organization's Australian Company
Number (ACN).  An ACN is a 9 decimal digit number, hence requiring upto 30
bits to represent.
28 bits is unnecessary.  A restriction to 32 bits is sufficient to simply
implementation.  It may be helpful to represent a single component in a 32
bit word, but not the encoding of a single component.  Holding a component
in a 32 bit word may simplify conversion to and from a decimal string as
standard printing and parsing routines can be used, e.g. scanf("%lu", &acn);
printf("%lu", acn);.  For instance, it may simplify use of dotted-decimal
notation for object identifiers in LDAP, e.g. "1.2.36.674528434".  Holding
an encoding of a single component in a 32 bit word is of less value: it
cannot be done for the first two components (as they are encoded together
into a single octet); it does not help printing or parsing from decimal
digits and it cannot be converted directly to an encoding (you need to know
how many octets to extract from the word).  It is almost conceivable that
the encoding of a single element is held in a 32 bit word at some point in
someone's implementation.  However, no such implementation is mentioned in
ac509prof and it would not be a valid reason for putting this restriction in
a standard anyway.
The 28 bit restriction in draft-ietf-pkix-ac509prof-02.txt should be changed
to a 32 bit restriction (or removed completely).  Replace the 1st sentence
of the 2nd paragraph of Appendix B: Object Identifiers with:
	"This specification mandates support of OIDs which have arc elements
with values that are less than 2^32, i.e. a conforming application MUST
handle any value between 0 and 4 294 967 295 inclusive."
P.S. Typo: rename "Appendix B: Object Identifiers" to "Appendix A: Object
Identifiers".


Received: from harry.cmr.gov (harry.cmr.gov [140.162.6.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18241 for <[e-mail]>; Tue, 14 Mar 2000 14:22:59 -0800 (PST)
Received: from dolphin.cmr.gov (dolphin [140.162.3.135]) by harry.cmr.gov (8.9.3/8.9.3) with ESMTP id RAA13533; Tue, 14 Mar 2000 17:24:05 -0500 (EST)
Received: from cmr.gov (localhost [127.0.0.1]) by dolphin.cmr.gov (8.9.1b+Sun/8.9.1) with ESMTP id RAA09211; Tue, 14 Mar 2000 17:23:47 -0500 (EST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 14 Mar 2000 17:23:46 -0500
From: "Patrick G. Moore" <[e-mail]>
Organization: Center for Monitoring Research
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>, [e-mail]
Subject: Re: key update - problem
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle Adams wrote:
> 
> Hi Martin,
> 
> > ----------
> > From:         Martin Szotkowski[SMTP:[e-mail]]
> > Sent:         Tuesday, March 14, 2000 10:42 AM
> > To:   [e-mail]
> > Subject:      key update - problem
> >
> > Hi all,
> >
> > (excuse me my English)
> > I think, that new key must be sign with old key (or in other way POP old
> > key) and new key POP must be too present.
> > I can't find, how create key update request. In CMP [RFC 2510] and CRMF
> > [RFC
> > 2511] are defined
> > "kur as CertReqMessages; CertReqMsg; CertRequest", but there is no place
> > for
> > old key.
> > Can me someone advise right way.
> 
> When doing a key update it is not necessary to supply the old public key and
> to prove possession of the old private key all over again.  In the request
> for a certificate for the new key pair, it is sufficient to put a pointer to
> the old certificate that is being updated/replaced.  This is the purpose of
> the OldCertId control (see Section 6.5 of RFC 2511).
> 
> The key update request needs to contain the new public key and POP for the
> new private key, but need not contain anything pertaining to the old
> certificate beyond this pointer.
> 
> Carlisle.

Hi Carlisle,

RFC 2510 says to use a secure transport for requests.  I would think, for POP
of an old key, you could put the update request in the body of a signed S/MIME
message, signed with the old cert.  Are there any profiles defined for CMP over
different transports, like S/MIME, http, FTP etc..., which address this issue?
It seems appropriate for key updates, so that an imposter can't request a new
key
for an existing cert.

Pat


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15544 for <[e-mail]>; Tue, 14 Mar 2000 11:38:41 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDTZ17Y>; Tue, 14 Mar 2000 14:39:24 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Martin Szotkowski'" <[e-mail]>
Cc: [e-mail]
Subject: RE: key update - problem
Date: Tue, 14 Mar 2000 14:39:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Martin,

> ----------
> From: 	Martin Szotkowski[SMTP:[e-mail]]
> Sent: 	Tuesday, March 14, 2000 10:42 AM
> To: 	[e-mail]
> Subject: 	key update - problem
> 
> Hi all,
> 
> (excuse me my English)
> I think, that new key must be sign with old key (or in other way POP old
> key) and new key POP must be too present.
> I can't find, how create key update request. In CMP [RFC 2510] and CRMF
> [RFC
> 2511] are defined
> "kur as CertReqMessages; CertReqMsg; CertRequest", but there is no place
> for
> old key.
> Can me someone advise right way.
 
When doing a key update it is not necessary to supply the old public key and
to prove possession of the old private key all over again.  In the request
for a certificate for the new key pair, it is sufficient to put a pointer to
the old certificate that is being updated/replaced.  This is the purpose of
the OldCertId control (see Section 6.5 of RFC 2511).

The key update request needs to contain the new public key and POP for the
new private key, but need not contain anything pertaining to the old
certificate beyond this pointer.

Carlisle.



Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11196 for <[e-mail]>; Tue, 14 Mar 2000 07:41:36 -0800 (PST)
Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id QAA29614 for <[e-mail]>; Tue, 14 Mar 2000 16:42:33 +0100 (CET)
Message-ID: <040a01bf8dcb$ea4dd4b0$0c7011ac@SZOTKOWSKI>
From: "Martin Szotkowski" <[e-mail]>
To: <[e-mail]>
Subject: key update - problem
Date: Tue, 14 Mar 2000 16:42:32 +0100
Organization: PVT, a.s.
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.00.2918.2701
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701

Hi all,

(excuse me my English)
I think, that new key must be sign with old key (or in other way POP old
key) and new key POP must be too present.
I can't find, how create key update request. In CMP [RFC 2510] and CRMF [RFC
2511] are defined
"kur as CertReqMessages; CertReqMsg; CertRequest", but there is no place for
old key.
Can me someone advise right way.

thanks Martin




Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09399 for <[e-mail]>; Tue, 14 Mar 2000 06:14:18 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.5) id RAA15101; Tue, 14 Mar 2000 17:15:16 +0300 (MSK)
Message-Id: <[e-mail]>
Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0) id xma015036; Tue, 14 Mar 00 17:14:27 +0300
From: "Valery Smyslov" <[e-mail]>
Organization: TWS
To: [e-mail]
Date: Tue, 14 Mar 2000 17:14:16 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Certificate verification algorithm
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12b)

Hi,

I have one question about certficate verification algorithm described in 
son-of-2459. Section 6.3.3, Step1, second "b", (ii) on page 71 states:

---------------------------------------------------------------------
            (ii) If CRL X did not include an issuing distribution point
            extension, or the onlySomeReasons field was not present in
            that extension, set approved_reasons to "all_reasons."  If
            CRL X includes an issuing distribution point extension, and
            the onlySomeReasons field is present, assign
            approved_reasons the intersection of approved reasons and
                                 ^^^^^^^^^^^^
            the onlySomeReasons field.
---------------------------------------------------------------------

Isn't it a typo in this paragraph? Shouldn't it be "union" instead of 
"intersection"? Otherwise this logic is unclear to me.

The same paragraph appears also on the next page (72).

Regards,
Valera Smyslov.



Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA06433 for <[e-mail]>; Tue, 14 Mar 2000 04:46:06 -0800 (PST)
Received: (qmail 40544 invoked from network); 14 Mar 2000 12:47:17 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 14 Mar 2000 12:47:17 -0000
Received: (qmail 15118 invoked from network); 14 Mar 2000 12:47:16 -0000
Received: from dhcp02.ua.dynas.se (10.131.2.152) by spirit.dynas.se with SMTP; 14 Mar 2000 12:47:16 -0000
Date: Tue, 14 Mar 2000 13:47:49 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
To: Ismo Heikkonen <[e-mail]>
cc: [e-mail]
Subject: Re: QC Inconsistency
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Ismo,

This is correct, the reference should be to X.501:1993 and not X.501:1997
(the reference to PKCS #9 should be changed as well). Thanks for the
catch.

-- Magnus
Magnus Nystrom		Email: [e-mail]
RSA Laboratories

On Wed, 8 Mar 2000, Ismo Heikkonen wrote:

> I found an inconsistency in document draft-ietf-pkix-qc-03.txt:
> 
> In section 2.4. "Uniqueness of names" there are references to X.501-1997
> version, but however, according to ASN.1 definitions the Name is
> imported from RFC2459, which defines the Name without support for X.500
> Context feature.
> So the reference should be changed to X.501 - 93, as RFC 2459 states.
> 
> By using X.500 1997 context feature you could be able to add more than
> one serial number attribute values to subject field, and in some cases
> this could be a useful feature .



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02555 for <[e-mail]>; Tue, 14 Mar 2000 03:20:08 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20232; Tue, 14 Mar 2000 06:21:18 -0500 (EST)
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-roadmap-05.txt
Date: Tue, 14 Mar 2000 06:21:18 -0500
Sender: [e-mail]

--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 PKIX Roadmap
	Author(s)	: A. Arsenault, S. Turner 
	Filename	: draft-ietf-pkix-roadmap-05.txt
	Pages		: 50
	Date		: 13-Mar-00
	
This document provides an overview or 'roadmap' of the work done by
the IETF PKIX working group. It describes some of the terminology
used in the working group's documents, and the theory behind an
X.509-based Public Key Infrastructure and Privilege Management
Infrastructure (PMI). It identifies each document developed by the
PKIX working group, and describes the relationships among the various
documents. It also provides advice to would-be PKIX implementors
about some of the issues discussed at length during PKIX development,
in hopes of making it easier to build implementations that will
actually interoperate.

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

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-roadmap-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-roadmap-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-roadmap-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-roadmap-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 mailgate.dave.sonera.fi (mailgate.dave.sonera.fi [194.137.238.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21526 for <[e-mail]>; Tue, 14 Mar 2000 00:37:13 -0800 (PST)
Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.216.195]) by mailgate.dave.sonera.fi (8.8.5/8.8.5) with ESMTP id KAA16234 for <[e-mail]>; Tue, 14 Mar 2000 10:37:52 +0200 (EET)
Received: from sonera.com (silverado.tkklpr.tele.fi [131.177.76.146]) by smtp.dave.sonera.fi (8.8.5/8.8.5) with ESMTP id KAA06109 for <[e-mail]>; Tue, 14 Mar 2000 10:37:51 +0200 (EET)
Message-ID: <[e-mail]>
Date: Tue, 14 Mar 2000 10:36:51 +0200
From: Ismo Heikkonen <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: CRL Problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
I have the following kind of problem:
I have to create grandmother- mother-child certificate chains. Each
parent will have
one or more children. The only common factors between these three
certificates are
the public key and serial number attribute in
subjectAltName-directoryName field.
Different CA's have signed these certs.

When the upper level certificate is revoked, all child certificates
shall be revoked
also.
A solution could be to have three CRL's, and each certificate  will have
one, two or
three distribution points, where respective  CRL information can be
found. But the
problem is that the child does not know implicitly the
certificateSerialNumber of it's
parent, just the subjectAltName serialNumber. It means that when each
CRL entry
is processed, the respective certificate shall be searched from the
directory, and
subjectAltName --serialNumber attribute picked up. This is too
tedious and resource consuming.

An easier solution would be if I were able to use subjectAltName
extension also in
CRL entry extension. In this case I would be able to add both
certificateSerialNumber and subjectAltName-serialNumber on CRL, and my
application could see easily if the subjectAltName-serialNumber is
revoked or not.

Actually issuerAltName is a legal extension for CRL entry, but
subjetAltName is not,
which is a defect in X.509, I think.

An other solution could be to publish two CRL's: one based on
certificateSerialNumber and the other one based on
subjectAltName-directoryName-serialNumber. I tried with an
implementation, but it can create CRL' s just for it's own certificates.

Have you seen any working solutions for this kind of case? I would not
like to go to
OCSP based solution due to the strict response time and availability
requirements.

Ismo






Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26038; Mon, 13 Mar 2000 14:32:32 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 13 Mar 2000 14:33:51 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: New draft on ASN.1 pitfalls
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Timing is everything. Just as the PKIX mailing list starts to talk about 
ASN.1 again, a new draft comes out that does a good job of listing some of 
the ASN.1 gotchas to look out for, as well as why ASN.1 isn't necessarily a 
great format to use (although it's a tad too late for that now...). Anyhow, 
take a look at 
<http://www.ietf.org/internet-drafts/draft-yu-asn1-pitfalls-00.txt>. The 
author said he's open to adding any PKIX-specific and S/MIME-specific 
warnings to the document.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24445 for <[e-mail]>; Mon, 13 Mar 2000 13:22:47 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA23581 for <[e-mail]>; Mon, 13 Mar 2000 16:24:27 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA23569 for <[e-mail]>; Mon, 13 Mar 2000 16:24:26 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id QAA04157 for <[e-mail]>; Mon, 13 Mar 2000 16:24:13 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id QAA01730 for <[e-mail]>; Mon, 13 Mar 2000 16:20:45 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 13 Mar 2000 16:20:44 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: ASN.1 Notation
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 0YhAxJBECrTIqliS7s4Yrg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Massimiliano Pala <[e-mail]>
> 
> You say using X.509 it would be hard to use something else, but I do
> think it would be WORTH it. Indeed we all are working on Open Standards
> for best interoperability (why else doing standards??). Why are the
> ietf rfcs/draft available for free ??

Arguably the best available documentation (free or otherwise) is
"ASN.1 Complete" by Professor John Larmouth.  Download from
http://www.oss.com/asn1/booksintro.html.




Received: from spyglass.cyclonecommerce.com ([12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23914 for <[e-mail]>; Mon, 13 Mar 2000 13:07:36 -0800 (PST)
Received: from cyclonecommerce.com (cc957496-a.taylor1.mi.home.com [24.10.48.186]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id G4J6NN8F; Mon, 13 Mar 2000 14:09:41 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 16:05:34 -0800
From: Timothy Fisher <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Diana Smetters <[e-mail]>
CC: "Salz, Rich" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, Massimiliano Pala <[e-mail]>, [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

IBM's alphaworks site has some great Java ASN1 tools.

www.alphaworks.ibm.com

Tim

Diana Smetters wrote:
> 
> Cryptix has the beginnings of an ASN.1->Java compiler that seems to be
> under relatively current development (www.cryptix.org).
> 
> --Diana
> 
> "Salz, Rich" wrote:
> >
> > The formal spec for ASN.1 is not freely available.  There are many
> > "good enough" documents around.  Why was ASN.1 chosen?  Well gee, if
> > the WG is using X.509 it would be hard to use something else, no?
> >
> > As for free ASN1 compilers, there are a couple; SNACC seems to be
> > the parent of two that are actively maintained, one as part of the
> > S/MIME freeware package, and another as part of DSTC's "oscar"
> > kit. There are probably others.
> >         /r$


Received: from spyglass.cyclonecommerce.com ([12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23820 for <[e-mail]>; Mon, 13 Mar 2000 13:06:17 -0800 (PST)
Received: from cyclonecommerce.com (cc957496-a.taylor1.mi.home.com [24.10.48.186]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id G4J6NN8C; Mon, 13 Mar 2000 14:08:22 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 16:04:16 -0800
From: Timothy Fisher <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Massimiliano Pala <[e-mail]>, [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, there are open source ASN.1 tools available.



Tony Bartoletti wrote:
> 
> As long as the subject is at hand...
> 
> Are there any open-source ASN.1 compilers available?
> 
> ___tony___
> 
> At 02:19 PM 03/13/2000 -0800, Timothy Fisher wrote:
> >The "laymans guide to ASN1" on the RSA website is an excellent doc.
> >This contains all the information that you should need to understand
> >and use the ASN1 stuff for info security purposes.
> >
> >Tim
> >
> >Massimiliano Pala wrote:
> > >
> > > Hi all,
> > >
> > > I have a simple question about the ASN.1. Are there available free
> > > ASN.1 docs available on the net ???
> > >
> > > C'you,
> > >
> > >         Massimiliano Pala ([e-mail])
> 
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA22960 for <[e-mail]>; Mon, 13 Mar 2000 12:27:39 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with SMTP id VAA19389; Mon, 13 Mar 2000 21:28:39 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 21:30:59 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Salz, Rich" <[e-mail]>, [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCFDEA600F4C56E9D9681F425"

This is a cryptographically signed message in MIME format.

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

"Salz, Rich" wrote:
> 
> The formal spec for ASN.1 is not freely available.  There are many
> "good enough" documents around.  Why was ASN.1 chosen?  Well gee, if
> the WG is using X.509 it would be hard to use something else, no?
> 
> As for free ASN1 compilers, there are a couple; SNACC seems to be
> the parent of two that are actively maintained, one as part of the
> S/MIME freeware package, and another as part of DSTC's "oscar"
> kit. There are probably others.
>         /r$

You say using X.509 it would be hard to use something else, but I do
think it would be WORTH it. Indeed we all are working on Open Standards
for best interoperability (why else doing standards??). Why are the
ietf rfcs/draft available for free ??

Well (this is only my personal vision but I think it could be useful
to think about it) I know it is actually not applicable changing the
used ASN.1 in favour of some other (better?) standard (to be developed?)
but it will be ever worst while adopting it for almost every application ...

Something about patented/not patented talk have recently taken place
on the list about time-stamping ISO interoperability: it is a similar
problem, somehow...

We could implement a superset of the ASN.1 that do follow somhow the
currently adopted format (if it is possible due to pending patents (?)).

I hope I made myself clear dispite my english (?) ... What do you think ?

C'you,

	Massimiliano Pala ([e-mail])
--------------msCFDEA600F4C56E9D9681F425
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMzEzMjAzMDU5WjAjBgkqhkiG9w0BCQQxFgQUut1Fi8HrFLWWvd9Akba+bNeXFqkw
DQYJKoZIhvcNAQEBBQAEgYCGxHEyq9uwLGo1rqbN/U+qRQKlHgEgdPK5/eekE7sBZ7i/B1gf
vW39s5aDGH4Q04gEI0pwi63NO/JSdaLCvQAY3Cva/5fMtAwbMCQqCqdzJ+naYNJRxN/zpxbS
dcgmGsAHfjJEOKVPaBBhwxpSR+/SjZI4S9bz6cvhU90bS4gr7g==
--------------msCFDEA600F4C56E9D9681F425--



Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA22278 for <[e-mail]>; Mon, 13 Mar 2000 12:06:31 -0800 (PST)
Received: from louise.parc.xerox.com ([13.2.118.28]) by alpha.xerox.com with SMTP id <70125(2)>; Mon, 13 Mar 2000 12:07:34 PST
Received: from parc.xerox.com ([13.1.100.95]) by louise.parc.xerox.com with SMTP id <358664>; Mon, 13 Mar 2000 12:07:21 PST
Message-ID: <[e-mail]>
From: Diana Smetters <[e-mail]>
Organization: Xerox Parc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: "Salz, Rich" <[e-mail]>
CC: "'Tony Bartoletti'" <[e-mail]>, Timothy Fisher <[e-mail]>, Massimiliano Pala <[e-mail]>, [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 13 Mar 2000 12:07:34 PST

Cryptix has the beginnings of an ASN.1->Java compiler that seems to be
under relatively current development (www.cryptix.org).

--Diana 

"Salz, Rich" wrote:
> 
> The formal spec for ASN.1 is not freely available.  There are many
> "good enough" documents around.  Why was ASN.1 chosen?  Well gee, if
> the WG is using X.509 it would be hard to use something else, no?
> 
> As for free ASN1 compilers, there are a couple; SNACC seems to be
> the parent of two that are actively maintained, one as part of the
> S/MIME freeware package, and another as part of DSTC's "oscar"
> kit. There are probably others.
>         /r$


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22031 for <[e-mail]>; Mon, 13 Mar 2000 12:03:24 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id MAA16441; Mon, 13 Mar 2000 12:03:49 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 13 Mar 2000 12:04:23 -0800
To: "Pawling, John" <[e-mail]>, Timothy Fisher <[e-mail]>, Massimiliano Pala <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: SNACC ASN.1 Freeware
Cc: [e-mail]
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

John,

Thanks for the extended response!  Very informative.

___tony___



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from harry.cmr.gov (harry.cmr.gov [140.162.6.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21819 for <[e-mail]>; Mon, 13 Mar 2000 12:00:18 -0800 (PST)
Received: from dolphin.cmr.gov (dolphin [140.162.3.135]) by harry.cmr.gov (8.9.3/8.9.3) with ESMTP id PAA15614; Mon, 13 Mar 2000 15:01:15 -0500 (EST)
Received: from cmr.gov (localhost [127.0.0.1]) by dolphin.cmr.gov (8.9.1b+Sun/8.9.1) with ESMTP id PAA08864; Mon, 13 Mar 2000 15:00:57 -0500 (EST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 15:00:56 -0500
From: "Patrick G. Moore" <[e-mail]>
Organization: Center for Monitoring Research
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tony Bartoletti wrote:
> 
> As long as the subject is at hand...
> 
> Are there any open-source ASN.1 compilers available?
> 
> ___tony___
> 
> At 02:19 PM 03/13/2000 -0800, Timothy Fisher wrote:
> >The "laymans guide to ASN1" on the RSA website is an excellent doc.
> >This contains all the information that you should need to understand
> >and use the ASN1 stuff for info security purposes.
> >
> >Tim
> >
> >Massimiliano Pala wrote:
> > >
> > > Hi all,
> > >
> > > I have a simple question about the ASN.1. Are there available free
> > > ASN.1 docs available on the net ???
> > >
> > > C'you,
> > >
> > >         Massimiliano Pala ([e-mail])
> 
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900

Try the snacc compiler

http://www.idiom.com/free-compilers/TOOL/ASN1-1.html

I watch thier low-volume mailing list.

cheers
Pat


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21504 for <[e-mail]>; Mon, 13 Mar 2000 11:55:34 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 5241D15532; Mon, 13 Mar 2000 14:56:01 -0500 (EST)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 27B517C0E8; Mon, 13 Mar 2000 14:56:01 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <F7ZJK2FH>; Mon, 13 Mar 2000 14:56:48 -0500
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Timothy Fisher <[e-mail]>, Massimiliano Pala <[e-mail]>
Cc: [e-mail]
Subject: RE: ASN.1 Notation
Date: Mon, 13 Mar 2000 14:56:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The formal spec for ASN.1 is not freely available.  There are many
"good enough" documents around.  Why was ASN.1 chosen?  Well gee, if
the WG is using X.509 it would be hard to use something else, no?

As for free ASN1 compilers, there are a couple; SNACC seems to be
the parent of two that are actively maintained, one as part of the
S/MIME freeware package, and another as part of DSTC's "oscar"
kit. There are probably others.
	/r$



Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21378 for <[e-mail]>; Mon, 13 Mar 2000 11:54:38 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJJM6D>; Mon, 13 Mar 2000 14:55:18 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Timothy Fisher <[e-mail]>, Massimiliano Pala <[e-mail]>
Cc: [e-mail]
Subject: SNACC ASN.1 Freeware (was RE: ASN.1 Notation)
Date: Mon, 13 Mar 2000 14:55:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Tony,

The DER-enhanced SNACC ASN.1 freeware is freely available to everyone at
J.G. Van Dyke and Associates' (VDA) S/MIME Freeware Library (SFL) web page
(http://www.jgvandyke.com/services/infosec/sfl.htm).  The snacc1_5VDA.zip
file contains the SNACC v1.3 rev 0.07 ASN.1 Compiler and Library source code
compilable for Unix and MS Windows NT/95/98.  The C++ version of SNACC has
been enhanced by VDA to implement the Distinguished Encoding Rules.  Project
files and makefiles are included.  This file also includes a sample test
project demonstrating the use of the SNACC classes.  SNACC implements the
majority of ASN.1 encoding/decoding rules.  SNACC does not support all of
the latest ASN.1 features, but there are work-arounds that allow SNACC to
be used to produce ASN.1 hex encodings that are identical to those 
produced by ASN.1 libraries that do support the latest ASN.1 features.  
Also note that many of the PKIX specs, such as RFC 2459, include 
1988-compliant ASN.1 syntax modules which can be directly compiled using
SNACC.

We are currently enhancing the C and C++ versions of the SNACC library
to support PrintableString, TeletexString, NumericString, IA5String, 
VisibileString, BMPString, UniversalString, and UTF8String.  We are 
adding an optional function that will be used to convert ASN.1 OCTET
STRINGs to single- and multi-byte character strings.  This is needed
to support the RFC 2459 PKIX requirements.  The SNACC library will
decode an object as it always has.  If the app/library needs the 
ASN.1 OCTET STRINGs converted to character strings, then it will 
call an additional SNACC function/class to perform the conversion.
The SNACC enhancement is being made to minimize the impact to 
existing code that uses SNACC.  If an app/library does not need 
the ASN.1 OCTET STRINGs converted, then it will not call the 
conversion function/classes and will use the SNACC-generated 
structures/classes as always.  We expect to have the enhanced
SNACC compiler and library delivered by 24 March 2000.

As part of the SFL <http://www.armadillo.huntsville.al.us/software/smime>, 
VDA is using SNACC to implement the S/MIME v3 set of specs.  VDA is also 
enhancing the freeware Certificate Management Library
(http://www.armadillo.huntsville.al.us/software/certmgmt/index.html) that
uses SNACC to implement the 1997 X.509 Recommendation.

The SNACC ASN.1 library is totally unencumbered as documented in the
following excerpt from the SFL Public License. 

"+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

           SNACC Abstract Syntax Notation.1 (ASN.1) Software 

The SNACC ASN.1 software is composed of the SNACC Compiler and the SNACC 
Library.  The SNACC Compiler is covered by the attached GNU General 
Public License (GPL).  The GPL states that the subject software may be 
freely distributed if the distributor: provides all source code for the
subject software; does not charge for the use of the subject software; 
and provides a copy of the GPL along with the subject software. The 
SNACC Library software is completely unencumbered.  None of the GNU 
public licenses apply to the SNACC Library.

Under contract to the U.S. Government, J.G. Van Dyke and Associates, Inc
(VDA), has made enhancements to the SNACC Compiler and Library.  VDA 
has clearly marked all enhancements made to the SNACC Compiler as 
required by the GNU GPL.  The SFL Public License applies to the 
enhancements that VDA has made to the SNACC Compiler and Library. 
VDA has met the requirements of the GNU GPL including: providing all
source code for the enhanced SNACC Compiler; freely
distributing the enhanced SNACC Compiler; and providing a copy of the 
GPL along with the enhanced SNACC Compiler. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"

The GNU General Public License can be retrieved from
http://www.fsf.org/copyleft/gpl.html.  The SFL public license can be
retrieved from the aforementioned VDA SFL web page.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Monday, March 13, 2000 2:40 PM
To: Timothy Fisher; Massimiliano Pala
Cc: [e-mail]
Subject: Re: ASN.1 Notation


As long as the subject is at hand...

Are there any open-source ASN.1 compilers available?

___tony___

At 02:19 PM 03/13/2000 -0800, Timothy Fisher wrote:
>The "laymans guide to ASN1" on the RSA website is an excellent doc.
>This contains all the information that you should need to understand
>and use the ASN1 stuff for info security purposes.
>
>Tim
>
>Massimiliano Pala wrote:
> > 
> > Hi all,
> > 
> > I have a simple question about the ASN.1. Are there available free
> > ASN.1 docs available on the net ???
> > 
> > C'you,
> > 
> >         Massimiliano Pala ([e-mail])

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from slack.lne.com ([e-mail] [209.157.136.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21238 for <[e-mail]>; Mon, 13 Mar 2000 11:52:15 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.9.3/8.9.3) id LAA00174; Mon, 13 Mar 2000 11:53:22 -0800
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 11:53:21 -0800
From: Eric Murray <[e-mail]>
To: Tony Bartoletti <[e-mail]>
Cc: Timothy Fisher <[e-mail]>, Massimiliano Pala <[e-mail]>, [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.76
In-Reply-To: <[e-mail]>; from Tony Bartoletti on Mon, Mar 13, 2000 at 11:39:55AM -0800

On Mon, Mar 13, 2000 at 11:39:55AM -0800, Tony Bartoletti wrote:
> As long as the subject is at hand...
> 
> Are there any open-source ASN.1 compilers available?

SNACC.  It's pretty old though.

-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20817 for <[e-mail]>; Mon, 13 Mar 2000 11:38:54 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA02024; Mon, 13 Mar 2000 11:39:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 13 Mar 2000 11:39:55 -0800
To: Timothy Fisher <[e-mail]>, Massimiliano Pala <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: ASN.1 Notation
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

As long as the subject is at hand...

Are there any open-source ASN.1 compilers available?

___tony___

At 02:19 PM 03/13/2000 -0800, Timothy Fisher wrote:
>The "laymans guide to ASN1" on the RSA website is an excellent doc.
>This contains all the information that you should need to understand
>and use the ASN1 stuff for info security purposes.
>
>Tim
>
>Massimiliano Pala wrote:
> > 
> > Hi all,
> > 
> > I have a simple question about the ASN.1. Are there available free
> > ASN.1 docs available on the net ???
> > 
> > C'you,
> > 
> >         Massimiliano Pala ([e-mail])

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA20567 for <[e-mail]>; Mon, 13 Mar 2000 11:32:43 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with SMTP id UAA17715; Mon, 13 Mar 2000 20:33:46 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 20:36:06 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Timothy Fisher <[e-mail]>
CC: [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms940CE16D575E6FD90D56E14C"

This is a cryptographically signed message in MIME format.

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

Timothy Fisher wrote:
> 
> The "laymans guide to ASN1" on the RSA website is an excellent doc.
> This contains all the information that you should need to understand
> and use the ASN1 stuff for info security purposes.
> 
> Tim

I knew it already, but I wanted some offical documentation: is there
any offical doc one can read to implement ASN.1 capable applications
or heve he/she to pay to read them ???

If this is the case, why ietf have chosen such a format to describe
its open standards ?? Are there some historical reasons ??

Thanks for the reply, best regards,

-- Massimiliano Pala ([e-mail])
--------------ms940CE16D575E6FD90D56E14C
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMzEzMTkzNjA2WjAjBgkqhkiG9w0BCQQxFgQUFnD14Z60aB5QRQclR0pCg+U+mBsw
DQYJKoZIhvcNAQEBBQAEgYCt+UCzJnAX9OVaeu2ret5ORFTyEXnuEhaeLIJ2OEa6voVwwZVg
7D8TIHx2WAS9Y7+jP1SRAR1YOrIygHSloOtv1Kh0Px2HVlxpaWzvr9gqD2BLJclIxlhydTRP
9f8V4LrUIG7R4gkc3r0LcwhkpULRgC/6/eJ9TyhVkiF1dv76wQ==
--------------ms940CE16D575E6FD90D56E14C--



Received: from spyglass.cyclonecommerce.com ([12.34.72.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20144 for <[e-mail]>; Mon, 13 Mar 2000 11:21:20 -0800 (PST)
Received: from cyclonecommerce.com (cc957496-a.taylor1.mi.home.com [24.10.48.186]) by spyglass.cyclonecommerce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id G4J6NNXD; Mon, 13 Mar 2000 12:23:24 -0700
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 14:19:30 -0800
From: Timothy Fisher <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: [e-mail]
Subject: Re: ASN.1 Notation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The "laymans guide to ASN1" on the RSA website is an excellent doc.
This contains all the information that you should need to understand
and use the ASN1 stuff for info security purposes.

Tim

Massimiliano Pala wrote:
> 
> Hi all,
> 
> I have a simple question about the ASN.1. Are there available free
> ASN.1 docs available on the net ???
> 
> C'you,
> 
>         Massimiliano Pala ([e-mail])


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19340 for <[e-mail]>; Mon, 13 Mar 2000 10:50:34 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with SMTP id TAA16047 for <[e-mail]>; Mon, 13 Mar 2000 19:51:40 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 13 Mar 2000 19:53:59 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: ASN.1 Notation
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3479544FE814A589BE0134C4"

This is a cryptographically signed message in MIME format.

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

Hi all,

I have a simple question about the ASN.1. Are there available free
ASN.1 docs available on the net ???

C'you,

	Massimiliano Pala ([e-mail])
--------------ms3479544FE814A589BE0134C4
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMzEzMTg1MzU5WjAjBgkqhkiG9w0BCQQxFgQUgkMkyRKloKWKomI0B4QAhe1lPg4w
DQYJKoZIhvcNAQEBBQAEgYCPqYF42pICgaikTyY3EVzQLUFsx+ouBqyIKnxTPLE8NINS8Zno
SvxJyo684GsGigmS/yA1Sjhh+gc/hDF+MEG3ykc13XGUxL8ZS/R3XoilzpOm3ElKsi9YIqpy
TSorvYTpwiz36Lu1vNISokdimTOGuNtjT7vmmGNipl/2pv3cCw==
--------------ms3479544FE814A589BE0134C4--



Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14601 for <[e-mail]>; Mon, 13 Mar 2000 06:45:08 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by csmes.ncsl.nist.gov (8.9.3+Sun/8.6.4jck0) with ESMTP id JAA21535 for <[e-mail]>; Mon, 13 Mar 2000 09:45:59 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 13 Mar 2000 09:44:46 -0500
To: PKIX mailing group <[e-mail]>
From: "David A. Cooper" <[e-mail]>
Subject: Re: son-of-2459. Certificate verification algorithm. Policy Mapping.
In-Reply-To: <[e-mail] o.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 12:32 PM 3/13/00 +1100, Michael Zolotarev wrote:
>Correct me if I'm wrong, but I believe there is a problem, or the text is
>not complete:

I believe that the algorithm is correct. It is rather complex, however, so it can be difficult to follow.

The reason that the algorithm works is as follows:

1) In the final pruning step, 6.1.5.(g).(iii), only nodes that are in the valid_policy_node_set are compared against the user_initial_policy_set.

2) In order for a node to be in the valid_policy_node_set, its parent must have a valid_policy of "any-policy".

3) Since certificate policies can not be mapped to or from "any-policy", no policy mapping can have taken place in any of the ancestor nodes of any node in the valid_policy_node_set.

4) So, the valid_policy of any node in the valid_policy_node_set will not be the result of policy mapping.

5) Therefore, one can safely compare the valid_policy of each node in the valid_policy_node_set with the user_initial_policy_set without taking policy mapping into consideration.

>The document says:
>-----------------------
>    6.1.4 Preparation for Certificate i+1
>
>    To prepare for processing of certificate i+1, perform the following
>steps for certificate i:
>                 ...
>       (b) If a policy mapping extension is present, then for each
>       issuerDomainPolicy ID-P in the policy mapping extension:
>
>          (1) If the policy_mapping variable is greater than 0, for each
>          node in the valid_policy_tree of depth i where ID-P is the
>          valid_policy, set expected_policy_set to the set of sub-
>          jectDomainPolicy values that are specified as equivalent to
>          ID-P by the policy mapping extension.
>---------------------------------------------
>
>The client, when defining the user_initial_policy_set (list of acceptable
>policy OID), knows about the 'base' OIDs. So that I would define that I
>accept OID_1.2.3.4, assuming that if it gets mapped into OID_X.Y.Z, it
>should be transparent to me. However, as the result of the step 6.1.4.b.1
>above, a node will be created in the tree, containing {Valid = OID_1.2.3.4,
>Expected = OID_X.Y.Z}, correct?
>Consequently, I will end up with the valid_policy_tree containing OIDs that
>are NOT in my initial_policy_set.

Notice that in this example, if OID_X.Y.Z is only added to the valid_policy_tree as a result of policy mapping, then any node with a valid_policy of OID_X.Y.Z must have a parent (or other ancestor) node containing {valid_policy = OID_1.2.3.4, expected_policy_set = OID_X.Y.Z}. As a result, the node containing valid_policy = OID_X.Y.Z will not have a parent with valid_policy = "any_policy". Therefore, the node containing valid_policy = OID_X.Y.Z will not be in the valid_policy_node_set and so there will be no check to determine whether OID_X.Y.Z is in the user_initial_policy_set. There will only be a check to see is OID_1.2.3.4 is in the user_initial_policy_set.

>If so, then the verification will fail, following the step (iii)(2) in the
>wrap-up procedure:
>---------------------------------------------------------
>        (iii) If the valid_policy_tree is not NULL and the
>          user_initial_policy_set is not "any-policy", calculate the
>          intersection of the valid_policy_tree and the
>          user_initial_policy_set as follows:
>
>             1. Determine the set of policy nodes whose parent nodes have
>             a valid_policy of "any-policy".  This is the
>             valid_policy_node_set.
>             2. If the valid_policy of any node in the
>             valid_policy_node_set is not in the user_initial_policy_set
>             and is not "any-policy", delete this node and all its chil-
>             dren.
>   ------------------------------------------------------
>
>The solution here would be to define that the verification procedure must
>remember all mappings, and use that stored mapping info during the wrap-up.
>The text (iii)(2) might therefore become:
>2. If the valid_policy of any node in the valid_policy_node_set is not in
>the user_initial_policy_set, OR WAS NOT PRODUCED BY MAPPING FROM THE THE
>user_initial_policy_set, and is not "any-policy", delete this node and all
>its children.
>
>And of course one extra state variable (mapping_info) would be necessary.
>
>Michael




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13874 for <[e-mail]>; Mon, 13 Mar 2000 06:17:33 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7.1) with ESMTP id GAA15832 for <[e-mail]>; Mon, 13 Mar 2000 06:15:23 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <GWH9DFQY>; Mon, 13 Mar 2000 06:17:44 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: [e-mail]
Subject: Update to OCSP-X
Date: Mon, 13 Mar 2000 06:17:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

A draft revision of OCSP-X is available at:

http://www.imc.org/ietf-pkix/temp-draft-ietf-pkix-ocspx.txt

Paul Hoffman kindly agreed to host it on his site as the submission didn't
make it to IETF in time to get it on the official server.

The draft is radically edited from the version briefed at D.C. in response
to comments received there.  It's now all of six pages long and proposes the
following extensions to OCSP as originally discussed on the floor in Oslo.

1. Delegated path validation:  An response type OID is defined for a
server's use in signalling that it has performed 2459-compliant path
validation.

2. Path discovery:  An extension enabling the server to return to the client
the path the server used.

3. Trust root specification: An extension enabling a client to specify a
trusted root for validation purposes.

4. Extended error status:  An extension that enables additional error
indications.

Many thanks to Phil for his initiative in D.C. with the first version.
There are several concepts in his original draft that deserve consideration
by the group for possible inclusion in a parallel I-D.

Mike


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09517 for <[e-mail]>; Mon, 13 Mar 2000 03:18:12 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15227; Mon, 13 Mar 2000 06:19:15 -0500 (EST)
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-scvp-02.txt
Date: Mon, 13 Mar 2000 06:19:15 -0500
Sender: [e-mail]

--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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, P. Hoffman
	Filename	: draft-ietf-pkix-scvp-02.txt
	Pages		: 23
	Date		: 10-Mar-00
	
The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not the certificate is valid, a chain
to a trusted root, and so on. SCVP has many purposes, including
simplifying client implementations and allowing companies to centralize
their trust and policy managment.

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

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-scvp-02.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-scvp-02.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-scvp-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from sbox.tu-graz.ac.at (fstgss05.tu-graz.ac.at [129.27.3.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA26254 for <[e-mail]>; Sun, 12 Mar 2000 19:29:10 -0800 (PST)
From: [e-mail]
Received: (from cyrus@localhost) by sbox.tu-graz.ac.at (8.9.3/8.9.3) id EAA29224; Mon, 13 Mar 2000 04:29:41 +0100 (MET)
Date: Mon, 13 Mar 2000 04:29:41 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Reply-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP3 Imap webMail Program 2.0.10
Sender: [e-mail]
X-Originating-IP: 128.220.223.110
X-WebMail-Company: Hotmail Killers, Inc.
Subject: time stamping

Hi, 

I'm going to implement time-stamping for the OpenCA organisation.

Is anybody else interested in doing this and likes to join me? 

Or is anybody busy in implementing time-stamping right now or in the near 
future?

Please mail to me personally.

cu, 

Petra


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17712 for <[e-mail]>; Sun, 12 Mar 2000 17:36:33 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA27074 for <[e-mail] >; Mon, 13 Mar 2000 11:41:43 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <G53PB3Y9>; Mon, 13 Mar 2000 12:37:22 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: PKIX mailing group <[e-mail]>
Subject: son-of-2459. Certificate validation. InhibitAnyPolicy extension
Date: Mon, 13 Mar 2000 12:37:22 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

6.1.4
 If the inhibitAnyPolicy extension ...

I could not find any description of the "inhibitAnyPolicy" extension
anywhere in the document, except for a lot of references in the "Validation
algorithm" section. ???

Michael


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17588 for <[e-mail]>; Sun, 12 Mar 2000 17:32:08 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id LAA27065 for <[e-mail] >; Mon, 13 Mar 2000 11:37:06 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <G53PB3Y8>; Mon, 13 Mar 2000 12:32:45 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: PKIX mailing group <[e-mail]>
Subject: sone-of-2459. Certificate verification algorithm. Policy Mapping.
Date: Mon, 13 Mar 2000 12:32:45 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Correct me if I'm wrong, but I believe there is a problem, or the text is
not complete:

The document says:
-----------------------
   6.1.4 Preparation for Certificate i+1

   To prepare for processing of certificate i+1, perform the following
steps for certificate i:
		...
      (b) If a policy mapping extension is present, then for each
      issuerDomainPolicy ID-P in the policy mapping extension:

         (1) If the policy_mapping variable is greater than 0, for each
         node in the valid_policy_tree of depth i where ID-P is the
         valid_policy, set expected_policy_set to the set of sub-
         jectDomainPolicy values that are specified as equivalent to
         ID-P by the policy mapping extension.
---------------------------------------------

The client, when defining the user_initial_policy_set (list of acceptable
policy OID), knows about the 'base' OIDs. So that I would define that I
accept OID_1.2.3.4, assuming that if it gets mapped into OID_X.Y.Z, it
should be transparent to me. However, as the result of the step 6.1.4.b.1
above, a node will be created in the tree, containing {Valid = OID_1.2.3.4,
Expected = OID_X.Y.Z}, correct?
Consequently, I will end up with the valid_policy_tree containing OIDs that
are NOT in my initial_policy_set.

If so, then the verification will fail, following the step (iii)(2) in the
wrap-up procedure:
---------------------------------------------------------
       (iii) If the valid_policy_tree is not NULL and the
         user_initial_policy_set is not "any-policy", calculate the
         intersection of the valid_policy_tree and the
         user_initial_policy_set as follows:

            1. Determine the set of policy nodes whose parent nodes have
            a valid_policy of "any-policy".  This is the
            valid_policy_node_set.
            2. If the valid_policy of any node in the
            valid_policy_node_set is not in the user_initial_policy_set
            and is not "any-policy", delete this node and all its chil-
            dren.
  ------------------------------------------------------

The solution here would be to define that the verification procedure must
remember all mappings, and use that stored mapping info during the wrap-up.
The text (iii)(2) might therefore become:
2. If the valid_policy of any node in the valid_policy_node_set is not in
the user_initial_policy_set, OR WAS NOT PRODUCED BY MAPPING FROM THE THE
user_initial_policy_set, and is not "any-policy", delete this node and all
its children.

And of course one extra state variable (mapping_info) would be necessary.

Michael


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23418 for <[e-mail]>; Fri, 10 Mar 2000 08:42:58 -0800 (PST)
Received: from ronald.trustpoint.com (ronald.trustpoint.com [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id IAA24216 for <[e-mail]>; Fri, 10 Mar 2000 08:43:40 -0800
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id IAA20565 for [e-mail]; Fri, 10 Mar 2000 08:43:40 -0800
From: "Life is hard, and then you die." <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: CONFIRM message in http used as transport
To: [e-mail]
Date: Fri, 10 Mar 2000 08:43:40 -0800 (PST)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> how can CONFIRM message be sent over http which used as transport of CMP?
> 
> the 3 way message exchange seems couldn't be done in http.
> 
> anyone who has an idea about this?
> 
> end entity can always stop the connection suddenly
> ( it makes things harder :-( ).

The different messages in a transaction are not associated with each
other via the connection. The association is done via the transactionID
field in the PKIHeader. So the Confirm may be sent on the same or on a
different connection, doesn't matter.  In fact, you may even be getting
requests for multiple transactions on the same connection, all
interleaved (i.e. just because a message arrives on the same connection
as another one doens't mean it belongs to the same transaction) - this
may happen, for example, when an http proxy sits between the client and
the server. You always use the transactionID to figure out which
transaction a messsage belongs to. The only requirement is that you send
back responses in the same order as the requests came in (this is an
http requirement, actually).

Note that this is the same when using TCP directly as transport.

Have a look at the latest CMP draft (draft-ietf-pkix-rfc2510bis-00.txt)
- it explains the transactionID field a bit better. Also, take a look at
the transport drafts (draft-ietf-pkix-cmp-http-00.txt and
draft-ietf-pkix-cmp-tcp-00.txt).


  Cheers,

  Ronald



Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA12139 for <[e-mail]>; Thu, 9 Mar 2000 16:51:19 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Mar 2000 16:47:12 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <GRS2JT9Q>; Thu, 9 Mar 2000 16:47:12 -0800
Message-ID: <[e-mail]>
From: Trevor Freeman <[e-mail]>
To: "'Tammy Green'" <[e-mail]>
Cc: Nathan Coe <[e-mail]>, [e-mail]
Subject: RE: Encoding for cRLNumber and invalidityDate
Date: Thu, 9 Mar 2000 16:50:01 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8A2A.2A8648AA"

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_01BF8A2A.2A8648AA
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Tammy,
 
 
There seems to be a disconnect between the text in RFC2459 describing the
example of the CRL and the decode of the actual ASN.
 
In looking at the example we read the ASN as a CRL with 1 revocation entry
sn=18. The CRL entry has an extension, the reason code extension where the
revocation reason is 1 = key compromise.
 
We find no CRL extensions in the ASN which contradicts the descriptions
which states that there is a CRLnumber extension.
 
Therefore we can find no problem with the ASN, only the description does not
mach the ASN itself. Therefore we do not see that the text contradicts the
example of how the CRLnumber extension should be encoded.
 
That being said, what is not clear is what you mean when you say IE5 only
takes CRLnumber as an Octet string. IE5 does not know about the CRLnumber
extension, so it would never attempt to decode that extension. On Windows
2000 if the CRLnumber extension is present and non-critical, we process the
CRL, if the extension is marked critical, we would reject the CRL as per the
RFC because we do not process the CRLnumber extension. On down level
platforms we do not fail revocation checking on critical CRL extensions we
do not process.
 
If you are interested, we are open to doing CRL interoperability testing
with CA vendors such as yourself.
 
Trevor

-----Original Message-----
From: Tammy Green [mailto:[e-mail]]
Sent: Thursday, March 09, 2000 9:47 AM
To: [e-mail]
Cc: Nathan Coe
Subject: Encoding for cRLNumber and invalidityDate


Two questions about encoding CRLs..... 
 
1.  Is cRLNumber an INTEGER or an OCTET STRING?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for cRLNumber is
INTEGER.  However, in the CRL examples that I've seen, it is encoded as an
OCTET STRING.  Also, Internet Explorer v5 only seems to take the CRL if the
cRLNumber is encoded as an OCTET STRING.
 
Has anyone else noticed this?
 
2.  Is invalidityDate encoded as GeneralizedTIme only?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for invalidityDate
is GeneralizedTime.  Unlike other dates in the CRL (or certificates), it is
not UTCTime through the year 2049 and GeneralizedTime thereafter.  However,
in  examples of CRLs, indeed, even in the CRL example in Appendix D, the
date is expressed in UTCTime.
 
Is this a typo?
 
 
Tammy Green
[e-mail] <mailto:[e-mail]> 
Software Engineer
Novell, Inc.
 
 
 


------_=_NextPart_001_01BF8A2A.2A8648AA
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV><SPAN class=672470923-09032000>Hi Tammy,</SPAN></DIV>
<DIV><SPAN class=672470923-09032000></SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=672470923-09032000>There seems to be a disconnect between the 
text in RFC2459 describing the example of the CRL and the decode of the actual 
ASN.</SPAN></DIV>
<DIV><SPAN class=672470923-09032000></SPAN>&nbsp;</DIV>
<DIV><SPAN class=672470923-09032000>In looking at the example we read the ASN as 
a CRL with 1 revocation entry sn=18. The CRL entry has an extension,&nbsp;the 
reason code extension where the revocation reason is 1 = key 
compromise.</SPAN></DIV>
<DIV><SPAN class=672470923-09032000></SPAN>&nbsp;</DIV>
<DIV><SPAN class=672470923-09032000>We find no CRL extensions in the ASN which 
contradicts the descriptions which states that there is a CRLnumber 
extension.</SPAN></DIV>
<DIV><SPAN class=672470923-09032000></SPAN>&nbsp;</DIV>
<DIV><SPAN class=672470923-09032000>Therefore we can find no problem with the 
ASN, only the description does not mach the ASN itself. Therefore we do not see 
that the text contradicts the example of how the CRLnumber extension should be 
encoded.</SPAN></DIV>
<DIV><SPAN class=672470923-09032000></SPAN>&nbsp;</DIV>
<DIV><SPAN class=672470923-09032000>That being said, what is not clear is what 
you mean when you say IE5 only takes CRLnumber as an Octet string. IE5 does not 
know about the CRLnumber extension, so it would never attempt to decode that 
extension. On Windows 2000 if the CRLnumber extension is present and 
non-critical, we process the CRL, if the extension is marked critical, we would 
reject the CRL as per the RFC because we do not process the CRLnumber extension. 
On down level platforms we do not fail revocation checking on critical CRL 
extensions we do not process.</SPAN></DIV>
<DIV><SPAN class=672470923-09032000></SPAN>&nbsp;</DIV>
<DIV><SPAN class=672470923-09032000>If you are interested, we are open to doing 
CRL interoperability testing with CA vendors such as yourself.</SPAN></DIV>
<DIV><SPAN class=672470923-09032000></SPAN>&nbsp;</DIV>
<DIV><SPAN class=672470923-09032000>Trevor</SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT 
  face=Tahoma>-----Original Message-----<BR><B>From:</B> Tammy Green 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, March 09, 2000 9:47 
  AM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> Nathan Coe<BR><B>Subject:</B> 
  Encoding for cRLNumber and invalidityDate<BR><BR></DIV></FONT>Two questions 
  about encoding CRLs..... 
  <DIV>&nbsp;</DIV>
  <DIV>1.&nbsp; Is cRLNumber an INTEGER or an OCTET STRING?</DIV>
  <DIV>In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for cRLNumber 
  is INTEGER.&nbsp; However, in the CRL examples that I've seen, it is encoded 
  as an OCTET STRING.&nbsp; Also, Internet Explorer v5 only seems to take the 
  CRL if the cRLNumber is encoded as an OCTET STRING.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Has anyone else noticed this?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>2.&nbsp; Is invalidityDate&nbsp;encoded as GeneralizedTIme only?</DIV>
  <DIV>In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for 
  invalidityDate is GeneralizedTime.&nbsp; Unlike other dates in the CRL (or 
  certificates), it is not UTCTime&nbsp;through the year 2049 and 
  GeneralizedTime thereafter.&nbsp; However, in&nbsp; examples of CRLs, indeed, 
  even in the CRL example in Appendix D, the date is expressed in UTCTime.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Is this a typo?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Tammy Green</DIV>
  <DIV><A href="mailto:[e-mail]">[e-mail]</A></DIV>
  <DIV>Software Engineer</DIV>
  <DIV>Novell, Inc.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF8A2A.2A8648AA--


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11903 for <[e-mail]>; Thu, 9 Mar 2000 16:46:01 -0800 (PST)
Received: from Santesson (lon-qbu-bsf-vty49.as.wcom.net [195.232.120.49]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id BAA16231 for <[e-mail]>; Fri, 10 Mar 2000 01:46:53 +0100
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Subject: SerialNumber consensus in QC 03
Date: Fri, 10 Mar 2000 01:44:07 +0100
Message-ID: <000701bf8a29$be7da220$3178e8c3@Santesson>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <61C5E6EA07DBD3119A670050DA74B1FC9E77@TRUST>

All,

I'd like to summarize and propose a consensus solution to the serialNumber
Issue in QC 03.

First of all I would like to point out that this is not at debate of whether
to use serialNumber or any other attribute (that issue was settled last
year). This is a debate regarding:

1) to define the semantics for information hold in the serial Number
attribute
2) how to indicate the applied semantics and characteristics of the
serialNumber attribute use in a particular certificate.

The proposed text regarding issue 1 is:

    "The serialNumber attribute type SHALL, when present, be used
    to differentiate between names where the subject field might
    otherwise be identical.  This attribute has no defined semantics
    beyond ensuring uniqueness of subject names."

This covers a number of usages from codes that may be reused among entities
to globally unique identifiers. Just as long as they provide uniqueness of
subject names.

Issue 2 have several valid solution which all are supported by the current
text:

1) Implicit knowledge
2) Through information defined by a certificate policy OID (contained in the
referred policy or the associated CPS).
3) Through semantics information defined by an OID in the qcStatements
extension.
4) Through repeating information into the subjectAltName extension as a
directory name.

Solution 4 was the last solution discussed on the list and could easily
handle the case where a subset of the attributes in the subject field have
the capacity to identify a person. By duplicating these attributes as a
directoryName in the subjectAltName extension, The CA also indicates that
this set of attributes provide a complete DN.

We can conclude that all options above are valid. We can also conclude that
this solution is already supported  by X.509 and thus, doesn't need further
profiling.

I would personally avoid inclusion/recommendations of this solution in QC
03) since that may imply that this solution is more valid than any other
solution mentioned above.

The conclusion is that QC 03 should remain unchanged with respect to this
topic.


/Stefan





Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA05900 for <[e-mail]>; Thu, 9 Mar 2000 09:47:09 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Mar 2000 10:47:22 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 09 Mar 2000 10:47:08 -0700
From: "Tammy Green" <[e-mail]>
To: <[e-mail]>
Cc: "Nathan Coe" <[e-mail]>
Subject: Encoding for cRLNumber and invalidityDate
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_CE973CBA.47262457"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_CE973CBA.47262457
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Two questions about encoding CRLs.....

1.  Is cRLNumber an INTEGER or an OCTET STRING?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for cRLNumber is =
INTEGER.  However, in the CRL examples that I've seen, it is encoded as an =
OCTET STRING.  Also, Internet Explorer v5 only seems to take the CRL if =
the cRLNumber is encoded as an OCTET STRING.

Has anyone else noticed this?

2.  Is invalidityDate encoded as GeneralizedTIme only?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for invalidityDat=
e is GeneralizedTime.  Unlike other dates in the CRL (or certificates), it =
is not UTCTime through the year 2049 and GeneralizedTime thereafter.  =
However, in  examples of CRLs, indeed, even in the CRL example in Appendix =
D, the date is expressed in UTCTime.

Is this a typo?


Tammy Green
[e-mail]
Software Engineer
Novell, Inc.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff=20
style=3D"FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">Two =
questions about=20
encoding CRLs.....
<DIV>&nbsp;</DIV>
<DIV>1.&nbsp; Is cRLNumber an INTEGER or an OCTET STRING?</DIV>
<DIV>In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for =
cRLNumber is=20
INTEGER.&nbsp; However, in the CRL examples that I've seen, it is encoded =
as an=20
OCTET STRING.&nbsp; Also, Internet Explorer v5 only seems to take the CRL =
if the=20
cRLNumber is encoded as an OCTET STRING.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Has anyone else noticed this?</DIV>
<DIV>&nbsp;</DIV>
<DIV>2.&nbsp; Is invalidityDate&nbsp;encoded as GeneralizedTIme only?</DIV>=

<DIV>In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for=20
invalidityDate is GeneralizedTime.&nbsp; Unlike other dates in the CRL =
(or=20
certificates), it is not UTCTime&nbsp;through the year 2049 and Generalized=
Time=20
thereafter.&nbsp; However, in&nbsp; examples of CRLs, indeed, even in the =
CRL=20
example in Appendix D, the date is expressed in UTCTime.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is this a typo?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Tammy Green</DIV>
<DIV><A href=3D"mailto:[e-mail]">[e-mail]</A></DIV>
<DIV>Software Engineer</DIV>
<DIV>Novell, Inc.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

--=_CE973CBA.47262457--


Received: from bounty.cisco.com (bounty.cisco.com [161.44.2.72]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03881 for <[e-mail]>; Thu, 9 Mar 2000 07:30:11 -0800 (PST)
Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA16740; Thu, 9 Mar 2000 10:30:28 -0500 (EST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 09 Mar 2000 10:30:27 -0500
From: Bryan Byerly <[e-mail]>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Please point me to specification for Kerberos ticket -> email safe  format
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi guys,

Could someone point me to an I-D or RFC that shows how to convert a
Kerberos ticket into an email-safe format.
Please cc me directly.

Thanks for your help!

Bryan

Bryan J. Byerly
[e-mail]




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03383 for <[e-mail]>; Thu, 9 Mar 2000 07:15:08 -0800 (PST)
Received: from Santesson (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA05735; Thu, 9 Mar 2000 16:14:59 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Cert comparison needs AI?
Date: Thu, 9 Mar 2000 17:15:25 +0100
Message-ID: <61C5E6EA07DBD3119A670050DA74B1FCC595@TRUST>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <62C5E6EA07DBD3119A670050DA74B1FC3306C1@TRUST>

Russ,

I agree.

The new proposed text for serialNumber in the subject field section is:

    "The serialNumber attribute type SHALL, when present, be used
    to differentiate between names where the subject field might
    otherwise be identical.  This attribute has no defined semantics
    beyond ensuring uniqueness of subject names."

I also agree to the proposed text in the security consideration:

   "A given physical entity may have multiple forms of unmistakable
    identity.  It is not necessarily possible to determine by examination
    that two qualified certificates refer to the same physical entity."

I'm not sure though if it should be "that two qualified certificates refer
to the same physical entity" or "if two qualified certificates refer to the
same physical entity".

Could you advise?

I'll be happy to adjust the current text accordingly.

/Stefan



> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Monday, March 06, 2000 6:45 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Cert comparison needs AI?
>
>
> Stefan:
>
> I agree with the changes that Dave is proposing.  I think
> that they will
> improve the document.
>
> Russ
>
>
> At 01:49 PM 02/14/2000 -0500, David P. Kemp wrote:
>
> > > From: Paul Koning <[e-mail]>
> > >
> > > >>>>> "Anders" == Anders Rundgren
> <[e-mail]> writes:
> > >
> > >  Anders> Stefan,
> > >  >> It means that when you form an application, you have to handle
> > >  >> this with care and make sure that the application
> don't produce
> > >  >> missleading results.
> > >
> > >  Anders> Noop. In the absence of defined semantics, this
> property or
> > >  Anders> quality MUST be a part of a valid QC CPS.  The German (QC
> > >  Anders> sample?) CPS must state that you can't compare
> German QCs (or
> > >  Anders> do it on your own risk) while the Swedish and
> Finnish ID-card
> > >  Anders> programs guarantee that you can trust the static
> unique ID as
> > >  Anders> being the sole attribute to compare (after you
> have detected
> > >  Anders> that the cert really is belonging to these domains).
> > >
> > > Maybe I'm reading too much into this.  Or my expectations are too
> > > high.  But it surely strikes me as very odd to have a "data type"
> > > whose semantics -- if any -- depend on the value of some unrelated
> > > other data object.  I suppose you could argue that it's
> like a tagged
> > > union type, but that seems a bit of a stretch.
> > >
> > > To put it differently, on what principles is a person supposed to
> > > judge the merits of a proposed standard that contains
> components whose
> > > meanings, if any, are undefined?
> >
> >
> >
> >"Undefined" is overstating the case.  QC-03 says:
> >
> >    "The serialNumber attribute type SHALL, when present, be used
> >    to differentiate between names where the subject field would
> >    otherwise be identical.  This attribute has no defined semantics
> >    beyond ensuring uniqueness of subject names."
> >
> >"ensuring uniqueness" is a defined semantic, even if the process by
> >which uniqueness is ensured is relegated to the CPS (or CP) for a
> >particular domain.  Although I have one quarrel with the
> definition, I
> >basically agree with Stefan that using the serialNumber attribute to
> >contain a true serial number (a static identifier which refers to the
> >same entity even when the Common Name changes) fits within an amended
> >definition:
> >
> >Stefan, could you change "would otherwise be identical" to
> >"might otherwise be identical" in the definition of serialNumber?
> >The former implies that serialNumber SHALL be used only in the case
> >of a known collision, whereas the latter accommodates the
> prophylactic
> >use of serialNumber in all certificates (within a given domain) to
> >eliminate the potential for collision.
> >
> >
> >
> >I agree with Anders that the penultimate paragraph under "Security
> >Considerations" is not particularly helpful as it stands:
> >
> >   "Comparing two qualified certificates to determine if they
> >   represent the same physical entity may provide misleading results
> >   and should be performed with care."
> >
> >It is obvious that just because a QC contains an "unmistakeable
> >identity" does not imply that there is only one possible unmistaken
> >identity for a given physical entity. It's hard to see how this
> >result would be "misleading" to anyone.
> >
> >On the other hand, if two certs contain the identical unmistakeable
> >identities yet refer to two different physical entities, then the
> >identities must not have been so unmistakeable in the first place,
> >and the QC has failed to satisfy the requirements of section 2.
> >
> >Stefan, could you either delete that paragraph from "Security
> >Considerations", or replace it with something like:
> >
> >   "A given physical entity may have multiple forms of unmistakeable
> >   identity.  It is not necessarily possible to determine by
> examination
> >   that two qualified certificates refer to the same
> physical entity."
>



Received: from mail.rbg.informatik.tu-darmstadt.de ([e-mail] [130.83.9.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28567 for <[e-mail]>; Thu, 9 Mar 2000 04:55:27 -0800 (PST)
Received: from rbg.informatik.tu-darmstadt.de (gkpc19.rbg.informatik.tu-darmstadt.de [130.83.240.139]) by mail.rbg.informatik.tu-darmstadt.de (8.9.3+Sun/8.9.1) with ESMTP id NAA09059 for <[e-mail]>; Thu, 9 Mar 2000 13:56:09 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 09 Mar 2000 14:01:43 +0100
From: Michele Boivin <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: subjectPublicKeyInfo
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear Sirs,

in section 7.3 of the "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile" you state that the subjectPublicKey is 
1. a BitString with value: DER encoded RSA public key,
2. a BitString with value: ASN1 encoded Diffie HEllman public key
3. a BitString with value: ASN1 DER encoded DSA Public Key, where DSA
public key is encoded as an INTEGER.

In the ansi x.9.62 standard the subjectPublicKey for ECDSA is said to be
the ASN1 encoded ECDSA public key, where ECDSA public key is an octet
string. 
My question is, do all public keys need to be DER encoded and is the
value of the BIT STRING always the DER encoded public key?

With best regards,

Michele Boivin
PhD Program 
"Enabling Technologies for Electronic Commerce"


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26191 for <[e-mail]>; Thu, 9 Mar 2000 03:29:19 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25235; Thu, 9 Mar 2000 06:30:03 -0500 (EST)
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-dcs-04.txt
Date: Thu, 09 Mar 2000 06:30:03 -0500
Sender: [e-mail]

--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 Data 
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester,  M. Zolotarev, R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-04.txt
	Pages		: 31
	Date		: 08-Mar-00
	
This document describes a general data validation and certification
service and the protocols to be used when communicating with it.  The
Data Validation and Certification Server is a Trusted Third Party
(TTP) that can be used as one component in building reliable non-
repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signed documents and to assert the validity of
public key certificates at a given time.
We give examples of how to use the Data Certification Server to
extend the lifetime of a signature beyond key expiry or revocation
and to query the Data Certification Server regarding the status of a
public key certificate.

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

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-dcs-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-dcs-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-dcs-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-dcs-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 ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26179 for <[e-mail]>; Thu, 9 Mar 2000 03:29:17 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25220; Thu, 9 Mar 2000 06:30:02 -0500 (EST)
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-ac509prof-02.txt
Date: Thu, 09 Mar 2000 06:29:57 -0500
Sender: [e-mail]

--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		: An Internet Attribute Certificate Profile for 
                          Authorization
	Author(s)	: S. Farrell, R. Housley
 	Filename	: draft-ietf-pkix-ac509prof-02.txt
	Pages		: 37
	Date		: 08-Mar-00
	
This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements.  The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications.

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

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-ac509prof-02.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-ac509prof-02.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-ac509prof-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13238 for <[e-mail]>; Wed, 8 Mar 2000 07:12:21 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GNNX721K>; Wed, 8 Mar 2000 10:12:32 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: I-D ACTION:draft-ietf-pkix-rfc2510bis-00.txt
Date: Wed, 8 Mar 2000 10:12:31 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8910.B9A4CA90"

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_000_01BF8910.B9A4CA90
Content-Type: text/plain

Hello,

This is the "son-of-RFC 2510" draft that was intended to appear "very
shortly" after the last IETF meeting (in other words, it's right on
schedule, according to traditional IETF practice...).

This revision incorporates the modifications/clarifications that were
required as a result of the ICSA-sponsored CMP interoperability testing,
including a new Appendix describing a couple of behavioral clarifications
needed for RFC 2511 (this seemed much preferable to revising that document
for such minor changes, especially since this would also necessitate
revising the soon-to-appear CMC, which also points to RFC 2511).

The revisions to 2510 are expected to be uncontentious (though I've been
surprised before!), and the hope is that this document will quickly be
approved as an RFC (either Proposed Standard or Draft Standard -- Warwick,
Steve?), obsoleting 2510.

Carlisle.

P.S., Those of you who are interested in seeing the precise changes from RFC
2510, please send me an e-mail and I will send you a Word document with
revisions "on".


> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, March 08, 2000 6:32 AM
> Cc: 	[e-mail]
> Subject: 	I-D ACTION:draft-ietf-pkix-rfc2510bis-00.txt
> 
>  <<...>> 
> 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
> Certificate 
>                           Management Protocols
> 	Author(s)	: C. Adams, S. Farrell
> 	Filename	: draft-ietf-pkix-rfc2510bis-00.txt
> 	Pages		: 86
> 	Date		: 07-Mar-00
> 	
> This document describes the Internet X.509 Public Key Infrastructure
> (PKI) Certificate Management Protocols. Protocol messages are defined
> for all relevant aspects of certificate creation and management.
> Note that 'certificate' in this document refers to an X.509v3
> Certificate as defined in [COR95, X509-AM].
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-00.txt
> 
> 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-rfc2510bis-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-rfc2510bis-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_000_01BF8910.B9A4CA90
Content-Type: message/rfc822

To: 
Subject: 
Date: Wed, 8 Mar 2000 10:12:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01BF8910.B9A4CA90"


------_=_NextPart_002_01BF8910.B9A4CA90
Content-Type: text/plain



------_=_NextPart_002_01BF8910.B9A4CA90
Content-Type: application/octet-stream;
	name="ATT12445.txt"
Content-Disposition: attachment;
	filename="ATT12445.txt"

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-rfc2510bis-00.txt

------_=_NextPart_002_01BF8910.B9A4CA90
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-ietf-pkix-rfc2510bis-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01BF8910.B9A4CA90--

------_=_NextPart_000_01BF8910.B9A4CA90--


Received: from mailgate.dave.sonera.fi (mailgate.dave.sonera.fi [194.137.238.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12151 for <[e-mail]>; Wed, 8 Mar 2000 06:32:01 -0800 (PST)
Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.216.195]) by mailgate.dave.sonera.fi (8.8.5/8.8.5) with ESMTP id QAA11176 for <[e-mail]>; Wed, 8 Mar 2000 16:32:11 +0200 (EET)
Received: from sonera.com (silverado.tkklpr.tele.fi [131.177.76.146]) by smtp.dave.sonera.fi (8.8.5/8.8.5) with ESMTP id QAA13526 for <[e-mail]>; Wed, 8 Mar 2000 16:32:10 +0200 (EET)
Message-ID: <[e-mail]>
Date: Wed, 08 Mar 2000 16:31:25 +0200
From: Ismo Heikkonen <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: QC Inconsistency
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I found an inconsistency in document draft-ietf-pkix-qc-03.txt:

In section 2.4. "Uniqueness of names" there are references to X.501-1997
version, but however, according to ASN.1 definitions the Name is
imported from RFC2459, which defines the Name without support for X.500
Context feature.
So the reference should be changed to X.501 - 93, as RFC 2459 states.

By using X.500 1997 context feature you could be able to add more than
one serial number attribute values to subject field, and in some cases
this could be a useful feature .

Ismo



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04808 for <[e-mail]>; Wed, 8 Mar 2000 03:31:38 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28882; Wed, 8 Mar 2000 06:32:17 -0500 (EST)
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-rfc2510bis-00.txt
Date: Wed, 08 Mar 2000 06:32:16 -0500
Sender: [e-mail]

--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 Certificate 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-rfc2510bis-00.txt
	Pages		: 86
	Date		: 07-Mar-00
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.
Note that 'certificate' in this document refers to an X.509v3
Certificate as defined in [COR95, X509-AM].

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

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-rfc2510bis-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-rfc2510bis-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-rfc2510bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc2510bis-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 e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20246 for <[e-mail]>; Tue, 7 Mar 2000 10:58:59 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA284278; Tue, 7 Mar 2000 13:58:16 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id NAA259822; Tue, 7 Mar 2000 13:59:34 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525689B.006850C2 ; Tue, 7 Mar 2000 13:59:24 -0500
X-Lotus-FromDomain: IBMUS
To: Peter Williams <[e-mail]>
cc: "''Massimiliano Pala' '" <[e-mail]>, "'IETF-PXIX '" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 7 Mar 2000 13:59:08 -0500
Subject: RE: SCVP, OCSP-X and DCS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I would also recommend the use of suspension-only CRL's for Madwolf's
usage, but there is one hole in the use of suspension-only CRL's in the
current standard, if one uses delta CRL's.  As I believe I pointed out once
before,  ReasonFlags include certificateHold but do not include
removeFromCRL.  If delta CRL's are partitioned using distribution points in
this way, it is not clear where the unsuspensions get recorded.  Should the
definition of issuingDistributionPoint (in new part1 section 5.2.5) be
changed to include a statement similar to the following: "in a delta CRL,
if onlySomeReasons contains the certificateHold flag, in addition to
revocations with reason code certificateHold (also known as suspensions)
revocation entries with reason code removeFromCRL may appear."?  Or perhaps
the following: "With the following exceptions, if onlySomeReasons appears
all revocations in the CRL must have reason codes with names matching flags
in onlySomeReasons.  The exceptions to this rule are that the 'unused' bit
governs the placement of revocations with reason code 'unspecified' and
also those with no reason code present, and that the 'certificateHold' bit
governs the placement of revocations with reason code 'removeFromCRL' as
well as those with reason code 'certificateHold'".

          Tom Gindin




Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19418 for <[e-mail]>; Tue, 7 Mar 2000 10:13:55 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <GNY3B9V6>; Tue, 7 Mar 2000 10:13:38 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "''Massimiliano Pala' '" <[e-mail]>, "'IETF-PXIX '" <[e-mail]>
Subject: RE: SCVP, OCSP-X and DCS
Date: Tue, 7 Mar 2000 10:13:37 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset="iso-8859-1"

madwolf:

Phil is totally opposed to certificate suspension,
and seems to believe that certificate management
by repositories should be confused with authorization
and access control enforcement systems.

Like Phil, I also do not believe suspension support should be 
a mandatory feature. Russ's view of a simple system 
should be the mandatory feature set; more complex
features can be selectively implemented by those
with more ambition and more demanding users. On
this latter issue, Phil and I diverge in opinion.

I am very much for suspension generally, along with
other status services that indicate a relying-parties
designation of status on a user and CA certificate. 
  
With the way that X.509 is setup, CRLs (using
various status codes) indicate formal status
on id and privilge attribute certs, as does
an OCSP service using CRL, repository or
other sourced data TODAY, in complete
PKIX compliance . One can suspend attribute 
certs, as one can suspend id certs. PKIX's
draft standards do not differentiate between
the types.

Lets note that some reasons for suspending
certs are given in the VeriSign CPS; one
important rationale for that design was
the need to address the vulnerabilities
in some enrollment protocols (such 
as the VeriSign CPS) which needed
to tightly confer, withhold or suspend CPS-validity 
status on an issued certificate.

The Microsoft Certificate Server's repository
can set and return arbitrary text status on certs to any user
of the ICertAdmin COM interface, as we
noted in the 1998 "Digital Certificates" book with
Java sample code (pg 404). Contrary
to Russ belief, it is not complicated at all,
in practice. It was not difficult then,
it is not difficult now.

But, we should note that the policy assigned meaning of 
suspension, like revocation,
is mainly a function of the CPS. Where support for
suspension notices is mandated by law, as in at least
one statute, national repositories need to be able
to respond. Private-market, DoD, and Internet-standard
repositories can do whatever their communities like,
of course.  

So madwolf: for internet standard app purposes, I suggest
you use a CRLDP to signal a list of certs with the held status 
code. Apart from the name, this IS a CSL. If the
CA or a CA-delegate issues the list, use CRLDP
construct as is. If another party issues the list, use
the indirect flag, and a DP name other than
than that of the CA. Of course, a CRLDP ios
only a CRL with the relevant extensions set to
give it appropriate semantics - like suspension
listing.

Refinements on the CRLDP implementation
of the CSL Construct welcome.

Peter.

-----Original Message-----
From: Philip Hallam-Baker
To: 'Massimiliano Pala'; IETF-PXIX
Sent: 3/7/00 9:09 AM
Subject: RE: SCVP, OCSP-X and DCS

 <<SMIME.txt>> 


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18396 for <[e-mail]>; Tue, 7 Mar 2000 09:10:17 -0800 (PST)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id JAA04470; Tue, 7 Mar 2000 09:07:24 -0800 (PST)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <GD1RVKR2>; Tue, 7 Mar 2000 09:09:44 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Massimiliano Pala'" <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: RE: SCVP, OCSP-X and DCS
Date: Tue, 7 Mar 2000 09:09:42 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_002B_01BF882E.2A3E43A0"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01BF882E.2A3E43A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am absolutely opposed to any involvement with anything
called a CSL for two reasons:

1) We have too many acronymns already. There is no need to
	introduce yet another TLA for CRLs that only have
	suspended certificates. The term CSLs will confuse 
	customers and users. Two vendors are already using
	the term ARL for different purposes with predictable
	results.

2) The idea of certificate suspension is unworkable in
	principle and in practice. Everything that can
	be acomplished by suspension can be accomplished
	by centralized management of authorization info.

We have been over this ground repeatedly. Certificate 
suspension through CRLs simply is not viable, there is
no practical circumstance in which a suspension can
be cancelled reliably using CRLs. Ergo there is no
difference between suspension and revocation.

Distributing suspension data through a real time service
makes no sense since the same effect can be achieved through
removing authorizations from the cert.

To summarise, suspension is a bad idea, it is really
a weak form of Athorization data and the requirements should
be met by a full authorization data infrastructure.

Lets mark all the references to suspension 'depricated'
and have done with it.

		Phill


-----Original Message-----
From: Massimiliano Pala [mailto:[e-mail]]
Sent: Monday, March 06, 2000 7:53 PM
To: IETF-PXIX
Subject: Re: SCVP, OCSP-X and DCS


Denis Pinkas wrote:
> 
> Ambarish made a nice presentation of OCSP and SCVP at the RSA
> Conference. The OCSP document has expired and no discussion has
> recently taken place about it. A revision is expected soon. The
> expired version included a large section on open issues.

I'd like very much to see added a new response status to the
Valid/Revoked/Unkown list: Suspended.

This issued was raised when writing about CSLs (Suspension Lists).
I do admit there is a way to implement it with extensions (as
suggested on the list), anyway I'd like to see the 'Suspended'
response added. Someone shares this point of view ??

C'you,

	Massimiliano Pala ([e-mail])

------=_NextPart_000_002B_01BF882E.2A3E43A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDMwNzE3MTA0NFowIwYJKoZI
hvcNAQkEMRYEFLVxLFkPetj9VItZ+g5xR1UrpeMBMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAAmon1typoejPnmNbDhqEfD2hGOw+1r40ODUBCmez6vGitg/f6MHxBtUke/2XSwOF
L1WjxGqmT2baWWZU02nNvqarRVXeyHP2c7zVZkWuoaIOh0Sc2Z7PbKCGFMtxftoRUsMearoWoiOG
q48gRE/BBdP2C1Yg0Q4qSCx/gFezFSoAAAAAAAA=

------=_NextPart_000_002B_01BF882E.2A3E43A0--



Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29614 for <[e-mail]>; Mon, 6 Mar 2000 22:39:09 -0800 (PST)
Received: from abstracon.se (d212-151-87-134.swipnet.se [212.151.87.134])  by mb04.swip.net (8.8.8/8.8.8) with ESMTP  id HAA13953 for <[e-mail]>;  Tue, 7 Mar 2000 07:36:52 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 07 Mar 2000 07:40:12 +0100
From: Arne Nilsson <[e-mail]>
Reply-To: [e-mail]
Organization: Abstracon
X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

unsubscribe




Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA10544 for <[e-mail]>; Mon, 6 Mar 2000 16:50:50 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with SMTP id BAA20015 for <[e-mail]>; Tue, 7 Mar 2000 01:51:20 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 07 Mar 2000 01:53:21 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Re: SCVP, OCSP-X and DCS
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC7248FAB56C90491B3703D27"

This is a cryptographically signed message in MIME format.

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

Denis Pinkas wrote:
> 
> Ambarish made a nice presentation of OCSP and SCVP at the RSA
> Conference. The OCSP document has expired and no discussion has
> recently taken place about it. A revision is expected soon. The
> expired version included a large section on open issues.

I'd like very much to see added a new response status to the
Valid/Revoked/Unkown list: Suspended.

This issued was raised when writing about CSLs (Suspension Lists).
I do admit there is a way to implement it with extensions (as
suggested on the list), anyway I'd like to see the 'Suspended'
response added. Someone shares this point of view ??

C'you,

	Massimiliano Pala ([e-mail])
--------------msC7248FAB56C90491B3703D27
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMzA3MDA1MzIxWjAjBgkqhkiG9w0BCQQxFgQUP77MIYWDNLeZVNzfq8NLGA6rW+8w
DQYJKoZIhvcNAQEBBQAEgYBSoD9jX3dQPggFS1AGkwlIc9UVsT6Xju2L0+R4HcdGzggLCKXV
wDiQw/x49K9NCRjEXRzcawOC5u2TiRWzBQXVEkVNrl6SKUHt1fHcYmEWfp5G3uZGNQcQqwMF
QAlWO9dsdSasakCAS0MONqU8lDXPUnmyyQ7t8uSVboTezsZGCw==
--------------msC7248FAB56C90491B3703D27--



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02871 for <[e-mail]>; Mon, 6 Mar 2000 09:16:50 -0800 (PST)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA20360 for <[e-mail]>; Mon, 6 Mar 2000 18:17:20 +0100
Message-ID: <[e-mail]>
Date: Mon, 06 Mar 2000 18:17:21 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: SCVP, OCSP-X and DCS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish made a nice presentation of OCSP and SCVP at the RSA
Conference. The OCSP document has expired and no discussion has
recently taken place about it. A revision is expected soon. The
expired version included a large section on open issues.

As far as I remember, it was requested to the various drafts editors
from DCS, OSCP-X and SCVP to meet together to come with a single
proposal. Apparently this has not happened yet, but this is still a
wish.

I provide the following comments, not specifically for SCVP but for
the "Son of SCVP, OSCP-X and DCS".

Note: Since I will be abroad for the remaining of the week, I will
not be able to answer until next week. Anyway, this mail may help to
progress the work.

Detailed comments

1. The structure of the document is not adequate. The ASN1 should
come upfront in section 3 so that it can be more easy to follow the
description. An ASN1 module should then be placed in an annex. 


2. The structure of the ASN1 response does not fit with the
structure of the ASN1 request, in particular when the ASN1 request
is about multiple certificates. The ASN1 request should be
restructured (see more detailed comments later).


3. The name TBSRequest is not explained. To Be Signed ? If it is,
the name is not correct, because the structure is not necessarily
signed.


4. In section 1.1 it said that "Untrusted severs can give client the
certificate chains needed for path validation". This contradicts the
fact that later on, in section 1.3 Open issues: "In this version of
spec., all responses must be signed". Such a response does not need
to be signed.


5. Section 3.15 is misnamed. The header is UsageID while the
description is " [It] specifies to the server the policy ID ... What
not call it "Policy ID" or ValidationPolicyID" ?


6. The section 3.16 should be deleted. This is a door opened to
proprietary implementations.


7. In section 3.17, two types of checks are mentioned. It is
proposed to have five types of checks instead:

  - Path validation to a trusted root,
  - Revocation status using CRLs for the leaf element,
  - Revocation status using OCSP for the leaf element,
  - Revocation status using CRLs all the way, except for the leaf
element,
  - Revocation status using OCSP all the way, except for the leaf
element,

It would be simpler and much shorter to define bits instead of
(long) OIDs.


8. In section 3.18, two information may be returned. It is proposed
to have five instead:

  - Certificate chain to a trusted root,
  - Proof of revocation status for the leaf element using CRLs,
  - Proof of revocation status for the leaf element using OCSP,
  - Proof of revocation status for CAs using CRLs all the way,
  - Proof of revocation status for CAs using OCSP all the way,


9. In section 3.19, it should be said that the default time is the
current time.


10. In section 3.19, it is said:" if the server doesn't have
historical information about that time, the information will be for
a time later than the ValidityTime." This does not work in general:
if the certificate has expired there is no more information
maintained in CRLs beyond the validity of the certificate and thus
the result will be "not revoked" instead of "revoked" ! This could
only work if that time is within the validity period of the
certificate. For the sake of simplicity, an error should be
returned. 


11. In section 3.21, the protocol should allow to specify a hash
algorithm, even if the default one is currently SHA-1.


12. Section 3.23 is about a "signature name". This item is not
needed and should be suppressed since the identifier of the
certificate's server should be present and signed anyway. 


13. Section 3.23 is about a KeyID. The KeyID should not be the hash
of a public key, but the certificate identifier together with the
hash of the certificate itself. 


14. In section 4.7 the time should not be Greenwich Mean Time, but
UTC (which happens to be equivalent to GMT).


15. Section 4.8 does not seem to make sense. Delete.


16. Section 5. As said earlier, the structure of the request does
not match with the structure of the response, which is more well
thought to support multiple responses. Without trying to make all
the necessary corrections and comments, hereafter are a few:


17. The request, if really able to support multiple certificates in
the request, should support for each certificate all the options.
This is not the case with the current proposal.


18. Under which circumstances should the request be signed or not
signed ?


19. Why is "Query" a CHOICE with a single choice, i.e. no choice !


20. The MAJOR item in the CertsQuery is usageID [4], which should
come upfront. A much better name would be ValidationPolicyID.


21. RevocationInfos should not be defined as an extension, but like
in CMS.


22. ConfigurationIdentifier should be deleted.


23. CertItem should be defined as:

CertItem::= SEQUENCE {
   certID   CertID,
   certHash CertHash,
}

This structure protects against a CA key compromise.


Denis


Received: from www.initech.com ([203.238.37.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27141 for <[e-mail]>; Mon, 6 Mar 2000 03:54:41 -0800 (PST)
Received: from sigma ([203.238.37.133]) by www.initech.com (8.9.3/8.9.3) with ESMTP id UAA06338 for <[e-mail]>; Mon, 6 Mar 2000 20:49:56 +0900 (KST)
From: "Kwon, YongChul" <[e-mail]>
To: <[e-mail]>
Subject: CONFIRM message in http used as transport
Date: Mon, 6 Mar 2000 20:50:16 +0900
Message-ID: <004201bf8762$248b7fd0$8525eecb@sigma>
MIME-Version: 1.0
Content-Type: text/plain; charset="EUC-KR"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id DAA27142

hello.

how can CONFIRM message be sent over http which used as transport of CMP?

the 3 way message exchange seems couldn't be done in http.

anyone who has an idea about this?

end entity can always stop the connection suddenly
( it makes things harder :-( ).

please tell me your ideas about that!

Thanks.


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06426 for <[e-mail]>; Sun, 5 Mar 2000 15:17:03 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA09709; Mon, 6 Mar 2000 09:21:12 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <GF9Z6GF5>; Mon, 6 Mar 2000 10:16:53 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: RE: Time Stamp Protocol (TSP) v6
Date: Mon, 6 Mar 2000 10:16:44 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

A minor one:
The Accuracy is now defined as Sequence, implying that a combination of the
fields can be present. But the text is saying "..decomposed either in...":
"accuracy is expressed as an integer, that can be decomposed either in
seconds, milliseconds (between 1-999) or microseconds (1-999)."

"Either" should go, with the text becoming just "...decomposed in...".


Received: from sparenix.metronet.com (qmailr@[207.170.106.3]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA23962 for <[e-mail]>; Fri, 3 Mar 2000 07:39:32 -0800 (PST)
From: [e-mail]
Received: (qmail 5744 invoked by uid 7770); 3 Mar 2000 17:00:07 -0000
Received: from fcn105-26.tmi.net (HELO ns1) (207.170.105.26) by sparenix.metronet.com with SMTP; 3 Mar 2000 17:00:07 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 03 Mar 2000 09:37:06 -0600
To: [e-mail]
Subject: Telecommunications Search Firm - Pacific Northwest Opportunity

Dear Telecommunications Professional

Please excuse this interruption. I am with a Telecommunications search firm
specializing in the area of Telephony PSTN wireline and wireless applications.

The purpose of this email is to locate and advise Telecommunications
Professionals of a search we have begun on behalf of a Pre-IPO,
privately-held wireless
equipment manufacturer whose mission is to reduce the cost of wireless
capacity.  
Their products, smart  antenna systems, allow wireless operators to increase
the capacity
of network infrastructure and avoid investment in new cell sites and costly 
equipment upgrades. Available for digital and analog networks, the systems
have been 
deployed by leading wireless operators in North America, South America and
Europe. 
The company was founded in 1995 and is headquartered in the Pacific
Northwest.  Stock 
options are an integral part of a new employees compensation package.

While additional positions will be available we are currently actively
seeking candidates 
for the following position:

Principal Systems Engineer:  Responsible for providing highly complex system
level 
design of  Client's GSM Smart Antenna products. The incumbent will
architect,  document 
and test products at a system level and support the  installation of those
products by 
the field service organization. 

We are seeking experienced engineering personnel with expertise in hardware
and software 
wireless telecommunications disciplines. Specific areas of interest would
be; RF principles 
including noise figure, IMD, link budgets, propagation and RF equipment design
on either the circuit or system level. Must possess experience in TDMA or
GSM wireless 
communications. Client prefers experience developing GSM base stations or
deploying systems 
into the network.

This is a unique opportunity to join a growth company developing
sophisticated wireless 
products. The management team consists of industry veterans from major
corporations
including Nortel, Siemens, Lucent Technologies/AT&T Bell Laboratories, US
West with a proven
track record of success. The company is backed by an impressive list of
investors. 
Excellent compensation package including generous stock options.

If you or an associate would be interested in learning more about this or
other opportunities 
with our client please contact me by calling the number below, replying to
this email and/or 
forwarding me a copy of your background information.

I will be happy to provide more detailed information.

Sincerely,

David Crowley
Managing Director
DSR - Search and Recruitment
1201 Richardson Drive Suite 220
Richardson, Texas  75080
972-689-8282
972-680-3202 (fax)
email: [e-mail]
www: www.telecomsearch.com



Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20512 for <[e-mail]>; Fri, 3 Mar 2000 07:00:45 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJ2KD4>; Fri, 3 Mar 2000 10:00:33 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: pkix <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Fri, 3 Mar 2000 10:00:30 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Peter,

Are those parameters associated with the "bio-enhanced" RSA signature value
or with the RSA public key? 

-John 

-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Thursday, March 02, 2000 6:23 PM
To: 'Tim Polk'; pkix
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00


Here are no parameters with RSA "for the
IETF-specified RSA algorithm" only. PKIX
conforming CA are not limited to IETF's RSA-based
digital signature algorithms, remember. Some
of the bio-enhanced RSA signing processes will
use parameters to help mix the hash, quite properly.

 


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA07735 for <[e-mail]>; Fri, 3 Mar 2000 03:27:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22695; Fri, 3 Mar 2000 06:28:05 -0500 (EST)
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-time-stamp-06.txt
Date: Fri, 03 Mar 2000 06:28:05 -0500
Sender: [e-mail]

--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 Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams,  P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-06.txt
	Pages		: 21
	Date		: 02-Mar-00
	
A time stamping service allows to prove that a datum existed before
a particular time and can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). This document describes the format of a request sent to a
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was generated
during the validity period of the corresponding public key
certificate is given in an annex.

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

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-time-stamp-06.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-time-stamp-06.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-time-stamp-06.txt

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

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

--OtherAccess--

--NextPart--




Received: from mail.moe.gov.tw (mail.moe.gov.tw [140.111.8.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16949; Thu, 2 Mar 2000 20:26:11 -0800 (PST)
Received: from L11P001 (moepc179.moe.edu.tw [140.111.2.179]) by mail.moe.gov.tw (AIX4.3/8.9.3/8.9.3) with SMTP id LAA02514; Fri, 3 Mar 2000 11:56:25 +0800
Message-ID: <006d01bf84c4$614dac40$b3026f8c@.edu.tw>
From: "¬_³Õ¤å" <[e-mail]>
To: <Undisclosed-Recipient:@mail.moe.gov.tw;>
Subject: Fw: ¤ßŦ¯fµo§@¦Û±Ï«æ±Ï³N
Date: Fri, 3 Mar 2000 11:55:13 +0800
Organization: MOE
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

¤ßŦ¯fµo§@«æ±Ï³N

    °²³]²{¦b®É¨è¬O¤U¤È¤­ÂI¤­¤Q¤À¡A¦£¦£¸L¸Lªº§A¤W¤F¤@¾ã¤Ñªº¯Z¡A¥¿¦b¶}¨®¦^®aªº
¸ô¤W(·íµM¬O¤@­Ó¤HÅo¡I)¡C¨ä¹ê¡A¤u§@¦£¸L¨I­«¤]´N½}¤F¡A¤µ¤ÑÁÙ¸ò¤W¥q·N¨£¤£¦X¡C¦n
»¡¤ï»¡¡A»¡¯}¤F¼L¡A¥L´N¬O¤£ªÖ´«­Ó¨¤«×¨Ó¬Ý§Aªº¥ß³õ¡C§A¯u¬O®ð¬µ¤F¡I¨ì²{¦bÁÙ¬O¶V
·Q¶V®ð¡C

    ¬ðµM¡A§A·P¨ì¯Ý¤f¦³¤@ªÑ¼@µh¡A¨Ã¥B¶}©lº©©µ¨ì¤âÁu©M¤U¤Ú¡C¥i¬O¡AÂ÷³ÌªñªºÂå°|
¤j·§ÁÙ¦³¤­¤½¨½»·¡C§óÁV¿|ªº¬O¡A§A¦Û¤v³£¤£ª¾¹D¯à¤£¯à¼µ±o¤F¨º»ò»·¡C«ç»ò¿ì¡H§A¥H
«e´¿¸g¨ü¹L¤ßªÍ½Æµd³NCPR°V½m¡A¦ý¬O±Ð½Ò¦Ñ®v¨Ã¨S±Ð§A«ç»ò¦Û¤vµ¹¦Û¤v°µ«æ±Ïªº¤è
ªk¡C

    ¿W³B®É¡A¤ßŦ¯fµo§@«æ±Ï³N

    (³\¦h¤H¤ßŦ¯fµo§@®É¡A¥|©P¨S¦³®Ç¤H¡C¦]¦¹¡A¾Ç·|¯à¦Û¤vµ¹¦Û¤v°µÂ²³æªº¤ßªÍ½Æ
µd³N¬O«D±`­«­nªº¡C)

    ¤@­Ó¤H­Y¬O¤ßŦ¤£¯à¥¿±`¸õ°Ê¡A¨Ã¥B¶}©l·P¨ì§Ö­n©ü¹L¥h®É¡A¥L¤j·§¥u¦³¤Q¬íÄÁªº
®É¶¡¡AµM«á´N·|¥¢¥hª¾Ä±¡A¤£¬Ù¤H¨Æ¡C­Y¬O¥|©P¨S¦³®Ç¤H¯àÀ°¦£«æ±Ï¡A±wªÌ­n¥ß¨è§â´¤
³o¤Q¬íÄÁªºµu¼È®É¶¡¦Û¤v±Ï¦Û¤v¡C­n¤£°±«y¹Â¡I¥Î¤Oªº«y¡I¨C¤@¦¸«y¹Â«e¡A³£­n¥ý²`§l
¤@¤j¤f®ð¡CµM«á¡A¥Î¤O¦a¡B²`²`¦a¡Bªøªø¦a«y¡A¦n¹³­n§â¯ÝµÄ²`³Bªº·ð«y¥X¨Ó¤@¯ë¡C¨C
¶¡¹j¤j¬ù¨â¬íÄÁ¡A­n°µ¤@¦¸§l¡B¤@¦¸«y¡A¤@ª½­n°µ¨ì±ÏÅ@»°¨ì®É¡A©ÎªÌ¤w¸g·P¨ì¤ß¸õ«ì
´_¥¿±`¡A¤~¯à¥ð®§¡C°µ²`©I§lªº¥Øªº¬O­n§â®ñ®ð§l¶iªÍ³¡¡A«y¹Âªº¥Øªº«h¬O­n¥H³o­Ó°Ê
§@À£À½¤ßŦ¡A¶i¦Ó«P¶i¦å²G´`Àô¡C¹ï¤ßŦªºÀ½À£¤]¥i¥HÀ°¥¦«ì´_¥¿±`¯ß·i¡C¦p¦¹«æ±Ï¡A
¥i¥HÅý¤ßŦ¯fµo§@±wªÌ¦³¾÷·|¥´¹q¸Ü¨D±Ï¡A©ÎªÌ¦b¨C¦¸§l®ð¶¡©I±Ï¡C

    ±Ï¤H¤@©R¡A³Ó³y¤C¯Å¯B±O¡C½Ð¤j®a§â³o­Ó¦Û§Ú¤ßªÍ½Æµd«æ±Ï³N§i¶D¤j®a¡A©Î¦A¼v¦L
¤Àµo¡C»¡¤£©w´N¦]¦¹±Ï¤F±zªº®a¤H¡B¿Ë±­¡BªB¤Í¡B¦P¨Æ¡B¥ª¾F¥kªÙ¡B©Î¥ô¦ó¤@­Ó¤£ºÞ±z
»{ÃѩΤ£»{ÃѪº¤H¤@©R¡C




Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02853 for <[e-mail]>; Thu, 2 Mar 2000 15:23:21 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLYKKH>; Thu, 2 Mar 2000 15:22:56 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, pkix <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Thu, 2 Mar 2000 15:22:54 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Here are no parameters with RSA "for the
IETF-specified RSA algorithm" only. PKIX
conforming CA are not limited to IETF's RSA-based
digital signature algorithms, remember. Some
of the bio-enhanced RSA signing processes will
use parameters to help mix the hash, quite properly.

 

-----Original Message-----
From: Tim Polk [mailto:[e-mail]]
Sent: Thursday, March 02, 2000 2:54 PM
To: pkix; Pawling, John
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00


John,

I'm glad we're in agreement.  It was a rather stimulating dicussion and
ensured I review this text exhaustively - both good things.  I see I have
some clean-up work to perform on that section, including your changes to
the wrap-up procedure.  They were needed either way.

Thanks!

Tim

At 01:41 PM 03/02/2000 -0500, you wrote:
>Tim/Santosh,
>
>I apologize for the confusion caused by my reply to Stephen's message.  I
>misinterpreted Stephen's use of the term "algorithm gap".  I strongly agree
>that algorithm parameter inheritance MUST NOT occur across an "algorithm
>gap" as defined in Stephen's and Tim's messages.  I strongly agree that
>parameter inheritance may only occur when the subject and issuer share the
>same parameters.  Recommend that sentence should be added to the first
>paragraph in section 7.3, Subject Public Key Algorithms.
>
>Stephen's recommended text enforces the rule that algorithm parameter
>inheritance must not occur across an "algorithm gap".  He recommended: "if
>the signing algorithm and subject public key algorithms in a certificate
>differ, then the issuer MUST include all algorithm parameters in the
>subjectPublicKeyInfo as parameter inheritance is not supported in such
>cases". Recommend that Stephen's text should be included in the first
>paragraph in section 7.3.  Recommend adding "(if applicable)" after "all
>algorithm parameters" in the above sentence.
>
>I agree with Santosh's statement that there is no such thing as parameters
>in the RSA.  However, I still believe that the pkix-new-part1-00 cert path
>validation procedures need to be clarified.  Recommend that the following
>text be added to the description of the working_public_key_parameters
>variable in section 6.1.2, bullet (i): "Note: There are no algorithm
>parameters associated with an RSA public key; therefore, the certification
>path validation procedures described in this section specify that the
>working_public_key_parameters variable is set to NULL when associated with
>an RSA working_public_key."  
>
>I stand by my original comment documented in the attached message that
>started this message exchange.
>
>-John
>
>
>-------------------- Original Message -------------------------------
>
>From:	Pawling, John [[e-mail]]
>Sent:	Friday, February 25, 2000 5:08 PM
>To:	[e-mail]
>Subject:	Cert Path Validation Bug in pkix-new-part1-00 
>
>All,
>
>There is a bug in the certification path validation Wrap-up procedures
>section (6.1.5) in the October 22, 1999 PKIX Certificate and CRL Profile
><draft-ietf-pkix-new-part1-00.txt>.  If an issuer cert containing a DSS
>public key is used to verify an end-entity cert containing an RSA public
>key, then the current Wrap-up procedure does not properly set the
>working_public_key_parameters variable to NULL.  With the current
procedure,
>the working_public_key_parameters is still set to the issuer's DSS
algorithm
>parameters.  Recommend the following change to section 6.1.5:
>
>OLD:  (d) If the subjectPublicKeyInfo field of the certificate contains an
>algorithm field with non-null parameters, assign the parameters to the
>working_public_key_parameters variable.
>
>NEW:  (d) If the subjectPublicKeyInfo field of the certificate contains an
>algorithm field with non-null parameters, assign the parameters to the
>working_public_key_parameters variable.  If the subjectPublicKeyInfo field
>of the certificate contains an algorithm field with null parameters,
compare
>the certificate subjectPublicKey algorithm to the
>working_public_key_algorithm.  If the certificate subjectPublicKey
algorithm
>and the working_public_key_algorithm are different, set the
>working_public_key_parameters to null.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>[e-mail]
>============================================ 
>
>


Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02320 for <[e-mail]>; Thu, 2 Mar 2000 14:51:16 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.9.3+Sun/8.6.4jck0) with SMTP id RAA22759; Thu, 2 Mar 2000 17:51:13 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Mar 2000 17:54:14 -0500
To: pkix <[e-mail]>, "Pawling, John" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

John,

I'm glad we're in agreement.  It was a rather stimulating dicussion and
ensured I review this text exhaustively - both good things.  I see I have
some clean-up work to perform on that section, including your changes to
the wrap-up procedure.  They were needed either way.

Thanks!

Tim

At 01:41 PM 03/02/2000 -0500, you wrote:
>Tim/Santosh,
>
>I apologize for the confusion caused by my reply to Stephen's message.  I
>misinterpreted Stephen's use of the term "algorithm gap".  I strongly agree
>that algorithm parameter inheritance MUST NOT occur across an "algorithm
>gap" as defined in Stephen's and Tim's messages.  I strongly agree that
>parameter inheritance may only occur when the subject and issuer share the
>same parameters.  Recommend that sentence should be added to the first
>paragraph in section 7.3, Subject Public Key Algorithms.
>
>Stephen's recommended text enforces the rule that algorithm parameter
>inheritance must not occur across an "algorithm gap".  He recommended: "if
>the signing algorithm and subject public key algorithms in a certificate
>differ, then the issuer MUST include all algorithm parameters in the
>subjectPublicKeyInfo as parameter inheritance is not supported in such
>cases". Recommend that Stephen's text should be included in the first
>paragraph in section 7.3.  Recommend adding "(if applicable)" after "all
>algorithm parameters" in the above sentence.
>
>I agree with Santosh's statement that there is no such thing as parameters
>in the RSA.  However, I still believe that the pkix-new-part1-00 cert path
>validation procedures need to be clarified.  Recommend that the following
>text be added to the description of the working_public_key_parameters
>variable in section 6.1.2, bullet (i): "Note: There are no algorithm
>parameters associated with an RSA public key; therefore, the certification
>path validation procedures described in this section specify that the
>working_public_key_parameters variable is set to NULL when associated with
>an RSA working_public_key."  
>
>I stand by my original comment documented in the attached message that
>started this message exchange.
>
>-John
>
>
>-------------------- Original Message -------------------------------
>
>From:	Pawling, John [[e-mail]]
>Sent:	Friday, February 25, 2000 5:08 PM
>To:	[e-mail]
>Subject:	Cert Path Validation Bug in pkix-new-part1-00 
>
>All,
>
>There is a bug in the certification path validation Wrap-up procedures
>section (6.1.5) in the October 22, 1999 PKIX Certificate and CRL Profile
><draft-ietf-pkix-new-part1-00.txt>.  If an issuer cert containing a DSS
>public key is used to verify an end-entity cert containing an RSA public
>key, then the current Wrap-up procedure does not properly set the
>working_public_key_parameters variable to NULL.  With the current procedure,
>the working_public_key_parameters is still set to the issuer's DSS algorithm
>parameters.  Recommend the following change to section 6.1.5:
>
>OLD:  (d) If the subjectPublicKeyInfo field of the certificate contains an
>algorithm field with non-null parameters, assign the parameters to the
>working_public_key_parameters variable.
>
>NEW:  (d) If the subjectPublicKeyInfo field of the certificate contains an
>algorithm field with non-null parameters, assign the parameters to the
>working_public_key_parameters variable.  If the subjectPublicKeyInfo field
>of the certificate contains an algorithm field with null parameters, compare
>the certificate subjectPublicKey algorithm to the
>working_public_key_algorithm.  If the certificate subjectPublicKey algorithm
>and the working_public_key_algorithm are different, set the
>working_public_key_parameters to null.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>[e-mail]
>============================================ 
>
>


Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28809 for <[e-mail]>; Thu, 2 Mar 2000 10:41:34 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFGF3KFA>; Thu, 2 Mar 2000 13:41:14 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: pkix <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Thu, 2 Mar 2000 13:41:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Tim/Santosh,

I apologize for the confusion caused by my reply to Stephen's message.  I
misinterpreted Stephen's use of the term "algorithm gap".  I strongly agree
that algorithm parameter inheritance MUST NOT occur across an "algorithm
gap" as defined in Stephen's and Tim's messages.  I strongly agree that
parameter inheritance may only occur when the subject and issuer share the
same parameters.  Recommend that sentence should be added to the first
paragraph in section 7.3, Subject Public Key Algorithms.

Stephen's recommended text enforces the rule that algorithm parameter
inheritance must not occur across an "algorithm gap".  He recommended: "if
the signing algorithm and subject public key algorithms in a certificate
differ, then the issuer MUST include all algorithm parameters in the
subjectPublicKeyInfo as parameter inheritance is not supported in such
cases". Recommend that Stephen's text should be included in the first
paragraph in section 7.3.  Recommend adding "(if applicable)" after "all
algorithm parameters" in the above sentence.

I agree with Santosh's statement that there is no such thing as parameters
in the RSA.  However, I still believe that the pkix-new-part1-00 cert path
validation procedures need to be clarified.  Recommend that the following
text be added to the description of the working_public_key_parameters
variable in section 6.1.2, bullet (i): "Note: There are no algorithm
parameters associated with an RSA public key; therefore, the certification
path validation procedures described in this section specify that the
working_public_key_parameters variable is set to NULL when associated with
an RSA working_public_key."  

I stand by my original comment documented in the attached message that
started this message exchange.

-John


-------------------- Original Message -------------------------------

From:	Pawling, John [[e-mail]]
Sent:	Friday, February 25, 2000 5:08 PM
To:	[e-mail]
Subject:	Cert Path Validation Bug in pkix-new-part1-00 

All,

There is a bug in the certification path validation Wrap-up procedures
section (6.1.5) in the October 22, 1999 PKIX Certificate and CRL Profile
<draft-ietf-pkix-new-part1-00.txt>.  If an issuer cert containing a DSS
public key is used to verify an end-entity cert containing an RSA public
key, then the current Wrap-up procedure does not properly set the
working_public_key_parameters variable to NULL.  With the current procedure,
the working_public_key_parameters is still set to the issuer's DSS algorithm
parameters.  Recommend the following change to section 6.1.5:

OLD:  (d) If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with non-null parameters, assign the parameters to the
working_public_key_parameters variable.

NEW:  (d) If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with non-null parameters, assign the parameters to the
working_public_key_parameters variable.  If the subjectPublicKeyInfo field
of the certificate contains an algorithm field with null parameters, compare
the certificate subjectPublicKey algorithm to the
working_public_key_algorithm.  If the certificate subjectPublicKey algorithm
and the working_public_key_algorithm are different, set the
working_public_key_parameters to null.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26668 for <[e-mail]>; Thu, 2 Mar 2000 08:59:16 -0800 (PST)
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA19324 for <[e-mail]>; Thu, 2 Mar 2000 17:59:24 +0100
Message-ID: <[e-mail]>
Date: Thu, 02 Mar 2000 17:59:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Time Stamp Protocol (TSP) v6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have just sent a new version for the Internet X.509 Public Key
Infrastructure Time Stamp Protocol (TSP)
<draft-ietf-pkix-time-stamp-06.txt> to the IETF web master. It
should be made available shortly. 

I have looked at the various comments sent during the last call
period and attempted to provide corrections to address the issues
that have been raised.

The main issues, raised by Roland Mueller, were about:

1. The request message,
2. The error codes,
3. The format of the reply message.

The first issue can be solved by adding an optional field in the
request, which, if absent, means that a digitally-signed token is
requested. No change to the current document is needed.

The second issue can be solved by reserving some error codes. I
propose to reserve two error codes, i.e. 18 and 19 for ISO purposes.
The IETF chairs and the WG shall then make sure that these error
codes are not assigned by the IETF. No change to the current
document is needed.

The third issue can be solved in the following way: A TimeStampToken
can be defined as a ContentInfo.

TimeStampToken ::= ContentInfo
  -- contentType is id-signedData ([CMS])
  -- content is SignedData ([CMS])

However, there exists other types of contentType defined in [CMS] in
particular DigestedData.

      DigestedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithm DigestAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo,  

     Digest ::= OCTET STRING

The digest can be a binding. Its interpretation is defined by the
digestAlgorithm.

So ISO could allow to have either signedData or DigestedData, while
the IETF will only has signedData.

Note: My aknowledgments to Peter Sylvester for suggesting this
solution.

Concerning the ASN1 tags, it is more a "matter of taste", since
there is nothing wrong in the current syntax (unless I made an error
?).

I hope that all the issues are now solved and I request you to have
a close look again at the document to make sure that everything is
fine.

Regards,

Denis


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26548 for <[e-mail]>; Thu, 2 Mar 2000 08:57:41 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAB25477; Thu, 2 Mar 2000 08:57:49 -0800 (PST)
Received: from sun.com (boston [129.156.238.80]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id QAA24341; Thu, 2 Mar 2000 16:57:47 GMT
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 02 Mar 2000 16:57:47 +0000
From: Sean Mullan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: New topic - selective retrieval of cross-certs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Sharon,

I'd like to raise another related issue with respect to building
certification paths.

As you note below, building certification paths in a 'reverse'
direction (from trust anchor to EE) is a valid way to build
certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
that the storage of cross certificates in the reverse component of
the crossCertificatePair is optional. It is not possible to efficiently
build a certification path in a 'reverse' direction unless the 
certificates are populated in the reverse component of the crossCertificatePair
attribute. Specifying that this feature is optional makes it
difficult to build paths in a reverse direction in a trust model
where lots of cross certificates and multiple directories
are involved and you don't know if the CAs support
the optional storage.

I would like to suggest that RFC 2587 be ammended to make storage
of cross certificates in the reverse component of the
crossCertificatePair attribute mandatory.

Thanks,
--Sean

Sharon Boeyen wrote:
> 
> I'd like to initiate discussion on solutions to the following problem:
> 
> In a strict hierarchy, each cert has a single superior and
> identification and retrieval of the next cert to build a path
> (from the EE cert to the root) is straightforward through use
> of the AIA extension. However, in a distributed trust model,
> especially one using a 'bridge CA' or hub and spoke model, the selection
> of the next cert to build a path is not as straightforward. Some build from
> the EE to a trusted CA key, others build from the trusted CA key toward
> the root. Some build a path and then start validating the certs, others
> validate the certs as they are building the chain in order to do early
> pruning of the set of certs. All these are valid techniques and I'm trying
> to look
> at the scaling issues in all these environments. As the number of CA
> certs issued to/by any given CA grows, it becomes infeasible for a verifier
> to
> deal with the complete set of certs in a single basket, such as a single
> directory
> attribute in its entirety with all values at once. For instance, if a bridge
> CA has
> 1,000 spokes, then its 'outbound' or reverse cross-certificates would take
> on the order
> of one hour to download over a phone. Obviously this is unacceptable.
> 
> A couple of options seem interesting.
> 
> If a directory is used as the repository, then the use of extended filters
> in
> directory search operations may be useful. This would allow a relying party
> to
> retrieve only a subset of the certificates in a directory attribute, based
> on
> whatever criteria were interesting to the relying party (e.g. retrieve only
> the
> certs that contain a given policy OID or only those that were issued within
> a
> given name subtree etc.). Issues with this approach may be the complexity of
> 
> supporting the filters, matching rules and search operations themselves in
> products.
> 
> An alternative to the directory filters would be be having
> the verifier use HTTP to retrieve just those certificates that meet its
> requirements.
> To do this effectively in path development/processing that is done from a
> trusted
> CA key toward the EE cert, a new extension "subjectInfoAccess" similar to
> the authorityInfoAccess
> would be useful. The SIA would contain a URL that represented the set of
> certificates issued
> to CAs by the CA that is the subject of the certificate containing the SIA
> extension.
> A verifier would perform an http 'get'on the URL contained in the
> subjectInfoAccess
> extension of a certificate. The current values of the state variables in the
> certification path
> processing algorithm would be included in the 'get' operation as parameters.
> For instance,
> the current acceptable policies, name constraints, inhibit mapping
> indicator, explicit policy
> indicator etc are included. Then a CGI on the target URL could return only
> those outbound
> certificates from the full list that satisfy the requirements defined by
> those parameters.
> 
> Similarly, if building the path from the EE toward a trusted CA key, the AIA
> could contain a URL
> that represented a set of certificates (rather than a single one as in a
> strict hierarchy) and
> the 'get' could contain a set of parameters to filter only certificates that
> match the processing
> parameters.
> 
> As I said earlier, these techniques wouldn't be necessary in a single strict
> hierarchy that
> isn't cross certified with any other PKIs, but in distributed trust models
> (especially hub & spoke CAs)
> as well as in cross-certified hierarchies and mixed environments, they would
> be useful.
> 
> I'm interested in hearing feedback on this http proposal as well as any
> other ideas for
> filtering sets of certs to make path construction and validation efficient
> in very large scale
> environments. Are folks interested in pursuing http based mechanisms further
> within PKIX? What, if
> anything, should PKIX do about this issue? Do people prefer the directory
> filter approach, the http
> approach, other?
> 
> Sharon
> 
> Sharon Boeyen
> Entrust Technologies
> [e-mail]

-- 
************************************************************
Sean Mullan
Sun Microsystems                        tel: [phone]
East Point Business Park                fax: [phone]
Clontarf                         mailto: [e-mail]
Dublin 3
Ireland
************************************************************


Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25705 for <[e-mail]>; Thu, 2 Mar 2000 08:12:55 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12446; Thu, 2 Mar 2000 09:13:01 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA20152; Thu, 2 Mar 2000 11:12:59 -0500 (EST)
Received: from sunlabs.east.sun.com (eastapp2.East.Sun.COM [129.148.162.99]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA13306; Thu, 2 Mar 2000 11:12:37 -0500 (EST)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 2 Mar 2000 11:15:55 -0500
To: "'David Chadwick'" <[e-mail]>, "Sharon Boeyen" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Reply-To: <[e-mail]>
Subject: RE: New topic - selective retrieval of cross-certs
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

>Some interesting ideas. I'm not particularly wedded to any specific 
>solution, but trying to raise some ideas for consideration. I'm very 
>familiar with the certificateAssertion match capabilities but I'm not
>familiar enough with directory and PKI client products to know whether 
>these are likely to be natively supported or not, because of their 
>complexity.

I can't speak for directory implementors, but PKI client products have lots of
code that's much more complicated than putting together a certificateAssertion.
How about parsing the dozens of complicated extensions that MUST be supported
under PKIX! If we can help improve cert path building, that would be very
helpful. And PKI clients that don't want to use the certificateAssertion (for
whatever reason) can pull down all the certs and filter them on the client.

> One appealing aspect of http is that it can more easily 
>address the firewall problems that directory protocols have more 
>trouble with. I'm not suggesting that we drop directory solutions at
>all, but think that http may also be a promising vehicle for repository 
>access especially the verifier doesn't necessarily have the address for 
>the directory in question or where firewall traversal is an issue.

There is a classic tendency to piggyback *everything* on top of http, citing
firewall traversal. This drives sysadmins batty and causes firewall vendors
to add stateful filtering so that they can block out certain *kinds* of HTTP
traffic. We may need to do this, but I would prefer not to if possible.

As for the question of how the PKI client knows the address of the directory,
why not use put in the CRLDistributionPoints extension a URIName with an ldap
scheme (including the DNS name of the directory server)?

>Your idea of passing the certificateAssertion syntax as http parameters
>may also be promising. One of the efficiencies I have in mind relates 
>to the environment where the verifier is doing validation of certs while 
>building the path. As the path processing variables change (e.g.
>allow/prevent
>policy mapping) it would be nice to be able to change the parameters of 
>the 'filter' with each subsequent cert retrieval attempt. If the
>certificateAssertion
>can handle all those variables, or is close to doing so, that's certainly
>worth 
>pursuing. That way we could have a single syntax that applies both to LDAP
>and 
>HTTP mechanisms.

I think we're close. In fact, I noticed that the definition of the policy
field in the certificateAssertion was changed in the most recent X.509 draft
to include the very change I suggested in my last message! I suppose that's
probably due to somebody's (Santosh's?) experience with building certification
paths. When I get back to my office, I'll dig up the list of other changes we
would suggest. But the existing certificateAssertion is pretty decent.

Thanks,

Steve



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23836 for <[e-mail]>; Thu, 2 Mar 2000 06:27:13 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <1TRVLDGN>; Thu, 2 Mar 2000 09:26:54 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, Sharon Boeyen <[e-mail]>, "'David Chadwick'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: New topic - selective retrieval of cross-certs
Date: Thu, 2 Mar 2000 09:26:53 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve, 
Some interesting ideas. I'm not particularly wedded to any specific 
solution, but trying to raise some ideas for consideration. I'm very 
familiar with the certificateAssertion match capabilities but I'm not
familiar enough with directory and PKI client products to know whether 
these are likely to be natively supported or not, because of their 
complexity. One appealing aspect of http is that it can more easily 
address the firewall problems that directory protocols have more 
trouble with. I'm not suggesting that we drop directory solutions at
all, but think that http may also be a promising vehicle for repository 
access especially the verifier doesn't necessarily have the address for 
the directory in question or where firewall traversal is an issue. 

Your idea of passing the certificateAssertion syntax as http parameters
may also be promising. One of the efficiencies I have in mind relates 
to the environment where the verifier is doing validation of certs while 
building the path. As the path processing variables change (e.g.
allow/prevent
policy mapping) it would be nice to be able to change the parameters of 
the 'filter' with each subsequent cert retrieval attempt. If the
certificateAssertion
can handle all those variables, or is close to doing so, that's certainly
worth 
pursuing. That way we could have a single syntax that applies both to LDAP
and 
HTTP mechanisms.

David, thoughts?

Sharon

> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Wednesday, March 01, 2000 4:20 PM
> To: Sharon Boeyen
> Cc: '[e-mail]'
> Subject: Re: New topic - selective retrieval of cross-certs
> 
> 
> Thanks, Sharon, for raising these issues. Building certification paths
> in a distributed trust model will probably grow in importance as
> cross-certification increases. Our research group has spent a 
> good deal
> of time studying this problem. My comments appear below.
> 
> Sharon Boeyen wrote:
> > If a directory is used as the repository, then the use of extended
> > filters in directory search operations may be useful. This 
> would allow
> > a relying party to retrieve only a subset of the certificates in a
> > directory attribute, based on whatever criteria were interesting to
> > the relying party (e.g. retrieve only the certs that contain a given
> > policy OID or only those that were issued within a given 
> name subtree
> > etc.). Issues with this approach may be the complexity of
> > supporting the filters, matching rules and search operations
> > themselves in products.
> 
> This approach could, of course, be supported using the certificate
> matching rules defined in X.509 (or some variation).
> 
> > An alternative to the directory filters would be be having
> > the verifier use HTTP to retrieve just those certificates that meet
> > its requirements. To do this effectively in path
> > development/processing that is done from a trusted CA key toward the
> > EE cert, a new extension "subjectInfoAccess" similar to the
> > authorityInfoAccess would be useful. The SIA would contain 
> a URL that
> > represented the set of certificates issued to CAs by the CA that is
> > the subject of the certificate containing the SIA extension.
> > A verifier would perform an http 'get'on the URL contained in the
> > subjectInfoAccess extension of a certificate. The current values of
> > the state variables in the certification path processing algorithm
> > would be included in the 'get' operation as parameters. For 
> instance,
> > the current acceptable policies, name constraints, inhibit mapping
> > indicator, explicit policy indicator etc are included. Then a CGI on
> > the target URL could return only those outbound 
> certificates from the
> > full list that satisfy the requirements defined by those parameters.
> 
> Why is this better than the solution described above? The complexities
> you described above all apply here. The only difference is 
> that you have
> added a new extension to the certificate and changed the transport
> protocol from LDAP to HTTP (which is probably less suited for 
> the job).
> 
> > Similarly, if building the path from the EE toward a trusted CA key,
> > the AIA could contain a URL that represented a set of certificates
> > (rather than a single one as in a strict hierarchy) and the 'get'
> > could contain a set of parameters to filter only certificates that
> > match the processing parameters.
> 
> Same comments as above. If people really want the ability to do this
> with HTTP, let's send the matching rule over as the 
> parameter. That way,
> we won't need two ways to encode the same information.
> 
> > I'm interested in hearing feedback on this http proposal as well as
> > any other ideas for filtering sets of certs to make path 
> construction
> > and validation efficient in very large scale environments. Are folks
> > interested in pursuing http based mechanisms further within PKIX?
> > What, if anything, should PKIX do about this issue? Do people prefer
> > the directory filter approach, the http approach, other?
> 
> Our group is definitely interested in finding ways to make path
> construction easier. We would like to propose some specific 
> changes and
> additions to the CertificateAssertion that will assist in building
> certification paths (such as changing the policy field to match any
> certificate that includes *any* of the specified policies). 
> We have also
> participated (with David Chadwick) in the development of an Internet
> Draft (draft-ietf-ldapext-matchedval-01.txt) that would allow an LDAP
> server to filter the elements of a crossCertificatePair attribute and
> return only those that match a given matching rule.
> 
> Steve Hanna
> Sun Labs
> 


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22983 for <[e-mail]>; Thu, 2 Mar 2000 06:11:20 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <1TRVLC00>; Thu, 2 Mar 2000 09:11:02 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tammy Green'" <[e-mail]>, [e-mail]
Subject: RE: What if the CRL distribution points for a CA change?
Date: Thu, 2 Mar 2000 09:11:00 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The status of the DAM and its contents is:
 
Technically, the collaborative ITU-T / ISO/IEC group believes it is solid
and it has completed the early round ballots in ISO. Many folks have 
been pointing out editorial and ASN.1 bugs and I am having these addressed
at the next ITU-T meeting later this month.
 
>From a process standpoint, the next step is the ITU-T approval. The docs
will be considered formally by ITU-T SG 7 at this month's meeting. 
Assuming approval from that group, then the final ISO/IEC ballot will occur
later this year (probably the summer/fall timeframe) and we will 
hopefully have the next edition of X.509 formally approved by both bodies by
year end.
 
Bugs and defects will of course continue to be addressed, but as editor, I
currently envision no major changes to the technical content, based 
on formal and informal feedback.
 
Tammy, I'll forward a copy of the combined draft separately to you.
 
Sharon
 
 

-----Original Message-----
From: Tammy Green [mailto:[e-mail]]
Sent: Wednesday, March 01, 2000 4:20 PM
To: [e-mail]; [e-mail]
Subject: RE: What if the CRL distribution points for a CA change?


The X.509 DAM has proved to be quite enlightening.  As it turns out, I was
trying to address the two issues which you highlight as well as a third
issue:
 
3) Limiting the scope of a CRL
 
all at once using only those extensions defined in RFC 2459 (and the new
part1 draft).  The crlScope and statusReferrals extensions provide exactly
what I need.
 
What are the status of these extensions?  Are they going to be put into the
new part1 draft?
 
And, if you could send me a copy of the restructured X.509 doc when it's
ready I'd be most appreciative.

Thanks!
 
Tammy Green

>>> Sharon Boeyen <[e-mail]> 3/1/00 8:14:42 AM >>>
Need to separate these into two separate issues:

1) Multiple name forms for the same CRL DP
2) Changing the value of a name form for a CRL DP

1 is accomodated in the CRL DP extension itself. You can allow 
access to the same CRL via various mechanisms through the
DistributionPointName
component of the cRLDistributionPoints extension. The syntax for the
fullName choice 
is GeneralNames so more than one name form for the the same CRL DP can be
included.
Note that the X.509 DAM contains an Annex on CRL generation and processing
(written 
by Santosh) that explains how these are used on the processing side.

2 - This requirement (and some other related ones) has been addressed in the
X.509 DAM. The 
statusReferrals extension is a new CRL extension that serves two purposes.
One is to publish 
a "trusted list" of CRLs to help relying parties find the CRLs of interest
to them (in case 
CRL DP is not included in a cert) and the other is to redirect a relying
party when following 
a pointer (e.g. a CRL DP extension in a cert) that has been changed since
the cert was issued. 
For details see 12.5.2.6 of the 509 DAM at:

ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc
<ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc> 

If you prefer to work from the draft restructured complete 509 document, let
me know and I'll 
send a copy to you. I expect to have this available on the web as well
shortly.  

> -----Original Message-----
> From: Tammy Green [mailto:[e-mail]]
> Sent: Friday, February 25, 2000 1:27 PM
> To: [e-mail]
> Subject: Re: What if the CRL distribution points for a CA change?
> 
> 
> Some clarification seems to be in order....
> 
> The idea of having multiple distribution points in a 
> certificate seems very reasonable in our context at Novell.  
> For our PKI, it is quite convenient to name at least two 
> distribution points:  one which is an X.500 name and one 
> which is an LDAP address.  Since our PKI is integrated with 
> our directory (NDS), it is natural for us to prefer 
> retrieving the CRLs directly from NDS rather than using LDAP. 
>  But, because there are applications out there that are not 
> NDS-aware, we'd like to include other distribution points 
> which can be accessed from outside of the company via HTTP or LDAP.  
> 
> As for changing the distribution points, there are a couple 
> of scenarios that I can envision where they would be changed. 
>  How true-to-life these scenarios are is something that I'm 
> hoping to discover.
> 
> 1.  The one externally-available distribution point (say it 
> is LDAP) currently listed in the certificates just doesn't 
> have enough bandwidth to accommodate all the queries.  Or, 
> the software package that the CEO of the company is using 
> can't use LDAP to get CRLs ? it must use HTTP.  The CA 
> Administrator is forced to add additional distribution points 
> to accommodate other protocols and/or unexpected traffic.
> 
> 2.  One of the distribution points is being phased out (for 
> whatever reason).  Maybe the company no longer wants to 
> support LDAP access to its directory.  Or maybe the company 
> has made an agreement with another organization to post its 
> CRLs on their high-volume servers.
> 
> 3.  The CA in question issues a million certificates a year 
> and expects that half of all of those certificates will be 
> revoked.  The CRLs for that CA would become quite large, and, 
> after some calculations, the CA Administrator decides that 
> CRLs of that size are unacceptable.  He therefore decides to 
> change the CRL distribution points every year.  So, 
> basically, for those certificates issued in the first year, 
> their CRLs would be found on distribution points A and B.  
> For those certificates issued in the second year, their CRLs 
> would be found on distribution points C and D.  If my option 
> (b) were used here, then the CRLs found on A, B, C, and D 
> would contain a maximum of 1 million certificates 
> certificates each in the worst case where all the 
> certificates were revoked (CRL on A = CRL on B; CRL on C = 
> CRL on D; CRL on A != CRL on C).  [If option (a) were used 
> here, the CA Administrator would have a nasty surprise in 
> that the CRLs on A, B, C, and D would be exactly the same and 
> contain 2 million certificates in the worst case scenario.]
> 
> 
> Are these scenarios something that you would find in the real 
> world?  If so, then is it acceptable to make the CRLs on all 
> distribution points ever specified the same?  Or, should they 
> contain only the minimum number of certificates?
> 
> 
> Tammy Green
> [e-mail] 
> Software Engineer
> Novell, Inc.
> 
> >>> "Bob Jueneman" <[e-mail]> 02/24/00 09:55PM >>>
> Don't do that?
> 
> I.e., :
> 
> 1.  Don't issue certificates containing multiple distribution points.
> 
> 2.  If issuing certificates with multiple distribution points 
> is absolutely necessary (for some reason I can't quite 
> fathom), don't change the distribution points unless you are 
> prepared to implement option b.
> 
> If we restrict the type of distribution points to LDAP 
> queries, wouldn't it be possible to remap the DNS name of the 
> server as might be required for load balancing, leaving the 
> LDAP query itself unmodified?  Doesn't this eliminate the 
> entire problem?
> 
> Bob
> 
> 
> 
> >>> Tammy Green 02/24/00 08:58PM >>>
> Say a CA begins minting certificates with distribution points 
> A, B, and C in the certificates.  It issues 10 certificates.  
> Then, at time t1, it changes the distribution points to A, D, 
> and E and issues 10 more certificates.
> 
> Now say that at time t2 certificate 1 was revoked as well as 
> certificate 11.  What should the CA do when it comes time to 
> issue the CRL?  [Assume here that the CA is only issuing a 
> basic CRL that is not subdivided by reason codes, etc.]  It 
> appears that there are two options.
> 
> (a)  Issue one CRL containing entries for certificate 1 and 
> 11.  Post that CRL to distribution points A, B, C, D, and E.
> 
> (b)  Issue one CRL containing entries for certificate 1 and 
> 11 and post that CRL to distribution point A.  Then issue 
> another CRL containing an entry for only certificate 1 and 
> post that CRL to distribution points B and C.  Finally issue 
> yet another CRL containing an entry for only certificate 10 
> and post that CRL to distribution points D and E.
> 
> Option a has the disadvantage of causing needless bloat to 
> the CRLs posted on distribution points B, C, D, and E:  no 
> one will look for revocation information about certificate 1 
> on distribution point D or E, and, likewise, no one will look 
> for revocation information about certificate 11 on 
> distribution point B or C.  Option a does have the advantage 
> of being far easier to implement, however.
> 
> Option b has the disadvantage of being much more complex.  
> And, each time the set of distribution points is modified, 
> the complexity increases as does the time required to 
> generate all of the CRLs which are required.  However, the 
> advantage is that the CRLs that are posted to the 
> distribution points contain only useful information.
> 
> Are there other solutions?  Preferences?  Implementations?  
> Guidelines?
> 
> 
> Tammy Green
> [e-mail] 
> Software Engineer
> Novell, Inc.
> 
> 




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22651 for <[e-mail]>; Thu, 2 Mar 2000 06:04:07 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA01184 for <[e-mail]>; Thu, 2 Mar 2000 09:04:50 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA01177 for <[e-mail]>; Thu, 2 Mar 2000 09:04:49 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA23660 for <[e-mail]>; Thu, 2 Mar 2000 09:04:38 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA03394 for <[e-mail]>; Thu, 2 Mar 2000 09:01:29 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 2 Mar 2000 09:01:29 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: What if the CRL distribution points for a CA change?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: fB+94sTUA2B7vDp2UrJ1ng==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Sharon,

Tammy's question raised a question in my mind - the two issues you
identify (multiple DPs and changing DPs) and a third: identifying the
CRL(s) which apply to a certificate.

The first two are operational issues - how can the RP know where to
find revocation information.  Ideally the RP could look for CRLs in
application-configured locations, CRL DP URIs, locations configured in
a network naming service, etc., and the locally-configured locations
could be changed on the fly without any involvement of the CA.

The third is a security issue - CAs and RPs must have a common
understanding of what constitutes the entire set of revocation
information for a given cert.  This trust linkage could be accomplished
with a location-independent identifier, in the same manner that
subjectKeyIdentifier/authorityKeyIdentifier link a cert to an
appropriate parent.

To solve Tammy's problem, would it not be appropriate to place
a directoryName (or maybe even a registeredID) in
DistributionPointName:fullName, and use some non-CA mechanism to
configure the RP applications to locate and retrieve the CRLs?

Dave



> From: Sharon Boeyen <[e-mail]>
> To: "'Tammy Green'" <[e-mail]>, [e-mail]
> Subject: RE: What if the CRL distribution points for a CA change?
> Date: Wed, 1 Mar 2000 10:14:42 -0500 
> 
> Need to separate these into two separate issues:
> 
> 1) Multiple name forms for the same CRL DP
> 2) Changing the value of a name form for a CRL DP
> 
> 1 is accomodated in the CRL DP extension itself. You can allow 
> access to the same CRL via various mechanisms through the
> DistributionPointName
> component of the cRLDistributionPoints extension. The syntax for the
> fullName choice 
> is GeneralNames so more than one name form for the the same CRL DP can be
> included.
> Note that the X.509 DAM contains an Annex on CRL generation and processing
> (written 
> by Santosh) that explains how these are used on the processing side.
> 
> 2 - This requirement (and some other related ones) has been addressed in the
> X.509 DAM. The 
> statusReferrals extension is a new CRL extension that serves two purposes.
> One is to publish 
> a "trusted list" of CRLs to help relying parties find the CRLs of interest
> to them (in case 
> CRL DP is not included in a cert) and the other is to redirect a relying
> party when following 
> a pointer (e.g. a CRL DP extension in a cert) that has been changed since
> the cert was issued. 
> For details see 12.5.2.6 of the 509 DAM at:
> 
> ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc
> 
> If you prefer to work from the draft restructured complete 509 document, let
> me know and I'll 
> send a copy to you. I expect to have this available on the web as well
> shortly.  
> 
> > -----Original Message-----
> > From: Tammy Green [mailto:[e-mail]]
> > Sent: Friday, February 25, 2000 1:27 PM
> > To: [e-mail]
> > Subject: Re: What if the CRL distribution points for a CA change?
> > 
> > 
> > Some clarification seems to be in order....
> > 
> > The idea of having multiple distribution points in a 
> > certificate seems very reasonable in our context at Novell.  
> > For our PKI, it is quite convenient to name at least two 
> > distribution points:  one which is an X.500 name and one 
> > which is an LDAP address.  Since our PKI is integrated with 
> > our directory (NDS), it is natural for us to prefer 
> > retrieving the CRLs directly from NDS rather than using LDAP. 
> >  But, because there are applications out there that are not 
> > NDS-aware, we'd like to include other distribution points 
> > which can be accessed from outside of the company via HTTP or LDAP.  
> > 
> > As for changing the distribution points, there are a couple 
> > of scenarios that I can envision where they would be changed. 
> >  How true-to-life these scenarios are is something that I'm 
> > hoping to discover.
> > 
> > 1.  The one externally-available distribution point (say it 
> > is LDAP) currently listed in the certificates just doesn't 
> > have enough bandwidth to accommodate all the queries.  Or, 
> > the software package that the CEO of the company is using 
> > can't use LDAP to get CRLs ? it must use HTTP.  The CA 
> > Administrator is forced to add additional distribution points 
> > to accommodate other protocols and/or unexpected traffic.
> > 
> > 2.  One of the distribution points is being phased out (for 
> > whatever reason).  Maybe the company no longer wants to 
> > support LDAP access to its directory.  Or maybe the company 
> > has made an agreement with another organization to post its 
> > CRLs on their high-volume servers.
> > 
> > 3.  The CA in question issues a million certificates a year 
> > and expects that half of all of those certificates will be 
> > revoked.  The CRLs for that CA would become quite large, and, 
> > after some calculations, the CA Administrator decides that 
> > CRLs of that size are unacceptable.  He therefore decides to 
> > change the CRL distribution points every year.  So, 
> > basically, for those certificates issued in the first year, 
> > their CRLs would be found on distribution points A and B.  
> > For those certificates issued in the second year, their CRLs 
> > would be found on distribution points C and D.  If my option 
> > (b) were used here, then the CRLs found on A, B, C, and D 
> > would contain a maximum of 1 million certificates 
> > certificates each in the worst case where all the 
> > certificates were revoked (CRL on A = CRL on B; CRL on C = 
> > CRL on D; CRL on A != CRL on C).  [If option (a) were used 
> > here, the CA Administrator would have a nasty surprise in 
> > that the CRLs on A, B, C, and D would be exactly the same and 
> > contain 2 million certificates in the worst case scenario.]
> > 
> > 
> > Are these scenarios something that you would find in the real 
> > world?  If so, then is it acceptable to make the CRLs on all 
> > distribution points ever specified the same?  Or, should they 
> > contain only the minimum number of certificates?
> > 
> > 
> > Tammy Green
> > [e-mail] 
> > Software Engineer
> > Novell, Inc.
> > 
> > >>> "Bob Jueneman" <[e-mail]> 02/24/00 09:55PM >>>
> > Don't do that?
> > 
> > I.e., :
> > 
> > 1.  Don't issue certificates containing multiple distribution points.
> > 
> > 2.  If issuing certificates with multiple distribution points 
> > is absolutely necessary (for some reason I can't quite 
> > fathom), don't change the distribution points unless you are 
> > prepared to implement option b.
> > 
> > If we restrict the type of distribution points to LDAP 
> > queries, wouldn't it be possible to remap the DNS name of the 
> > server as might be required for load balancing, leaving the 
> > LDAP query itself unmodified?  Doesn't this eliminate the 
> > entire problem?
> > 
> > Bob
> > 
> > 
> > 
> > >>> Tammy Green 02/24/00 08:58PM >>>
> > Say a CA begins minting certificates with distribution points 
> > A, B, and C in the certificates.  It issues 10 certificates.  
> > Then, at time t1, it changes the distribution points to A, D, 
> > and E and issues 10 more certificates.
> > 
> > Now say that at time t2 certificate 1 was revoked as well as 
> > certificate 11.  What should the CA do when it comes time to 
> > issue the CRL?  [Assume here that the CA is only issuing a 
> > basic CRL that is not subdivided by reason codes, etc.]  It 
> > appears that there are two options.
> > 
> > (a)  Issue one CRL containing entries for certificate 1 and 
> > 11.  Post that CRL to distribution points A, B, C, D, and E.
> > 
> > (b)  Issue one CRL containing entries for certificate 1 and 
> > 11 and post that CRL to distribution point A.  Then issue 
> > another CRL containing an entry for only certificate 1 and 
> > post that CRL to distribution points B and C.  Finally issue 
> > yet another CRL containing an entry for only certificate 10 
> > and post that CRL to distribution points D and E.
> > 
> > Option a has the disadvantage of causing needless bloat to 
> > the CRLs posted on distribution points B, C, D, and E:  no 
> > one will look for revocation information about certificate 1 
> > on distribution point D or E, and, likewise, no one will look 
> > for revocation information about certificate 11 on 
> > distribution point B or C.  Option a does have the advantage 
> > of being far easier to implement, however.
> > 
> > Option b has the disadvantage of being much more complex.  
> > And, each time the set of distribution points is modified, 
> > the complexity increases as does the time required to 
> > generate all of the CRLs which are required.  However, the 
> > advantage is that the CRLs that are posted to the 
> > distribution points contain only useful information.
> > 
> > Are there other solutions?  Preferences?  Implementations?  
> > Guidelines?
> > 
> > 
> > Tammy Green
> > [e-mail] 
> > Software Engineer
> > Novell, Inc.
> > 
> > 



Received: from rafiki.ganet.org ([e-mail] [167.193.194.192]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20556 for <[e-mail]>; Thu, 2 Mar 2000 05:12:57 -0800 (PST)
Received: from LAPTOP (robertr2.vlan.net [209.160.75.98]) by rafiki.ganet.org (8.8.5/8.8.5) with SMTP id IAA15646 for <[e-mail]>; Thu, 2 Mar 2000 08:12:44 -0500 (EST)
From: "Robert Rowland" <[e-mail]>
To: <[e-mail]>
Date: Thu, 2 Mar 2000 07:10:51 -0800
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.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

unsubscribe


Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18770 for <[e-mail]>; Thu, 2 Mar 2000 04:37:28 -0800 (PST)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2650.21) id <FZNCVSFG>; Thu, 2 Mar 2000 07:37:33 -0500
Message-ID: <[e-mail]>
From: "Ramaswamy, Sridhar" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "Ramaswamy, Sridhar" <[e-mail]>
Subject: subscribe
Date: Thu, 2 Mar 2000 07:37:31 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

subscribe


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00780 for <[e-mail]>; Wed, 1 Mar 2000 22:58:57 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLY2GD>; Wed, 1 Mar 2000 22:58:27 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Tamura, Takuya'" <[e-mail]>, [e-mail]
Subject: RE: Is SCVP still alive?
Date: Wed, 1 Mar 2000 22:58:26 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Tak,
    We will have the next draft out before the cutoff date for
this IETF.

Ambarish


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


> -----Original Message-----
> From: Tamura, Takuya [mailto:[e-mail]]
> Sent: Wednesday, March 01, 2000 9:40 PM
> To: [e-mail]
> Subject: Is SCVP still alive?
> 
> 
> Hi all,
> 
>   Could anybody tell me the status of SCVP?
>   draft-ietf-pkix-scvp-01.txt looks expired and
>   there's no update yet.
> 
>   Thanks in advance,
>   Tak
> 


Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27786 for <[e-mail]>; Wed, 1 Mar 2000 21:40:16 -0800 (PST)
Received: from m1.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway) id OAA08068 for <[e-mail]>; Thu, 2 Mar 2000 14:39:50 +0900 (JST) (envelope-from [e-mail])
Received: from vishnu.ec.cs.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master) id OAA07689; Thu, 2 Mar 2000 14:39:49 +0900 (JST)
Received: from ec.cs.fujitsu.co.jp ([10.34.199.168]) by vishnu.ec.cs.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.4W5-04/12/98 EC domain mail master) with ESMTP id OAA20065 for <[e-mail]>; Thu, 2 Mar 2000 14:39:51 +0900 (JST)
Message-ID: <[e-mail]>
Date: Thu, 02 Mar 2000 14:39:47 +0900
From: "Tamura, Takuya" <[e-mail]>
Organization: Devlp Dpt. II, Application Server Sw Div., FUJITSU LIMITED
X-Mailer: Mozilla 4.6 [ja] (Win95; I)
X-Accept-Language: ja,en,zh,zh-CN,fr
MIME-Version: 1.0
To: [e-mail]
Subject: Is SCVP still alive?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

  Could anybody tell me the status of SCVP?
  draft-ietf-pkix-scvp-01.txt looks expired and
  there's no update yet.

  Thanks in advance,
  Tak


Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08915 for <[e-mail]>; Wed, 1 Mar 2000 13:22:43 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04117; Wed, 1 Mar 2000 14:22:45 -0700 (MST)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA02059; Wed, 1 Mar 2000 16:22:44 -0500 (EST)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id QAA14167; Wed, 1 Mar 2000 16:22:43 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 01 Mar 2000 16:20:15 -0500
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: New topic - selective retrieval of cross-certs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks, Sharon, for raising these issues. Building certification paths
in a distributed trust model will probably grow in importance as
cross-certification increases. Our research group has spent a good deal
of time studying this problem. My comments appear below.

Sharon Boeyen wrote:
> If a directory is used as the repository, then the use of extended
> filters in directory search operations may be useful. This would allow
> a relying party to retrieve only a subset of the certificates in a
> directory attribute, based on whatever criteria were interesting to
> the relying party (e.g. retrieve only the certs that contain a given
> policy OID or only those that were issued within a given name subtree
> etc.). Issues with this approach may be the complexity of
> supporting the filters, matching rules and search operations
> themselves in products.

This approach could, of course, be supported using the certificate
matching rules defined in X.509 (or some variation).

> An alternative to the directory filters would be be having
> the verifier use HTTP to retrieve just those certificates that meet
> its requirements. To do this effectively in path
> development/processing that is done from a trusted CA key toward the
> EE cert, a new extension "subjectInfoAccess" similar to the
> authorityInfoAccess would be useful. The SIA would contain a URL that
> represented the set of certificates issued to CAs by the CA that is
> the subject of the certificate containing the SIA extension.
> A verifier would perform an http 'get'on the URL contained in the
> subjectInfoAccess extension of a certificate. The current values of
> the state variables in the certification path processing algorithm
> would be included in the 'get' operation as parameters. For instance,
> the current acceptable policies, name constraints, inhibit mapping
> indicator, explicit policy indicator etc are included. Then a CGI on
> the target URL could return only those outbound certificates from the
> full list that satisfy the requirements defined by those parameters.

Why is this better than the solution described above? The complexities
you described above all apply here. The only difference is that you have
added a new extension to the certificate and changed the transport
protocol from LDAP to HTTP (which is probably less suited for the job).

> Similarly, if building the path from the EE toward a trusted CA key,
> the AIA could contain a URL that represented a set of certificates
> (rather than a single one as in a strict hierarchy) and the 'get'
> could contain a set of parameters to filter only certificates that
> match the processing parameters.

Same comments as above. If people really want the ability to do this
with HTTP, let's send the matching rule over as the parameter. That way,
we won't need two ways to encode the same information.

> I'm interested in hearing feedback on this http proposal as well as
> any other ideas for filtering sets of certs to make path construction
> and validation efficient in very large scale environments. Are folks
> interested in pursuing http based mechanisms further within PKIX?
> What, if anything, should PKIX do about this issue? Do people prefer
> the directory filter approach, the http approach, other?

Our group is definitely interested in finding ways to make path
construction easier. We would like to propose some specific changes and
additions to the CertificateAssertion that will assist in building
certification paths (such as changing the policy field to match any
certificate that includes *any* of the specified policies). We have also
participated (with David Chadwick) in the development of an Internet
Draft (draft-ietf-ldapext-matchedval-01.txt) that would allow an LDAP
server to filter the elements of a crossCertificatePair attribute and
return only those that match a given matching rule.

Steve Hanna
Sun Labs


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA08760 for <[e-mail]>; Wed, 1 Mar 2000 13:20:35 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 01 Mar 2000 14:20:11 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 01 Mar 2000 14:19:57 -0700
From: "Tammy Green" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: What if the CRL distribution points for a CA change?
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_FFA6779B.0C6D663F"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_FFA6779B.0C6D663F
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

The X.509 DAM has proved to be quite enlightening.  As it turns out, I was =
trying to address the two issues which you highlight as well as a third =
issue:

3) Limiting the scope of a CRL

all at once using only those extensions defined in RFC 2459 (and the new =
part1 draft).  The crlScope and statusReferrals extensions provide exactly =
what I need.

What are the status of these extensions?  Are they going to be put into =
the new part1 draft?

And, if you could send me a copy of the restructured X.509 doc when it's =
ready I'd be most appreciative.

Thanks!

Tammy Green

>>> Sharon Boeyen <[e-mail]> 3/1/00 8:14:42 AM >>>
Need to separate these into two separate issues:

1) Multiple name forms for the same CRL DP
2) Changing the value of a name form for a CRL DP

1 is accomodated in the CRL DP extension itself. You can allow=20
access to the same CRL via various mechanisms through the
DistributionPointName
component of the cRLDistributionPoints extension. The syntax for the
fullName choice=20
is GeneralNames so more than one name form for the the same CRL DP can be
included.
Note that the X.509 DAM contains an Annex on CRL generation and processing
(written=20
by Santosh) that explains how these are used on the processing side.

2 - This requirement (and some other related ones) has been addressed in =
the
X.509 DAM. The=20
statusReferrals extension is a new CRL extension that serves two purposes.
One is to publish=20
a "trusted list" of CRLs to help relying parties find the CRLs of interest
to them (in case=20
CRL DP is not included in a cert) and the other is to redirect a relying
party when following=20
a pointer (e.g. a CRL DP extension in a cert) that has been changed since
the cert was issued.=20
For details see 12.5.2.6 of the 509 DAM at:

ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc

If you prefer to work from the draft restructured complete 509 document, =
let
me know and I'll=20
send a copy to you. I expect to have this available on the web as well
shortly. =20

> -----Original Message-----
> From: Tammy Green [mailto:[e-mail]]
> Sent: Friday, February 25, 2000 1:27 PM
> To: [e-mail]
> Subject: Re: What if the CRL distribution points for a CA change?
>=20
>=20
> Some clarification seems to be in order....
>=20
> The idea of having multiple distribution points in a=20
> certificate seems very reasonable in our context at Novell. =20
> For our PKI, it is quite convenient to name at least two=20
> distribution points:  one which is an X.500 name and one=20
> which is an LDAP address.  Since our PKI is integrated with=20
> our directory (NDS), it is natural for us to prefer=20
> retrieving the CRLs directly from NDS rather than using LDAP.=20
>  But, because there are applications out there that are not=20
> NDS-aware, we'd like to include other distribution points=20
> which can be accessed from outside of the company via HTTP or LDAP. =20
>=20
> As for changing the distribution points, there are a couple=20
> of scenarios that I can envision where they would be changed.=20
>  How true-to-life these scenarios are is something that I'm=20
> hoping to discover.
>=20
> 1.  The one externally-available distribution point (say it=20
> is LDAP) currently listed in the certificates just doesn't=20
> have enough bandwidth to accommodate all the queries.  Or,=20
> the software package that the CEO of the company is using=20
> can't use LDAP to get CRLs ? it must use HTTP.  The CA=20
> Administrator is forced to add additional distribution points=20
> to accommodate other protocols and/or unexpected traffic.
>=20
> 2.  One of the distribution points is being phased out (for=20
> whatever reason).  Maybe the company no longer wants to=20
> support LDAP access to its directory.  Or maybe the company=20
> has made an agreement with another organization to post its=20
> CRLs on their high-volume servers.
>=20
> 3.  The CA in question issues a million certificates a year=20
> and expects that half of all of those certificates will be=20
> revoked.  The CRLs for that CA would become quite large, and,=20
> after some calculations, the CA Administrator decides that=20
> CRLs of that size are unacceptable.  He therefore decides to=20
> change the CRL distribution points every year.  So,=20
> basically, for those certificates issued in the first year,=20
> their CRLs would be found on distribution points A and B. =20
> For those certificates issued in the second year, their CRLs=20
> would be found on distribution points C and D.  If my option=20
> (b) were used here, then the CRLs found on A, B, C, and D=20
> would contain a maximum of 1 million certificates=20
> certificates each in the worst case where all the=20
> certificates were revoked (CRL on A =3D CRL on B; CRL on C =3D=20
> CRL on D; CRL on A !=3D CRL on C).  [If option (a) were used=20
> here, the CA Administrator would have a nasty surprise in=20
> that the CRLs on A, B, C, and D would be exactly the same and=20
> contain 2 million certificates in the worst case scenario.]
>=20
>=20
> Are these scenarios something that you would find in the real=20
> world?  If so, then is it acceptable to make the CRLs on all=20
> distribution points ever specified the same?  Or, should they=20
> contain only the minimum number of certificates?
>=20
>=20
> Tammy Green
> [e-mail]=20
> Software Engineer
> Novell, Inc.
>=20
> >>> "Bob Jueneman" <[e-mail]> 02/24/00 09:55PM >>>
> Don't do that?
>=20
> I.e., :
>=20
> 1.  Don't issue certificates containing multiple distribution points.
>=20
> 2.  If issuing certificates with multiple distribution points=20
> is absolutely necessary (for some reason I can't quite=20
> fathom), don't change the distribution points unless you are=20
> prepared to implement option b.
>=20
> If we restrict the type of distribution points to LDAP=20
> queries, wouldn't it be possible to remap the DNS name of the=20
> server as might be required for load balancing, leaving the=20
> LDAP query itself unmodified?  Doesn't this eliminate the=20
> entire problem?
>=20
> Bob
>=20
>=20
>=20
> >>> Tammy Green 02/24/00 08:58PM >>>
> Say a CA begins minting certificates with distribution points=20
> A, B, and C in the certificates.  It issues 10 certificates. =20
> Then, at time t1, it changes the distribution points to A, D,=20
> and E and issues 10 more certificates.
>=20
> Now say that at time t2 certificate 1 was revoked as well as=20
> certificate 11.  What should the CA do when it comes time to=20
> issue the CRL?  [Assume here that the CA is only issuing a=20
> basic CRL that is not subdivided by reason codes, etc.]  It=20
> appears that there are two options.
>=20
> (a)  Issue one CRL containing entries for certificate 1 and=20
> 11.  Post that CRL to distribution points A, B, C, D, and E.
>=20
> (b)  Issue one CRL containing entries for certificate 1 and=20
> 11 and post that CRL to distribution point A.  Then issue=20
> another CRL containing an entry for only certificate 1 and=20
> post that CRL to distribution points B and C.  Finally issue=20
> yet another CRL containing an entry for only certificate 10=20
> and post that CRL to distribution points D and E.
>=20
> Option a has the disadvantage of causing needless bloat to=20
> the CRLs posted on distribution points B, C, D, and E:  no=20
> one will look for revocation information about certificate 1=20
> on distribution point D or E, and, likewise, no one will look=20
> for revocation information about certificate 11 on=20
> distribution point B or C.  Option a does have the advantage=20
> of being far easier to implement, however.
>=20
> Option b has the disadvantage of being much more complex. =20
> And, each time the set of distribution points is modified,=20
> the complexity increases as does the time required to=20
> generate all of the CRLs which are required.  However, the=20
> advantage is that the CRLs that are posted to the=20
> distribution points contain only useful information.
>=20
> Are there other solutions?  Preferences?  Implementations? =20
> Guidelines?
>=20
>=20
> Tammy Green
> [e-mail]=20
> Software Engineer
> Novell, Inc.
>=20
>=20

--=_FFA6779B.0C6D663F
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff=20
style=3D"FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>The X.509 DAM has proved to be quite enlightening.&nbsp; As it turns =
out, I=20
was trying to address the two issues which you highlight as well as a =
third=20
issue:</DIV>
<DIV>&nbsp;</DIV>
<DIV>3) Limiting the scope of a CRL</DIV>
<DIV>&nbsp;</DIV>
<DIV>all at once using only those extensions defined in RFC 2459 (and the =
new=20
part1 draft).&nbsp; The crlScope and statusReferrals extensions provide =
exactly=20
what I need.</DIV>
<DIV>&nbsp;</DIV>
<DIV>What are the status of these extensions?&nbsp; Are they&nbsp;going to =
be=20
put into the&nbsp;new part1&nbsp;draft?</DIV>
<DIV>&nbsp;</DIV>
<DIV>And, if you could send me a copy of the restructured X.509 doc when =
it's=20
ready I'd be most appreciative.<BR></DIV>
<DIV>Thanks!</DIV>
<DIV>&nbsp;</DIV>
<DIV>Tammy Green</DIV>
<DIV><BR>&gt;&gt;&gt; Sharon Boeyen &lt;[e-mail]&gt; =
3/1/00=20
8:14:42 AM &gt;&gt;&gt;<BR>Need to separate these into two separate=20
issues:<BR><BR>1) Multiple name forms for the same CRL DP<BR>2) Changing =
the=20
value of a name form for a CRL DP<BR><BR>1 is accomodated in the CRL DP=20
extension itself. You can allow <BR>access to the same CRL via various=20
mechanisms through the<BR>DistributionPointName<BR>component of the=20
cRLDistributionPoints extension. The syntax for the<BR>fullName choice =
<BR>is=20
GeneralNames so more than one name form for the the same CRL DP can=20
be<BR>included.<BR>Note that the X.509 DAM contains an Annex on CRL =
generation=20
and processing<BR>(written <BR>by Santosh) that explains how these are =
used on=20
the processing side.<BR><BR>2 - This requirement (and some other related =
ones)=20
has been addressed in the<BR>X.509 DAM. The <BR>statusReferrals extension =
is a=20
new CRL extension that serves two purposes.<BR>One is to publish <BR>a =
"trusted=20
list" of CRLs to help relying parties find the CRLs of interest<BR>to them =
(in=20
case <BR>CRL DP is not included in a cert) and the other is to redirect =
a=20
relying<BR>party when following <BR>a pointer (e.g. a CRL DP extension in =
a=20
cert) that has been changed since<BR>the cert was issued. <BR>For details =
see=20
12.5.2.6 of the 509 DAM at:<BR><BR><A=20
href=3D"ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.d=
oc">ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc</=
A><BR><BR>If=20
you prefer to work from the draft restructured complete 509 document, =
let<BR>me=20
know and I'll <BR>send a copy to you. I expect to have this available on =
the web=20
as well<BR>shortly.&nbsp; <BR><BR>&gt; -----Original Message-----<BR>&gt; =
From:=20
Tammy Green [mailto:[e-mail]]<BR>&gt; Sent: Friday, February 25, =
2000=20
1:27 PM<BR>&gt; To: [e-mail]<BR>&gt; Subject: Re: What if the =
CRL=20
distribution points for a CA change?<BR>&gt; <BR>&gt; <BR>&gt; Some=20
clarification seems to be in order....<BR>&gt; <BR>&gt; The idea of =
having=20
multiple distribution points in a <BR>&gt; certificate seems very =
reasonable in=20
our context at Novell.&nbsp; <BR>&gt; For our PKI, it is quite convenient =
to=20
name at least two <BR>&gt; distribution points:&nbsp; one which is an =
X.500 name=20
and one <BR>&gt; which is an LDAP address.&nbsp; Since our PKI is =
integrated=20
with <BR>&gt; our directory (NDS), it is natural for us to prefer =
<BR>&gt;=20
retrieving the CRLs directly from NDS rather than using LDAP. <BR>&gt;&nbsp=
;=20
But, because there are applications out there that are not <BR>&gt; =
NDS-aware,=20
we'd like to include other distribution points <BR>&gt; which can be =
accessed=20
from outside of the company via HTTP or LDAP.&nbsp; <BR>&gt; <BR>&gt; As =
for=20
changing the distribution points, there are a couple <BR>&gt; of scenarios =
that=20
I can envision where they would be changed. <BR>&gt;&nbsp; How true-to-life=
=20
these scenarios are is something that I'm <BR>&gt; hoping to discover.<BR>&=
gt;=20
<BR>&gt; 1.&nbsp; The one externally-available distribution point (say =
it=20
<BR>&gt; is LDAP) currently listed in the certificates just doesn't =
<BR>&gt;=20
have enough bandwidth to accommodate all the queries.&nbsp; Or, <BR>&gt; =
the=20
software package that the CEO of the company is using <BR>&gt; can't use =
LDAP to=20
get CRLs ? it must use HTTP.&nbsp; The CA <BR>&gt; Administrator is forced =
to=20
add additional distribution points <BR>&gt; to accommodate other =
protocols=20
and/or unexpected traffic.<BR>&gt; <BR>&gt; 2.&nbsp; One of the distributio=
n=20
points is being phased out (for <BR>&gt; whatever reason).&nbsp; Maybe =
the=20
company no longer wants to <BR>&gt; support LDAP access to its directory.&n=
bsp;=20
Or maybe the company <BR>&gt; has made an agreement with another organizati=
on to=20
post its <BR>&gt; CRLs on their high-volume servers.<BR>&gt; <BR>&gt; =
3.&nbsp;=20
The CA in question issues a million certificates a year <BR>&gt; and =
expects=20
that half of all of those certificates will be <BR>&gt; revoked.&nbsp; The =
CRLs=20
for that CA would become quite large, and, <BR>&gt; after some calculations=
, the=20
CA Administrator decides that <BR>&gt; CRLs of that size are unacceptable.&=
nbsp;=20
He therefore decides to <BR>&gt; change the CRL distribution points =
every=20
year.&nbsp; So, <BR>&gt; basically, for those certificates issued in the =
first=20
year, <BR>&gt; their CRLs would be found on distribution points A and =
B.&nbsp;=20
<BR>&gt; For those certificates issued in the second year, their CRLs =
<BR>&gt;=20
would be found on distribution points C and D.&nbsp; If my option <BR>&gt; =
(b)=20
were used here, then the CRLs found on A, B, C, and D <BR>&gt; would =
contain a=20
maximum of 1 million certificates <BR>&gt; certificates each in the worst =
case=20
where all the <BR>&gt; certificates were revoked (CRL on A =3D CRL on B; =
CRL on C=20
=3D <BR>&gt; CRL on D; CRL on A !=3D CRL on C).&nbsp; [If option (a) were =
used=20
<BR>&gt; here, the CA Administrator would have a nasty surprise in =
<BR>&gt; that=20
the CRLs on A, B, C, and D would be exactly the same and <BR>&gt; contain =
2=20
million certificates in the worst case scenario.]<BR>&gt; <BR>&gt; =
<BR>&gt; Are=20
these scenarios something that you would find in the real <BR>&gt; =
world?&nbsp;=20
If so, then is it acceptable to make the CRLs on all <BR>&gt; distribution=
=20
points ever specified the same?&nbsp; Or, should they <BR>&gt; contain =
only the=20
minimum number of certificates?<BR>&gt; <BR>&gt; <BR>&gt; Tammy Green<BR>&g=
t;=20
[e-mail] <BR>&gt; Software Engineer<BR>&gt; Novell, Inc.<BR>&gt;=
=20
<BR>&gt; &gt;&gt;&gt; "Bob Jueneman" &lt;[e-mail]&gt; =
02/24/00=20
09:55PM &gt;&gt;&gt;<BR>&gt; Don't do that?<BR>&gt; <BR>&gt; I.e., =
:<BR>&gt;=20
<BR>&gt; 1.&nbsp; Don't issue certificates containing multiple distribution=
=20
points.<BR>&gt; <BR>&gt; 2.&nbsp; If issuing certificates with multiple=20
distribution points <BR>&gt; is absolutely necessary (for some reason I =
can't=20
quite <BR>&gt; fathom), don't change the distribution points unless you =
are=20
<BR>&gt; prepared to implement option b.<BR>&gt; <BR>&gt; If we restrict =
the=20
type of distribution points to LDAP <BR>&gt; queries, wouldn't it be =
possible to=20
remap the DNS name of the <BR>&gt; server as might be required for load=20
balancing, leaving the <BR>&gt; LDAP query itself unmodified?&nbsp; =
Doesn't this=20
eliminate the <BR>&gt; entire problem?<BR>&gt; <BR>&gt; Bob<BR>&gt; =
<BR>&gt;=20
<BR>&gt; <BR>&gt; &gt;&gt;&gt; Tammy Green 02/24/00 08:58PM &gt;&gt;&gt;<BR=
>&gt;=20
Say a CA begins minting certificates with distribution points <BR>&gt; A, =
B, and=20
C in the certificates.&nbsp; It issues 10 certificates.&nbsp; <BR>&gt; =
Then, at=20
time t1, it changes the distribution points to A, D, <BR>&gt; and E and =
issues=20
10 more certificates.<BR>&gt; <BR>&gt; Now say that at time t2 certificate =
1 was=20
revoked as well as <BR>&gt; certificate 11.&nbsp; What should the CA do =
when it=20
comes time to <BR>&gt; issue the CRL?&nbsp; [Assume here that the CA is =
only=20
issuing a <BR>&gt; basic CRL that is not subdivided by reason codes, =
etc.]&nbsp;=20
It <BR>&gt; appears that there are two options.<BR>&gt; <BR>&gt; (a)&nbsp; =
Issue=20
one CRL containing entries for certificate 1 and <BR>&gt; 11.&nbsp; Post =
that=20
CRL to distribution points A, B, C, D, and E.<BR>&gt; <BR>&gt; (b)&nbsp; =
Issue=20
one CRL containing entries for certificate 1 and <BR>&gt; 11 and post that =
CRL=20
to distribution point A.&nbsp; Then issue <BR>&gt; another CRL containing =
an=20
entry for only certificate 1 and <BR>&gt; post that CRL to distribution =
points B=20
and C.&nbsp; Finally issue <BR>&gt; yet another CRL containing an entry =
for only=20
certificate 10 <BR>&gt; and post that CRL to distribution points D and=20
E.<BR>&gt; <BR>&gt; Option a has the disadvantage of causing needless =
bloat to=20
<BR>&gt; the CRLs posted on distribution points B, C, D, and E:&nbsp; =
no=20
<BR>&gt; one will look for revocation information about certificate 1 =
<BR>&gt;=20
on distribution point D or E, and, likewise, no one will look <BR>&gt; =
for=20
revocation information about certificate 11 on <BR>&gt; distribution point =
B or=20
C.&nbsp; Option a does have the advantage <BR>&gt; of being far easier =
to=20
implement, however.<BR>&gt; <BR>&gt; Option b has the disadvantage of =
being much=20
more complex.&nbsp; <BR>&gt; And, each time the set of distribution points =
is=20
modified, <BR>&gt; the complexity increases as does the time required =
to=20
<BR>&gt; generate all of the CRLs which are required.&nbsp; However, =
the=20
<BR>&gt; advantage is that the CRLs that are posted to the <BR>&gt; =
distribution=20
points contain only useful information.<BR>&gt; <BR>&gt; Are there =
other=20
solutions?&nbsp; Preferences?&nbsp; Implementations?&nbsp; <BR>&gt;=20
Guidelines?<BR>&gt; <BR>&gt; <BR>&gt; Tammy Green<BR>&gt; [e-mail]=
=20
<BR>&gt; Software Engineer<BR>&gt; Novell, Inc.<BR>&gt; <BR>&gt;=20
<BR></DIV></BODY></HTML>

--=_FFA6779B.0C6D663F--


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07611 for <[e-mail]>; Wed, 1 Mar 2000 11:58:23 -0800 (PST)
Received: from mega (t1o69p101.telia.com [62.20.144.101]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id VAA28637; Wed, 1 Mar 2000 21:01:44 +0100
Message-ID: <000801bf83c0$5c5447d0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Robert Malick" <[e-mail]>, <[e-mail]>
Subject: Re: UI DN as certificate subject was RE: Straw Poll: SerialNumber definition
Date: Wed, 1 Mar 2000 20:54:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA07613

Robert, 
May I put my personal view on this matter. 
As far as I can see there is no real standard for how you utilize DNs. 
Some comments in line. 

-----Original Message-----
From: Robert Malick <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Tuesday, February 29, 2000 20:02
Subject: UI DN as certificate subject was RE: Straw Poll: SerialNumber definition

>
>It seems in the discussion of placing the uniquely identifiying DN in the
>SubjectAltName everyone is assuming that one needs something other than
>that as the certificate subject.
>
>Is it totally illegal or just not good practice for some reason to have a
>uniquely identifying DN as a certificate subject and have the application
>find other commentary attributes like displayable name (e.g., cn)
>by accessing the entry in the directory for that subject DN? 

Probably not illegal (I am not an X500 lawyer) but the practice seems to be to use 
subject DNs as placeholders for various subject-related data. That was my reason for 
adding an extension to aid the interpretation (if the RP wants that) of unmistakable 
identities as well as display data.

>For example,
>
>Certificate Subject: sn=0001000018, o=acme, c=us
>
>An application when looking up that DN in the directory will find:
>
>dn: sn=0001000018, o=acme, c=us
>cn: Joe Smith
>...

I have some comments to this. 

1. If the cert is going places outside of its original domain it seems less useful without 
the name of the subject as the CA may well be trusted but SN may not say that much (except 
working in conjunction with the other attributes as a perfect unmistakable identity) 

2. Commercial SW displaying certificates work better if they get a CN which seems 
to be the lowest common denominator.  IE 4.0 presents my Swedish ID-cert as
two vertical bars only (!!) while IE 5.0 says “Rundgren” but it should have said
"Anders Rundgren" which is my common name.  That is where you land if you
read the X50.9 standard too literally and forget about programs that can’t guess
that great.  Steve, are you listening? :-) :-)

3. Talking about unmistakable identities: If the anticipated CAs domain is US, I would 
say that C=US is redundant. But C is common practice regardless if it is required or not. 

>The application can display what it likes of this particular certificate
>identity. Most likely the application will access the directory for other
>things for certificate path processing so I don't see this as anything out
>of the ordinary.
> 

For local apps this works fine, for standard SW this is not too common. 

>Also, this allows one to assign identity without the overhead of
>revoking certificates if these commentary attributes should change (e.g.,
>cn).
>
>Can someone tell me why it seems that one should assume that commentary
>attributes must be in the subject DN of the certificate?

This is a sensitive issue. MY opinion is that X509.v3 is a smorgasbord of 
structures that looks like a real committee product. I.e. everybody tried to fit in 
their favorites.   As a true X500 heretic I believe that 
DNs will continue to be a place to stuff of different weight and use as other 
solutions require a change in practice.   New conventions as some propose
will just make things even worse!

Anders

> Robert Malick
> National Institutes of Health
>





Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06519 for <[e-mail]>; Wed, 1 Mar 2000 10:33:21 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <1TRVK75T>; Wed, 1 Mar 2000 13:32:58 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: New topic - selective retrieval of cross-certs
Date: Wed, 1 Mar 2000 13:32:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I'd like to initiate discussion on solutions to the following problem:

In a strict hierarchy, each cert has a single superior and 
identification and retrieval of the next cert to build a path 
(from the EE cert to the root) is straightforward through use 
of the AIA extension. However, in a distributed trust model, 
especially one using a 'bridge CA' or hub and spoke model, the selection 
of the next cert to build a path is not as straightforward. Some build from 
the EE to a trusted CA key, others build from the trusted CA key toward 
the root. Some build a path and then start validating the certs, others 
validate the certs as they are building the chain in order to do early 
pruning of the set of certs. All these are valid techniques and I'm trying
to look
at the scaling issues in all these environments. As the number of CA
certs issued to/by any given CA grows, it becomes infeasible for a verifier
to 
deal with the complete set of certs in a single basket, such as a single
directory 
attribute in its entirety with all values at once. For instance, if a bridge
CA has 
1,000 spokes, then its 'outbound' or reverse cross-certificates would take
on the order 
of one hour to download over a phone. Obviously this is unacceptable. 

A couple of options seem interesting.

If a directory is used as the repository, then the use of extended filters
in 
directory search operations may be useful. This would allow a relying party
to 
retrieve only a subset of the certificates in a directory attribute, based
on 
whatever criteria were interesting to the relying party (e.g. retrieve only
the 
certs that contain a given policy OID or only those that were issued within
a 
given name subtree etc.). Issues with this approach may be the complexity of

supporting the filters, matching rules and search operations themselves in
products.

An alternative to the directory filters would be be having 
the verifier use HTTP to retrieve just those certificates that meet its
requirements.
To do this effectively in path development/processing that is done from a
trusted 
CA key toward the EE cert, a new extension "subjectInfoAccess" similar to
the authorityInfoAccess
would be useful. The SIA would contain a URL that represented the set of
certificates issued
to CAs by the CA that is the subject of the certificate containing the SIA
extension. 
A verifier would perform an http 'get'on the URL contained in the
subjectInfoAccess 
extension of a certificate. The current values of the state variables in the
certification path 
processing algorithm would be included in the 'get' operation as parameters.
For instance, 
the current acceptable policies, name constraints, inhibit mapping
indicator, explicit policy 
indicator etc are included. Then a CGI on the target URL could return only
those outbound 
certificates from the full list that satisfy the requirements defined by
those parameters.

Similarly, if building the path from the EE toward a trusted CA key, the AIA
could contain a URL 
that represented a set of certificates (rather than a single one as in a
strict hierarchy) and 
the 'get' could contain a set of parameters to filter only certificates that
match the processing
parameters. 

As I said earlier, these techniques wouldn't be necessary in a single strict
hierarchy that 
isn't cross certified with any other PKIs, but in distributed trust models
(especially hub & spoke CAs) 
as well as in cross-certified hierarchies and mixed environments, they would
be useful.

I'm interested in hearing feedback on this http proposal as well as any
other ideas for 
filtering sets of certs to make path construction and validation efficient
in very large scale
environments. Are folks interested in pursuing http based mechanisms further
within PKIX? What, if 
anything, should PKIX do about this issue? Do people prefer the directory
filter approach, the http
approach, other?

Sharon 

Sharon Boeyen
Entrust Technologies
[e-mail]


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05986 for <[e-mail]>; Wed, 1 Mar 2000 10:09:21 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <F62561Y0>; Wed, 1 Mar 2000 13:02:41 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E58F744@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, [e-mail], [e-mail], pkix <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Wed, 1 Mar 2000 13:02:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

I been meaning to respond to Steve with exactly what Tim said.  The
parameters should not be inherited across algorithms and across
certificates.

-----Original Message-----
From: Tim Polk [mailto:[e-mail]]
Sent: Wednesday, March 01, 2000 12:20 PM
To: [e-mail]; [e-mail]; pkix
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00



John and Steve -

I believe that the algorithm has *two* bugs in it. However, I see different
bugs!

The path validation algorithm was not intended to permit algorithm
inheritance across an "algorithm gap".  We meant to support parameter
inheritance only when the subject and issuer share the same parameters!
So, the key in the certificate and the key used to sign would have to be
for the same algorithm.

I read through the Steve's scenario (with the 4 certificate chain) several
times. I don't think we should support this type of chain for a couple of
reasons.  If we don't have a hierarchy, this is a recipe for disaster.  If
another "top-ca" issues a certificate to the "mid-ca", it probably won't
have the right DSA parameters.  (It might not even sign with DSA!) So,
"mid-ca" is forced to include the parameters in the "low-ca" certificate if
they want it to be useful...

That means this is only useful in a strictly hierarchical PKI.  If we have
enough organizational control to implement a strict hierarchy, are we
likely to mix algorithms at different levels in the tree?

There is another possibility that is even worse - but it is only a
possibility 'cause I can barely spell crypto.  What if the top-ca rekeys
with new parameters?  It issues a new certificate to mid-ca with it's old
key in it.  What happens?  You use the wrong parameters to verify the
signature on the fourth certificate.

Could this lead to a vulnerability?  It seems somewhat analgous to the
parameter substitution attack Santosh described when you use parameters
that were not protected by the certificate signature!  While you can't make
the subsitution yourself, couldn't some combinations of keys and parameters
be unsafe???

It seems like permitting an algorithm gap is living on the edge - and I'm
getting too old for that!

I believe that the parameter inheritance needs to be re-worked so that
parameters are inherited only when the issuer and subject share the
parameters.  I believe that will require changes in both the body and
wrap-up procedure.  I would like to gain consensus on the list before I
rework it, though.

Thanks,

Tim


Received: from mot.ncsl.nist.gov (mot.ncsl.nist.gov [129.6.52.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05088 for <[e-mail]>; Wed, 1 Mar 2000 09:19:36 -0800 (PST)
Received: (uucp@localhost) by mot.ncsl.nist.gov (8.7.3/8.6.4) id MAA01389; Wed, 1 Mar 2000 12:44:56 -0500 (EST)
Received: from asynce017.nist.gov(129.6.31.17) by mot.ncsl.nist.gov via smap (3.2) id xma001387; Wed, 1 Mar 00 12:44:37 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Wed, 01 Mar 2000 12:19:53 -0500
To: <[e-mail]>, <[e-mail]>, pkix <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
In-Reply-To: <51BF55C30B4FD1118B4900207812701E58F737@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

John and Steve -

I believe that the algorithm has *two* bugs in it. However, I see different
bugs!

The path validation algorithm was not intended to permit algorithm
inheritance across an "algorithm gap".  We meant to support parameter
inheritance only when the subject and issuer share the same parameters!
So, the key in the certificate and the key used to sign would have to be
for the same algorithm.

I read through the Steve's scenario (with the 4 certificate chain) several
times. I don't think we should support this type of chain for a couple of
reasons.  If we don't have a hierarchy, this is a recipe for disaster.  If
another "top-ca" issues a certificate to the "mid-ca", it probably won't
have the right DSA parameters.  (It might not even sign with DSA!) So,
"mid-ca" is forced to include the parameters in the "low-ca" certificate if
they want it to be useful...

That means this is only useful in a strictly hierarchical PKI.  If we have
enough organizational control to implement a strict hierarchy, are we
likely to mix algorithms at different levels in the tree?

There is another possibility that is even worse - but it is only a
possibility 'cause I can barely spell crypto.  What if the top-ca rekeys
with new parameters?  It issues a new certificate to mid-ca with it's old
key in it.  What happens?  You use the wrong parameters to verify the
signature on the fourth certificate.

Could this lead to a vulnerability?  It seems somewhat analgous to the
parameter substitution attack Santosh described when you use parameters
that were not protected by the certificate signature!  While you can't make
the subsitution yourself, couldn't some combinations of keys and parameters
be unsafe???

It seems like permitting an algorithm gap is living on the edge - and I'm
getting too old for that!

I believe that the parameter inheritance needs to be re-worked so that
parameters are inherited only when the issuer and subject share the
parameters.  I believe that will require changes in both the body and
wrap-up procedure.  I would like to gain consensus on the list before I
rework it, though.

Thanks,

Tim



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03226 for <[e-mail]>; Wed, 1 Mar 2000 07:15:08 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <1TRVK5VM>; Wed, 1 Mar 2000 10:14:44 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Tammy Green'" <[e-mail]>, [e-mail]
Subject: RE: What if the CRL distribution points for a CA change?
Date: Wed, 1 Mar 2000 10:14:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-7"

Need to separate these into two separate issues:

1) Multiple name forms for the same CRL DP
2) Changing the value of a name form for a CRL DP

1 is accomodated in the CRL DP extension itself. You can allow 
access to the same CRL via various mechanisms through the
DistributionPointName
component of the cRLDistributionPoints extension. The syntax for the
fullName choice 
is GeneralNames so more than one name form for the the same CRL DP can be
included.
Note that the X.509 DAM contains an Annex on CRL generation and processing
(written 
by Santosh) that explains how these are used on the processing side.

2 - This requirement (and some other related ones) has been addressed in the
X.509 DAM. The 
statusReferrals extension is a new CRL extension that serves two purposes.
One is to publish 
a "trusted list" of CRLs to help relying parties find the CRLs of interest
to them (in case 
CRL DP is not included in a cert) and the other is to redirect a relying
party when following 
a pointer (e.g. a CRL DP extension in a cert) that has been changed since
the cert was issued. 
For details see 12.5.2.6 of the 509 DAM at:

ftp://ftp.bull.com/pub/OSIdirectory/Copenhagen99Output/CertExtDAM.doc

If you prefer to work from the draft restructured complete 509 document, let
me know and I'll 
send a copy to you. I expect to have this available on the web as well
shortly.  

> -----Original Message-----
> From: Tammy Green [mailto:[e-mail]]
> Sent: Friday, February 25, 2000 1:27 PM
> To: [e-mail]
> Subject: Re: What if the CRL distribution points for a CA change?
> 
> 
> Some clarification seems to be in order....
> 
> The idea of having multiple distribution points in a 
> certificate seems very reasonable in our context at Novell.  
> For our PKI, it is quite convenient to name at least two 
> distribution points:  one which is an X.500 name and one 
> which is an LDAP address.  Since our PKI is integrated with 
> our directory (NDS), it is natural for us to prefer 
> retrieving the CRLs directly from NDS rather than using LDAP. 
>  But, because there are applications out there that are not 
> NDS-aware, we'd like to include other distribution points 
> which can be accessed from outside of the company via HTTP or LDAP.  
> 
> As for changing the distribution points, there are a couple 
> of scenarios that I can envision where they would be changed. 
>  How true-to-life these scenarios are is something that I'm 
> hoping to discover.
> 
> 1.  The one externally-available distribution point (say it 
> is LDAP) currently listed in the certificates just doesn't 
> have enough bandwidth to accommodate all the queries.  Or, 
> the software package that the CEO of the company is using 
> can't use LDAP to get CRLs ? it must use HTTP.  The CA 
> Administrator is forced to add additional distribution points 
> to accommodate other protocols and/or unexpected traffic.
> 
> 2.  One of the distribution points is being phased out (for 
> whatever reason).  Maybe the company no longer wants to 
> support LDAP access to its directory.  Or maybe the company 
> has made an agreement with another organization to post its 
> CRLs on their high-volume servers.
> 
> 3.  The CA in question issues a million certificates a year 
> and expects that half of all of those certificates will be 
> revoked.  The CRLs for that CA would become quite large, and, 
> after some calculations, the CA Administrator decides that 
> CRLs of that size are unacceptable.  He therefore decides to 
> change the CRL distribution points every year.  So, 
> basically, for those certificates issued in the first year, 
> their CRLs would be found on distribution points A and B.  
> For those certificates issued in the second year, their CRLs 
> would be found on distribution points C and D.  If my option 
> (b) were used here, then the CRLs found on A, B, C, and D 
> would contain a maximum of 1 million certificates 
> certificates each in the worst case where all the 
> certificates were revoked (CRL on A = CRL on B; CRL on C = 
> CRL on D; CRL on A != CRL on C).  [If option (a) were used 
> here, the CA Administrator would have a nasty surprise in 
> that the CRLs on A, B, C, and D would be exactly the same and 
> contain 2 million certificates in the worst case scenario.]
> 
> 
> Are these scenarios something that you would find in the real 
> world?  If so, then is it acceptable to make the CRLs on all 
> distribution points ever specified the same?  Or, should they 
> contain only the minimum number of certificates?
> 
> 
> Tammy Green
> [e-mail] 
> Software Engineer
> Novell, Inc.
> 
> >>> "Bob Jueneman" <[e-mail]> 02/24/00 09:55PM >>>
> Don't do that?
> 
> I.e., :
> 
> 1.  Don't issue certificates containing multiple distribution points.
> 
> 2.  If issuing certificates with multiple distribution points 
> is absolutely necessary (for some reason I can't quite 
> fathom), don't change the distribution points unless you are 
> prepared to implement option b.
> 
> If we restrict the type of distribution points to LDAP 
> queries, wouldn't it be possible to remap the DNS name of the 
> server as might be required for load balancing, leaving the 
> LDAP query itself unmodified?  Doesn't this eliminate the 
> entire problem?
> 
> Bob
> 
> 
> 
> >>> Tammy Green 02/24/00 08:58PM >>>
> Say a CA begins minting certificates with distribution points 
> A, B, and C in the certificates.  It issues 10 certificates.  
> Then, at time t1, it changes the distribution points to A, D, 
> and E and issues 10 more certificates.
> 
> Now say that at time t2 certificate 1 was revoked as well as 
> certificate 11.  What should the CA do when it comes time to 
> issue the CRL?  [Assume here that the CA is only issuing a 
> basic CRL that is not subdivided by reason codes, etc.]  It 
> appears that there are two options.
> 
> (a)  Issue one CRL containing entries for certificate 1 and 
> 11.  Post that CRL to distribution points A, B, C, D, and E.
> 
> (b)  Issue one CRL containing entries for certificate 1 and 
> 11 and post that CRL to distribution point A.  Then issue 
> another CRL containing an entry for only certificate 1 and 
> post that CRL to distribution points B and C.  Finally issue 
> yet another CRL containing an entry for only certificate 10 
> and post that CRL to distribution points D and E.
> 
> Option a has the disadvantage of causing needless bloat to 
> the CRLs posted on distribution points B, C, D, and E:  no 
> one will look for revocation information about certificate 1 
> on distribution point D or E, and, likewise, no one will look 
> for revocation information about certificate 11 on 
> distribution point B or C.  Option a does have the advantage 
> of being far easier to implement, however.
> 
> Option b has the disadvantage of being much more complex.  
> And, each time the set of distribution points is modified, 
> the complexity increases as does the time required to 
> generate all of the CRLs which are required.  However, the 
> advantage is that the CRLs that are posted to the 
> distribution points contain only useful information.
> 
> Are there other solutions?  Preferences?  Implementations?  
> Guidelines?
> 
> 
> Tammy Green
> [e-mail] 
> Software Engineer
> Novell, Inc.
> 
> 


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20020 for <[e-mail]>; Wed, 1 Mar 2000 02:34:57 -0800 (PST)
Received: by balinese.baltimore.ie; id KAA25485; Wed, 1 Mar 2000 10:34:46 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma025449; Wed, 1 Mar 00 10:34:31 GMT
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA13819; Wed, 1 Mar 2000 10:34:26 GMT
Message-ID: <[e-mail]>
Date: Wed, 01 Mar 2000 10:34:26 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'Pawling, John'" <[e-mail]>, pkix <[e-mail]>, xme <[e-mail]>
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00
References: <51BF55C30B4FD1118B4900207812701E58F737@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Santosh Chokhani wrote:
> Please note that there is no such thing as parameters in the RSA.  

That's entirely correct from an arithmetic point of view. However,
there is a parameter in the ASN.1 representation, which (using the
PKCS OIDS) always has the same value - the encoding of an ASN.1 
NULL (i.e. the two bytes '0500'H). Hence the discussion of RSA
parameters. 

BTW: I've no idea why this was put in - maybe someone misunderstand
ASN.1 OPTIONAL way back then. Or something else?

In any case, if you replace "RSA", with "ECDSA", in the
previous mails in the thread, you get the same effect, so its
not entirely nit-picking.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com